I opened an issue directly on HA Github, since it looks like is related to the Energy feature. Let’s see what do they say about it.
did you check HA logs for errors?
Yes, one of the first thing I did… I’m not new to this, since developing and debugging is what I do for living…
Did you also check the statistics tab in dev tools?
I found the issue, it wasn’t added in the recorder. Don’t know why, probably I didn’t fully reboot HA once I add it to the recorder. Now it is shown. I keep forgetting that in order to have statistics (and then energy) it should also be added to the recorder.
damn it! I always forget this: we already had this issue with a user. I think it was discussed here, or on the GH repo. I’m sorry I didn’t remember it when you wrote me.
Thanks for the feedback.
Alex,
sorry if I’m bothering you again, I have a question: your component logs an error if the inverter is unreachable, like during the night when is turned off. This is correct, but it bothers me a bit to see all of that errors in the logs. I was wondering if you have any suggestion on how to solve this situation.
I tried to disable the automatic polling in your integration
to see if I can then use an automation with the home_assistant.update_entity service to update the Inverter data based on other condition (like if the inverter is reachable via ping).
But that didn’t worked since even if I disable the automatic polling, your integration will keep polling the inverter for data.
I thought on setting the highest polling value, but that would only reduce the amount of error in the logs.
Do you have any suggestion on this?
Thanks
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’ll let you know if I will test this automation.
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.
Thanks Alex
Currently using ping, and seems working fine. I’ll test also the luminosity sensor I have in the meteo station.
Thanks again
Claudio
@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.
binary_sensor:
- platform: ping
name: "ABB VSN300 Status"
host: "abb-vsn300.axel.dom"
count: 3
scan_interval: 10
- 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?
You’re right, I corrected it.
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.
I wonder if that is only possible through LAN connection and not VLAN and if I need first use a USB-RJ45 adapter to connect to the inverter locally?
Sorry again if it sounds too obvious the answer.
You have to follow the instructions in the repo.
- Install the component through HACS and restart HA
- Go to integrations, and add the ABB Sunspec integration, at that point the configuration screen will come up.
LAN/VLAN doesn’t matter, as long as there’s connectivity between HA and the IP of the inverter.
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?
I use HA Core. Here is my log:
2023-04-15 12:33:55.185 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] Setup abb_powerone_pvi_sunspec.Wechselrichter
2023-04-15 12:33:55.279 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_inv) Slave ID: 1
2023-04-15 12:33:55.280 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_inv) Base Address: 0
2023-04-15 12:33:55.280 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_inv) Manufacturer: Power-One
2023-04-15 12:33:55.280 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_inv) Model: -3M08-
2023-04-15 12:33:55.280 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_inv) Options: G
2023-04-15 12:33:55.280 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (opt_printable) opt_model: G - opt_model_int: 71
2023-04-15 12:33:55.280 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (opt_comm_model) comm_model: UNO-2.5-OUTD
2023-04-15 12:33:55.280 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_inv) Version: C073
2023-04-15 12:33:55.280 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_inv) Sernum: 128915-3M08-4716
2023-04-15 12:33:55.288 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_1) Slave ID: 1
2023-04-15 12:33:55.289 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_1) Base Address: 0
2023-04-15 12:33:55.289 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_1) Inverter Type (int): 101
2023-04-15 12:33:55.289 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_1) Inverter Type (str): Single Phase
2023-04-15 12:33:55.289 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_1) Total Energy Value Read: 18093416
2023-04-15 12:33:55.289 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_1) Total Energy Previous Value: 1
2023-04-15 12:33:55.322 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_2) Slave ID: 1
2023-04-15 12:33:55.322 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_2) Base Address: 0
2023-04-15 12:33:55.322 ERROR (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_2) Reading data failed! Please check Slave ID: 1
2023-04-15 12:33:55.323 ERROR (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_2) Reading data failed! Please check Reg. Base Address: 0
2023-04-15 12:33:55.325 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec.sensor] (sensor) Model: UNO-2.5-OUTD
2023-04-15 12:33:55.325 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec.sensor] (sensor) Manufacturer: Power-One
2023-04-15 12:33:55.325 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec.sensor] (sensor) SW Version: C073
2023-04-15 12:33:55.325 DEBUG (MainThread) [custom_components.abb_powerone_pvi_sunspec.sensor] (sensor) Inverter Type (str): Single Phase
2023-04-15 12:34:55.561 ERROR (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_2) Reading data failed! Please check Slave ID: 1
2023-04-15 12:34:55.563 ERROR (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_2) Reading data failed! Please check Reg. Base Address: 0
2023-04-15 12:35:06.170 ERROR (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_2) Reading data failed! Please check Slave ID: 1
2023-04-15 12:35:06.172 ERROR (MainThread) [custom_components.abb_powerone_pvi_sunspec] (read_rt_2) Reading data failed! Please check Reg. Base Address: 0
I thought it was a bug because the installation guide says it’s usually slave id 2 or 247.
Thank you for your fast reply.