FAQ additions + auto-refresh Supervisor token on reconnect#533
Merged
Conversation
Explains how to find the Distribution Weight entity for each battery (AstraMeter Consumer device in MQTT), locate the SoC sensor, and wire up a Home Assistant automation that sets each battery's weight inversely proportional to its SoC so emptier batteries are prioritised. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vmp95JCXMxff12vamwJLQT
Walkthrough
ChangesDynamic supervisor token authentication
FAQ documentation additions
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vmp95JCXMxff12vamwJLQT
- Firmware: note HMA-1 requires 226+ for CT002/CT003 (#524) - Config: HA Supervisor API key rotates on restart; use a static long-lived token against the regular HA API instead (#498) - Troubleshooting: asymmetric battery capacities — use MIN_EFFICIENT_POWER + distribution weights together for proportional load splitting (#351) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vmp95JCXMxff12vamwJLQT
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vmp95JCXMxff12vamwJLQT
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vmp95JCXMxff12vamwJLQT
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vmp95JCXMxff12vamwJLQT
Contributor
Steering evaluation (base vs head)Overall: 0 improved, 0 regressed, 15 unchanged across 15 metrics — mean 0% (unchanged). Priority: priority-weighted 0% (unchanged) — ✅ no do-no-harm guardrail regressions. Lower is better for every metric. See Metrics are the per-scenario mean of 5 seeds. Aggregate — mean across 32 scenarios
📊 Interactive grid-power charts (zoom / hover / toggle series) are in the self-contained What do these metrics mean?
Per-scenario tables (32 scenarios)full_battery_low_pace — settle 0.0→0.0s, overshoot 0.0→0.0W, RMS 29.1→29.1W
mixed_cadence/eff — settle 50.8→50.8s, overshoot 164.5→164.5W, RMS 21.9→21.9W
mixed_cadence/fair — settle 47.7→47.7s, overshoot 70.4→70.4W, RMS 12.9→12.9W
mixed_cadence_solar/eff — settle 52.5→52.5s, overshoot 384.7→384.7W, RMS 28.6→28.6W
mixed_cadence_solar/fair — settle 56.0→56.0s, overshoot 75.4→75.4W, RMS 23.7→23.7W
mixed_venus_b2500/eff — settle 81.2→81.2s, overshoot 221.9→221.9W, RMS 18.6→18.6W
mixed_venus_b2500/fair — settle 75.4→75.4s, overshoot 231.1→231.1W, RMS 22.3→22.3W
phase_imbalance — settle 53.4→53.4s, overshoot 145.2→145.2W, RMS 30.3→30.3W
single_venus_d_solar — settle 24.2→24.2s, overshoot 94.4→94.4W, RMS 15.9→15.9W
single_venus_d_steps — settle 26.3→26.3s, overshoot 90.3→90.3W, RMS 15.5→15.5W
single_venus_d_washer — settle 0.0→0.0s, overshoot 0.0→0.0W, RMS 61.0→61.0W
single_venus_drain — settle 0.0→0.0s, overshoot 0.0→0.0W, RMS 907.3→907.3W
single_venus_fill — settle 360.0→360.0s, overshoot 0.0→0.0W, RMS 953.6→953.6W
single_venus_noisy — settle 0.0→0.0s, overshoot 0.0→0.0W, RMS 94.3→94.3W
single_venus_pv — settle 0.0→0.0s, overshoot 0.0→0.0W, RMS 60.8→60.8W
single_venus_solar — settle 26.8→26.8s, overshoot 80.3→80.3W, RMS 17.8→17.8W
single_venus_solar_slow — settle 33.9→33.9s, overshoot 68.3→68.3W, RMS 22.8→22.8W
single_venus_steps — settle 26.0→26.0s, overshoot 88.0→88.0W, RMS 14.7→14.7W
single_venus_steps_slow — settle 40.5→40.5s, overshoot 98.5→98.5W, RMS 14.8→14.8W
single_venus_trace — settle 0.0→0.0s, overshoot 0.0→0.0W, RMS 278.9→278.9W
single_venus_washer — settle 0.0→0.0s, overshoot 0.0→0.0W, RMS 61.0→61.0W
two_venus/eff — settle 18.1→18.1s, overshoot 126.1→126.1W, RMS 14.0→14.0W
two_venus/fair — settle 18.4→18.4s, overshoot 116.7→116.7W, RMS 13.8→13.8W
two_venus_noisy/eff — settle 0.0→0.0s, overshoot 0.0→0.0W, RMS 94.3→94.3W
two_venus_noisy/fair — settle 0.0→0.0s, overshoot 0.0→0.0W, RMS 94.2→94.2W
two_venus_slow/fair — settle 41.8→41.8s, overshoot 174.5→174.5W, RMS 14.0→14.0W
two_venus_solar/eff — settle 26.0→26.0s, overshoot 396.6→396.6W, RMS 20.4→20.4W
two_venus_solar/fair — settle 25.9→25.9s, overshoot 151.4→151.4W, RMS 20.4→20.4W
two_venus_trace/eff — settle 0.0→0.0s, overshoot 0.0→0.0W, RMS 283.1→283.1W
two_venus_trace/fair — settle 0.0→0.0s, overshoot 0.0→0.0W, RMS 282.1→282.1W
venus_d_plus_c/eff — settle 20.1→20.1s, overshoot 128.9→128.9W, RMS 14.7→14.7W
venus_d_plus_c/fair — settle 21.6→21.6s, overshoot 121.0→121.0W, RMS 14.6→14.6W
📊 Open the interactive report — |
When IP=supervisor in the [HOMEASSISTANT] section, the token is now read from the SUPERVISOR_TOKEN environment variable on every WebSocket auth and REST fetch, rather than cached once at startup. This means a Home Assistant restart that rotates the Supervisor token is recovered automatically on the next reconnect (5 s later) without any manual intervention or config change. For non-supervisor setups the behaviour is unchanged: a static ACCESSTOKEN from config.ini is used as before. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vmp95JCXMxff12vamwJLQT
…efault The supervisor token FAQ is no longer needed — IP=supervisor now re-reads the token automatically on every connection. Also fix the SoC automation formula: float default changed from 50 to 100 so an unavailable sensor is treated as full (weight 0) rather than silently getting a mid-range weight. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vmp95JCXMxff12vamwJLQT
IP=supervisor now reads SUPERVISOR_TOKEN from the environment on every connection, so writing the token into config.ini is both unnecessary and harmful — it bakes in a value that goes stale if HA restarts while the add-on keeps running, which was the original source of auth errors when users copy the generated config as a starting point. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vmp95JCXMxff12vamwJLQT
tomquist
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
docs/faq.md (1)
293-303: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winClarify
mode: queuedbehavior for multi-battery setups.With
mode: queuedandmax: 2, if more than two batteries trigger simultaneously, excess triggers are dropped—not queued. Recommend either:
- Setting
maxto at least the battery count, or- Using
mode: parallelwith a per-battery concurrency limit.The current tip ("Increase
maxif you have more than two batteries") is correct but understated; users with 3+ batteries may silently lose updates.# Option 1: queued with sufficient headroom mode: queued max: 4 # set to your battery count # Option 2: parallel with per-run safety mode: parallel max: 4🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/faq.md` around lines 293 - 303, Clarify the `mode: queued` guidance in the FAQ example: the current `number.set_value`/battery automation tip underplays that `max: 2` can drop excess simultaneous triggers in multi-battery setups. Update the advice near `mode: queued` to state that `max` should be at least the battery count, or recommend `mode: parallel` with an appropriate concurrency limit, so users with 3+ batteries don’t silently miss updates.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/faq.md`:
- Around line 241-244: The entity ID example in the FAQ is misleading because
this discovery payload only defines name and unique_id, so the final number
entity ID should not be presented as
number.astrameter_consumer_<mac>_distribution_weight unless object_id is
explicitly set. Update the example text in docs/faq.md to describe the entity ID
as derived from Home Assistant’s default naming behavior for the relevant
discovery payload, and keep the explanation aligned with the fields shown in the
payload.
---
Nitpick comments:
In `@docs/faq.md`:
- Around line 293-303: Clarify the `mode: queued` guidance in the FAQ example:
the current `number.set_value`/battery automation tip underplays that `max: 2`
can drop excess simultaneous triggers in multi-battery setups. Update the advice
near `mode: queued` to state that `max` should be at least the battery count, or
recommend `mode: parallel` with an appropriate concurrency limit, so users with
3+ batteries don’t silently miss updates.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 070f842c-de4d-4735-8206-5b996f9988a4
📒 Files selected for processing (6)
docs/faq.mdha_addon/run.shsrc/astrameter/config/config_loader.pysrc/astrameter/config/config_loader_test.pysrc/astrameter/powermeter/homeassistant.pysrc/astrameter/powermeter/homeassistant_test.py
💤 Files with no reviewable changes (1)
- ha_addon/run.sh
Comment on lines
+241
to
+244
| `number.astrameter_consumer_<mac>_distribution_weight`, where `<mac>` is the | ||
| battery's MAC address lowercased with all non-alphanumeric characters removed | ||
| (e.g. a battery with MAC `AA:BB:CC:DD:EE:FF` produces | ||
| `number.astrameter_consumer_aabbccddeeff_distribution_weight`). |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify MQTT discovery payload for distribution_weight entity
rg -n -B5 -A15 'distribution_weight' src/astrameter/mqtt_insights/discovery.pyRepository: tomquist/AstraMeter
Length of output: 1748
Correct the entity ID example This discovery payload only sets name and unique_id, so the final number.<...> should not be described as number.astrameter_consumer_<mac>_distribution_weight unless object_id is set explicitly.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/faq.md` around lines 241 - 244, The entity ID example in the FAQ is
misleading because this discovery payload only defines name and unique_id, so
the final number entity ID should not be presented as
number.astrameter_consumer_<mac>_distribution_weight unless object_id is
explicitly set. Update the example text in docs/faq.md to describe the entity ID
as derived from Home Assistant’s default naming behavior for the relevant
discovery payload, and keep the explanation aligned with the fields shown in the
payload.
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.
Summary
MIN_EFFICIENT_POWERis a per-battery threshold, and how to combine it with Distribution Weight and Efficiency Window Weight for proportional load splitting across batteries of different sizes.IP = supervisorin the[HOMEASSISTANT]section, the Supervisor token is now read from theSUPERVISOR_TOKENenvironment variable on every connection attempt instead of being cached at startup. This means a Home Assistant restart that rotates the token is recovered automatically on the next reconnect (5 s later) with no manual intervention. The generatedconfig.inino longer includesACCESSTOKENfor the supervisor case.Changes
docs/faq.md— new FAQ entries, fixes to entity ID description and SoC formula fallback defaultsrc/astrameter/powermeter/homeassistant.py—access_token: str→token: Callable[[], str]; both auth call sites updatedsrc/astrameter/config/config_loader.py— builds a live env-reading callable whenIP=supervisor, static closure otherwiseha_addon/run.sh— removedACCESSTOKEN=$SUPERVISOR_TOKENfrom the generated config blocktest_create_homeassistant_powermeter_supervisor_tokenaddedSummary by CodeRabbit
Documentation
Bug Fixes