HomeAssistant Discovery

[taylormia]

In the last two months, I’ve moved away from HS3 to Home Assistant for everything - except for ZWave management, and don’t plan on doing anything with HS4.

[Michael McSharry]

Device Type (String) has been depreciated in HS4. It is also a field that is user editable in HS3 so could be problematic for users that have their own purposes for Device Type (String). Have you done anything with HS4?

[taylormia]

I don't have any of these devices on HS3 yet...but will soon and will get you the info when I do. They are valid ZWave command classes and I've seen them on an Ecolink Tilt Sensor for example. The Command Class would show under "Device Type (String)" in the Advanced tab of the device.

[Michael McSharry]

Where do you see Zwave battery or Zwave binary sensor in HS?

[taylormia]

I believe these are the ways HA characterizes some of my devices from zwave2mqtt, but I'm not 100% sure. I got the list below from the HS3 Custom Component page referenced in my earlier post. Also in HA, I see the same type of match up between zwave2mqtt and HA.

• Z-Wave Battery (as Home Assistant sensor)
• Z-Wave Sensor Binary (as Home Assistant binary sensor)
• Z-Wave Switch (as Home Assistant switch)
• Z-Wave Switch Binary (as Home Assistant switch)
• Z-Wave Switch Multilevel (as Home Assistant light)
• Z-Wave Temperature (as Home Assistant sensor)
• Z-Wave Relative Humidity (as Home Assistant sensor)
• Z-Wave Luminance (as Home Assistant sensor)

The Central Scene for a HomeSeer brand Dimmer is characterized by zwave2mqtt in HA as "scene_state" with values shown below:

[Michael McSharry]

A simple question. How do you know from HS a Zwave device is a light or motion sensor or anything in particular?

[taylormia]

I'm sorry Michael, I am not familiar enough with the details of Home Assistant and OpenZwave/Zwave2MQTT to answer your questions. I hope others more aware of HA internals can help here.
For now, I'm planning on using the HS3 Custom Component for Home Assistant which uses the pyhs3 library to support HS3 ZWave devices in HA.
Thanks for your continued support and responsiveness.

[Michael McSharry]

Let us work with this example of family room dimmer light and assess what information HS has about it.

First thing in the protocol is topic "homeassistant/X/Y/Z/config where in this case
X = light, Y = family-room-lights, Z =dimmer

I assume family-room-lights is a room and/or floor in the HS context. dimmer is HS device name. The problem element is X or light in this case. The X is the most important part of discovery as it identifies then nature of the device. What mcsMQTT now has implemented for HS3 is the DeviceType property for X. The available choices in HS for DeviceType are shown below. I'm guessing your dimmer device has DeviceType of Plug-In or No_API. How should mcsMQTT identify this device as being a "light"?

Public Enum eDeviceAPI
No_API = 0 ' All other devices.
Plug_In = 4 ' Device is owned/managed by a plug-in.
Thermostat = 16 ' Device is owned/managed by a plug-in and is a thermostat device.
Media = 32 ' Device is owned/managed by a plug-in and is a media player device.
Security = 8 ' Device is owned/managed by a plug-in and is a security device.
SourceSwitch = 64 ' Device is owned/managed by a plug-in and is a matrix switch device.
Script = 128 ' Device launches a script when the value and/or string changes.
End Enum

The Homeassistant discovery protocol has provisions for several device properties. In this case "brightness_template" is appropriate. It appears HA is expecting brightness to be in range 0 to 255 while zwave2mqtt is providing a value in the range of 0 to 100. Am I correct about HA expectations for a dimmer range? What HS device property should be used to know if the device is a dimmer or not so that the plugin will know if the "brightness_template" should be included in the discovery message? From the HS documentation the most likely candidate is shown below, but the documentation indicates that it is largely unused. Does your zwave dimmer have the Can_Dim property set?

Public Property Can_Dim(ByVal hs As IHSApplication) As Boolean
This property is largely unused in HS3. When set to True and no other device value/status pairs have been assigned to the device, the default value/status pairs assigned will allow for levels/values from 1 to 99 in addition to 0 (Off) and 100 (On).

There is also a ControlUse property that can be set as part of the ValueStatusPair definitions. This property would be good for the enumeration of control states. In the discovery protocol "mode_command_topic" and "mode_state_topic" is used to communicate the state enumeration. I did not see this in the zwave2mqtt screeshots. How does HA become aware that there are four control options for this device? Does your HS dimmer device VSP definitions show all four states?

ePairControlUse is an Enum used in value/status pairs and has the following values:
Public Enum ePairControlUse Not_Specified = 0 _On = 1 _Off = 2 _Dim = 3 _On_Alternate = 4 End Enun

Device hardware and firmware characteristics are disclosed. How important is this in HA? Technology Address property is the only thing I am aware in HS that has this type of information.

Unique ID from the HS perspective is the Device Reference number. I suspect some variant of this number could be used for the discovery.

Name looks to be a combination of location and name. For HS this would be floor_room_name.

[taylormia]

I am assuming that you want mcsMQTT to use Homeassistant Discovery protocol to send the definition of HS Zwave devices so HA is able to create devices and integrate with HS.

That's exactly what I'm looking for...I'm sure many HA users in the same boat as me would like this functionality too. Just read this thread on the HA Community Forums: https://community.home-assistant.io/...refugee/181820

What specific information is used by HA for what you want to do with it. Standard info is the topic to report status, topic to be used to send commands, type of device (e.g. switch, binary sensor, light) device name and device states. For specific types there is other information such as fan speeds, lights color space, etc.

I'm not sure of this info exactly but I can point you to the open source zwave2mqtt site for more info. Below is an example of how a ZWave device (HomeSeer HS-WD100+ Wall Dimmer) from zwave2mqtt is represented in Home Assistant and the MQTT details:




Current Level of Dimmer






ZWave Central Scene:

I can focus on Zwave, but still need to know what information is useful to help with the HA integration.

That would be great. I can help as much as possible

[Michael McSharry]

I am assuming that you want mcsMQTT to use Homeassistant Discovery protocol to send the definition of HS Zwave devices so HA is able to create devices and integrate with HS. What specific information is used by HA for what you want to do with it. Standard info is the topic to report status, topic to be used to send commands, type of device (e.g. switch, binary sensor, light) device name and device states. For specific types there is other information such as fan speeds, lights color space, etc.

mcsMQTT already has HomeAssistant discovery implemented to announce discovery information for devices in HS that have been associated in mcsMQTT. The problem is that it is lame because HS does a very poor job of characterizing devices. There are some provision in HS3 and some in HS4, but they are not the same and seem to be created adHoc based upon what is used by HST plugins.

I can focus on Zwave, but still need to know what information is useful to help with the HA integration.

[taylormia]

I'm not sure of the internals of how zwave2mqtt does the HA Discovery but the result is that MQTT topics (and resultant Home Assistant entities) are created automatically for every ZWave root device and child devices for status and control. I suppose I'm asking for an automated way of doing this integration - but would also like to know how it could be done manually.

[Michael McSharry]

I understand your request at a high level, but I do not know specifically what else mcsMQTT should be doing to support it. Are you asking for mcsMQTT to provide a discovery service for specifically zwave devices in HS? Is there something you cannot do now or is is just a more automated way to setup the integration?

[taylormia]

Hi Michael,
Is it possible with mcsMQTT to do for HS3 ZWave devices what zwave2MQTT does for OpenZwave and Home Assistant Discovery using MQTT.
I'm currently running zwave2mqtt with Home Assistant Discovery and the discovery part works very well, but OpenZwave is not as stable as HS3 is for ZWave. Therefore I would like to use HS3 for ZWave management only but Home Assistant for all automations etc.. mcsMQTT would act as the bridge/gateway between HS3 ZWave devices and Home Assistant.

[Pete]

Thank you Michael.

Tried it. Not a big issue as I have it configured in HS3 and it is working fine.

SetOption19 1 is what you do at the Console page from Tasmota at the IP of the GDO.

20:25:25 CMD: SetOption19 1
20:25:25 MQT: GarageDoor1/RESULT = {"Command":"Unknown"}

hxxtp://192.168.244.220/cm?cmnd=SetOption19%201
RESULT = {"Command":"Unknown"}

[Michael McSharry]

Pete SetOption19 1 is what you do at the Console page from Tasmota at the IP of the GDO.

I took a look at Zigbee2MQTT's implementation of HomeAssistant discovery and it is different. Below is the disclosure for a Xiaomi Aqara water leak sensor. There were three /config messages. One for binary_sensor and two for sensor. What they have done is a separate topic for each json item being disclosed. These being water_leak, battery, and linkquality. While there is a good attempt to define a protocol by HomeAssistant, the interpretation of this by each developer is different and that makes it difficult for something like mcsMQTT (or HomeAssistant) to recognize the actual disclosure. I understand why it was done this way for Zigbee2MQTT as it wants to disclose all of the items it is reporting while Tasmota and ESPHome only disclosed the primary items. Additional logic will be needed in mcsMQTT to recognize the same state topic being declared for multiple items and these items comprising a json payload set of keys.

9:41:04 PM homeassistant/binary_sensor/0x00158d00026e2bf1/water_leak/config=
{"payload_on":true,"payload_off":false,"value_template":"{{ value_json.water_leak }}","device_class":"moisture",
"state_topic":"zigbee/0x00158d00026e2bf1",
"json_attributes_topic":"zigbee/0x00158d00026e2bf1","name":"0x00158d00026e2bf1_water_leak","unique_id":"0x00158d00026e2bf1_water_leak_zigbee","device":{"identifiers":"zigbee2mqtt_0x00158d00026e2bf1","name":"0x00158d00026e2bf1","sw_version":"Zigbee2mqtt 1.2.1","model":"Aqara water leak sensor (SJCGQ11LM)","manufacturer":"Xiaomi"},"availability_topic":"zigbee/bridge/state"}

9:41:04 PM homeassistant/sensor/0x00158d00026e2bf1/battery/config={"unit_of_measurement":"%","device_class":"battery","value_template":"{{ value_json.battery }}",
"state_topic":"zigbee/0x00158d00026e2bf1",
"json_attributes_topic":"zigbee/0x00158d00026e2bf1","name":"0x00158d00026e2bf1_battery","unique_id":"0x00158d00026e2bf1_battery_zigbee","device":{"identifiers":"zigbee2mqtt_0x00158d00026e2bf1","name":"0x00158d00026e2bf1","sw_version":"Zigbee2mqtt 1.2.1","model":"Aqara water leak sensor (SJCGQ11LM)","manufacturer":"Xiaomi"},"availability_topic":"zigbee/bridge/state"}

9:41:04 PM homeassistant/sensor/0x00158d00026e2bf1/linkquality/config={"unit_of_measurement":"-","value_template":"{{ value_json.linkquality }}",
"state_topic":"zigbee/0x00158d00026e2bf1",
"json_attributes_topic":"zigbee/0x00158d00026e2bf1","name":"0x00158d00026e2bf1_linkquality","unique_id":"0x00158d00026e2bf1_linkquality_zigbee","device":{"identifiers":"zigbee2mqtt_0x00158d00026e2bf1","name":"0x00158d00026e2bf1","sw_version":"Zigbee2mqtt 1.2.1","model":"Aqara water leak sensor (SJCGQ11LM)","manufacturer":"Xiaomi"},"availability_topic":"zigbee/bridge/state"}