For anyone also reading throgh this threade. I had to ring solaregde and have them remove Amber (VPP) from the control to resume my control. Now I have full function again
What happens when you manually change the value in that number entity on your dashboard?
Does it change briefly and then return to a fixed value?
Is your SolarEdge inverter enrolled in Amber SmartShift or another VPP/ Grid Services ? If so you may not be able to change those values unless you unenroll. Oh, I see your follow-up so you are unenrolled which is good.
Yes, Ive resumed full controll.
The values i put are working. Ive even setup up a dumb discharge feature through node red and i can input the values using automation, But i cant have that number a variable.
So these flows trigger automations as im working on getting node red smoother using other flows,
But as ive said i can put a variable solution in place for some reason.
Curious if you could try on your system using the site limit as a test as you dont have the same functions as me as your using a tesla. If yours is displaying across could you show me your automation that made that work as ive tried this also.
Try to simplify your automation to get it to work
alias: p_batt_forecast automation - solaredge
description: ""
trigger:
- platform: state
entity_id:
- sensor.p_batt_forecast
to: null
enabled: true
condition: []
action:
- service: number.set_value
data:
value: "{{states('sensor.p_batt_forecast')}}"
target:
entity_id: number.solaredge_i1_storage_discharge_limit
enabled: true
- service: number.set_value
data:
value: "{{states('sensor.p_batt_forecast')}}"
target:
entity_id: number.solaredge_i1_external_production_max
enabled: true
mode: single
Manually switch Remote Control and Discharge modes. (& External Production)
Then run the automation manually.
Have a look at the automation traces.
Get it working from a very simple automation first before trying to replicate in node red and your Sonnen battery
I don’t have i1_srorage, but this script did change i1_external for me.
This error originated from a custom integration.
Logger: custom_components.solaredge_modbus_multi
Source: helpers/update_coordinator.py:322
Integration: SolarEdge Modbus Multi (documentation, issues)
First occurred: 31 October 2023 at 04:23:36 (3 occurrences)
Last logged: 05:00:26
Error fetching SolarEdge Coordinator data: Modbus/TCP connect to 192.168.0.67:1502 failed.
@WillCodeForCats sorry to tag you directly, but this is becomming a bit of an issue for me now and I know it’s a “known” issue. I’m just wondering if you could suggest anything I might be able to do to either diagnose the problem or at least mitigate its impact.
It used to happen once in 24 hours, but now it happens regularly twice a day, usually around 8pm and 5am, but that time can vary by an hour either way. This morning it happened just before a scheduled battery grid charge slot and this happened:
Logger: homeassistant.components.automation.grid_charge_battery_to_full
Source: components/automation/__init__.py:676
Integration: Automation (documentation, issues)
First occurred: 05:00:08 (1 occurrences)
Last logged: 05:00:08
Error while executing automation automation.grid_charge_battery_to_full: Connection to inverter ID 1 failed.
I’ve been keeping a log of every time it happens now.
I can’t see anything else in the logs around the same time so I wonder if it’s a polling issue with the inverter?
At the end of the day, I can live with it. I just wondered if there was anything I could do my end to help investigate.
Thanks
Hi Mark,
It ended up working. I just had to turn node red off, the node red cant find the api and i forgot it was on, clearly its conflicting each other.
Ive kept that animation you created and it works a charm.
Thank you
1 Like
hello everyone,
can someone tell me if i can use this integration without having a battery?
basically the installation are just my solaredge panels which sending the produced electricity back to the grid.
I don’t have a battery and use this integration every day.
Have you tried loading it to see if it works for you?
i finally managed to make it work 
i just struggled at the beginning with all the sensor…it is not clear yet what i really need and what not
Sorry for my ignorance, but I don’t have the time to read all 500 posts, and are just wondering if anyone got this working with Fronius Sunspec Modbus?
I’m looking to replace the Fronius integration with Sunspec instead to get more exact values in the Energy dashboard.
I made the integration and I don’t have batteries.
There’s really nothing to investigate within the integration as far as connection errors like that go. When you try to send a command it tries to open a Modbus/TCP connection using the pymodbus library and if it can’t connect it will return the “connection failed” message.
You could go lower level and use wireshark to sniff packets to see what’s happening on the wire between Home Assistant and the inverter.
There is a difference between reads and writes that I have some retry logic on reads to try and avoid unavailable state, but writes only get one attempt and immediately return error on failure. I could extend retries to writes and see how that goes, my concern that it could cause UI problems in HA with delayed responses if there is ultimately an error. Or maybe it will be fine, i don’t know since I can only test writes with my simulator which is more well behaved than the real inverters are.
I also recommend running HA 2023.11.0 or higher or Release v2.4.7-pre.1, either of which will load dependencies for the latest version of pymodbus (3.5.4 as of this writing).
That’s a great work, thank you! I have recently installed SE8K-RWB48 with a battery and have a quick question on AC_POWER values.
Does Inverter AC_POWER (40083 40084 1 I_AC_Power int16 Watts AC Power value) ever go into a negative value same as Inverter DC_POWER (40100 40101 1 I_DC_Power int16 Watts DC Power value) does when charging battery from grid and there is 0 PV production?
It doesn’t seem to be the case for me. While charging battery from grid, AC POWER stays at 0, while DC power is negative. I can see some conditions assume it can go negative: https://github.com/ryanm101/hasolarcfg/blob/2b86032adfff5115df272fdf7fc3184d5c5e7821/packages/electricity.yaml#L162
I have the latest software on the inverter. I had previously a regular SE8K without battery so couldn’t observe a negative value due to lack of battery.
Okay, thanks for clarifying. I guess I need to work out why it’s not connecting when a command is sent on those two specific occasions. Is there any way of finding out what the command was that was trying to be sent?
I suppose that’s my other option, in case it’s the ethernet cable causing the issue. I did try changing to a different port in the switch, but that made no difference.
I’m largely able to predict when it’s most likely to happen based on historical data, so I just try to avoid sending any commands around those predicted times.
I shall investigate further.
Hi @WillCodeForCats,
this all would be no problem if the sensors would return to their normal state as soon as the read/write becomes available again, but as soon as they become unavailable, they will stay (because the sensor cannot convert “unavailable” to a number I guess). I am not good enough to provide a solution, but would it work to catch that “unavailable” case within the sensor definition and then just set the sensor to it’s most recent value?
Write errors never cause an unavailable state.
Reads have to fail multiple retry attempts where each error increases the retry time before the next attempt before being declared unavailable. So if it’s failing an update cycle it’s really failing multiple read attempts.
If you want to try changing this behavior you can edit the file solaredge_modbus_multi/const.py and increasing the values in class RetrySettings:
class RetrySettings(IntEnum):
"""Retry settings when opening a connection to the inverter fails."""
Time = 800 # first attempt in milliseconds
Ratio = 3 # time multiplier between each attempt
Limit = 4 # number of attempts before failing
You can start with changing Time to 1000 or changing Limit to 6 or higher. Restart Home Assistant after saving the changes to the file. Debug logging will show the values being applied during retry attempts. If you figure out values that work better for you then we can see how far off they are from my defaults. The defaults are based on observed results for my dual inverter system while trying to avoid excessively high values.
2 Likes
Hi, also trying to diagnose the problem above, since I also have on average two connection problems a day. I have the configuration you mention now as follows:
Time = 1500 # first attempt in milliseconds
Ratio = 3 # time multiplier between each attempt
Limit = 6 # number of attempts before failing
The last two attempts log as follows in the debug logs:
2023-11-15 04:21:32.996 WARNING (MainThread) [pymodbus.logging] Failed to connect
2023-11-15 04:21:37.500 WARNING (MainThread) [pymodbus.logging] Failed to connect
2023-11-15 04:21:42.014 WARNING (MainThread) [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.178.28', 1502)
And:
2023-11-15 18:18:27.998 WARNING (MainThread) [pymodbus.logging] Failed to connect
2023-11-15 18:18:32.502 WARNING (MainThread) [pymodbus.logging] Failed to connect
2023-11-15 18:18:40.007 WARNING (MainThread) [pymodbus.logging] Failed to connect
I did restart Home Assistant - but I don’t really see 6 attempts being made - and also the retry-times don’t really appear to match. Anything I am doing wrong?
I am interested in this because I am trying to set my Battery Discharge Power to 0 so my heat-pump does not suck my home battery dry in the morning while my power prices are still cheap - and then has no power left when we get into the expensive time.
Even though to be honest, my suspicion is now that the inverter resets itself between 4:00 and 5:00 - and with it looses the parameters I have set before - so rather than fixing the connection problems, I would rather need to work around the reset (e.g. by triggering an action when the battery starts discharging when it should not according to my automation).
Those aren’t debug logs for the integration, those are pymodbus log entries.
Debug log entries for retry attempts look like this:
2023-11-15 11:11:13.740 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 20.4
2023-11-15 11:11:16.742 WARNING (MainThread) [pymodbus.logging] Failed to connect
2023-11-15 11:11:16.743 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Failed data refresh attempt #1
2023-11-15 11:11:16.743 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Waiting 800 ms before data refresh attempt #2
2023-11-15 11:11:17.545 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 20.4
2023-11-15 11:11:20.546 WARNING (MainThread) [pymodbus.logging] Failed to connect
2023-11-15 11:11:20.547 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Failed data refresh attempt #2
2023-11-15 11:11:20.547 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Waiting 2400 ms before data refresh attempt #3
2023-11-15 11:11:22.949 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 20.4
2023-11-15 11:11:25.950 WARNING (MainThread) [pymodbus.logging] Failed to connect
2023-11-15 11:11:25.950 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Failed data refresh attempt #3
2023-11-15 11:11:25.950 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Waiting 7200 ms before data refresh attempt #4
2023-11-15 11:11:33.152 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 20.4
2023-11-15 11:11:36.153 WARNING (MainThread) [pymodbus.logging] Failed to connect
2023-11-15 11:11:36.153 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] No more data refresh attempts (maximum 4)
2023-11-15 11:11:36.154 ERROR (MainThread) [custom_components.solaredge_modbus_multi] Error fetching SolarEdge Coordinator data: Modbus/TCP connect to 10.0.0.97:1502 failed.
2023-11-15 11:11:36.154 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 22.414 seconds (success: False)
Yes, I was hoping I could spare my poor SD-card all the logs, since the pymodbus log entries are caused by your integration and do contain a timestamp. Oh well, I have now enabled the logging, I think tomorrow morning I will know more.