If you just woukve read this thread you would know why rebooting temp. fixes the issue.
I have a new SE7K (no display, firmware 0004.0024.0009) & Victron battery and have the same problems with the modbus stability. I opened a ticket to downgrade the firmware to version 4.22.44. How long did it take for SE to do that in your case? I am still waiting to have my ticket processed. I tried it directly by using the “chat function” of SE’s Owner Support, but get only : “agents are not available”…
So maybe you could point me to it then? There’s 142 messages in this thread excuse me for not reading all of them.
Requested a downgrade of my system last week with SE support.all is working fine since yesterday. Thanks for the support !
FYI: Yesterday I requested a downgrade of my system from 4.24.9 to 4.22.44. I got a downgrade to 4.21.23. Since today all is working fine (I did not have to make the usual manual Victron reboot in the morning to re-establish correct communications). Let’s hope that SE will fix the problem in future firmware releases. Thanks for the quick SE support!
Did you explain the problem why you wanted this downgrade or just requested it?
As I explained above: I had the same communication problem between SE and the Victron as all the other people in this thread! The FW downgrade solved the problem: up to now the connection between both devices is stable.
to add: yes I explained it to SE, and they did the downgrade promptly.
for how long has it been stable? I’d say you need at least a week to know the problem is really gone because the reboot will solve it for 1-2 days.
it is stable up to now, i.e. ca. 4 days. Before the downgrade I had to reboot the Victron in the morning every day, then it was stable only til next morning. I will observe the system carefully and report if the communication gets unstable again. Let’s cross fingers…
great, please keep us updated. If this fix works I will also send an email to downgrade my installation.
All, my system has been stable for one week now with SE firmware 4.22.44
1 Like
Got a message from SE today that they downgraded my inverter firmware to version 4.22.44. Communications seem to be stable now..
My system (I ask for downgrade to 4.22.44 but they did it to 4.21.23) is stable now for >10 days. So it looks like the downgrade solved the communication problem.
1 Like
I have 3 sites running. Two of them are on version 4.22.44 and work without any issues. One site is on version 4.23.27, and the disconnects are getting worse every day. today i made a ticket at solar edge - i hope for the best 
Today 14 nov 2025 i contact SolarEdge. They update my firmware version from 4.24.9 to 4.24.16. This must solved the communication problem .
We will see.
I‘ve never heard about version 4.24.16. If it’s a new version issued this year I’d expect 4.25.x. Are you sure?
That’s what SolarEdge wrote to me in a chat. I don’t think communication has improved yet after 2 days.
Hi,
have a similar problem , sometimes communication works perfect for days
and sometimes its starts for 2 minutes, after an other minute Victron recognizes lost of communication (PV disappears from screen, AC load = 0) after 1.3 minutes communication is back again … repeats the whole day every 4.5-5 minutes.
Till now I could not find out a reason for this.
This were the unsuccessful actionsI already tried:
- uninstalled OpenHab SolarEdge binding
- updated to my SE9k to firmware 4.24.16
- updated my Venus OS V3.70.35 to V3.70~60
- changed SE port from502 to 1502
I will continue analyzing
I’ve a system with two SolarEdge Inverters (SE7K-RW0 and SE8K-RWS) and one MP2 5000 with a Cerbo GX with firmware 3.66.
I integrated both SolarEdge Inverters to a local monitoring system (Raspberry-Pi every minute, CFOS Wallbox every 3 seconds). These systems are using a modbus-Proxy on Raspberry-Pi, because SolarEdge Inverters allowing only one Modbus-TCP simultanous.
I also integrated both SolarEdge Inverters into Cerbo GX. This is done with following methods:
One methods is via Node-Red Flow with Modbus-Getter via modbus-Proxy.
The second method is direct to the SE IP with sunspec ID 126 via Integrations/PV Inverters.
On the SolarEdge SE7K-RW0 the firmware 4.19.39 is installed.
The Modbus-TCP communication is working without issues with local monitoring system and both methods on Cerbo GX.
During Installation of the SolarEdge SE8K-RWS the firmware was upgraded to 4.24.9. With this Firmware the communication with local monitoring system and both methods on Cerbo GX are frequently failing.
It could be resolved by restarting modbus-Proxy and Cerbo GX.
Therefore I’ve requested from SoalarEdge support a firmware downgrade to 4.22.44. But they did a downgrade to 4.20.36.
With this firmware the Modbus-TCP communication is working without issues with local monitoring system and both methods on Cerbo GX.
A few days ago the SolarEdge Support asked me to upgrade to test firmware 4.24.15 for SolarEdge SE8K-RWS.
Status since a few days:
The Modbus-TCP communication is working without issues with local monitoring system.
The Modbus-TCP communication from Cerbo GX is also working without issues with the method via a Node-Red Flow and using a modbus-proxy.
The Modbus-TCP communication method from Cerbo GX direct to the SE IP with sunspec ID 126 is crashing frequently. The communication is automaticly reestablished by Cerbo GX without reboot.
I’ve also stopped all communications via modbus-Proxy, but the Modbus-TCP communication method direct to the SE IP with sunspec ID 126 is also crashing frequently.
Perhaps Solaredge and Victron needs to correct their firmware to fully solve this communication issue.
But this could also be a problem, because SolarEdge Inverters allowing only one Modbus-TCP connection simultanous.
It would be better, that Victron would allow to manually configure the IP of SolarEdge Inverters to use a modbus-proxy.
I’ve found now a workaround for my installation.
On Cerbo GX instead of using direct connection to SolarEdge Inverters I redirect the requests to use a modbus-proxy.
SE7K-RW0: 10.0.7.7
SE8K-RWS: 10.0.7.8
Raspberry-Pi with modbus-proxy: 10.0.7.1
Content of /data/rc.local:
#!/bin/bash
#use the modbus proxy on 10.0.7.1
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -I OUTPUT -p tcp --destination 10.0.7.7 --dport 502 -j DNAT --to-destination 10.0.7.1:9707
iptables -t nat -I OUTPUT -p tcp --destination 10.0.7.8 --dport 502 -j DNAT --to-destination 10.0.7.1:9708
iptables -t nat -I POSTROUTING -p tcp --destination 10.0.7.1 --dport 9707 -j MASQUERADE
iptables -t nat -I POSTROUTING -p tcp --destination 10.0.7.1 --dport 9708 -j MASQUERADE
With this configuration all communication methods are working fine without issues.
1 Like