Zwave2mqtt: [bug] Parsing of aeotec ZW122 Water Sensor 6 events/capabilities

[twochannel]

Version 2.1.0

Build/Run method

• [x] Docker
• [ ] PKG
• [ ] Manually built (git clone - npm install - npm run build )

Zwave2Mqtt version: 2.1.0
Openzwave Version: 1.4.1 (whatever is default in the container)

Describe the bug
Water events are not changing status of the entity in home assistant. I see the zwave2mqtt event logs show the a water event and water clear.
2020-01-13 01:18:11.499 Info, Node013, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Flood event:2, status=255
2020-01-13 01:18:14.540 Info, Node013, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Flood event:0, status=255

mqtt events get published to the node/instance/index (specifically 1/1, 1/2, and 1/8 for my testing (alarm, source, and flood, respectively) but the states in home assistant are not updated. I do not see any config mqtt topics that point to these state topics.

To Reproduce
Steps to reproduce the behavior:

• home assistant discovery is turned on
• the mqtt prefix is the same as the discovery prefix (homeassistant)
• water sensor is securely paired (without secure paring the flood and burglar instances/entities do not show up)
• Temperature and battery life do appear to work correctly.

1. Using mqtt explorer or equivalent watch published messages to the topics configured for the water sensor.
2. Compare the config topics payload of state topic with states that are actually published to.
3. Confirm with home assistant, Using integrations or dev-tools/states, note that there is no 'flood' entity. Note that the other index/instances are not updated to match the published messages to their matching topic
4. There is a binary sensor contact entity created, I'm not sure which device feature this aligns to. I do not see it changing state with my testing.

user guide: https://aeotec.freshdesk.com/support/solutions/articles/6000171886-water-sensor-6-user-guide-
tech specs: https://aeotec.freshdesk.com/support/solutions/articles/6000176513-water-sensor-6-technical-specification-

Expected behavior
All device instances/entities should be reflected in mqtt/home assistant. The devices has 4 contacts for water detection, these should show up as unique entities.

Additional context

• The native home assistant zwave integration handled these correctly.
• I'll open a separate bug for the manufacture/model/name showing up as unknown when paired securely.

[robertsLando]

@twochannel

mqtt events get published to the node/instance/index

You said that mqtt events get published but that they don't work on hass. If mqtt events get published why not just manually add a sensor in hass that handles them?

[twochannel]

Thank you, I think I could do that but the ease of discovery is very compelling and wanted share what I was experiencing.

[robertsLando]

@twochannel Can I close this?

[twochannel]

Well, I'd like it to work as expected. I know discovery is beta so maybe I can help if you could point me in a direction. From what I can tell the zwave part of the app looks correct. I didn't see any errors in processing of the zwave messages. Is the mapping of zwave status to mqtt topic/messages something definable through a configuration or is it in the logic of the app? I'm happy to update a config or do more testing.

[twochannel]

I dont know much about javascript but I poked around a bit and I think the alarm type in the switch statement in gateway.js may be why its only publishing topics for level (0), alarm (1), and burglar (10). I'm researching the flood type but wanted to verify 8 is the correct type identifier since I'm seeing 5 mentioned as flood in some home assistant docs for the alarm v2 event. I'm assuming they found some list but I'm not having much luck finding it or if there are newer versions that would explain the sensor using 8 instead of 5. I'm learning as I go so my understanding continues to evolve.

Could this be a straight forward as adding a case for 8 and pointing it to the water_leak entry configuration.js?

I also want to verify 8 is correct for flood by looking at the zwave bytes from the sensor itself but that's going to take me a bit to understand the format.

[Fishwaldo]

This file contains the list of alarm type id’s:
https://github.com/OpenZWave/open-zwave/blob/master/config/NotificationCCTypes.xml

8 seems wrong. The OZW logs should tell you what alarm types are supported/triggered by the device.

[twochannel]

Ok I will look for that. Will that be in the logs on inclusion or just during normal reporting? and will it be some byte value or something more human readable?

Perhaps this?
2020-01-13 01:12:32.295 Detail, Node013, Decrypted Packet: 0x00, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x05, 0x02, 0x00
2020-01-13 01:12:32.301 Detail,
2020-01-13 01:12:32.305 Info, Node013, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Flood event:2, status=255

Taking a wild guess as I try figure this out. If the hex value before the event value (0x05 in this case) is the alarm type, The the byte values in the ozw logs align w/ the link you provided and the ha link I provided above...as expected.
Heat = 0x04
Flood = 0x05
Burglar = 0x07 (aka Home security?)

However, mqtt-topic-wise these are indexed as
Heat = 7
Flood = 8
Burglar = 10
These are the labels in the json payload published to the topic

Fwiw, they're all 3 higher than the spec. Not sure its so simple, that just jumped out at me.

But then what I can't explain is the topics for 0,1, and 2. These are labeled Alarm Type, Alarm Level, Source NodeId. Which do not align w/ your link.

---

The 8 came from watching mqtt explorer during a water test. The label published to the topic was under index 8.

{ "value_id": "13-113-1-8", "node_id": 13, "class_id": 113, "type": "byte", "genre": "user", "instance": 1, "index": 8, "label": "Flood", "units": "", "help": "", "read_only": true, "write_only": false, "min": 0, "max": 255, "is_polled": false, "value": 254 }

[twochannel]

I changed Gateway.js to have a case for 8 for water_sensor so now I see a config topic for the flood sensors and home assistant picked them up. When I tested tonight I was not getting different values. Each time I tested I never saw the expected value of 2. So maybe something is up with either the sensor or the pairing. I may try a new battery and a exclude/include to see if I get the right values. Distance isn't an issue, the sensor is 6' from the stick with no obstructions.

2020-01-17 01:10:27.243 Detail, Node013, Decrypted Packet: 0x00, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x05, 0xfe, 0x00
2020-01-17 01:10:27.244 Detail,
2020-01-17 01:10:27.246 Info, Node013, Response RTT 306 Average Response RTT 287
2020-01-17 01:10:27.249 Info, Node013, Received a MultiChannelEncap from node 13, endpoint 1 for Command Class COMMAND_CLASS_ALARM
2020-01-17 01:10:27.252 Info, Node013, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Flood event:254, status=255
2020-01-17 01:10:27.253 Detail, Node013, Refreshed Value: old value=0, new value=0, type=byte
2020-01-17 01:10:27.256 Detail, Node013, Changes to this value are not verified
2020-01-17 01:10:27.272 Detail, Node013, Refreshed Value: old value=0, new value=0, type=byte
2020-01-17 01:10:27.273 Detail, Node013, Changes to this value are not verified
2020-01-17 01:10:27.275 Detail, Node013, Refreshed Value: old value=0, new value=0, type=byte
2020-01-17 01:10:27.276 Detail, Node013, Changes to this value are not verified
2020-01-17 01:10:27.279 Detail, Node013, Refreshed Value: old value=254, new value=254, type=byte
2020-01-17 01:10:27.280 Detail, Node013, Changes to this value are not verified
2020-01-17 01:10:27.282 Detail, Node013, Expected reply and command class was received

[Fishwaldo]

Is this OpenZWave 1.4 or 1.6? The alarm class was rewritten in 1.6 and the index values are difference.

I don’t support 1.4 anymore

[twochannel]

It is OpenZwave Version 1.4.3496, I'm using the zwave2mqtt docker container and this is what came with it.

Thanks for keeping an eye on this thread. I don't think I have an ozw issue since this worked w/ native home assistant which is 1.4. The only odd thing are those device alarm reports w/ no changing values. Hope to replace battery tonight and maybe repair.

[robertsLando]

@twochannel Use latest-dev docker tag instead of latest, latest-dev uses ozw 1.6

[twochannel]

I setup a new container with latest:dev and have not had much luck. When pairing both securely or non, i only get two sensors, battery and temp.

However, I see this in the logs

2020-01-20 01:29:21.825 Info, Node017, FUNC_ID_ZW_REQUEST_NODE_INFO Request successful.
2020-01-20 01:29:21.850 Detail, Node017, Received: 0x01, 0x1a, 0x00, 0x49, 0x84, 0x11, 0x14, 0x04, 0x07, 0x01, 0x5e, 0x85, 0x59, 0x80, 0x70, 0x7a, 0x71, 0x73, 0x31, 0x86, 0x84, 0x60, 0x8e, 0x98, 0x72, 0x5a, 0xef, 0xa7
2020-01-20 01:29:21.856 Detail,
2020-01-20 01:29:21.863 Info, Node017, UPDATE_STATE_NODE_INFO_RECEIVED from node 17
2020-01-20 01:29:21.864 Info, Node017, Optional CommandClasses for node 17:
2020-01-20 01:29:21.867 Info, Node017, COMMAND_CLASS_ZWAVEPLUS_INFO
2020-01-20 01:29:21.873 Info, Node017, COMMAND_CLASS_ASSOCIATION (Existing)
2020-01-20 01:29:21.874 Info, Node017, CommandClass 0x59 - NOT REQUIRED
2020-01-20 01:29:21.885 Info, Node017, COMMAND_CLASS_BATTERY
2020-01-20 01:29:21.887 Info, Node017, COMMAND_CLASS_CONFIGURATION (Existing)
2020-01-20 01:29:21.888 Info, Node017, CommandClass 0x7a - NOT REQUIRED
2020-01-20 01:29:21.892 Info, Node017, COMMAND_CLASS_NOTIFICATION
2020-01-20 01:29:21.895 Info, Node017, COMMAND_CLASS_POWERLEVEL
2020-01-20 01:29:21.907 Info, Node017, COMMAND_CLASS_SENSOR_MULTILEVEL
2020-01-20 01:29:21.910 Info, Node017, COMMAND_CLASS_VERSION
2020-01-20 01:29:21.913 Info, Node017, COMMAND_CLASS_WAKE_UP (Existing)
2020-01-20 01:29:21.914 Info, Node017, COMMAND_CLASS_MULTI_INSTANCE/CHANNEL (Existing)
2020-01-20 01:29:21.922 Info, Node017, COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION (Existing)
2020-01-20 01:29:21.924 Info, Node017, COMMAND_CLASS_SECURITY
2020-01-20 01:29:21.926 Info, Node017, COMMAND_CLASS_MANUFACTURER_SPECIFIC (Existing)
2020-01-20 01:29:21.927 Info, Node017, COMMAND_CLASS_DEVICE_RESET_LOCALLY
2020-01-20 01:29:21.933 Info, Node017, Optional CommandClasses controlled by node 17:
2020-01-20 01:29:21.944 Info, Node017, None
2020-01-20 01:29:21.945 Detail, Node017, AdvanceQueries queryPending=1 queryRetries=0 queryStage=NodeInfo live=1
2020-01-20 01:29:21.948 Detail, Node017, Expected reply was received
2020-01-20 01:29:21.949 Detail, Node017, Message transaction complete
2020-01-20 01:29:21.951 Detail,
2020-01-20 01:29:21.969 Detail, Node017, Removing current message

and this

OpenZWave Error, Node017, ERROR: Dropping command, expected response not received after 1 attempt(s). Command: "MultiChannel Encapsulated (instance=2): AlarmCmd_Get (Node=17): 0x01, 0x10, 0x00, 0x13, 0x11, 0x09, 0x60, 0x0d, 0x01, 0x02, 0x71, 0x04, 0x00, 0xff, 0x00, 0x25, 0x46, 0x63"

I've rebooted, unpaired/repaired, etc.

[Fishwaldo]

Can you please post the full log?

[Fishwaldo]

The alarmclass get failure is ok. Not all devices will support it.

[twochannel]

Let me know if this has what you need https://pastebin.com/718epTNd

[robertsLando]

@Fishwaldo

[twochannel]

Closing this, I'm on build 3.0.2 w/ ozw 1.6 and things are much better but i still have 2 observations I'll open a new issue for. Thanks!