You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add configurable wait-for-fresh-push behavior for event-driven powermeters (#330)
* Stop wait_for_next_message regressions from breaking battery responses
PR #322 wired wait_for_next_message into update_readings so push-based
powermeters serve fresh data on every CT002 request. Two regressions
followed:
1. Slow event-driven meters (e.g. Home Assistant wrapping a P1 that
ticks every 10s, or any source with high THROTTLE_INTERVAL) raise
TimeoutError on every request, which surfaces as "CT002 before_send
failed" warnings and skips the cached value that would have been
perfectly usable (issue #327).
2. MQTT multi-topic kept clearing the event whenever the waker happened
to be a phase that had already published, so any topic still at None
would force the full 5s timeout even though a fresh message had
arrived.
Treat wait_for_next_message as best-effort freshness:
- update_readings caps the wait at 2s and swallows TimeoutError (cached
value is served, which matches behaviour pre-#322).
- Add WAIT_FOR_NEXT_MESSAGE (global [GENERAL] + per-section) so users
can opt out of the wait entirely for sources that always update
slower than the cap. Defaults to true.
- MQTT wait_for_next_message returns on any next message instead of
re-arming the event when not all topics have ever published.
Refactor the closure inside run_device into a module-level
read_ct_powermeter helper so the swallow-timeout behaviour is
unit-testable.
* Revert CHANGELOG entry for wait_for_next_message fix
* Expose WAIT_FOR_NEXT_MESSAGE in the Home Assistant app config
Adds a "Wait For Fresh Home Assistant Reading" toggle (default true) to
the HA app so users with slow-updating source sensors (e.g. P1 smart
meters) can opt out of the up-to-2s freshness wait and serve the
last-known value immediately.
* Honor WAIT_FOR_NEXT_MESSAGE in the Shelly emulator path
The Shelly UDP handler was ignoring the per-powermeter wait flag, so a
Shelly-emulated device would never wait for a fresh push from an
event-driven powermeter (behaviour matched pre-#322). Mirror the CT path:
read the flag when matching addr to powermeter, then best-effort await
``wait_for_next_message(timeout=2)`` with ``TimeoutError`` swallowed.
Also consolidate the duplicate ``[HOMEASSISTANT]`` per-powermeter throttle
example in config.ini.example: keep the more informative
``THROTTLE_INTERVAL = 2`` block (with the "2-3 seconds due to network
latency" note) and drop the stray ``= 1`` duplicate that predated the
``WAIT_FOR_NEXT_MESSAGE`` example.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: ha_addon/translations/en.yaml
+3Lines changed: 3 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -14,6 +14,9 @@ configuration:
14
14
throttle_interval:
15
15
name: Throttling Interval
16
16
description: "Minimum time interval (in seconds) between power meter readings. When set to 0, throttling is disabled for maximum performance. For slower data sources or to prevent control instability, set to 1-3 seconds. Supports decimal values (e.g., 1.5 for 1.5 seconds). Increase this value if you're seeing oscillations or instability with slow data sources."
17
+
wait_for_next_message:
18
+
name: Wait For Fresh Home Assistant Reading
19
+
description: "When enabled (default), the app waits briefly (up to 2 seconds) for Home Assistant to push a fresh value before responding to the battery, keeping control loops on the freshest data. Disable this if your source sensor (e.g. a P1 smart meter) updates slower than 2 seconds — turning it off avoids the needless wait and always serves the last-known value immediately."
17
20
log_level:
18
21
name: Log Level
19
22
description: "Controls the verbosity of log messages. Select 'critical' for only critical errors, 'error' for error messages and above, 'warning' for warnings and above, 'info' for informational messages and above (recommended), or 'debug' for detailed debugging information. Use 'debug' for troubleshooting connection or configuration issues."
0 commit comments