ZEN17 endpoints improperly mapped

Describe the bug

The new Zooz ZEN17 Universal Relay allows the two inputs (S1/S2) to be decoupled from control of the two relays (R1/R2). The prototypical use case for this is a garage door connected to R1 and a reed switch connected to S2, which is templated in HA to be the open/close state of the door.

At present, when S2 is decoupled from R2, a change to S2 causes R1 to switch. The log file shows:

14:10:17.365 CNTRLR   [Node 140] Mapping unsolicited report from root device to first supporting end
                      point #1

Adding the preserveRootApplicationCCValueIDs compat flag to the device file fixes this aspect and a third entity is created for the root endpoint. I’ve merged a draft PR to this effect.

However, S2 changing still causes R2 to physically change. I’m unsure if this is a device bug (not respecting the parameter setting) or we’re commanding the R2 endpoint to on. I believe this is a device issue?

14:25:40.237 DRIVER « [Node 140] [REQ] [ApplicationCommand]
           └─[BinarySwitchCCReport]
             current value: true
             target value: true
             duration:   [Duration: 0seconds]
14:25:40.312 DRIVER « [Node 140] [REQ] [ApplicationCommand]
           └─[MultiChannelCCCommandEncapsulation]
            │ source:   2
            │ destination: 0
            └─[BinarySwitchCCReport]
              current value: true
              target value: true
              duration:   [Duration: 0seconds]

Additionally, commanding S1 to on causes the root endpoint to also turn on, so this may confuse HA/users. I’m unsure if its avoidable. (It does technically work because the root endpoint stays on if either R1 or R2 is on, so what happens at present is you command S1 on, R1 triggers door (then goes back off), root endpoint turns on with S1, reed sensor opens, report is received from S2, R2 physically turns on (shouldn’t happen), S2 goes off, R2 goes off, root endpoint goes off.)

14:34:20.307 DRIVER » [Node 140] [REQ] [SendData]
           │ transmit options: 0x25
           │ callback id:   210
           └─[MultiChannelCCCommandEncapsulation]
            │ source:   0
            │ destination: 1
            └─[BinarySwitchCCSet]
              target value: true
14:34:20.316 DRIVER « [RES] [SendData]
            was sent: true
14:34:20.390 DRIVER « [REQ] [SendData]
            callback id:   210
            transmit status: OK
14:34:20.814 DRIVER « [Node 140] [REQ] [ApplicationCommand]
           └─[BinarySwitchCCReport]
             current value: true
             target value: true
             duration:   [Duration: 0seconds]
14:34:20.884 DRIVER « [Node 140] [REQ] [ApplicationCommand]
           └─[MultiChannelCCCommandEncapsulation]
            │ source:   1
            │ destination: 0
            └─[BinarySwitchCCReport]
              current value: true
              target value: true
              duration:   [Duration: 0seconds]
14:34:21.444 DRIVER » [Node 140] [REQ] [SendData]
           │ transmit options: 0x25
           │ callback id:   211
           └─[MultiChannelCCCommandEncapsulation]
            │ source:   0
            │ destination: 1
            └─[BinarySwitchCCGet]
14:34:21.452 DRIVER « [RES] [SendData]
            was sent: true
14:34:21.536 DRIVER « [REQ] [SendData]
            callback id:   211
            transmit status: OK
14:34:21.728 DRIVER « [Node 140] [REQ] [ApplicationCommand]
           └─[MultiChannelCCCommandEncapsulation]
            │ source:   1
            │ destination: 0
            └─[BinarySwitchCCReport]
              current value: true
              target value: true
              duration:   [Duration: 0seconds]

What should happen is: S1 triggers R1 to trigger door (then goes off), reed sensor opens, report is received from S2, S2 turns on, S2 goes off.) If our endpoint is tracking R2 and not S2 then fixing that would actually cause a different issue I think as we would no longer have an entity to template to track the door open/close state (unless the root endpoint) continues to turn on with S2, but we’d need to see.

[blhoward2]

Ok, after more info from Zooz. The root endpoint thing is something they’re looking at but we need the compat flag for now for the ZEN17. Based on the description by @masonevans, we also need this for the ZEN16. It seems likely they copied the functionality from that as they are very similar devices.

The relay controlling despite parameter 10/11 being disabled is because this only works with certain switch types. I’ve edited our description to make this clear.

Healing nearby nodes seems to have fixed my interview issues, at least the parameter values are now loading up on interview.

I think my PR closes these issues and renders this relay good-to-go.

[blhoward2]

It didn’t make any difference on mine. I don’t have any switches connected to my zen16 to test it. Your description matches, though.