v1.15.5: BLOKYSPOTREBY-OK systematic naming
Revert v1.15.4: BLOKYSPOTREBY-OK is a binary_sensor again, named systematically
v1.15.4 restored the v1.15.1 descriptor-derived name "Heating circuit switch" for BLOKYSPOTREBY-OK. That name was itself misleading — it came from a <row> in okruh.xml whose text describes the adjacent switch control (<switch prop="TO-POVOLENI"/>), not the read-only status flag the row's prop attribute points at.
The six BLOKYSPOTREBY*-OK fields all have the same semantics ("is the HP currently serving this consumer?") and are now named systematically:
| Prop | Czech | English |
|---|---|---|
BLOKYSPOTREBY-OK |
TČ topí okruh | HP heating circuit |
BLOKYSPOTREBY1-OK |
TČ topí bazén 1 | HP heating pool 1 |
BLOKYSPOTREBY2-OK |
TČ topí bazénovou místnost | HP heating pool room |
BLOKYSPOTREBY3-OK |
TČ ohřívá TUV | HP heating DHW |
BLOKYSPOTREBY6-OK |
TČ ohřívá TUV 2 | HP heating DHW 2 |
BLOKYSPOTREBY7-OK |
TČ topí bazén 2 | HP heating pool 2 |
All are binary_sensor with device_class=running. Same as v1.15.3 for this field.
Upgrade notes
If you pinned an automation or dashboard tile to the v1.15.4 sensor.*_heating_circuit_switch, switch it to the binary_sensor the HP is currently heating the circuit. The entity_id will follow Home Assistant's usual slugification of the device + friendly name.