Skip to content

Release 2.6.6: fix entity prefix, Vigicrues 206, rain rate sawtooth, config flow (#132, #133, #134, #135) - #136

Merged
kmich merged 2 commits into
mainfrom
claude/github-issues-review-d2c575
Aug 11, 2026
Merged

Release 2.6.6: fix entity prefix, Vigicrues 206, rain rate sawtooth, config flow (#132, #133, #134, #135)#136
kmich merged 2 commits into
mainfrom
claude/github-issues-review-d2c575

Conversation

@kmich

@kmich kmich commented Aug 11, 2026

Copy link
Copy Markdown
Owner

Summary

Fixes 4 open bug reports in a single 2.6.6 patch release.

Fixed

  • Entity prefix consistency (Prefix consistency (ws_ vs weather_station_) #134): most sensors (temperature, humidity, pressure, wind, and the two Vigicrues river sensors) ignored the configured entity prefix on a fresh install and were created as sensor.weather_station_* instead of sensor.{prefix}_*, breaking the pre-built dashboards. Root cause: _attr_suggested_object_id is treated by Home Assistant as object_id_base, which gets prefixed with the device name whenever has_entity_name = True (used by every entity here) — it does not behave like a raw object id in that case. All platforms now set entity_id directly at construction time instead, which HA honours verbatim regardless of has_entity_name. This also let us drop the ad-hoc "rename back to the expected id on every restart" workaround a few platforms had grown, which had its own bug of silently reverting a user's manual rename on every restart.
  • Vigicrues auto-detect and station picker stuck on HTTP 206 (Vigicrues auto-detect always returns HTTP 206 and never resolves a station list #133): Hub'Eau's station-lookup endpoint routinely answers HTTP 206 (Partial Content) rather than 200 whenever the result set doesn't include every matching station — normal, not an error, and the same coordinator already accepted it for the observations endpoint. Auto-detect and the config/options flow's station dropdown only accepted a strict 200, so auto-detect looped on a warning every ~15 minutes and the manual station picker only ever showed "Auto". Both now accept 206 alongside 200.
  • Rain rate sawtooth (Rain rate #132): rain rate was computed as the instantaneous delta since the previous ~60s poll cycle. When the underlying rain-total sensor only updates in discrete bucket-tip increments, a tip landing inside one poll cycle read as a brief, disproportionate spike (e.g. 56 mm/h from a single tip) that decayed back to zero before the next tip — repeating for as long as it rained. Rain rate is now averaged over a 10-minute sliding window of the same rain-total history already tracked for the 1h/24h accumulation sensors.
  • Config flow: optional sensor fields couldn't be cleared (config flow - cannot empty optional fields #135): optional source-sensor pickers (and the named-room temp/humidity/CO₂ pickers) pre-filled auto-detected guesses using a hard default=, which Home Assistant's entity picker cannot be cleared back to empty — a wrong/unavailable/wrong-type guess blocked saving entirely. Switched to description={"suggested_value": ...}, which still pre-fills the same suggestion but leaves the field genuinely clearable.

Notes

  • Version bumped to 2.6.6 in manifest.json and pyproject.toml.
  • Existing entities already stuck under the wrong weather_station_ prefix are not renamed automatically (would risk clobbering other user renames) — the Prefix consistency (ws_ vs weather_station_) #134 fix only affects newly created entities.
  • All fixes covered by new/updated tests; full suite passes (311 tests).

Test plan

  • python -m pytest tests/ — 311 passed
  • python -m ruff check — clean
  • Manual smoke test in a real HA instance recommended before tagging the release

🤖 Generated with Claude Code

kmich and others added 2 commits August 11, 2026 14:25
…config flow (issues #132-#135)

- Entity prefix consistency (#134): most sensor/binary_sensor/event/river
  entities used _attr_suggested_object_id, which HA treats as object_id_base
  and prefixes with the device name ("weather_station_") instead of the
  configured prefix whenever has_entity_name=True. All platforms now set
  entity_id directly at construction, which HA honours verbatim. This also
  removes the ad-hoc "force entity_id back on every restart" workaround a
  few platforms had grown, which itself silently reverted user renames.

- Vigicrues auto-detect/station picker stuck on HTTP 206 (#133): Hub'Eau's
  station-lookup endpoint routinely answers 206 (Partial Content), not 200,
  when the result set is incomplete - normal, not an error, and already
  accepted for the observations endpoint. Auto-detect and the config/options
  flow's station dropdown now accept 206 alongside 200.

- Rain rate sawtooth (#132): rate was computed as the instantaneous delta
  since the previous ~60s poll. A single bucket-tip landing inside one poll
  read as a brief extreme spike (e.g. 56 mm/h) that decayed to zero before
  the next tip. Rate is now averaged over a 10-minute sliding window of the
  same rain-total history already tracked for accumulation sensors.

- Config flow: optional sensor fields couldn't be cleared (#135): optional
  source/room sensor pickers used default=<guessed sensor>, which HA's
  entity picker cannot clear back to empty, blocking save whenever the
  guess was wrong/unavailable/wrong-type. Switched to
  description={"suggested_value": ...}, which still pre-fills but stays
  clearable.

All four verified against source and covered by new/updated tests
(311 passed). Version bumped to 2.6.6 in manifest.json and pyproject.toml.
The validate_dashboard_entities.py script statically greps binary_sensor.py
for f"{prefix}_..." to build its known-entity allowlist; the #134 fix
changed that to f"binary_sensor.{prefix}_..." (entity_id set directly
instead of _attr_suggested_object_id), so the regex needs updating to
match. Also applies ruff format to the optional_sources_opt field
expression from the #135 fix.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@kmich
kmich merged commit 25a00ec into main Aug 11, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant