Shelly integration does not reconnect after Shelly device reboots (Cerbo GX, Venus OS v3.80)

Been running into something that's been quietly driving me mad with my garden office setup, and wondering if anyone else has hit the same wall.

Since updating to Venus OS v3.80 on my Cerbo GX, I've been using the built-in Shelly integration to monitor a couple of loads — seemed elegant, avoided a whole extra layer of Node-RED nonsense. Works beautifully until the Shelly device loses power or reboots for whatever reason (mine did after a brief grid blip last week).

The Cerbo just... sits there. Stares into the middle distance. Refuses to pick the connection back up automatically. Only way I've found to restore it is a full restart of the Cerbo itself, which is less than ideal when you're trying to run a hands-off system.

My suspicion is the integration establishes the connection once at startup and never attempts to re-initiate if the Shelly drops off the local network temporarily. Classic "assume happy path" bug.

A few questions for the room:

• Has anyone found a workaround short of rebooting the Cerbo?
• Would a watchdog script via Venus OS terminal be the sensible route here?
• Is this specific to v3.80 or did it creep in earlier?

I've raised it on the Victron Community forum too but thought this crowd might have some practical workarounds already in the drawer. The Shelly integration felt like a proper grown-up feature when it landed — would be a shame if a reconnect oversight is what lets it down.

@PikeWalker oh mate, this one bit me hard back in January with my motorhome setup.

The short version: Venus OS v3.80 has a known issue where the Shelly integration loses its MQTT session and just... sits there sulking. It won't attempt a reconnect unless you manually restart the dbus-shelly service or reboot the Cerbo itself.

What I did as a temporary workaround was set up a scheduled Cerbo restart overnight via VRM — not elegant, I know, but it kept things ticking until a proper fix lands.

Worth checking the Victron community forums too — there's a GitHub issue raised against it. Some people have had luck with a Venus OS Large variant that handles the MQTT broker slightly differently.

Annoying regression really, worked flawlessly on v3.73.

Interesting one — does this affect the Shelly Plus 1PM as well, or just the original Shelly 1PM? I've got a couple of the Plus variants monitoring loads in my static caravan setup and I've not noticed dropouts, but I'm still on v3.74 so probably haven't hit this yet.

Tempted to hold off upgrading now until there's a confirmed fix. Has anyone raised it on the Victron Community forum directly? Those tend to get picked up by devs fairly quickly compared to third-party forums.

Also wondering whether setting a longer reconnect retry interval in Venus OS would act as a workaround in the meantime — or is the issue that it simply never retries at all after the Shelly reboots?

@TelHall good question actually — I've got a Shelly Plus 1PM on my static and had exactly this issue after updating. So yes, affects both generations from what I can tell.

What's annoying me is there's seemingly no workaround short of either:

• Rolling back Venus OS
• Setting up a cron job to ping the Shelly and restart the integration service if it drops

Anyone actually got the cron approach working reliably? I've seen vague references to it on the Victron community forums but nothing concrete. The official Victron response seems to be "we're aware of it" which tells me precisely nothing about when a fix lands.

@PikeWalker — is your Cerbo on a UPS or just bare mains? Wondering if the Shelly reboots are being triggered by something upstream rather than the devices just deciding to have a wobble on their own.

Good thread this — I've been wrestling with the same thing on my narrowboat since v3.80 dropped.

@DorsetDweller @BayTim glad it's not just me losing my mind then.

One thing worth adding that I haven't seen mentioned yet: I found setting a static IP on the Shelly itself (rather than relying on DHCP reservation on the router) seemed to reduce how often the reconnection issue triggered in the first place. Not a fix by any means, but it cut the frequency noticeably for me.

Also worth checking your MQTT keep-alive settings if you haven't already — there's a timeout value in the Shelly's MQTT config that can help. I bumped mine to 60 seconds and it's been marginally more stable.

Still waiting on Victron to properly acknowledge this as a bug though. Anyone raised it on the Victron Community forum directly?