I should also add: if I can’t duplicate or see the problem personally it’s almost impossible for me to actually do something about it. For batteries, for example, I require logs becasue I set data points in a modbus simulator to work with since I don’t have batteries personally.
I really don’t know how a modbus proxy would or would not affect anything. If you’re getting modbus timeout errors then I would have to guess those are coming from the proxy, not the inverter directly, so I would think the proxy would have logs too that could be matched up. I don’t know how the proxy handles multiple reads across to the inverter, but I have modbus serial to TCP/IP converters at work that do something similar where sometimes they have read collision issues where one thing tries to read before a previous read is complete and modbus packets get corrupt, so it’s possible that can be a thing too.
Anyone using a proxy I would suggest to try it without the proxy and see if the problem continues or not.
Thanks for the replies. After solar production begins again in the morning, the values recover (without reboot). I noticed tgat this always happens at 11 pm, so maybe same as your inverter.
Nonetheless, I will activate debug logging on proxy and your plugin and see if I can catch it.
FYI in case anyone missed them, there is a button in the latest release to trigger an update manually, and the next pre-release will add a button for updating/retrying offline units. These can be used manually or with a service call.
This error originated from a custom integration.
Logger: custom_components.solaredge_modbus_multi
Source: helpers/update_coordinator.py:229
Integration: SolarEdge Modbus Multi (documentation, issues)
First occurred: 10 August 2023 at 23:04:06 (1 occurrences)
Last logged: 10 August 2023 at 23:04:06
Error fetching SolarEdge Coordinator data: Modbus/TCP connect to 192.168.0.67:1502 failed.
Last night, but just as my automation to grid charge the battery triggered at 2am, I also got this error:
This error originated from a custom integration.
Logger: custom_components.solaredge_modbus_multi
Source: custom_components/solaredge_modbus_multi/hub.py:817
Integration: SolarEdge Modbus Multi (documentation, issues)
First occurred: 02:00:11 (1 occurrences)
Last logged: 02:00:11
Unexpected error fetching SolarEdge Coordinator data: unpack requires a buffer of 2 bytes
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 283, in _async_refresh
self.data = await self._async_update_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solaredge_modbus_multi/__init__.py", line 189, in _async_update_data
return await self._refresh_modbus_data_with_retry(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solaredge_modbus_multi/__init__.py", line 227, in _refresh_modbus_data_with_retry
raise ex
File "/config/custom_components/solaredge_modbus_multi/__init__.py", line 224, in _refresh_modbus_data_with_retry
return await self._hub.async_refresh_modbus_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solaredge_modbus_multi/hub.py", line 414, in async_refresh_modbus_data
await inverter.read_modbus_data()
File "/config/custom_components/solaredge_modbus_multi/hub.py", line 817, in read_modbus_data
("AC_Current", decoder.decode_16bit_uint()),
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pymodbus/payload.py", line 375, in decode_16bit_uint
return unpack(fstring, handle)[0]
^^^^^^^^^^^^^^^^^^^^^^^
struct.error: unpack requires a buffer of 2 bytes
Should I raise this as an issue, or is it just another symptom of the connection issue? Just for clarity, everything worked as it should despite the error.
That’s raised from within pymodbus, definitely not something I can fix. It means that there was no data at the AC_Current location but could probably be handled more gracefully. I would need to look more at the pymodbus repo.
Followup on this: I did personally see this happen once with my simulator which should be impossible because the simulator can always send a “perfect” response. I also saw that Home Assistant had a PR for updating pymodbus library from v3.3.1 to v3.4.1 which I presume will be included with HA 2023.9, so while I haven’t looked through every pymodbus PR there are quite a lot of fixes and hopefully this is related to one of them.
Hi, I had this problem as well. I see it was Dec 22 so probably solved by now. My Battery Charge needle was flicking back to zero but showing the correct % but an identical guage elsewhere was performing correctly then I noticed that you had min: 0 & max: 100 in the yaml which my other guage did not so I took them out and the guage now works correctly.
I have the energy page working well but I don’t have solaredge_b1_state_of_energy so I can’t get the tesla-style-solar-power-card working!
Where is this value generated?
I’m watching the efficiency of my byd battery, and i get values around 75%~85%, seem quite low values. And on top of that there is the inverter efficiency (that in case of the se10k-rws seem to average at 99%).
The formula using i1 dc power/b1 dc power seem correct.
Someone else, please, want to share their values, so i can see if my system have problems?
Thanks!
Our Solaredge Home Battery generally sits at very high levels of efficiency (or effectiveness), eg 95% - 99%. However, the efficiency can drop to quite low levels when the battery gets to a low state of charge eg < 10%. The only issue with that is it affects the value of power going to the house, because the template sensor solar_battery_to_house_w uses battery effectiveness in its calculation. So if the house is running purely from the battery and drawing 500W, and the battery effectiveness is 50%, solar_battery_to_house_w is 250W, when in reality it is 500W.
There was a discussion further up this thread about battery efficiency, or indeed battery effectiveness. ie how effective is the battery at providing the power the house needs. The discussion exposed some facts about the Solaredge battery that Solaredge probably don’t want made widely available ie the battery is not particularly effective at low states of charge.
FYI: There were several reports that a recent SolarEdge firmware update omits a battery device string that was used for detection. I had to change the way the integration tries to detect batteries (using the rated capacity value greater than 0 instead of make/model values).
You will need to use Release v2.4.2 or newer if your battery stops being detected.
hello everyone, I’ve been using this integration for a long time. Before the values were accurate, for some time now the ones I’ve read from HA compared to Solaredge are different. for what reason?
Recently there was a report that a dual function meter was appearing in both the M1 and M2 meter slots with a duplicate serial number (the integration ignored duplicate serial numbers). I modified the integration to allow duplicate meter serial numbers, but unfortunately it just returns an M1 and M2 with the same values which was not useful.
However, the behavior of reporting a second meter is new and optimistically one could hope it’s a sign SolarEdge will eventually fix dual function meters to work with the modbus interface.
Hi, I am copying the dashboard code into the Raw Configuration Editor then after saving, when clicking the X to exit the editor, the dashboard shows beautifully. BUT, when I go to a different dashboard then back to this energy flow dashboard it is totally blank, I have to go into then out of the Raw Configurator again to see the dashboard. Any ideas what I am doing wrong?
Thanks to @Remko & @WillCodeForCats for the fantastic work on the integration and dashboard and other yaml code which is way above my head.