A quick background: I’m working on supporting some door and window sensors over MQTT since the existing solutions I have found are in adequate. This may be more of a “development” issue, but I’m sticking with “configuration” since I believe the issue stems from my configuration I push to discovery.
Each device has 3 entities: state (open/closed), tamper (tampered/untampered), battery (normal/low). The three discovered configurations as seen in Device Info → MQTT Info are:
Open/Close Sensor:
unique_id: living_room_front_windows_state
name: Living Room Front Windows
device_class: window
payload_on: open
payload_off: closed
qos: 1
availability_topic: home/downstairs/living-room/front-windows/availability
payload_available: online
payload_not_available: offline
state_topic: home/downstairs/living-room/front-windows/state
device:
identifiers:
- 361625
- 362446
name: Living Room Front Windows Sensor
model: Honeywell-Security
suggested_area: Living Room
platform: mqtt
Battery:
unique_id: living_room_front_windows_battery
name: Living Room Front Windows battery
device_class: battery
payload_on: low
payload_off: normal
qos: 1
availability_topic: home/downstairs/living-room/front-windows/availability
payload_available: online
payload_not_available: offline
state_topic: farrington/home/living-room/front-windows/battery
device:
identifiers:
- 361625
- 362446
name: Living Room Front Windows Sensor
model: Honeywell-Security
suggested_area: Living Room
platform: mqtt
Tamper:
unique_id: living_room_front_windows_tamper
name: Living Room Front Windows tamper
device_class: safety
payload_on: tampered
payload_off: untampered
qos: 1
availability_topic: home/downstairs/living-room/front-windows/availability
payload_available: online
payload_not_available: offline
state_topic: home/downstairs/living-room/front-windows/tamper
device:
identifiers:
- 361625
- 362446
name: Living Room Front Windows Sensor
model: Honeywell-Security
suggested_area: Living Room
platform: mqtt
The Device Info page shows everything the way I would expect. I see all three entities, and it even shows the battery health as an icon on the top right of the page:
Similarly, the battery icon shows in the device listing, similar to other battery powered devices: (New users can only attach one image? Screenshot: shows my MQTT, Zigbee, and iPhone in configuration’s device listing w/ black battery icons on the right column)
Now, for what is wrong. My battery entity shows in the main Lovelace “overview” page and mobile app:
(Screenshot: shows all three entities on the room’s card).
This clutters the page and isn’t super obvious from a “health” standpoint. Compare this to the Zigbee sensor, the battery entity doesn’t show. Instead, a black battery icon similar to the one seen earlier will annotate the entities when the battery is unhealthy (Screenshot showing what I just said)
So, how do I get hass to treat the battery in a similar fashion? I looked through config options and the entity battery_level_topic
attribute looked promising. However, when I specify bat_lev_t
, I get:
voluptuous.error.MultipleInvalid: extra keys not allowed @ data['battery_level_topic']
Any thoughts? Thanks!