Regression: Zero-export efficiency for Marstek Venus E degraded by 50% since v2.0.1

[dasphilipt]

What's the issue?

I would like to report an issue regarding the zero-export efficiency. Since updating the AstraMeter add-on from version 1.0.8 to version 2.0.1, the zero-export efficiency has worsened by a factor of 2.
I am fully aware that achieving a 100% perfect zero-export is technically impossible, but the degradation since the update is very noticeable.

• Expected / Previous Behavior (v1.0.8): At night, my power draw from the grid used to be between 0.011 kWh and 0.015 kWh per hour.
• Actual / Current Behavior (v2.0.1): At night, my power draw from the grid has doubled and is now between 0.022 kWh and 0.030 kWh per hour.
  Is this a known issue, or is it known what might be causing this drop in efficiency? Can we expect a future update that restores the previous efficiency levels of v1.0.8?

Your setup

• Installation method: Home Assistant Add-on
• Storage system: Marstek Venus E V148
• Power meter source: Fronius SmartMeter

Configuration

power_input_alias: sensor.netzbezug_ohne_wallbox
power_output_alias: sensor.einspeiseleistung_ohne_wallbox
device_types: shellypro3em
throttle_interval: 1
wait_for_next_message: false
marstek_auto_register_ct_device: false
marstek_mailbox: ""
marstek_password: ""
min_efficient_power: 0
efficiency_rotation_interval: 900
log_level: info

Error messages or logs

# No specific error messages. The issue is a degradation in zero-export efficiency rather than a crash.

Additional info

• My add-on settings were kept exactly the same as in the previous version.
• I have already tried tweaking and experimenting with all conceivable parameters (throttle_interval and wait_for_next_message) in the new version, but unfortunately, there was no improvement.
• Absolutely nothing else was changed—neither the hardware nor any external parameters. The only difference in my setup was the update to v2.0.1.
  Thank you for your help and the amazing work you are doing on this add-on!

[dasphilipt]

Just a quick update: I have now rolled back to version 1.0.8, and the fluctuations for the zero-export are noticeably smaller again.
For additional context: I am fetching the data from my Fronius SmartMeter via Modbus every 0.5 seconds. With v1.0.8, the zero-export handles this data and runs twice as efficiently compared to v2.0.1.
Here is the configuration I am using with 1.0.8:

power_input_alias: sensor.netzbezug_ohne_wallbox
power_output_alias: sensor.einspeiseleistung_ohne_wallbox
poll_interval: 1
disable_absolute_values: true
device_types: ct001, shellypro3em
throttle_interval: 1
log_level: info

Thanks again for looking into this!

[tomquist]

Quick sanity-check first: when you said you tried all combinations of throttle_interval and wait_for_next_message, did that include throttle_interval: 0 together with wait_for_next_message: true specifically? That's the v2.0.x design-intended pairing for HA WebSocket. Each Shelly response is gated on a fresh push with no throttle wrapper adding 0–1 s of latency in between. The throttle wrapper was originally for slow HTTP polling sources; against the new WebSocket cache it mostly just adds lag.

Independent of that, the bigger structural change between 1.0.8 and 2.0.x for your setup is the switch from REST polling to WebSocket subscribe_entities for the HA powermeter. With REST, your two sensors were fetched back-to-back in the same UDP-triggered request, both reflecting HA's state machine at that instant. With WebSocket, each sensor's cached value is updated by independent push frames, so a Shelly read between the two pushes can serve "fresh import − previous-cycle export" (or vice versa). A transient phantom error that didn't exist under REST. Over a night of small fridge/standby cycles that asymmetry can plausibly account for the doubled grid draw, and it would explain why toggling throttle/wait hasn't moved the needle.

Two things worth trying:
1. Single signed sensor via a HA helper. This is the cleanest test of the split-sensor hypothesis. Create a template sensor that does the subtraction once on HA's side, e.g.:

template:
  - sensor:
      - name: "Grid Power (signed, ohne Wallbox)"
        unique_id: grid_power_signed_ohne_wallbox
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {{ (states('sensor.netzbezug_ohne_wallbox') | float(0))
             - (states('sensor.einspeiseleistung_ohne_wallbox') | float(0)) }}
        availability: >
          {{ has_value('sensor.netzbezug_ohne_wallbox')
             and has_value('sensor.einspeiseleistung_ohne_wallbox') }}

Then, in the add-on UI: put that helper in power_input_alias, leave power_output_alias empty, and AstraMeter will read a single cached value with one push event per Fronius cycle (no power_in − power_out across two cache slots). Sign convention is positive = import, negative = export, same as your current setup.

2. If you can spare ~30 min one night, run with log_level: debug and post a short slice of Home Assistant: update_entity_value lines together with the matching Shelly response lines from around the same window. That gives us direct evidence of push cadence and any skew between the two sensors, rather than guessing.

[dasphilipt]

Thank you for this incredibly detailed and insightful explanation! The split-sensor hypothesis regarding the WebSocket push cadence makes perfect sense.

To answer your sanity check: Yes, I actually did try the specific combination of throttle_interval: 0 and wait_for_next_message: true during my initial troubleshooting. However, it didn't improve the efficiency back then. With your explanation about the split sensors and the independent push frames, it now makes perfect sense why toggling those parameters alone didn't work.

Following your main recommendation, I have updated the add-on back to version 2.0.1 and implemented the template helper: Single Signed Sensor: I created the template helper sensor in Home Assistant exactly as you suggested to do the subtraction on HA's side.

Configuration Update: I updated the add-on configuration to use only this single sensor, removed the output alias, and made sure the intended v2.0.1 WebSocket settings are active.

Here is my current configuration under v2.0.1:
YAML

power_input_alias: sensor.netzbezug_einspeisung_ohne_wallbox
power_output_alias: ""
device_types: shellypro3em
throttle_interval: 0
wait_for_next_message: true
marstek_auto_register_ct_device: false
marstek_mailbox: ""
marstek_password: ""
min_efficient_power: 0
efficiency_rotation_interval: 900
log_level: info

I will let this run overnight to monitor the zero-export efficiency with the new single-sensor setup.

If the grid draw fluctuations don't improve tonight, I will change the log_level to debug, capture a short slice of the logs showing the update_entity_value and Shelly response lines as requested, and post them here tomorrow.

Thanks again for the amazing support!

[dasphilipt]

Update after testing the single-sensor setup overnight: the efficiency has improved significantly!

Here are the numbers:

The overall grid draw last night was back down to between 0.012 and 0.018 kWh per hour.

Between 3:00 AM and 4:00 AM, I also installed the update to the new add-on version 2.0.2.

In the two hours following that update, the grid draw was at 0.015 kWh and 0.013 kWh per hour.

Just to confirm the baseline: the devices drawing standby power at night are exactly the same as they were before the initial add-on update, so these numbers are highly comparable. The single-sensor approach definitely solved the WebSocket sync issue for my setup!

I think we can leave it running like this for now, and I will continue to monitor it. If I notice any further anomalies or if the efficiency drops again, I will report back here and provide the debug logs.

One quick question out of curiosity:
Do you have any experience or insights on what amount of hourly grid draw is considered "normal" or optimal for these zero-export setups? I know this is nearly impossible to compare perfectly, as every household has different appliances causing sudden power spikes, and there is always an inevitable physical delay in the hardware control loop. But I’d be interested to know if my ~0.015 kWh/h is roughly as good as it gets!

Thank you!

[tomquist]

Nice! Glad this helped. Yeah, the amount vastly depends on your conditions so it's hard to tell what's normal. If your batteries are typically empty in the morning I recommend adding a small offset (either via the config or via your sensor helper in home assistant) to make it less likely to steer into negatives as long as the batteries are not full. That's what I am doing and I have a feed in of 0,1kWh per day

[dasphilipt]

Yes, in the current season I still have between 30 and 40% SoC left the next morning. Last year I also once integrated an offset, so that in case of doubt I would rather feed in a bit more than draw too much. But actually, it might even make sense to do it in both directions now. Especially because even on bad days, the PV system still delivers enough power to fully charge the battery.
Maybe an offset of 20–40 W, so that it doesn’t become too much either ...

Thanks for the tip and the excellent work — I’ll try a bit of experimenting.