[basmeerman]

Why

A setting changed component with its write tier — sensor ↔ number, binary_sensor ↔ switch. The domain is part of the entity id, so each toggle was a delete plus a register: every hand-written dashboard, automation, template and statistics series referencing the old id broke, silently. Worse, HA restores deleted registry rows by unique_id, so on a 6-pack install enabling both tiers flipped 204 entities and brought 156 pre-2.2.0 ids back from the dead, needing a second rename_entities.py --apply to repair.

What changes

Each setting is published as two entities:

	Entity	Exists
Read-only twin	sensor.bms_1_maximum_charge_current	always
Control	number.bms_1_maximum_charge_current_control	only while its write tier is on

Packed bits likewise: binary_sensor.bms_1_smart_sleep + switch.bms_1_smart_sleep_control.

The twin's id is stable for the life of the install. The control appears when you enable a tier and disappears when you disable it — and nothing else moves. Both share the existing control/<param> state topic; the control's command_topic is the existing control/<param>/set, so the write path HA → MQTT → RS485 is unchanged, as is the write executor's tier gating.

Why two entities rather than one

MQTT discovery cannot express a read-only number or switch: command_topic is vol.Required in MQTT_RW_SCHEMA, which both platforms extend. I checked that specifically, including that MQTT_ENTITY_COMMON_SCHEMA does not later downgrade it — voluptuous extend() overrides keys, and the vol.Optional(CONF_COMMAND_TOPIC) elsewhere belongs to DEVICE_DISCOVERY_SCHEMA. HA also has no per-entity read-only flag; discussion #13 is open with nothing shipped, and its author notes "unavailable" is not a substitute because it hides the value.

Upgrade

The control topic older versions published under the setting's own object_id is now always cleared, so those entities vanish on first start instead of lingering or being restored by unique_id.

Hand-written dashboards referencing a setting's number.* / switch.* id need pointing at either the stable read-only id (to display) or the new …_control id (to change).

Test plan

• ruff, mypy, pytest — 575 passed, 100 % branch coverage
• Drift check across all four tier combinations: 100 / 111 / 123 / 134 entities (+11 basic, +23 safety)
• With both tiers off the generated dashboard is byte-identical to 2.3.0
• Tests pin: twin published whatever the tier, control only when on, legacy topic always cleared, both twins of a hidden unverified entity removed
• On HA: enable a tier, confirm the control appears and writes reach the BMS while the twin keeps its id
• On HA: disable it again, confirm the control disappears and nothing else changes

Closes #23

🤖 Generated with Claude Code