I already discussed this problem and that possible workaround with @Claudio1L in this issue, but it didn’t work.
The only thing to do is actually disabling the integration and re-enable it via an automation. Right now I’m only doing the latter (enabling it at sunrise) through homeassistant.reload_config_entry.
Unfortunately HA doesn’t provide services to disable/enable an integration, but lately @frenck created Spook and it provides a service to enable/disable an integration.
This is the only way to solve your problem, but I didn’t test it yet, if you do it please let us have a feedback so maybe we can describe it in the documentation.
@MatteGary@Claudio1L I finally found some time to update my existing automation, that ensured the integration was running in the morning in case it got disabled during the night because of a restart of HA or excessive number of polling/timeouts.
Like I was saying, I used Spook new services to enable the integration in the morning and disable it in the evening. In order to do this, I used as a main trigger the luminosity sensor of my weather station, but you can use the sun integration for sunrise/sunset triggers or you can use time schedules, as you prefer.
In the automation, I basically wait for enough light in the morning as trigger, and I also check if one of the entities of the integration is in the unavailable state, if both conditions are met, I use Spook service to enable the integration.
In the evening I do the reverse: the trigger is when the external luminosity goes below 1 for 5 minutes, I check if the AC Power sensor is below 1, then I use Spook service to disable the integration.
I’ll test it in the following days…here’s the code of the automation (the config_entry_id value is picked up by the automation wizard when picking the integration from the listbox, you’ll need to pick yours obviously):
alias: Manage operation state of ABB Custom Component
description: >-
Ensure ABB Component is running in the morning and disable it at sunset to
avoid filling log with errors
trigger:
- platform: numeric_state
entity_id: sensor.tempest_luminosita
above: 1000
for:
hours: 0
minutes: 5
seconds: 0
alias: Luminosity Sunrise
id: luminosity_sunrise
- platform: numeric_state
entity_id: sensor.tempest_luminosita
for:
hours: 0
minutes: 5
seconds: 0
value_template: ""
below: 1
alias: Luminosity Sunset
id: luminosity_sunset
condition: []
action:
- if:
- condition: and
conditions:
- condition: trigger
id: luminosity_sunrise
- condition: state
entity_id: sensor.abb_vsn300_operating_state
state: unavailable
for:
hours: 0
minutes: 0
seconds: 10
then:
- service: homeassistant.enable_config_entry
data:
config_entry_id: 669ea7e7feb9b859d9b42bdf729aa64b
else:
- if:
- condition: trigger
id: luminosity_sunset
- condition: numeric_state
entity_id: sensor.abb_vsn300_ac_power
below: 1
then:
- service: homeassistant.disable_config_entry
data:
config_entry_id: 669ea7e7feb9b859d9b42bdf729aa64b
mode: single
Hi Alex,
I will wait form your feedback to see if the Spock service can be a solution.
For the automation part, I was thinking on using the Ping platform to ping the ip address of the Inverter, and using the automation to turn on or off the integration based on the Ping result.
In this way I should be quite sure to be able to follow the status of the inverter with the status of the integration. The only downside the I see is that the integration might get disabled during the day in case of poor Wi-Fi connection. I can tune the automation to wait the ping binary_sensor to stay on or off for a while, trying to avoid false negatives.
I’ve used the ping platform in the past for automations, but it’s not reliable in my experience, had many “false alarms”, and I’ve learned the lesson. So I personally prefer a more robust event for triggers, but you can use whatever you feel is working in your case.
@Claudio1L@MatteGary I tested it for some days and it seems to be reliable both in enabling in the morning and disabling when the inverter goes off. I’ll leave some instructions if some user in the future wants to do it:
Create a binary ping sensor that checks the VSNx00: it will go on/off based on the network state of the card.
Create an automation with two triggers, based on the state of the binary sensor created in step 1. To avoid false triggers, the automation expects the ping sensor state changes to last for 20s. When creating the automation, you will notice that there are config_entry entities with some long values, those are the IDs of the entities for my specific installation. You will need to pick yours when you edit the automation via UI. For the enable/disable service (spook), you need to choose the ABB integration, for the reload (needed after re-enabling it) you need to choose one of the sensors of the integration.
alias: Manage operation state of ABB Custom Component
description: >-
Ensure ABB Component is running in the morning and disable it at sunset to
avoid filling log with errors
trigger:
- platform: state
id: trigger_abb_vsn300_connected
entity_id:
- binary_sensor.abb_vsn300_status
from: "off"
to: "on"
for:
hours: 0
minutes: 0
seconds: 20
- platform: state
id: trigger_abb_vsn300_disconnected
entity_id:
- binary_sensor.abb_vsn300_status
from: "on"
to: "off"
for:
hours: 0
minutes: 0
seconds: 20
condition: []
action:
- choose:
- conditions:
- condition: trigger
id: trigger_abb_vsn300_connected
sequence:
- service: homeassistant.enable_config_entry
data:
config_entry_id: 669ea7e7feb9b859d9b42bdf729aa64b
- service: homeassistant.reload_config_entry
data: {}
target:
device_id: ab0bea32218dfd580d560e46fc85c722
- conditions:
- condition: trigger
id: trigger_abb_vsn300_disconnected
sequence:
- service: homeassistant.disable_config_entry
data:
config_entry_id: 669ea7e7feb9b859d9b42bdf729aa64b
mode: single
Hi Alex,
I was monitoring the ping values, and looks consistent to me in my setup, so I’m going to try the automation.
There’s only one thing I don’t get in your automation:
You have the scan_interval of the ping sensor set to 30s, and your automation is triggered when the values stays on (or off) for at least 20s.
But it looks to me that in case of a false positive (or negative) the automation will trigger anyway, only 20s later, without waiting for the next ping update.
Don’t you should have a scan_interval of maximum 10s?
First of all, let me apologize if I am sounding like a newbie. Now, I am trying to understand if my ABB PV (version and more below) is compatible with this integration.
I am seeing that after the installation in HA, you have in the configuration a network configuration. I can connect to my ABB via web browser but that picture it will never appear to me after I click CONFIGURE on the integration.
Hello Alex!
I have an VSN300 and the integration works… once.
It shows all the data but only refreshes it when I reload the integration or restart hass.
I tried diffrent polling periods (2,5,10,60 secs) but it didn’t work.
Also it doesn’t work for me with the slave id 2 or 247 but with 1 it works.
It means there’s something wrong with your setup. Never heard of this problem in the past, it works for many people. Did you check the log for errors? What platform do you use for HA?
That’s why the integration is configurable: if your inverter is on slave id 1, you need to configure 1, it’s an address for the modbus requests. Why did you find it strange?
As you can see, there is a problem communicating with the VSN300/inverter. Reads are failing. Are you using other integrations/apps accessing the VSN300 maybe? You need to use only one.
Usually means that from what we observed here in this thread, many have Slave ID 247 others have 2. It depends on the configuration of the inverter that the installer made.
The integration does its first read correctly, and on the second it fails to communicate with the VSN300. It’s clear from the logs. Is the wifi connection of the VSN300 stable? I don’t know how to help if the modbus component can’t connect to the VSN300, it’s a blocking issue that you have to debug locally. The integration has been tested for a long time and it doesn’t have major issues like this.
And don’t go lower than 30s for the polling period, keep in mind that the VSN300 polls the inverter in 60s cycles, so you won’t improve anything going lower.
@monkeypr00f Federico, I introduced basic authentication for the VSN700 in my vsn monitor python program. Can you please test it for me and report the output? I suspect the JSON response structure is different among VSN300 & VSN700, but I need to have the full output to compare the two structures.
Please download the files and configure the .cfg by specifying the hostname, the vsn model, and user/pw before running it. The model in the cfg is needed so the program uses basic auth for it, if VSN300 is configured X-Digest auth scheme is used.
If this works for the VSN700, I just need to parse the JSON structure and I can modify the custom component to drop modbus and use REST/JSON to get data from the inverter. I hope the structures of the two are not so different.
HI Alex, i’ve recently added ABB integration and is awesom. Thanks a lot for your great job!
I’ve just created the binary sensor and the automation but in your example you say “for ther reloard (needed after re-enabling it) you need to choose one of the sensors of the integration” but the yaml code show a device
