Correct, frequency based reduction still works in an off-grid situation
I hope you get more out of them then me. They wonât help me because Iâm not an installer and my installer has been bought by a company that wonât answer any requestsâŚ
EDIT: they said an installer needs to âcheck some settingsâ but they wonât elaborate on what
I have just opened a case as an installer with SolarEdge and referenced this thread, will keep you all updated here about the response
If you can find a good contact within SE let us know.
1 Like
I also created a case as an installer at SolarEdge
@iburger you probably have seen the ACK, RST being sent back from solaredge right before it stops responding right? I understand the RST as a termination of the IP connection, but Venus still tries to use it? Or am I mistaken? Maybe a filter on packets was applied in the screenshot?
In my case time-outs of modbus connection to SolarEdge (SE16K fw 0004.0023.0036) only happen when inverter is in standby mode and go away after it switches on. Iâve only noticed dropouts after the latest SolarEdge update, before it hadnât had any issues.
I did some Wireshark captures, in One thing that stood out is that it seems my Cerbo is trying to acces the SolarEdge inverter on port 80. AFAIK there is no server running on port 80 since a few years now,. Whenever this happens the dashboard seems stutter on the SE data. I also see some unexpected sessions on the modbus port around when that happens. specifically an older session is being reset, [RST,ACK] and the activity on the new session gets stuck up.
After a while a new modbus session is created but the old one is not closed properly, which only happens after a while.
Any news by any chance? Or @ADoorhof ?
Thanks!
SolarEdge replied on my ticket yesterday but only the acknowledgement that they see that modbus is active on port 502 and a link to the manual.
Not sure what answer that is⌠
but I kindly requested again to look into the problem
I have, on that one site. It doesnât happen every time, and not on every site checked, so it is unclear if it is part of the problem. I think itâs unrelated.
RST is sent when a packet is received that doesnât seem to belong to any known connection. It also doesnât fit with the pattern that later packets are still ACKed, indicating that there is no problem with connection tracking. I am therefore inclined to dismiss that.
Iâll ask among my colleagues who are more familiar with these brands if they know who we can ask about this.
I have not yet received a response to my ticket which I submitted to Solaredge
Analyzing from the wireshark traces, the RST is sent by the SolarEdge device after a while for a connection which runs into time-out. The RST is seen on an older session, which is not being used by the modbus client at that time. After the RST it seems (at least on my system) that the SolarEdge is not responding for a while, which seems to cause the new session to start. Maybe this is of help to the debugging.
SolarEdge just changed the port from 502 to 1502 without even asking in advance. Kindly requested to put it back. Now the response is this:
Beste klant,
Bedankt dat u contact hebt opgenomen met de technische ondersteuning van SolarEdge.
Ik heb dit probleem zojuist met het senior team besproken. Zij hebben aangegeven dat we alleen de Modbus-poort kunnen wijzigen, maar dat we geen hulp bieden bij verbindingsproblemen.
Als u vragen heeft, kunt u gerust contact met ons opnemen voor verdere ondersteuning.
So basically they implemented a feature that they donât give any support onâŚ
All depends on your support agent actually explaining it correctly to the senior teamâŚ
Perhaps persuade them with the results of the testing in this thread?
My general experience with support desks (except Victron of course) is that they are trained to bring things back into the last know accepted working state as documented. This means they will revert any custom configuration and then not look further if there is no response from the ticket.
As the modbus configuration was probably tested on port 1502 with home assistant in their qa street, this is what they revert back to.
Are there any solaredge installations on the latest software release with a Venus 3.6x+ version which do not have this issue?
What I understand people with 3.55 have no issues? But maybe they run on an old SE version as well, and they will not have dynamic throttlingâŚ
Any frontline support will interpret a request like this to mean there is a setup issue so will just bat it.
You need to be explicit that there is possibly a bug in their firmware and provide the traces and detail, asking for it to be escalated to L2 or L3 engineering.
1 Like
Yes, explicitly asked to forward to the development team for further investigation and given them the link to this thread
I also received a response from Solaredge. Just like with @blieve, they changed my TCP port from 502 to 1502. Of course, that didnât work.
In my response, I more explicitly stated that this appears to be a firmware issue, including the link to this thread.
Not a Victron user, but my Melbourne-based SE5000 started running into a very similar Modbus TCP timeout issue with an independent client implementation on 2025-07-21, after being stable since about 2018, so I thought I might give an extra data point since the timing seems suspiciously similar.
Now, it happens that I also monitor all the traffic between the inverter and the SolarEdge endpoint, and I can see that they pushed three firmware updates on that day, which I havenât seen them ever do before. My primary firmware was 3.1818 the day before, and it now seems to be 3.2537. During the exchange the server also read an unusual number of inverter configuration parameters, but the only changes it seems to have made were the three firmware updates.
The SolarEdge server commanded a reset after the first firmware update at 2025-07-21T05:56:00Z. I poll the Modbus registers every 10 seconds, and the last successful read I have was at 2025-07-21T05:55:53Z.
Iâve filed a ticket with SolarEdge, but it would be interesting to know if anybody else had a sneaky pushed firmware update at the same time.