Test Zooz ZEN17 FW 1.4

[blhoward2]

Zooz ZEN17 first-go at testing fw 1.4.

Compat flag required

I'm not sure this fw really changes any functionality (whether due to it or our end). I tried it without the compat flag to preserve the root endpoint and we went back to mapping the message to the first endpoint 1, causing endpoint 1 to flip states when endpoint two changed.

2021-04-16T02:36:46.943Z DRIVER » [Node 003] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      4
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      0
                                    │ destination: 2
                                    └─[BinarySwitchCCSet]
                                        target value: true
2021-04-16T02:36:46.948Z SERIAL « [ACK]                                                                   (0x06)
2021-04-16T02:36:46.953Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2021-04-16T02:36:46.954Z SERIAL » [ACK]                                                                   (0x06)
2021-04-16T02:36:46.957Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-04-16T02:36:46.964Z SERIAL « 0x010500130400ed                                                     (7 bytes)
2021-04-16T02:36:46.965Z SERIAL » [ACK]                                                                   (0x06)
2021-04-16T02:36:46.968Z DRIVER « [REQ] [SendData]
                                    callback id:     4
                                    transmit status: OK
2021-04-16T02:36:46.978Z CNTRLR   [Node 003] [~] [Binary Switch] currentValue: false => true        [Endpoint 2]
2021-04-16T02:36:47.240Z SERIAL « 0x010b00040003052503ffff00d0                                        (13 bytes)
2021-04-16T02:36:47.242Z CNTRLR   [Node 003] [~] [Binary Switch] currentValue: false => true        [Endpoint 0]
2021-04-16T02:36:47.243Z CNTRLR   [Node 003] [~] [Binary Switch] targetValue: false => true         [Endpoint 0]
2021-04-16T02:36:47.244Z CNTRLR   [Node 003] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 0]
                                  ds"} => {"value":0,"unit":"seconds"}
2021-04-16T02:36:47.244Z SERIAL » [ACK]                                                                   (0x06)
2021-04-16T02:36:47.245Z DRIVER « [Node 003] [REQ] [ApplicationCommand]
                                  └─[BinarySwitchCCReport]
                                      current value: true
                                      target value:  true
                                      duration:      [Duration: 0 seconds]
2021-04-16T02:36:47.250Z CNTRLR   [Node 003] Mapping unsolicited report from root device to first supporting end
                                  point #1
2021-04-16T02:36:47.251Z CNTRLR   [Node 003] [~] [Binary Switch] currentValue: false => true        [Endpoint 1]
2021-04-16T02:36:47.254Z CNTRLR   [Node 003] [~] [Binary Switch] targetValue: false => true         [Endpoint 1]
2021-04-16T02:36:47.256Z CNTRLR   [Node 003] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 1]
                                  ds"} => {"value":0,"unit":"seconds"}
2021-04-16T02:36:47.264Z SERIAL « 0x010f0004000309600d02002503ffff00b7                                (17 bytes)
2021-04-16T02:36:47.265Z CNTRLR   [Node 003] [~] [Binary Switch] currentValue: true => true         [Endpoint 2]
2021-04-16T02:36:47.268Z CNTRLR   [Node 003] [~] [Binary Switch] targetValue: true => true          [Endpoint 2]
2021-04-16T02:36:47.270Z CNTRLR   [Node 003] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 2]
                                  ds"} => {"value":0,"unit":"seconds"}
2021-04-16T02:36:47.272Z SERIAL » [ACK]                                                                   (0x06)
2021-04-16T02:36:47.277Z DRIVER « [Node 003] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      2
                                    │ destination: 0
                                    └─[BinarySwitchCCReport]
                                        current value: true
                                        target value:  true
                                        duration:      [Duration: 0 seconds]
2021-04-16T02:36:47.999Z SERIAL » 0x010d00130306600d0002250225058c                                    (15 bytes)
2021-04-16T02:36:48.001Z DRIVER » [Node 003] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      5
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      0
                                    │ destination: 2
                                    └─[BinarySwitchCCGet]
2021-04-16T02:36:48.006Z SERIAL « [ACK]                                                                   (0x06)
2021-04-16T02:36:48.017Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2021-04-16T02:36:48.018Z SERIAL » [ACK]                                                                   (0x06)
2021-04-16T02:36:48.020Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-04-16T02:36:48.027Z SERIAL « 0x010500130500ec                                                     (7 bytes)
2021-04-16T02:36:48.028Z SERIAL » [ACK]                                                                   (0x06)
2021-04-16T02:36:48.030Z DRIVER « [REQ] [SendData]
                                    callback id:     5
                                    transmit status: OK
2021-04-16T02:36:48.040Z SERIAL « 0x010f0004000309600d02002503ffff00b7                                (17 bytes)
2021-04-16T02:36:48.043Z CNTRLR   [Node 003] [~] [Binary Switch] currentValue: true => true         [Endpoint 2]
2021-04-16T02:36:48.049Z CNTRLR   [Node 003] [~] [Binary Switch] targetValue: true => true          [Endpoint 2]
2021-04-16T02:36:48.052Z CNTRLR   [Node 003] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 2]
                                  ds"} => {"value":0,"unit":"seconds"}
2021-04-16T02:36:48.055Z SERIAL » [ACK]                                                                   (0x06)
2021-04-16T02:36:48.065Z DRIVER « [Node 003] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      2
                                    │ destination: 0
                                    └─[BinarySwitchCCReport]
                                        current value: true
                                        target value:  true
                                        duration:      [Duration: 0 seconds]

Immediately upon including:

initial interview.log

I then readded the compat flag and changed the type for SW1 to a water sensor. This should cause a binary water sensor to be created. Endpoint 1 would remain as that is really for Relay 1 (R1).

Immediately thereafter:

node_2 (change endpoint 1 to water, no interview).json.zip

Oddly, a binary sensor was created in zjs2mqtt but it was type Any and then it disappeared after I re-interviewed the node:

interview after type change before exclude.log

node_2 (change endpoint 1 to water, after intervew, binary sensor disappeared).json.zip

Exclude/Include

I then did an exclude and include without resetting, which is what the manual has you do under the old firmware. That worked and a new sensor was created:

exclude and reinclude.log

node_2 (change endpoint 1 to water, after exclude and include, gains water sensor).json.zip

Temporarily working dynamically

Now, here is what is weird. I've changed the type of SW1 to and done an export/import to get that appear. On a whim I changed SW2 and poof, a correct binary sensor appeared?

post-include_on_the_fly_changes_to_other_endpoint_work_too.log

Changing the type of SW2 again did not work, however. And then it disappeared on a reinterview.

Conclusion

Ultimately, so far this is how it all worked under version 1.3 too.

[AlCalzone]

Initial interview:

2021-04-16T01:41:07.387Z DRIVER « [Node 002] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCEndPointReport]
                                      endpoint count (individual): 2
                                      count is dynamic:            false
                                      identical capabilities:      true
                                      endpoint count (aggregated): 0

still reports 2 endpoints, and the count is not reported to be dynamic.

Oddly, a binary sensor was created in zjs2mqtt but it was type Any and then it disappeared after I re-interviewed the node

The device just sends a binary sensor report. None of the endpoints reflect this capability, so it vanishes after a re-interview. But that is because you needed to re-include. After the re-inclusion, the CC appears:

2021-04-16T01:48:09.375Z CNTRLR   finished adding node 3:
                                    basic device class:    Routing Slave
                                    generic device class:  Binary Switch
                                    specific device class: Unused
                                    supported CCs: 
                                    · Basic (0x20)
                                    · Binary Switch (0x25)
                                    · Z-Wave Plus Info (0x5e)
                                    · Association (0x85)
                                    · Multi Channel Association (0x8e)
                                    · Association Group Information (0x59)
                                    · Transport Service (0x55)
                                    · Version (0x86)
                                    · Manufacturer Specific (0x72)
                                    · Device Reset Locally (0x5a)
                                    · Powerlevel (0x73)
                                    · Configuration (0x70)
                                    · Multi Channel (0x60)
                                    · Security 2 (0x9f)
                                    · Supervision (0x6c)
                                    · Firmware Update Meta Data (0x7a)
                                    · Notification (0x71)
                                    · Binary Sensor (0x30)

and now the device reports 2 static endpoints but with different capabilities:

2021-04-16T01:48:10.704Z DRIVER « [Node 003] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCEndPointReport]
                                      endpoint count (individual): 2
                                      count is dynamic:            false
                                      identical capabilities:      false
                                      endpoint count (aggregated): 0

Endpoint 1 now has a binary sensor, endpoint 2 doesn't:

2021-04-16T01:48:10.785Z CNTRLR « [Node 003] received response for endpoint capabilities (#1):
                                  generic device class:  Binary Switch
                                  specific device class: Unused
                                  is dynamic end point:  false
                                  supported CCs:
                                    · Z-Wave Plus Info
                                    · Binary Switch
                                    · Basic
                                    · Association
                                    · Association Group Information
                                    · Notification
                                    · Binary Sensor
                                    · Multi Channel Association
                                    · Supervision
                                    · Security 2

2021-04-16T01:48:10.825Z CNTRLR « [Node 003] received response for endpoint capabilities (#2):
                                  generic device class:  Binary Switch
                                  specific device class: Unused
                                  is dynamic end point:  false
                                  supported CCs:
                                    · Z-Wave Plus Info
                                    · Binary Switch
                                    · Basic
                                    · Association
                                    · Association Group Information
                                    · Multi Channel Association
                                    · Supervision
                                    · Security 2

Endpoint 1 tells us it has a water sensor like you configured:

2021-04-16T01:48:11.206Z DRIVER « [Node 003] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      1
                                    │ destination: 0
                                    └─[BinarySensorCCSupportedReport]
                                        supported types: Water

On a whim I changed SW2 and poof, a correct binary sensor appeared?
Changing the type of SW2 again did not work, however. And then it disappeared on a reinterview.

The device sent us a binary sensor report but the endpoint capabilities don't seem to reflect that endpoint 2 supports the CC:

2021-04-16T01:52:59.846Z DRIVER « [Node 003] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      2
                                    │ destination: 0
                                    └─[BinarySensorCCReport]
                                        type:  Water
                                        value: false

Did you re-include again after that?

---

I tried it without the compat flag to preserve the root endpoint and we went back to mapping the message to the first endpoint 1, causing endpoint 1 to flip states when endpoint two changed.

Looks like the device sends both an update from the endpoint and the root device. At least for endpoint 2. Do you have a log for the same action on endpoint 1?

---

All in all: These aren't dynamic endpoints - so not what we proposed. These are static endpoints that change their capabilities after a re-inclusion.

And this seems to be another bug (invalid notification type/event):

2021-04-16T01:52:59.807Z SERIAL « 0x0115000400030f600d02007105000000ff000000000006                    (23 bytes)
2021-04-16T01:52:59.815Z DRIVER « [Node 003] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      2
                                    │ destination: 0
                                    └─[NotificationCCReport]
                                        notification type:   Unknown (0x00)
                                        notification status: 255
                                        notification event:  Unknown (0x00)

[blhoward2]

Ok. I emailed them to let them know, copying you.

[blhoward2]

Looks like the device sends both an update from the endpoint and the root device. At least for endpoint 2. Do you have a log for the same action on endpoint 1?

I'll make one later.

[blhoward2]

I think I found a new issue with this fw. My door state on endpoint 2 doesn't change anymore. I also gained a second custom notification entity in the UI:

Neither of these change when I cycle the door but I do see access control messages in the log:

11:26:29.000 DRIVER « [Node 097] [REQ] [BridgeApplicationCommand]
└─[MultiChannelCCCommandEncapsulation]
│ source: 2
│ destination: 0
└─[NotificationCCReport]
notification type: Access Control
notification status: 255
notification state: Window/door is open
11:26:29.003 CNTRLR [Node 097] [~] [Notification] Access Control[Door state]: 23 => 2 [Endpoint 2]
2
11:26:29.007 SERIAL « 0x011800a80001610f600d02007105000000ff061700000000ac79 (26 bytes)
11:26:29.008 SERIAL » [ACK] (0x06)
11:26:29.009 DRIVER « [Node 097] [REQ] [BridgeApplicationCommand]
└─[MultiChannelCCCommandEncapsulation]
│ source: 2
│ destination: 0
└─[NotificationCCReport]
notification type: Access Control
notification status: 255
notification state: Window/door is closed
11:26:29.010 CNTRLR [Node 097] [~] [Notification] Access Control[Door state]: 22 => 2 [Endpoint 2]
3
11:26:29.013 SERIAL « 0x011100a800016108600d02003003000a00acd4 (19 bytes)
11:26:29.013 CNTRLR [Node 097] [Binary Sensor] Door/Window: metadata updated [Endpoint 2]
11:26:29.014 CNTRLR [Node 097] [~] [Binary Sensor] Door/Window: false => false [Endpoint 2]
11:26:29.014 SERIAL » [ACK] (0x06)
11:26:29.015 DRIVER « [Node 097] [REQ] [BridgeApplicationCommand]
└─[MultiChannelCCCommandEncapsulation]
│ source: 2
│ destination: 0
└─[BinarySensorCCReport]
type: Door/Window
value: false
11:26:29.995 SERIAL « 0x010e00a800016105250300000000acb6 (16 bytes)

11:27:13.007 DRIVER « [Node 097] [REQ] [BridgeApplicationCommand]
└─[MultiChannelCCCommandEncapsulation]
│ source: 2
│ destination: 0
└─[NotificationCCReport]
notification type: Access Control
notification status: 255
notification state: Window/door is open
11:27:13.008 CNTRLR [Node 097] [~] [Notification] Access Control[Door state]: 23 => 2 [Endpoint 2]
2
11:27:13.014 SERIAL « 0x011800a80001610f600d02007105000000ff061700000000ab7e (26 bytes)
11:27:13.014 SERIAL » [ACK] (0x06)
11:27:13.014 DRIVER « [Node 097] [REQ] [BridgeApplicationCommand]
└─[MultiChannelCCCommandEncapsulation]
│ source: 2
│ destination: 0
└─[NotificationCCReport]
notification type: Access Control
notification status: 255
notification state: Window/door is closed
11:27:13.015 CNTRLR [Node 097] [~] [Notification] Access Control[Door state]: 22 => 2 [Endpoint 2]
3
11:27:13.025 SERIAL « 0x011100a800016108600d02003003000a00abd3 (19 bytes)
11:27:13.025 CNTRLR [Node 097] [Binary Sensor] Door/Window: metadata updated [Endpoint 2]
11:27:13.026 CNTRLR [Node 097] [~] [Binary Sensor] Door/Window: false => false [Endpoint 2]
11:27:13.026 SERIAL » [ACK] (0x06)
11:27:13.027 DRIVER « [Node 097] [REQ] [BridgeApplicationCommand]
└─[MultiChannelCCCommandEncapsulation]
│ source: 2
│ destination: 0
└─[BinarySensorCCReport]
type: Door/Window
value: false

These were two cycles subsequent cycles so one should be open and one closed. Is this on our end, or theirs?

garage_door.log
garage_door.json.zip