mirror of
https://github.com/home-assistant/home-assistant.io.git
synced 2025-05-09 20:48:59 +00:00
207 lines
7.2 KiB
Markdown
207 lines
7.2 KiB
Markdown
---
|
|
title: "Z-Wave Entity Naming"
|
|
description: "A summary of common entity names."
|
|
---
|
|
|
|
<div class='note'>
|
|
|
|
This is a work in progress, based upon reports in the forum, the author's own devices and reading of various documentation. It will be incomplete, so if you have a device that isn't reported here or have a device that reports a different value, please provide a report in the [Z-Wave section](https://community.home-assistant.io/c/configuration/zwave) of the forum or the `#zwave` channel on [Discord](https://discord.gg/RkajcgS).
|
|
|
|
</div>
|
|
|
|
## Binary Sensor
|
|
|
|
Devices that support the Binary Sensor command class will create one (or more) entities starting with `binary_sensor`. For example, if the node is `door_sensor` then the binary sensor entity will be `binary_sensor.door_sensor`.
|
|
|
|
These will normally be `on` when the sensor is active, otherwise they will be `off`. Some devices use `on` for closed, and some use `on` for open, and some devices allow you to change how they report.
|
|
|
|
## Alarm
|
|
|
|
This is for a single purpose sensor, multi sensors are explained under Multi Sensor.
|
|
|
|
Devices (usually sensors) that support the Alarm command class will create entities starting with `sensor`, and with some generic suffixes, and a suffix that relates to the supported alarm class. For example, the smoke detector `lounge` will have an entity `sensor.lounge_smoke`, and possibly also `sensor.lounge_alarm_type` and `sensor.lounge_alarm_level`. If the device creates a `binary_sensor` entity, it is recommended to use that rather then the `sensor` entity.
|
|
|
|
Note that the older Z-Wave alarm command class version 1 didn't have standardized types, and so each manufacturer specified their own version and type info. With Version 2 the alarm type was standardized to the below list. See the [openzwave alarm command class documents](https://github.com/OpenZWave/open-zwave/wiki/Alarm-Command-Class) for more info. You can see which version your sensor supports via the `zwcfg_0x*.xml` file. An example with version 2 support:
|
|
|
|
```xml
|
|
<CommandClass id="113" name="COMMAND_CLASS_ALARM" version="2" request_flags="2" innif="true">
|
|
```
|
|
|
|
### Alarm Type Entity
|
|
|
|
[//]: # (from the openzwave source found here: https://github.com/OpenZWave/open-zwave/blob/master/cpp/src/command_classes/Alarm.cpp#L56)
|
|
|
|
- Version 2 **alarm_type**:
|
|
- **0**: General purpose
|
|
- **1**: Smoke sensor
|
|
- **2**: Carbon Monoxide (CO) sensor
|
|
- **3**: Carbon Dioxide (CO2) sensor
|
|
- **4**: Heat sensor
|
|
- **5**: Water leak (flood) sensor
|
|
- **6**: Access control
|
|
- **7**: Burglar
|
|
- **8**: Power management
|
|
- **9**: System
|
|
- **10**: Emergency
|
|
- **11**: Clock
|
|
- **12**: Appliance
|
|
- **13**: Home Health
|
|
|
|
- Version 1 (manufacturer-specific) **alarm_type**:
|
|
- **9**: Lock jammed
|
|
- **18**: Lock locked with user code
|
|
- **19**: Lock unlocked with user code
|
|
- **21**: Manual lock
|
|
- **22**: Manual unlock
|
|
- **24**: Locked by RF
|
|
- **25**: Unlocked by RF
|
|
- **27**: Auto lock
|
|
- **33**: User deleted
|
|
- **112**: Master code changed, or user added
|
|
- **113**: Duplicate PIN code error
|
|
- **130**: RF Module power cycled
|
|
- **161**: Tamper alarm
|
|
- **167**: Low battery
|
|
- **168**: Critical battery level
|
|
- **169**: Battery too low to operate
|
|
|
|
### Alarm Level Entity
|
|
|
|
The meaning of the `alarm_level` entity depends on the nature of the alarm sensor.
|
|
|
|
#### Smoke, CO, and CO2
|
|
|
|
- **1**: Detection - will include a Node Location Report
|
|
- **2**: Detection (unknown location)
|
|
- **254**: Unknown event
|
|
|
|
#### Heat
|
|
|
|
- **1**: Overheat detected - will include a Node Location Report
|
|
- **2**: Overheat detected (unknown location)
|
|
- **3**: Rapid temperature rise - will include a Node Location Report
|
|
- **4**: Rapid temperature rise (unknown location)
|
|
- **5**: Underheat detection - will include a Node Location Report
|
|
- **6**: Underheat detection (unknown location)
|
|
- **254**: Unknown event
|
|
|
|
#### Water leak
|
|
|
|
- **1**: Water leak detected - will include a Node Location Report
|
|
- **2**: Water leak detected (unknown location)
|
|
- **3**: Water level dropped - will include a Node Location Report
|
|
- **4**: Water level dropped (unknown location)
|
|
- **254**: Unknown event
|
|
|
|
#### Access control
|
|
|
|
- **1**: Manual lock
|
|
- **2**: Manual unlock
|
|
- **3**: RF lock
|
|
- **4**: RF unlock
|
|
- **5**: Keypad lock - will include the User Identifier of the User Code Report
|
|
- **6**: Keypad unlock - will include the User Identifier of the User Code Report
|
|
- **254**: Unknown event
|
|
|
|
#### Burglar
|
|
|
|
- **1**: Intrusion - will include a Node Location Report
|
|
- **2**: Intrusion (unknown location)
|
|
- **3**: Tampering (case opened)
|
|
- **4**: Tampering (invalid code)
|
|
- **5**: Glass break - will include a Node Location Report
|
|
- **6**: Glass break (invalid code)
|
|
- **254**: Unknown event
|
|
|
|
#### Power Management
|
|
|
|
- **1**: Power applied
|
|
- **2**: AC disconnected
|
|
- **3**: AC re-connected
|
|
- **4**: Surge detection
|
|
- **5**: Voltage drop or drift
|
|
- **254**: Unknown event
|
|
|
|
#### System Alarm
|
|
|
|
- **1**: System hardware failure
|
|
- **2**: System software failure
|
|
- **254**: Unknown event
|
|
|
|
#### Emergency Alarm
|
|
|
|
- **1**: Contact Police
|
|
- **2**: Contact Fire Service
|
|
- **3**: Contact Medical Service
|
|
- **254**: Unknown event
|
|
|
|
#### Alarm Clock
|
|
|
|
- **1**: Wake up
|
|
- **254**: Unknown event
|
|
|
|
### Access Control Entity
|
|
|
|
- **access_control**: These *may* vary between brands
|
|
- **22**: Open
|
|
- **23**: Closed
|
|
- **254**: Deep sleep
|
|
- **255**: Case open
|
|
|
|
If your device has an `access_control` entity, but not a `binary_sensor` equivalent, you can use a [template binary sensor](/integrations/binary_sensor.template/) to create one (here we've defined it as a door, but you can use [any relevant device class](/integrations/binary_sensor/#device-class):
|
|
|
|
{% raw %}
|
|
|
|
```yaml
|
|
binary_sensor:
|
|
- platform: template
|
|
sensors:
|
|
YOUR_SENSOR:
|
|
friendly_name: "Friendly name here"
|
|
device_class: door
|
|
value_template: "{{ is_state('sensor.YOUR_ORIGINAL_SENSOR_access_control', '22') }}"
|
|
```
|
|
|
|
{% endraw %}
|
|
|
|
### Burglar Entity
|
|
|
|
- **burglar**: These *may* vary between brands
|
|
- **0**: Not active
|
|
- **2**: Smoke (?)
|
|
- **3**: Tamper
|
|
- **8**: Motion
|
|
- **22**: Open
|
|
- **23**: Closed
|
|
- **254**: Deep sleep
|
|
- **255**: Case open
|
|
|
|
If your device has a `burglar` entity, but not a `binary_sensor` equivalent, you can use a [template binary sensor](/integrations/binary_sensor.template/) to create one (here we've defined it as a motion sensor, but you can use [any relevant device class](/integrations/binary_sensor/#device-class):
|
|
|
|
{% raw %}
|
|
|
|
```yaml
|
|
binary_sensor:
|
|
- platform: template
|
|
sensors:
|
|
YOUR_SENSOR:
|
|
friendly_name: "Friendly name here"
|
|
device_class: motion
|
|
value_template: "{{ is_state('sensor.YOUR_SENSOR_burglar', '8') }}"
|
|
```
|
|
|
|
{% endraw %}
|
|
|
|
### Source Node ID Entity
|
|
|
|
- **sourcenodeid**: Reports the sensor that generated the alarm - this is only valid for Zensor Net based devices
|
|
|
|
## Multisensor
|
|
|
|
Multi sensor devices will create a number of entities, one for each sensor, potentially a `binary_sensor` entity, and probably also `alarm_type` and `alarm_level` entities.
|
|
|
|
These are all generally self explanatory, however it's worth noting:
|
|
|
|
- **ultraviolet** sensors will usually report zero indoors, as UVB is blocked by glass
|
|
- **luminance** sensors should report in [Lux](https://en.wikipedia.org/wiki/Lux)
|