feat: add Shelly push mode to fix Marstek Venus v153 communication issues

[cmer81]

Summary

Adds push mode functionality to work around communication interruptions introduced in Marstek Venus firmware v153.

Problem

After updating to Venus firmware v153, the battery randomly stops querying the Shelly Pro 3EM emulator after 10 seconds to 2 minutes, causing communication failures (see issue #180).

Solution

Instead of waiting for periodic JSON-RPC requests from the battery, the emulator can now proactively push power data to the battery at configurable intervals.

Changes

• Add push mode parameters to Shelly class constructor
• Implement _push_data_loop() for periodic data transmission
• Add configuration options in GENERAL section:
  • SHELLY_PUSH_MODE: enable/disable push mode
  • SHELLY_PUSH_TARGET_IP: target IP address
  • SHELLY_PUSH_TARGET_PORT: target port
  • SHELLY_PUSH_INTERVAL: transmission interval in seconds
• Maintain backward compatibility with existing UDP server
• Works with all Shelly device types (Pro3EM, EMG3, ProEM50)
• Add CLAUDE.md for development guidance

Configuration Example

[GENERAL]
DEVICE_TYPE = shellypro3em
SHELLY_PUSH_MODE = True
SHELLY_PUSH_TARGET_IP = 192.168.2.8
SHELLY_PUSH_TARGET_PORT = 22222
SHELLY_PUSH_INTERVAL = 1.0

Test Plan

• Tested with Venus v153 firmware - resolves communication interruptions
• Backward compatibility maintained - UDP server still responds to requests
• Docker build successful
• Configuration parsing works correctly

Fixes #180

[don-at-work]

Yes, i have the same problem. At least it looks like this. Same Batterie. Same Firmware.
By now my Batterie doesn't even find the emulator after i've rebooted my router.
And my HA afterwards. Even rebooting the Venus, because i couldn't find any reason for this.
Which is kind of strange - but it would fit into this timetable from "updating the batterie" to now.

[cmer81]

Yes, i have the same problem. At least it looks like this. Same Batterie. Same Firmware. By now my Batterie doesn't even find the emulator after i've rebooted my router. And my HA afterwards. Even rebooting the Venus, because i couldn't find any reason for this. Which is kind of strange - but it would fit into this timetable from "updating the batterie" to now.

Hi!

I've been in contact with Marstek support regarding this exact issue with Venus firmware v153.

Two official solutions available:

1. Update to v154: A new firmware version v154 is available that fixes this communication bug. You need to request it via email from Marstek support.

2. Downgrade to v152: You can also request a downgrade to version v152 which was working properly.

For your discovery issue after reboot:

This is indeed related to the same v153 bug. The battery no longer properly handles network discovery and periodic requests.

In the meantime:

My PR #181 implements a "push" mode that completely bypasses the problem by proactively sending data to the battery. It works very well with v153.

[290989]

I have firmware V152
Every 10 minutes the power is set to 0. After a few seconds the battery starts working again. Usually there is no connection between b2500 and Venus at this moment.
Could it be the same problem?

If yes, I have two batteries.
How can I push the power value to both of them?
What is the correct part in general for:
SHELLY_PUSH_TARGET_IP = 192.168.2.8

[Sweti934]

Hei - When can we have this merged? This would be a very nice option for all those affected by the issue ... or How Can I do this on Home Assistant Addon locally? thanks!

[richardwem]

So, I put some time in getting this PR running locally to fix my issues between the Marstek Venus and the B2500 meter.

@Sweti934 I never did something like this before... but it is possible with some basic coding knowledge and some AI tooling to help you filling in the gaps on errors. Some pointing in the right direction:

• You'll need the terminal add-on on Home Assistant. With that, using git, you can checkout this PR.
• Then, you'll find a local add-on B2500 meter in your addons screen (after refreshing).
• Then, it's getting a bit harder. Form me, I needed to make some changes to the content to get it working.
• Docker-compose.yaml needs to be pointed to build: . image: b2500-meter-pr-181
• You need to copy all the files and folders that are in /addons/b2500-meter and are relevant to the application, to /addons/b2500-meter/ha_addon
• in /ha_addon, in config.yaml, you need to remove the line that points it to the image (otherwise it won't build its own, which you'll need)
• You'll need a localconfig.ini in /addon_configs and you need to point to that in the add-on configuration. In there, you need to setup manually everything that's in the configuration tab, because it doesn't 'merge' this information.

I had a hard time getting to my sensor data, since the default homeassistant connection to its own sensordata (supervisor:80) also didn't work with my manual setup weirdly enough, I needed to use HTTPS, which gives even more problems.

In the end, I could get it working. I could validate it sending UDP packages when I would fill in my laptop IP in the customconfig.ini, and running nc -u -l 22222 from my laptop terminal (OSX).

So the PR works fine, although I must say it's just hard to debug this addon generally. It would be really helpful to have a little knowledge of what we expect from the Marstek (so we could debug/emulate stuff ourselves) and to have some more error handling (for example, when I didn't set some customconfig.ini since I thought it would be inherited from the addon configuration, it couldnt test the powermeter, but it didn't show me error messages about it).
I can understand why it's not merged, since I think it's not necessary anymore since Marstek released firmware v154 (you can ask for that in the feedback screen in the app).

Anyhow. After all of this configuration.... my Marstek still couldn't connect to the emulated powermeter :(

So I kept debugging, trying different firmwares as well (now on v154), and some more AI suggested debugging.

In the end, the solution for me was changing some network settings. Looks like an Unifi software update made some changes to:

• Gateway mDNS Proxy (needs to be enabled manually, with a default VLAN scope)
• IGMP Snooping (needs to be turned off)

So, big facepalm after all :) it was way more easy to fix than running this PR locally for me. But, I hope I can help someone with this explainer.

[Ativelos]

@richardwem so it works for you without the PR now?
I'm not sure if V154 really changed anything, because back when the problem appeared (two months ago or something), V154 already got released and I believe the Venus E still didn't manage to find the emulated Shelly.
Sind then I've had a weird mix of the Uni Meter Add-On and B2500-Meter local Add-On with the PR running which kind of works, but none of them worked on their own back then.
Do you think I should try running the normal B2500-Meter again?

[richardwem]

@Ativelos yes, it works for me.

I'm also not 100% sure if v154 fixes the problem with querying the Shelly, since in the end, my problem seemed to be a networking problem, not a Marstek bug. My Marstek on v154 has (for now) at least no problem at all with finding the (emulated) Shelly.

Do you think I should try running the normal B2500-Meter again?

Well; this PR doesn't have changes that would break the current implementation. So, if you can't make it work with this PR, I'm sure you also wouldn't make it work with the normal B2500-Meter.
I would suggest asking Marstek to rollback to v151 firmware if you're affected by connectivity problems.

[Ativelos]

Thanks for your response. I'll probably just try it again and roll back to the local add on based on this PR that's currently running.