Drop the redundant system mode sensor #86

Merged

rob merged 1 commit from fix/drop-mode-sensor into main

2026-09-24 19:12:16 +00:00

Claude commented

2026-09-24 18:55:32 +00:00

Collaborator

CCS-HA-52. There were two representations of system mode on the bridge device: the "System mode" select and the diagnostic "System mode last known value" sensor. This drops the sensor.

No functionality moved over, because there was nothing to move: the select's extra_state_attributes already carried the mode word (including shutdown and values this build has no word for, which the select's own current_option can't show), plus set_by, origin and latched. Retargeted the tests that read the sensor's state at the select's mode attribute instead.

CampervanModeEntity had one subclass left after the sensor went, so it's folded into CampervanSystemMode directly rather than kept as a base class of one.

The retired sensor entity will linger, disabled-looking but present, in the entity registry until someone deletes it by hand — nothing here purges it.

CCS-HA-52. There were two representations of system mode on the bridge device: the "System mode" select and the diagnostic "System mode last known value" sensor. This drops the sensor. No functionality moved over, because there was nothing to move: the select's `extra_state_attributes` already carried the `mode` word (including shutdown and values this build has no word for, which the select's own `current_option` can't show), plus `set_by`, `origin` and `latched`. Retargeted the tests that read the sensor's state at the select's `mode` attribute instead. `CampervanModeEntity` had one subclass left after the sensor went, so it's folded into `CampervanSystemMode` directly rather than kept as a base class of one. The retired sensor entity will linger, disabled-looking but present, in the entity registry until someone deletes it by hand — nothing here purges it.

Claude added 1 commit

2026-09-24 18:55:32 +00:00

Drop the redundant system mode sensor

Lint, type check and test / hassfest (pull_request) Successful in 11s

Details

Lint, type check and test / quality (pull_request) Successful in 1m58s

Details

Lint, type check and test / release (pull_request) Has been skipped

Details

e64e574675

The select already carries the same mode word, source, origin and latch state in its extra_state_attributes, including modes it does not offer as an option (shutdown, unrecognised values), so nothing is lost by removing the sensor. Folded the now single-subclass CampervanModeEntity into CampervanSystemMode.

Claude reviewed

2026-09-24 18:57:40 +00:00

Claude left a comment

Checked the claim in the PR body against the code: the select's extra_state_attributes["mode"] does carry the full mode word for both shutdown and out-of-band values (0x7F etc), same as the deleted sensor's native_value did — nothing is lost. The set_by/origin/latched attributes and the async_add_mode_listener registration moved across unchanged.

No leftover references to CampervanModeReading, CampervanModeEntity, SENSOR_KEY or reading_of anywhere in the tree.

The retargeted tests in tests/test_modes.py still assert the same facts the old reading_of() ones did (shutdown reported while current_option/state stays unknown, unrecognised mode kept as 0x.., mode belongs to the bridge device, confirmed shutdown broadcast) — just read off select_of(hass)'s mode attribute instead of a separate entity. Nothing weakened.

Folding CampervanModeEntity into CampervanSystemMode is the right call now it has one subclass — matches this repo's preference for deleting over keeping a one-implementation abstraction.

ruff check, ruff format --check and the full pytest suite (1207 passed, 3 skipped) all pass in the worktree.

PR body is accurate, including the honest callout that the retired sensor will linger in the entity registry until removed by hand — worth knowing but not a reason to block this.

No findings to act on — this one's clean.

Checked the claim in the PR body against the code: the select's `extra_state_attributes["mode"]` does carry the full mode word for both `shutdown` and out-of-band values (`0x7F` etc), same as the deleted sensor's `native_value` did — nothing is lost. The `set_by`/`origin`/`latched` attributes and the `async_add_mode_listener` registration moved across unchanged. No leftover references to `CampervanModeReading`, `CampervanModeEntity`, `SENSOR_KEY` or `reading_of` anywhere in the tree. The retargeted tests in `tests/test_modes.py` still assert the same facts the old `reading_of()` ones did (shutdown reported while `current_option`/state stays unknown, unrecognised mode kept as `0x..`, mode belongs to the bridge device, confirmed shutdown broadcast) — just read off `select_of(hass)`'s `mode` attribute instead of a separate entity. Nothing weakened. Folding `CampervanModeEntity` into `CampervanSystemMode` is the right call now it has one subclass — matches this repo's preference for deleting over keeping a one-implementation abstraction. `ruff check`, `ruff format --check` and the full `pytest` suite (1207 passed, 3 skipped) all pass in the worktree. PR body is accurate, including the honest callout that the retired sensor will linger in the entity registry until removed by hand — worth knowing but not a reason to block this. No findings to act on — this one's clean.

rob merged commit fa1ce574cf into main

2026-09-24 19:12:16 +00:00

rob deleted branch fix/drop-mode-sensor

2026-09-24 19:12:16 +00:00

rob referenced this pull request from a commit

2026-09-24 19:12:17 +00:00

Merge pull request 'Drop the redundant system mode sensor' (#86) from fix/drop-mode-sensor into main