Let me know if you need another and I’ll send you the ID, remote is enabled, both devices are cable connected, no connection issues.
Hi Nick,
If you still need someone, I’m definitely available. Let me know, and I’ll send you the details.
I only have one device here (the Cerbo) that connects to the Solaredge.
The UTP cables have been tested with a cable tester and are fine.
I even disconnected the rest of my network from the router for a test, so that only the Cerbo and the Solaredge were connected to the router. Even then, I still experienced communication loss between the Cerbo and the Solaredge.
Just post site id’s here. They are secure so no need to worry
Initial indications are that modbus is hanging up on the SE.
805569
Forgot to mention: pv inverter is “not shown” to not have wrong data as I have an external meter on the solaredge
feel free to enable it to debug
Yours has been stable overnight.
yes indeed, after the Cerbo GX reboot after installing the beta venus yesterday it is stable. But sometimes it is stable for a day or 2 and then the issue reappears. if you look at the history, you see that it sometimes starts with issues in the morning and then is stable again after a few hours (without doing anything).
So I can’t say for sure it is solved or not, maybe if it is stable for a longer continious period
I have the same issue with my SE10K and Cerbo. It was stable for a while, but since I upgrade to large it’s been more flaky again. I disabled auto-scanning which seems to have helped a bit, and I set the log period to 1 minute in the Cerbo, which maybe has helped as well. (Was assuming it could be a time-out issue on the SolarEdge side, which needs keep alive every 2 minutes).
Somehow I wonder if it could be related to making a connection on the solaredge app (mysolaredge or the solaredge go or setapp), as it seems many times when I check the app, the connection gets a hiccup.
If you want to have a look on my system, don’t hesitate to ping me.
I have so far analysed three sites this morning. Two of the three is behaving perfectly this morning, one of them being @WEHA’s site which is currently still running the test.
At the one site where I could reproduce it easily, it is clearly a problem on the SolarEdge side. Communication stops working, and after 5 retries, spaced 10 seconds apart, it closes the connection and tries again, sometimes succeeding.
The problem, specifically, is that the PV inverter stops responding to modbus ReadHoldingRegister commands. The TCP packets are still ACKed, which means the TCP networking layer is not impacted. But the Modbus application layer appears to lock up and stop working.
That also explains why it responds to pings, which is IP-level.
The first thing to do would be to make sure you are running the latest firmware version from SolarEdge.
For the technically inclined, and since these images show no sensitive info other than a private IP address, this is a healthy communication pattern, where I marked the request and response messages.
And then it stops responding. Note how we still get an ACK on the IP layer (packet was received), but never a response on the application (modbus) layer:
1 Like
VRM Installation ID: 797887
Solaredge SE7K Firmware 0004.0020.0036 (is the latetest firmware)
Today (July 29, 2025) around 12:10 PM, I re-enabled the connection in Cerbo under:
Settings → Integrations → PV inverters → Inverters → 7E0XXXXX → Show (select on) → Dynamic Power Limiting ‘Enabled’
Here you see the settings at 12:23 PM, when the connection is good.
Here you see the settings at 12:31 PM, when the connection is lost.
FYI I’m not sure if you received my information about it but the communication was fine for 5 years with home assistant.
The only thing that is different now is port 502 en sunspec to non-se logger.
Hi Izak,
Thank you for investigating, for my install (785015) the solaredge is on the latest version. It was updated just before I enabled modbus with sunspec.
I’ll try to open a ticket with solaredge to investigate further
If everyone affected can just be sure that there are no other devices like HA etc querying the SE over modbus. The only client needs to be the GX.
Yes, and I also think someone mentioned they tried it with a direct connection (ADoorhof)
Yes, nothing else of smart devices on that network
This seems highly timing dependent, related to multiple connected clients, or perhaps also by the fact that we’re writing a few extra registers to do limiting since Venus 3.60. I can only guess.
Your site has the same issue as the one analysed earlier. After 5 requests with no response, it gives up.
That is right, I tested it with the router (Zyxel VMG8825-T50) to which only the Cerbo and the Solaredge were connected, using UTP CAT6 cables.
Perhaps a certain request of the GX is considered a new connection and hence blocks it?
I saw this too a while back when I was trying to debug on 1 PC and home assistant was trying on another PC, the first connection “won”.
But I’m assuming, I don’t know what the Solaredge blocks, if it’s IP based then my speculation does not hold up.
Now that it’s been determined that several installations are experiencing this issue, what’s the next step?
Will Victron, perhaps in consultation with SolarEdge, investigate what they can do about this?
For now, I think I’ll turn off the connection and have the PV yield measured again by a Victron VM3P75, which measures the SolarEdge yield.
This way, I can at least see the PV yield clearly in my dashboard and know that DESS is working properly, although unfortunately without the “dynamic power limiting”
You will probably not have the dynamic power limiting this way. However if the modbus interface is in a disconnected state it is questionable if that would continue to work. I guess the frequency based reduction should still function… right?
So far every indication is that this is an issue with SE and how it handles these requests.
It is an open standard and so far only these systems appear to have an issue, ultimately the best victron can do is make sure they are fully compatible with the specification. As a community we can’t answer this, I would encourage all of you to also raise this with SE.