Fix Tesla/Powerwall data handling and improve robustness of control loop#3232
Open
NicoP-codeing wants to merge 1 commit intoopenWB:masterfrom
Open
Fix Tesla/Powerwall data handling and improve robustness of control loop#3232NicoP-codeing wants to merge 1 commit intoopenWB:masterfrom
NicoP-codeing wants to merge 1 commit intoopenWB:masterfrom
Conversation
…d gateway diagnostics - add structured HTTP error handling in PowerwallHttpClient - distinguish transport, HTTP and JSON parsing failures - support fail_fast=False for non-critical requests - track cycle_failed and cookie_renewed state across one polling cycle - add fail-fast handling in device.py - stop remaining Tesla component updates once a critical Powerwall request fails - log native TCP connection state diagnostics via /proc/net/tcp(/tcp6) - emit periodic session / connection health logs - keep cookie reuse, but mark startup + reauth cycles explicitly - reduce /api/status traffic in counter.py - fetch firmware only after startup or after a new auth cookie was negotiated - treat /api/status as non-critical so it cannot fail the whole cycle - keep import/export counters based on aggregate["site"]["energy_imported/exported"] - do not use summed per-phase energy counters as meter source - keep /api/meters/site for phase details only - add derived fallback currents and signed power factors from P/Q/U when Tesla/Neurio currents are 0 - expose additional diagnostics such as frequency / serial number - add throttled debug logging to compare aggregate counters with per-phase sums - restore aggregate-based site counters so load management works correctly again
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
see also OpenWB Forum entry: https://forum.openwb.de/viewtopic.php?t=11634
Problem
Tesla/Powerwall sometimes provides unusable or inconsistent per-phase energy values.
/api/status is not critical for the control loop, but currently can still affect it.
Missing current values from Tesla/Neurio result in incomplete data, causing load management to fail.
Critical HTTP errors currently do not stop the Tesla cycle, which can lead to cascading issues.
Changes
Restored aggregate-based import/export counters (site-level data)
Per-phase energy is now used for diagnostic purposes only
Reduced /api/status usage and marked it as non-critical
Added fallback calculation for currents and power factor from P/Q/U
Implemented fail-fast behavior for critical requests
Added additional diagnostics and session logging
Motivation / Background
The main goal of this change is to restore reliable load management by using per-phase values for current-related calculations and diagnostics while keeping consistent aggregate site import/export counters.
Additional improvements were made to increase robustness and observability of the Tesla/Powerwall integration, especially in cases of incomplete data or intermittent API issues.
Testing
Tested with a real Tesla Powerwall setup
Verified that load management works reliably again
Checked that import/export counters are consistent and plausible
Simulated missing current values → fallback calculation works
Simulated API timeouts → control loop continues without cascading failures