Naming schema
The default names generated by Home Assistant are unsustainable in the long term and hard to work with. This is how I tediously work around them
Naming of light
entities
light.${area}_${kind}_${placement}
where$placement
is optional and used when needed. examples:light.bedroom_ceiling
light.hallway_lamps_table
Naming of binary_sensor
entities
Naming convention:
binary_sensor.${kind}_${area}_${placement}
If there are more than one type of sensor in a location, they are named in one of the following ways:
binary_sensor.${kind}_${area}_${placement}
binary_sensor.${kind}_${area}_${number}
And then they get all grouped or templated together into a single binary_sensor.${kind}_${area}
. Then
it is often the group/template that it makes sense to show on dashboard and build automations with.
A (non-exhaustive) list of diferent $kind
s of binary_sensor
s:
radar
: mmWave presence detectionmotion
: PIR sensors, motion detectors and "moving target" on mmWave sesorsdoor
: a magnetic/hall/reed/window sensor affixed to a door.window
: same, but affixed to a windowtamper
: tamper detection, commonly found on various Z-Wave sensors
Examples:
binary_sensor.door_${area}
binary_sensor.window_${area}
binary_sensor.motion_${area}
binary_sensor.presence_${area}
Adding new devices
Z-Wave
Default name | Naming standard |
---|---|
switch.outlet_${area} | switch.outlet_${area} for kinds outlet |
sensor.${kind}_${area}_electric_consumption_w | sensor.electric_w_${kind}_${area} |
sensor.${kind}_${area}_electric_consumption_kwh | sensor.electric_kwh_${kind}_${area} |
sensor.${kind}_${area}_electric_consumption_a | sensor.electric_a_${kind}_${area} |
sensor.${kind}_${area}_electric_consumption_v | sensor.electric_v_${kind}_${area} |
update.${kind}_${area}_firmware | update.firmware_${kind}_${locatiom} |
button.${kind}_${area}_ping | button.ping_${kind}_${area} |
sensor.${kind}_${area}_node_status | sensor.node_status_${kind}_${area} |
sensor.${kind}_${area}_successful_commands_rx | sensor.ok_rx_${kind}_${area} |
sensor.${kind}_${area}_successful_commands_tx | sensor.ok_tx_${kind}_${area} |
Additionally I create derivative sensors:
sensor.ok_rx_per_min_${kind}_${area}
ofsensor.ok_rx_${kind}_${area}
sensor.ok_tx_per_min_${kind}_${area}
ofsensor.ok_tx_${kind}_${area}
They are good for spotting devices that are wrongly configured to send too many reports.
Zigbee
First we need to get the device to join the Zigbee network. These devices are not very standardized in how they join a network, and are very picky about distance from the controller. Sometimes there are instructions in Zigbee2mqtt's Device page but not always. Aside from the devices manual, it's a good place to start looking.
Once the device has joined, rename it from the default 0x..
name. The
device's friendly_name
and id are stored in the configuration.yaml
file (using config as storage..). Since i manage this with ansible, i
add something like this to the inventory variable hass_zigbee_devices
, and
ansible will template it into configuration.yaml
(same yaml-structure):
'0x70ac08fffeb4cd10':
friendly_name: light_livingroom_plants
Protip: the web ui has a "Update Home Assistant entity ID" toggle, which defaults to false
Now the device is in Home Assistant, with a mostly-correct name, but
the entity_id
s are wrong and need to be redefined in Home Assistant.
default name | naming standard |
---|---|
select.${device_name}_power_on_behavior | select.power_on_behavior_${device_name} |
sensor.${device_name}_linkquality | sensor.linkquality_${device_name} |
Zigbee devices dont expose a lot of entities.