I am using the new built-in Shelly integration on a Cerbo GX and found a problem: when the Shelly device drops off the network (reboot or power loss), the GX does not reconnect to it automatically.
Setup
Cerbo GX, Venus OS v3.80 (official release, 2026-09-21), tested on both Normal and Large image
ESS system: Quattro 48/8000, Pylontech battery, 2× SmartSolar MPPT RS
Shelly 1PM Gen4 (firmware 2.0.1) with Shelly Plus Add-on and a DS18B20 temperature sensor, controlling a water heater
Shelly has a fixed IP (DHCP reservation on a MikroTik router); it is connected to a second Wi-Fi access point in the same subnet as the GX
Output function was set to “Opportunity load” (Opportunity Loads enabled)
Steps to reproduce
Add the Shelly in Settings → Integrations → Shelly devices and enable its channel. Everything works: the device shows up in Devices, power and energy are logged to VRM, and Opportunity Loads switches it.
Reboot the Shelly (or cut its power for a moment). It comes back online within about 25 seconds with the same IP.
Wait a few minutes.
Result
In Devices, the Shelly first shows “Not connected” and then disappears completely.
In Integrations → Shelly devices, the “Discovered devices” list is empty.
VRM stops receiving data from the device, and Opportunity Loads can no longer control it.
The only way to recover is to press “Refresh” in the Shelly devices menu, open the device, and switch the channel on again. The channel is always found disabled after this.
Adding the IP address manually (Add IP addresses manually → 192.168.0.78) does not help. The device is still not reconnected until “Refresh” is pressed.
After a reboot of the GX itself, the Shelly is found again automatically.
Expected
The GX should periodically retry known or manually added Shelly devices and reconnect to them, keeping the channel enabled and the output function unchanged.
Why it matters
A short power outage or Wi-Fi drop at the Shelly silently removes the load from Opportunity Loads control until someone notices and re-adds it manually. As a workaround I now control the Shelly directly from Node-RED, but it would be great to have this fixed in the native integration.
When the shelly comes back online it should automatically be rediscovered over mDNS and be enabled again. Unfortunately, this is not always the case.
The GX should periodically retry known or manually added Shelly devices and reconnect to them, keeping the channel enabled and the output function unchanged.
I’m working on a stability improvement where the GX does exactly this, for all endpoints known, either found by a manually added IP or over mDNS. I expect/hope this will be released in 3.90 beta in a few weeks.
Thank you very much for the quick reply and for confirming the issue. It’s great to hear that a periodic reconnect to known/manually added endpoints is already in the works. That is exactly what would solve it for us.
I would be happy to test it as soon as it lands in the 3.90 beta. My setup reproduces the problem quite reliably, because the Shelly sits on a second Wi-Fi access point and the circuit it is on is sometimes switched between the inverter output and the grid, so the relay reboots or drops off now and then. When the beta is out, I’ll install it, reboot the Shelly / cut its power a few times and report back here whether the GX picks it up again on its own, keeping the channel enabled and the output function unchanged.
If any logs or details would help you (Shelly 1PM Gen4, firmware 2.0.1, with Plus Add-on + DS18B20; Cerbo GX on v3.80, Large image), just let me know what to collect.
@Bah434x thanks for the tip! The Shelly already has a fixed IP via a DHCP reservation on the router, and I also added it manually by IP in the GX, but that didn’t help in my case. I may still try setting the static IP directly on the device and will post the result.
@Bah434x thanks for sharing, that confirms it is not specific to my setup, and that a static IP does not prevent it either.
@rzee one more point that may be worth considering for the 3.90 fix: what happens to the relay output when the GX loses contact with a Shelly. In the case above both relays were switched on and then the connection was lost, so the GX could no longer switch them off, and the loads kept draining the battery. For Opportunity Loads that is the worst possible outcome.
Would it be possible to add some kind of fail-safe, for example:
the GX sends an “off” command as soon as it detects that a device is going “Not connected”, while it may still be reachable, and/or
using the Shelly’s own auto-off timer (toggle_after) on every “on” command from the GX, renewed periodically while the load should stay on, so the relay turns itself off if the GX stops talking to it.
For now I have worked around it by controlling my water heater relay directly from Node-RED on the GX (output function set to Manual), with its own safety rule that switches the heater off if the battery starts discharging.
I am still happy to test the 3.90 beta on my setup as soon as it is available and report back.
Both mine are controlling lighting so nothing with a huge a load, however over a long period this would cause an issue. They have been working ok since 3.80 was installed a few weeks ago so wonder if something in the VRM changes has effected them.
Thanks for you suggestions. I agree that it may be useful to make sure the Shelly relay is off when the connection is lost. That can for sure be implemented somehow. The GX won’t be able to send the off command when the connection is lost, but your second suggestion may work.
@rzee same problem here with a shelly 2pm + add on temperature extension. 1 virtual temperature sensor and the temperature goes over mqtt to the cerbo gx (always working)
shelly 2pm has a fix ip address and is added in the cerbo gx - Heizstab (is always visible but not active after 2h) you need to activate it a again over and over…
yesterday - i made a virtual switch and connected is with mqtt - mqtt is working fine… for sure the shelly integration over cerbo gx would be nice for the meter and so on…
