[Bug] Sporadic incoherent values

[fmartinou]

Before you submit

• I have read the README and my question is not answered there.
• I have searched existing issues and this is not a duplicate.

Battery / device models

Marstek Venus

Version

1.3.5

Deployment

Docker Compose

B2500 MQTT configuration

Not applicable — I don't have a B2500

Are you using hm2mqtt?

Yes

What's happening?

Hi,

I've deployed both hame-relay and hm2mqtt using Docker-Compose:

    # Hame-relay
    hame-relay:
        image: ghcr.io/tomquist/hame-relay:1.3.5
        restart: always
        volumes:
            - /var/lib/services/hame-relay/config:/app/config
            - /etc/localtime:/etc/localtime:ro
        environment:
            - TZ=Europe/Paris
            - LOG_LEVEL=info

    # Hm2mqtt
    hm2mqtt:
        image: ghcr.io/tomquist/hm2mqtt:1.6.0
        restart: always
        volumes:
            - /etc/localtime:/etc/localtime:ro
        environment:
            - TZ=Europe/Paris
            - LOG_LEVEL=info
            - MQTT_BROKER_URL=mqtt://mosquitto:1883
            - DEVICE_0=VNSE3-0:xxxxxxxxxxxx
            - MQTT_POLLING_INTERVAL=300

Several times a day the battery reports incoherent values.
The values are so extreme that it totally breaks Home-Assistant energy charts.

As you can see, for example, today, only 2 values were incoherent but these 2 single values break the whole statistics.

295kwh or 32kwh are clearly impossible for a Venus E 3.0.

Please also notice that with the default polling interval on hm2mqtt (60s), the battery crashed within 24 hours.
After having increased the polling interval to (300s), the system is stable.

Thank you very much for your support.

Configuration

{
  "log_level": "info",
  "username": "xxx@xxx.com",
  "password": "xxxxxx",
  "broker_url": "mqtt://mosquitto:1883",
  "devices": [
    {
      "device_id": "xxxx",
      "mac": "xxxx",
      "type": "VNSE3-0",
      "version": 148
    }
  ]
}

Logs

[2026-05-22 08:01:39] INFO: Fetching devices from Hame API...
[2026-05-22 08:01:39] INFO: Fetching device token for xxx@xxx.com...
[2026-05-22 08:01:40] INFO: Fetching device list...
[2026-05-22 08:01:40] INFO: Successfully fetched 1 devices from Hame API
[2026-05-22 08:01:40] INFO: Successfully retrieved 1 devices from API
[2026-05-22 08:01:40] INFO: Auto-selected broker hame-2025 for device 7a5a0134373259565011xxxx
[2026-05-22 08:01:40] INFO: 
Configured devices: 1 total
[2026-05-22 08:01:40] INFO: ------------------
[2026-05-22 08:01:40] INFO: Device 1:
[2026-05-22 08:01:40] INFO:   Name: MST_VNSE3_ffa1
[2026-05-22 08:01:40] INFO:   Device ID: 7a5a01343732595650xxxxxx
[2026-05-22 08:01:40] INFO:   Remote ID: nVy0y0BVM0M0bVw0y0xxxxxx
[2026-05-22 08:01:40] INFO:   MAC: 009b08xxxxxx
[2026-05-22 08:01:40] INFO:   Type: VNSE3-0
[2026-05-22 08:01:40] INFO:   Version: 148
[2026-05-22 08:01:40] INFO:   Broker: hame-2025
[2026-05-22 08:01:40] INFO:   Inverse Forwarding: true
[2026-05-22 08:01:40] INFO:   Use Remote Topic ID: false
[2026-05-22 08:01:40] INFO: ------------------
[2026-05-22 08:01:40] INFO: 
[2026-05-22 08:01:40] INFO: Health server listening on port 8080
[2026-05-22 08:01:40] INFO: [hame-2025] Connected to config broker
[2026-05-22 08:01:40] INFO: [hame-2025] Subscribed to local broker topics
[2026-05-22 08:01:40] INFO: [hame-2025] Connected to remote broker
[2026-05-22 08:01:40] INFO: [hame-2025] Subscribed to remote broker topics
[2026-05-22 08:11:39] INFO: [hame-2025] Forwarded message from local to remote: hame_energy/VNSE3-0/App/009b0805ffa1/ctrl -> marstek_energy/VNSE3-0/App/nVy0y0BVM0M0bVw0y0xxxxxx/ctrl
[2026-05-22 08:11:39] INFO: [hame-2025] Forwarded message from remote to local: marstek_energy/VNSE3-0/device/nVy0y0BVM0M0bVw0y0xxxxxx/ctrl -> hame_energy/VNSE3-0/device/009b08xxxxxx/ctrl
[2026-05-22 08:21:39] INFO: [hame-2025] Forwarded message from local to remote: hame_energy/VNSE3-0/App/009b08xxxxxx/ctrl -> marstek_energy/VNSE3-0/App/nVy0y0BVM0M0bVw0y0xxxxxx/ctrl
[2026-05-22 08:21:39] INFO: [hame-2025] Forwarded message from remote to local: marstek_energy/VNSE3-0/device/nVy0y0BVM0M0bVw0y0xxxxxx/ctrl -> hame_energy/VNSE3-0/device/009b08xxxxxx/ctrl
[2026-05-22 08:31:39] INFO: [hame-2025] Forwarded message from local to remote: hame_energy/VNSE3-0/App/009b08xxxxxx/ctrl -> marstek_energy/VNSE3-0/App/nVy0y0BVM0M0bVw0y0xxxxxx/ctrl

[github-actions]

Thanks for the report — I can take a look, but I’ll need logs to debug this.

Please add:

1. hm2mqtt logs (DEBUG)

   • Home Assistant → Settings → Add-ons → hm2mqtt
   • In the add-on configuration, set:
     • log_level: debug
     • debug: true
   • Restart the add-on
   • Then paste the relevant log excerpt here (around the time the problem happens)

2. Hame Relay logs (DEBUG)

   • In the Hame Relay add-on, enable debug logging (log level debug) and restart
   • Paste the relevant log excerpt here

Important: please redact/replace any IDs (deviceId/MAC, tokens, MQTT credentials, etc.) before posting.

[tomquist]

Ideally, I'd need logs from hm2mqtt in debug mode when the issue occurs. Hm2mqtt is just forwarding the battery data, so my suspicion is that the bad data is coming from the battery, but I can only confirm after getting debug logs.

[fmartinou]

Hi,

Thank you for your quick reply.
I just set hm2mqtt and hame-relay log levels in DEBUG mode.
Now I wait the next time when incoherent values are published, then I'll send you all the logs.

[fmartinou]

I got abnormal values logged in HA at:

• 27/05/2026 - 07:40 UTC (33.99 kwh sensor.hame_energy_vnse3_0_009b08xxxxxx_total_charging_capacity)

• 27/05/2026 - 07:40 UTC (43.18 kwh sensor.hame_energy_vnse3_0_009b08xxxxxx_total_discharge_capacity)

• 27/05/2026 - 07:45 UTC (305.94 kwh charge sensor.hame_energy_vnse3_0_009b08xxxxxx_total_charging_capacity)

• 27/05/2026 - 07:45 UTC (388.69 kwh sensor.hame_energy_vnse3_0_009b08xxxxxx_total_discharge_capacity)

Please find below debug logs around these time.

• hm2mqtt.log
• hame-relay.log

Thank you very much for your help

[tomquist]

This hm2mqtt export is from 2026-05-25/26 though — each "Device state … updated" line embeds a "timestamp" field (e.g. "timestamp":"2026-05-26T07:42:52.994Z"), and all 15 readings fall on the 25th/26th, none on the 27th. So it's the day before the spike.

Every reading in it is the correct, steady 338.34/430.7 kWh, the 33.99 and 305.94 values aren't in the file.

Could you grab the log covering 2026-05-27 ~07:40–07:45 UTC? That's the only way to tell whether hm2mqtt got bad data from the battery.

[fmartinou]

Oops, very sorry for the mistake.

Below the log from the right day.

hm2mqtt.log

[tomquist]

Thanks, this log has the answer. At 07:43:29 UTC the battery itself sent corrupted counters with the last digit dropped:

normal:  tot_i=33993, tot_o=43187   → 339.93 / 431.87 kWh
07:43:   tot_i=3399,  tot_o=4318    → 33.99  / 43.18  kWh   ← bad
07:48:   tot_i=33993, tot_o=43187   → back to normal

So the bad value comes straight from the battery and hm2mqtt just divides by 100 and forwards it. And the 305.94/388.69 you saw aren't published values, they're Home Assistant's computed deltas after it treats the dip as a meter reset (339.93 − 33.99 = 305.94, 431.87 − 43.18 = 388.69), which is what spikes the energy chart.

I'll look at adding a sanity check in hm2mqtt that drops an implausible backward jump in these total counters so a single bad reading like this can't poison HA's statistics.

[fmartinou]

Thank you very much for the quick analysis and explanations!

It would be awesome, as you suggest, if hm2mqtt could just detect these invalid data and drop them 👍.

For my understanding, are these data read from the remote Hame mqtt broker?

If so, why the Marstek app doesn't display these anomalies?

[tomquist]

Yes, hm2mqtt receives exactly the payload the battery publishes to the cloud (Hame/Marstek) broker, relayed locally via hame-relay. It's the same data the Marstek app consumes.

The app doesn't show the spike because it just displays the current value, and the glitch recovers on the very next reading. Home Assistant is different: the Energy dashboard derives consumption from the differences between readings of a total_increasing sensor, so a momentary dip-then-recover looks like a meter reset and books the recovery as a huge chunk of energy.

[fmartinou]

Thanks for the explanations; it makes sense 👌