randomic HA response delay with ABB Integration #61
Comments
Sorry, cannot reproduce here, I have no delays whatsoever on my lights/switches or anything else. Even if the automation tries to reach the inverter, it doesn't block other devices, this would be a severe limitation of HA, but since I know it's all async calls, that is not an issue. BTW: when the inverter is off, you should see an error in the logs saying that the integration can't reach the inverter, and only one time, not every Xs (polling period). Can you check please? |
|
The automation for the workaround already reloaded the config, so I need to check tomorrow night. I'm 99% sure it retry multiple times, not every 10 sec btw, but I let you know tomorrow. Thanks |
|
The only periodic connection is governed by the polling period. There's no other timer. In any case, a tentative TCP connection to a host should not impact anything: if it does, you have other major issues with your setup. All these tasks are asynchronous and non blocking, that's the HA architecture that is based on python. In any case, if you think that's what's happening to you, please provide the full HA log that shows the multiple recurring connections with the timeout error of the component. From the timestamps and the specific error we can try to understand what is going on. Take also in consideration that the component is being used by many users, and you're the only one reporting this, and I'm not able to reproduce it here. |
|
ok, confirmed the multiple retries. I switched off the AP connecting the inverter, and tried to see. As you can see, there are 18 occurence in less than 3 minutes, about one every 10 seconds. Of course the issue started as soon as Inverter disconnected. I'm also available to show you via webex what's happening.
|
|
Does it stop after X retries or it goes on forever? It should go disabled after some retries. Also, like I told you, 10s is the polling period you configured. I would not advise polling so frequently, I have mine set to 30s. In any case, the retry shouldn't impact anything on your HA, I'm not able to reproduce your slow response on other device. A TCP connection attempt every 10s shouldn't impact anything. |
|
Tonight will see if stops after some retries and let you know. Anyway I agree with you, it shouldn't impact, but that's it. Eventually tomorrow I'll try to deploy the integration on a different instance exporting the entities on the main one, leveraging Remote Home-Assistant integration, to see if the problem will move to the new instance or if it's a local issue |
|
Even if I implemented some sort of auto-disable after X retries, you would need an automation in the morning to wake it up. I actually have an automation that wakes up the integration in the morning because if I restart HA during the evening, and the inverter is off, the integration goes in disabled state and in the morning it didn't autorestart. So in the morning at sunrise the automation triggers and wakes up the integration. Do you use a Raspberry for HA? |
|
yes, similar to what I did as workaround to the delay issue. An automation that simply reload the integration after the sunrise and after the sunset, when the ping sensor goes on or off. But only as workaround for the delay, because otherwise leaving the integration always active, automatically works when the inverter wake up. To be honest I don't know if the issue I'm having has been there from day 1, I can only say that around one month ago I noticed those random delays and has been difficult to understand the root cause, at least if was an integration issue or wifi issue or other things. Anyway I'm running a VM on esxi mini PC, and I'm spinning up a container on a different synology Nas to see if reproducible also there. |
Unfortunately that's not the case. I created my automation because if during the evening, when inverter is off, I restarted HA, the integration would go disabled. So now at sunrise I wake it up through an automation.
I started with HA on a Raspberry many years ago, and after 2 months I started having weird issues and lost lots of hours trying to understand the root cause, in the end, I found it: it was the RPi, too slow for a full HA with many devices. :) I then started building my homelab with two mini servers and Proxmox, and everything was good from then, I don't use supervised, I use HA Core in a docker environment on a Proxmox LXC. Never had issues since then. Anyway...trust me, a TCP connection can't cause a severe impact on other devices, unless you have a fundamental underlying problem.
A NAS is not the ideal platform either, usually they don't have a good CPU, unless you have a high-end NAS obviously. Intel NUCs (even old ones, with an i3) are perfect for HA, if you want a dedicated device. If you want to virtualize, you need a decent server. |
|
ok, let me do some more troubleshooting. I want to capture the traffic during the issue, to see if for some reasons there are broadcast storms generated somewere or something like that. VM cpu stay at 2-3% average and the memory is 30% busy, so it should not be a lack of resources. Let me see |
|
tested with wireshark if something happen on the network after the switch off and seems fine. Captured a video to show you what I mean when there is the issue. You can see that sometime initially the light stop to answer. After reloading the integration, the entities disapper because the inverter is switched off and the issue does't happen anymore. I'm sending the video privately. from the log I see first a single message EDIT: sorry, looking at the timestamp it is the last captured. Possibly the first after the config reload ?
Then a continous polling every 10 seconds, till the integration reload, then it stops.
|
|
Claudio, can you please set a polling period of 30s and tell me tomorrow if it improved your light issue. The only thing the integration does is trying to open a TCP connection and then it fails, then retries after the polling period. This cannot have an impact on a light switch, if it does, it means your system is not able to manage things properly. I could understand if the integration was trying to open 120 TCP connections per second, but we're talking about a TCP tentative connection every 10s. :) I think there's an underlying issue and that you think the integration has a bug or something that causes your system to be "stressed" in some way, but that is not the case. Setting the polling period to 30s will alleviate things a tiny bit...but I don't think the integration is the problem. BTW: you should also monitor system resources closely...CPU/RAM/Network while it's working and while it's not and try to understand what is going on at system level. And also, did you take a look at the HA log to see if there are any warnings/errors, apart the integration timeout when inverter is off? |
|
I'm spinning up another instance, disabling the main one, to see if can be reproduced on a fresh install. Another strange thing arise. Did the following: spinning up the new vm (with ip x.x.x.253/24) and installed the integration (no config yet). Disabled integration in the main instance (has ip x.x.x.254/24) and configured the integration on the new instance. Config went fine but no entities are detected. Tried some reboots, shut of the main instance but nothing. He started to detect entities on the new VM when I changed his ip address to .254, the one from the main instance (shutted down in the meantime). Is it possible that the inverter has a cached ip of the modbus client? Moving back to 253 lose entities again. No idea.. |
|
btw, polling 30s move the issue every 30 sec, so I understand what you are saying but there is a correlation for sure. Perhaps not related to the tcp session, instead related to some conflict with another process? don't know. In the past I had an issue for the modbus version conflicting with the solax integration. I'm going to reproduce it disabling solax to see if something change. |
|
Failed also disabling solax. Last try is definitively the new VM. Later will try it changing the ip |
|
after a quick test, it seems working fine on the new vm. Later will do some more tests and will try to troubleshoot what is conflicting on the main instance |
|
Was thinking to the alternative to use a container I'm running for test on the nas just for the abb integration. It would be useful to understand if the modbus client IP is cached and possibly tomorrow morning, when the inverter power on, can use a different IP from the container. |
|
What do you mean by caching? Modbus TCP client is a library function, it does not have an IP. It uses the IP of the host where it's running. |
|
Maybe I found a possible solution for you: disable "polling for updates". Go to integrations page, select the 3 dots, and select System Options.
Disable Polling for Updates:
This function is described here: https://www.home-assistant.io/blog/2021/06/02/release-20216/#disable-polling-updates-on-any-integration What happens is that HA will disable the automatic polling. I disabled it last night, then my automation this morning waked up the integration as usual, and then the integration is doing the polling as usual, but HA won't do it on its own. Maybe it could work for you...let me know. This is the automation to ensure the integration is running in the morning, no matter the state (due to HA restarts in the evening, etc.), the trigger is alias: Keep ABB integration running
description: Check if ABB integration is unavailable
trigger:
- platform: sun
event: sunrise
offset: "15"
condition:
- condition: state
entity_id: sensor.abb_vsn300_vendor_operating_state
state: unavailable
for:
hours: 0
minutes: 1
seconds: 0
action:
- service: homeassistant.reload_config_entry
data: {}
target:
entity_id: sensor.abb_vsn300_vendor_operating_state
mode: single |
I mean, I'm seeing that if I move the integration on another HA istance, it works only if I move the IP address also, otherwise the integration installation works, but no entities are created. Looks like the HA IP address is cached in some way. It should not an Arp issue because I can ping from the new HA instance, so ARP/Mac table of the inverter are updated. |
Just configured. Let you know soon. Thanks |
I don't know how you're migrating HA. But I changed server a couple of times since I use HA, with different IPs, and I never had any issue. If you install HA as a test instance on a new server, why shouldn't the integration work there? It's the same thing. I don't know how you're migrating things...maybe it's not che correct procedure. You are also on supervised, which adds a layer of complexity. |
|
I can't show you because the inverter switched off, Tomorrow I'll send you the screenshot of what I mean. Basically I do what I did in the main installation. Install the integration in a fresh ha istance, with a different IP from the main one of course, the integration installs fine but entities are not discovered. If I move the ip address from the main instance to the new one entities immediately appear. It's like if the inverter expect to talk with the ip from the main instance only :-) . Anyway I want to try with a different IP when the inverter switch on in the morning. Perhaps is a sort of caching of the first host contacting the inverter?. I don't know. All the strange things to me :-) |
I have 2 HA installations on 2 different servers, the second is a test bed, and the integration runs perfectly on both of them. The inverter does not have any caching functionality. It uses a modbus tcp server that answers to queries, and it doesn't care of the source ip, it's pretty stupid as a protocol. Do you have the VSN300/VSN700 addon card? Or did you find it integrated in the inverter?
Yes, I can confirm what you're saying. :) |
no way, also disabling "polling for update" same issue. and the retries increase |
|
Do you have the VSN300/VSN700 addon card? Or did you find it integrated in the inverter? Integrated |
|
anyway, tomorrow morning want to try a first contact with the new instance with different IP to see what happen |
on the new instance, if you have the problem that it doesn't create the entities, you should check HA log for errors. |
I'll do it |
|
Also, make sure the other instance of the ABB integration is not running. Otherwise you'll add another "strange issue". :) |
yes. I disable it now so avoid to forget tomorrow |
|
quick update. today I spun up a container on the Nas with only the abb integration and a single shelly switch to test the delay issue.
Better than yersterday, with some reasonable results. At this point, will leave the integration running on the container instance, exposing the entities to the main one with the remote HA integration. Is working fine because I can expose the entities with exactly the same name, not losing statistics |
|
Thanks a lot for the patient, of course :-) |
|
No problem, glad to have confirmation that it's not the integration. |
|
@alexdelprete I'm getting this too, only at night after the inverters shut off. It's causing my Home Assistant install to be very slow and have random delays. If I disable the integration the delays go away. Also, during the day while the inverters are online, there are no delays. I have added an automation to disable the integration after sunset and enable after sunrise for now. Additionally there appears to be a bug when the inverter comes online where it might return 0, causing the Home Assistant Energy component to register 65k kWh because it's doing a diff of readings. I believe I submitted a PR for this fix before the refactor. I can take a look again to see where this might be happening. We should not return a value if the inverter is not online properly. |
try:
hub = ABBPowerOnePVISunSpecHub(hass, name, host, port, slave_id, base_addr)
coordinator = HubDataUpdateCoordinator(hass, hub=hub, entry=entry)
await coordinator.async_config_entry_first_refresh()
except ConnectionException as connerr:
raise ConfigEntryNotReady(f"Problem connecting to device {host}:{port} - Exception: {connerr}") from connerr
|
|
I had wrote a wrapper to save the state into a template sensor, perhaps that is adding some issues. I've just removed it and am using the entity directly now. Let me see in a few days if the issue goes away. For now my automation on sunrise/sunset seems to alleviate things. Thanks for ensuring the old PR was considered! Will keep you posted. |
|
I moved the ABB integration to a separated container HA instance, running only that integration, and then exposing the entities to the main HA instance leveraging https://github.com/custom-components/remote_homeassistant
In this way, the main HA is not slowed down and counters are not corrupted by the integration disabling
From: Bryan York ***@***.***>
Date: Wednesday, 13 September 2023 at 08:35
To: alexdelprete/ha-abb-powerone-pvi-sunspec ***@***.***>
Cc: Claudio1L ***@***.***>, Author ***@***.***>
Subject: Re: [alexdelprete/ha-abb-powerone-pvi-sunspec] randomic HA response delay with ABB Integration (Issue #61)
I had wrote a wrapper to save the state into a template sensor, perhaps that is adding some issues. I've just removed it and am using the entity directly now. Let me see in a few days if the issue goes away. For now my automation on sunrise/sunset seems to alleviate things.
Thanks for ensuring the old PR was considered! Will keep you posted.
—
Reply to this email directly, view it on GitHub<#61 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXK6MPWK5CEXKKQGL3JAIWLX2FH4LANCNFSM6AAAAAAVQX624E>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
So, an integration in an instance slows it down and in another instance it doesn't? Weird. I would point to other issues in the instance that slows down. Counters corrupted? Never seen anything like that. You can disable an integration at runtime and that won't cause any corruption, it's a message/transaction based architecture. Anyway...last beta version is under test, and it solves the retry/log spamming issue finally. I will monitor it for a couple of days then release a new stable version so there will be no need to disable the integration when the inverter is off. BTW: the solution was to let HA manage the retry automatically in background, so it does the exact same thing, but it doesn't write errors to the log except for the first couple of retries. |
|
@bryanyork @Claudio1L please test beta.5. I'm testing it since 24h without disabling the integration or any external automation. The solution was to test if Modbus TCP was available at socket level before trying the modbus connect (pymodbus call). This avoids all the errors etc. The retry mechanism is managed by HA itself, and the integration will be online automatically as soon as the TCP port is available (inverter on) and the Modbus TCP connect is processed correctly. |
|
|
|
There are some differences, between the two instances.
The main instance is based on HAOS, it’s a ESXi VM and include all the home automations. The second instance is a simple container running only the ABB integration and another integration for a remote thermostat (another home), not supporting multitenancy so I had to run in a different instance to have two of them.
Don’t know if the slow effect appears also in the second instance because I don’t have light or switch to switch on/off, so also if should be there does not affect the main instance.
From: Alessandro Del Prete ***@***.***>
Date: Thursday, 14 September 2023 at 22:51
To: alexdelprete/ha-abb-powerone-pvi-sunspec ***@***.***>
Cc: Claudio1L ***@***.***>, Author ***@***.***>
Subject: Re: [alexdelprete/ha-abb-powerone-pvi-sunspec] randomic HA response delay with ABB Integration (Issue #61)
I moved the ABB integration to a separated container HA instance, running only that integration, and then exposing the entities to the main HA instance leveraging https://github.com/custom-components/remote_homeassistant In this way, the main HA is not slowed down and counters are not corrupted by the integration disabling
So, an integration in an instance slows it down and in another instance it doesn't? Weird. I would point to other issues in the instance that slows down.
Counters corrupted? Never seen anything like that. You can disable an integration at runtime and that won't cause any corruption, it's a message/transaction based architecture.
Anyway...last beta version is under test, and it solves the retry/log spamming issue finally. I will monitor it for a couple of days then release a new stable version so there will be no need to disable the integration when the inverter is off.
BTW: the solution was to let HA manage the retry automatically in background, so it does the exact same thing, but it doesn't write errors to the log except for the first couple of retries.
—
Reply to this email directly, view it on GitHub<#61 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXK6MPVPOZDBLFALEZSI7FDX2NU5PANCNFSM6AAAAAAVQX624E>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Latest beta doesn't address a spike, because there's no spike. You can read release notes to understand what's changed. I can't understand this spike thing: the production is read from the inverter's modbus registry, no data manipulation whatsoever. Showing a graph doesn't tell me anything that could help me diagnose your issue: enable debug in the integration, and pass me the full log so we can check what value has been actually read from the inverter's modbus registry.
When enabled, open the full HA log, filter with keyword "abb" and you'll find these: You'll see I'm pretty confident your spikes are due to data manipulation on your end, a template/calculated/integral sensor, or conversion, or something like that. I never seen another report regarding bad data regarding the integration. Furthermore, I don't understand the graph you posted: why do you have 2 sensors for total energy? Please open the total_energy sensor from the integration directly, and shome me the HA default graph. So we can see what has HA actually read from the sensor that is managed by the integration.
|
HA checks for device availability by polling, each 60s, that is delegated to HA internal functions, and should not slowdown anything. In latest 3.1 I also introduced a check if the TCP port is actually open, before doing any I/O operation, to speed up even more things. A poll of a device should not slowdown a system. It would if you do it evert millisecond, not every 60s. If you want to understand how it works better, you can read here: https://developers.home-assistant.io/docs/integration_setup_failures |
|
I will enable debug logging and see if I can catch this again. I have two VSN300's for my two inverters, hence left and right. This was with version v3.0.0 and I had already disabled any template sensors. I just disabled my automation to disable/ enable at sunrise. Will keep posted with some better debugging. |
|
The integration dropped to 0, hence my suspicion. Let me look at the code. |
Impossible: On start, totalenergy is initialized to 1, then code checks if value received is less than previous. If it is, it's skipped and debug message is written to the log. # registers 94 to 96
totalenergy = decoder.decode_32bit_uint()
totalenergysf = decoder.decode_16bit_uint()
totalenergy = self.calculate_value(totalenergy, totalenergysf)
# ensure that totalenergy is always an increasing value (total_increasing)
_LOGGER.debug("(read_rt_101_103) Total Energy Value Read: %s", totalenergy)
_LOGGER.debug("(read_rt_101_103) Total Energy Previous Value: %s", self.data["totalenergy"])
if totalenergy < self.data["totalenergy"]:
_LOGGER.error("(read_rt_101_103) Total Energy less than previous value! Value Read: %s - Previous Value: %s", totalenergy, self.data["totalenergy"])
else:
self.data["totalenergy"] = totalenergyI need to see the debug log, or the graph of the integration sensor, "Right Inverter Total Energy" might be a calculated sensor. The integration sensor total_energy can't be 0. |
|
Nothing to do. Also after upgrade to latest 3.1.2, every 60 secs the slowdown happen, also if the log report only the first event.
On top, after the shutdown, all entities goes to unavailable state and this corrupt some templates I built on top of those entities. In the previous 2.6.6 they stay at the last value till the inverter restart in the morning.
It should not be a big issue if the slowdon disappear, but in this condition, I prefer to come back and running the integration on the separate instance.
Thanks anyway
Claudio
From: Alessandro Del Prete ***@***.***>
Date: Sunday, 17 September 2023 at 21:17
To: alexdelprete/ha-abb-powerone-pvi-sunspec ***@***.***>
Cc: Claudio1L ***@***.***>, Mention ***@***.***>
Subject: Re: [alexdelprete/ha-abb-powerone-pvi-sunspec] randomic HA response delay with ABB Integration (Issue #61)
There are some differences, between the two instances. The main instance is based on HAOS, it’s a ESXi VM and include all the home automations. The second instance is a simple container running only the ABB integration and another integration for a remote thermostat (another home), not supporting multitenancy so I had to run in a different instance to have two of them. Don’t know if the slow effect appears also in the second instance because I don’t have light or switch to switch on/off, so also if should be there does not affect the main instance. From: Alessandro Del Prete @.> Date: Thursday, 14 September 2023 at 22:51 To: alexdelprete/ha-abb-powerone-pvi-sunspec @.> Cc: Claudio1L @.>, Author @.> Subject: Re: [alexdelprete/ha-abb-powerone-pvi-sunspec] randomic HA response delay with ABB Integration (Issue #61<#61>) I moved the ABB integration to a separated container HA instance, running only that integration, and then exposing the entities to the main HA instance leveraging https://github.com/custom-components/remote_homeassistant In this way, the main HA is not slowed down and counters are not corrupted by the integration disabling So, an integration in an instance slows it down and in another instance it doesn't? Weird. I would point to other issues in the instance that slows down. Counters corrupted? Never seen anything like that. You can disable an integration at runtime and that won't cause any corruption, it's a message/transaction based architecture. Anyway...last beta version is under test, and it solves the retry/log spamming issue finally. I will monitor it for a couple of days then release a new stable version so there will be no need to disable the integration when the inverter is off. BTW: the solution was to let HA manage the retry automatically in background, so it does the exact same thing, but it doesn't write errors to the log except for the first couple of retries. — Reply to this email directly, view it on GitHub<#61 (comment)<#61 (comment)>>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AXK6MPVPOZDBLFALEZSI7FDX2NU5PANCNFSM6AAAAAAVQX624E. You are receiving this because you authored the thread.Message ID: @.***>
HA checks for device availability by polling, each 60s, that is delegated to HA internal functions, and should not slowdown anything.
In latest 3.1 I also introduced a check if the TCP port is actually open, before doing any I/O operation, to speed up even more things.
A poll of a device should not slowdown a system. It would if you do it evert millisecond, not every 60s.
If you want to understand how it works better, you can read here: https://developers.home-assistant.io/docs/integration_setup_failures
—
Reply to this email directly, view it on GitHub<#61 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXK6MPUOL7Z5R74BACCSIA3X25EGJANCNFSM6AAAAAAVQX624E>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
So, on one of your two HA installations, when the integration does a modbus tcp connection and retrieves the data from the inverter (the operation lasts 0.05-0.10s, it would be interesting seeing your debug log to check how long does the fetch operation last), you see your HA installation slowing down. On the second installation it doesn't slow down? Very strange, because you're the only one with this issue. @bryanyork had the problem only when the inverter went offline, and that has been solved now in the code. What hardware are you using to host HA?
When a device goes offline, the sensors must go to state UNAVAILABLE (it's a known state). That's how it's supposed to work and it is documented in HA docs. Why does a sensor have to be available when the device from which the sensor gets its data is offline? Think about it. :) Your problem is how you created the templates on top of the sensors, you should test in your code if the sensor is unavailable and then decide what to do with the template sensor.
That was because the integration kept polling (throwing error in the log) until the device next morning came up. It was a bad behaviour, that has now been fixed, and the integration respects HA's best practices. If you created template sensors, simply use them, and test when the real sensors go unavailable, and use last state of template ones. |
|
As said, they are two different instances one haos and the other a container running on a nas. I don’t think is a matter of “power” of the hw, it’s a 4 core intel cpu running stable at 1-2%.
In the containerized instance I’m not sure if slowed down or not, but does not impact the main instance and it’s fine for me.
Regarding the templates, yes I have to concatenate some additional templates to maintain the last value. As said not a big issue, but I’ll do it only if really need to migrate to 3.x
At the moment, I’ll stay at 2.6.6 containerized.
Thanks anyway for the support.
From: Alessandro Del Prete ***@***.***>
Date: Tuesday, 19 September 2023 at 22:40
To: alexdelprete/ha-abb-powerone-pvi-sunspec ***@***.***>
Cc: Claudio1L ***@***.***>, Mention ***@***.***>
Subject: Re: [alexdelprete/ha-abb-powerone-pvi-sunspec] randomic HA response delay with ABB Integration (Issue #61)
Nothing to do. Also after upgrade to latest 3.1.2, every 60 secs the slowdown happen, also if the log report only the first event.
So, on one of your two HA installations, when the integration does a modbus tcp connection and retrieves the data from the inverter (the operation lasts 0.05-0.10s), you see your HA installation slowing down. On the second installation it doesn't slow down? Very strange, because you're the only one with this issue. @bryanyork<https://github.com/bryanyork> had the problem only when the inverter went offline, and that has been solved now in the code. What hardware are you using to host HA?
On top, after the shutdown, all entities goes to unavailable state and this corrupt some templates I built on top of those entities.
When a device goes offline, the sensors must go to state UNAVAILABLE (it's a known state). That's how it's supposed to work and it is documented in HA docs. Why does a sensor have to be available when the device from which the sensor gets its data is offline? Think about it. :)
Your problem is how you created the templates on top of the sensors, you should test in your code if the sensor is unavailable and then decide what to do with the template sensor.
In the previous 2.6.6 they stay at the last value till the inverter restart in the morning.
That was because the integration kept polling (throwing error in the log) until the device next morning came up. It was a bad behaviour, that has now been fixed, and the integration respects HA's best practices.
If you use template sensors, simply use them, and test when the real sensors go unavailable, and use last state.
—
Reply to this email directly, view it on GitHub<#61 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXK6MPQMXLYMSHRXFKWZV6LX3H7KXANCNFSM6AAAAAAVQX624E>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Running the latest version it seems like the 0 readings have gone away. I see this in my logs however: (read_rt_101_103) Total Energy less than previous value! Value Read: 0 - Previous Value: 39278912 However, at night when the inverters are offline I still see some pauses to my HA install. I will try and debug how this might be caused. Again, if I disable the integration, the pauses go away. |
Those are zero readings Bryan. See "Value Read"? Should never be zero for Total Energy, and that is read from the Inverter. You can enable debug log so we can have some more information in HA log when it happens. This is a debug log of one read-cycle: |
|
@alexdelprete here are the debug logs. Is it possible that |
No, because the inverter answered correctly. I never saw this "Sending Parameters" status. Might mean that it is sending data to AuroraVision on cloud maybe? I never saw this in my logs...maybe it depends on the logger fw version...I have v1.9.1 on VSN300. Anyway, that 0 value is ignored by code, so it's not an issue. If you have 0 in your HA graphs, it's not due to the component's sensors. |
|
@Claudio1L @bryanyork I released v3.1.3, introduced thread locking on connect/disconnect/read operations, I don't know if it might benefit your specific issues, but it's worth trying. |
|
Hi Alessandro
Not had the opportunity to test it. I’ll let you know.
Not sure you have seen this:
CJNE/ha-sunspec#165 (comment)
Thanks
Il giorno mar 26 set 2023 alle 18:30 Alessandro Del Prete <
***@***.***> ha scritto:
… I released v3.1.3, introduced thread locking on connect/disconnect/read
operations, I don't know if it might benefit your specific issues, but it's
worth trying.
—
Reply to this email directly, view it on GitHub
<#61 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXK6MPVAN6BHWUPWFZU7YQLX4L7J7ANCNFSM6AAAAAAVQX624E>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
My code is a bit different and is based on different libraries (I use pymodbus, the other integration uses pysunspec2), and in recent versions, to avoid pymodbus errors that I couldn't disable when inverter was off, I introduced a socket check to see if the modbus port on the VSN card is open or not. So I don't do any connect now, unless the port is available. There's no blocking issue that could slow HA. Furthermore, have you seen any serious error like this in the logs of my component? If so, please show me: |
|
@alexdelprete I got another spike, it seems that if I upgrade home assistant overnight perhaps it put the integration in some weird state, it might cause this. According to debug logs the previous reading was 1 not 0, which is strange. Because I upgraded I missed the log before I upgraded. I will work on sending logs to a central Loki server to see if I can catch this next time. |
|
Previous reading is 1 because at init (before any read) the variable is initialized with 1. The only weird thing is why your inverter reads zero. Anyway, zero is skipped, so it shouldn't cause any issue. And I don't understand what you mean with overnight upgrades of HA. Reading zero from a modbus register is not related to HA upgrade. |
Hi
after some weeks of troubleshooting, I'm pretty sure there is a problem with the integration. Let me describe:
When the sun goes down, the inverter switch off and home assistant is not able to reach the inverter, also via IP (ping).
In that phase starts a random delay in the HA responsivenessy. At least in my case it is easy to reproduce. It's enough to switch on/off a light, or a switch, repeatedly and after 4-5 cycles you can see that delay. That Light or switch does not respond for 2-3 secs and then start again switching fine, till the next 4-5 cycles.
I could imagine an issue when the abb integration try to reach the inverter (polling period) during the switch off phase.
Reloading HA or the Integration only, fix the issue because inverter is switched off and entities are removed.
I'm not sure when it appeared, I realized one or two months ago.
running the follow:
the configuration I use is the follow:
As a workaround I solved with an automation that is reloading the abb config entry, after few minutes from the switch off (that I detect with a ping sensor) to remove entities and few minutes after the switch on to restore entities.
alias: Abb Inverter reload
description: ""
trigger:
entity_id:
to: "off"
for:
hours: 0
minutes: 3
seconds: 0
entity_id:
to: "on"
for:
hours: 0
minutes: 5
seconds: 0
condition: []
action:
data: {}
target:
device_id: b906894628baf2ad2040b276f38b68ca
mode: single
No particular logs a part from the one when the integration is unable to reach the inverter. I reloaded HA so I lost the one from this night but I can gather tomorrow if you need.
The text was updated successfully, but these errors were encountered: