Anyone Using Zooz Universal Relay (ZEN17)?

Attached is the SETUP for the ZEN17 ...

I'm curious if it's the DC Motor option. From Zooz: "DC motor mode enabled (relay will check the status of the other relay after being triggered and will shut the other relay off before activating so that only one of the relays is on at the same time)."

I'm not sure why that would be causing it to act buggy, but it will cause an action for one relay to send a signal on the other. Try setting that to "disabled" and see if you still get phantom commands.

Sorry, I can't tinker with mine right now.... mine is hooked up to my alarm panel for smoke and door bell inputs. Two things that I don't want to mess with while the baby is sleeping.

I picked up a couple of these recently for two different applications as I saw that Indigo supports them.
However, the main reason I bought them is because you can uncouple the switch inputs from the relays and use them for independent dry contact sensing. Makes it similar to the MIMO2 (digital only) which is no longer available.

Sadly Indigo 2022.1 does not seem to support switch modes (params 2, 3) beyond 3 (4-10), and does not recognize and create the child devices for the switch inputs.
It also does not provide the ability to configure decoupled trigger operation for the relays (params 10, 11).

It appears that the device does work as expected with these settings when the parameters are manually configured, and I can see the S1, S2 inputs changing as "relay status update" without triggering the relays. For the time being will try to create triggers on the raw zwave status from the master device.

Any plans to implement full support for the zen17?

[matt (support)]

Definitely on the feature request list. Z-Wave devices that can dynamically (based on config params) change their behavior or the number or type of devices that need to be created are difficult and problematic to support since they require custom coding and not a simpler static device definition. We need to make some deeper plumbing changes so that Indigo can more easily handle these types of devices.

Thanks Matt.

It looks like matching the zwave status message contents will be my only option for triggering right now. I have reached out to Zooz to get more details on their status messaging.
Though I am aware of the method to dump the last 60s of zwave messages, is their another way of continually dumping zwave traffic to the log for better understanding of the messaging from a specific device?

Try https://www.indigodomo.com/pluginstore/43/

I have been working on revealing these binary sensor child devices as well for this unit.

With the help of Zoos support I have updated my devices to the latest FW 1.20 and problem still persists.

After I change the settings 2,3 = 10 and 10,11 = 0, exclude and include , power cycle, etc- If I make the S1 input the relay changes - the relay should no longer be linked! When I exclude from Indigo and Include in Simplicity Z-Wave PC Controller the binary sensor devices don't get created either.

I think they have FW issues I'm pushing back on them.

As a follow up to my questions, thought I would provide my current solution for the Zen17.
Zen17 is one of the few (only?) zwave multi-IO modules still readily available, as the Fortrezz MiMo series seems to no longer be available since they were acquired by Ezlo.

I have a number of applications requiring multi-IO, including HVAC control/propane sensor monitoring, and well pump/water purification control and monitoring. In both of these applications I use the relay outputs independently from the digital sensor inputs. Though the MIMO2+ was an ok solution, the binary input function was always cumbersome given it is actually a threshold triggered ADC vs a true binary digital input..

Enter the Zooz Zen17. Seems to be a nice multi-IO implementation based on the SiLabs 700 series, supports independent operation of the relays and sensor inputs, supports true digital binary sensing on its inputs, and also supports a wide range of power supply and voltage sensing on the inputs.

As has been pointed out by others and confirmed by Matt, Indigo 2022.1.2 (and likely 2022.2) does not yet fully support the independent endpoint/device operation of the Zen17 outputs and inputs. When associated and configured as a device, Indigo creates the root device and the relay1 and relay2 endpoints. It does not currently understand separate sensor devices when the device is manually configured for this mode.

With the help of the Zwave Watcher and Zwave Interpreter plugins, and some feedback from Zooz tech support, I was able to capture and decode the reported status traffic from the device.

When configured for independent S1/2 sensor operation, the Zen17 reports status for relay1/2 outputs and S1/2 inputs via the Zwave multi channel v4 command class. Currently one must (or at least this is the only way I found to make it work) trigger on raw incoming zwave commands to capture the true status of the individual endpoints/devices.

Here are the trigger command patterns I am using:

S input state is indicated as a Sensor Binary class encapsulated in a multichannel v4 command class
S1 Off (dry contact open)
? ? ? ? ? ? ? 0x60 0x0D 0x01 0x00 0x30 0x03 0x00 ? ?
S1 On (dry contact closed)
? ? ? ? ? ? ? 0x60 0x0D 0x01 0x00 0x30 0x03 0xFF ? ?

S2 Off (dry contact open)
? ? ? ? ? ? ? 0x60 0x0D 0x02 0x00 0x30 0x03 0x00 ? ?
S2 On (dry contact closed)
? ? ? ? ? ? ? 0x60 0x0D 0x02 0x00 0x30 0x03 0xFF ? ?

Relay State is indicated as a Switch Binary class encapsulated in a multichannel v4 command class
Relay 1 State Off
? ? ? ? ? ? ? 0x60 0x0D 0x01 0x00 0x25 0x03 0x00 0x00 ? ?
Relay 1 State On
? ? ? ? ? ? ? 0x60 0x0D 0x01 0x00 0x25 0x03 0xFF 0xFF ? ?

Relay 2 State Off
? ? ? ? ? ? ? 0x60 0x0D 0x02 0x00 0x25 0x03 0x00 0x00 ? ?
Relay 2 State On
? ? ? ? ? ? ? 0x60 0x0D 0x02 0x00 0x25 0x03 0xFF 0xFF ? ?

Though you can still use the indigo device commands to turn the relays on and off, you must trigger on the raw Zwave commands above to maintain state in variables of both the relays and the S inputs. This technique seems to be pretty solid so far. Given that I am not attempting to change the association within Indigo, I simply modified the appropriate configuration parameters and enabled the triggers to get things working.

Hope this info is helpful to someone else.

-- Jeff

Hi Jeff,
Your work (below) is greatly appreciated, this is the functionality that I am looking for. Can you provide sample code showing how you programmed the device and are triggering on the raw data?

Thanks

Here are the trigger command patterns I am using:

S input state is indicated as a Sensor Binary class encapsulated in a multichannel v4 command class
S1 Off (dry contact open)
? ? ? ? ? ? ? 0x60 0x0D 0x01 0x00 0x30 0x03 0x00 ? ?
S1 On (dry contact closed)
? ? ? ? ? ? ? 0x60 0x0D 0x01 0x00 0x30 0x03 0xFF ? ?

S2 Off (dry contact open)
? ? ? ? ? ? ? 0x60 0x0D 0x02 0x00 0x30 0x03 0x00 ? ?
S2 On (dry contact closed)
? ? ? ? ? ? ? 0x60 0x0D 0x02 0x00 0x30 0x03 0xFF ? ?

Relay State is indicated as a Switch Binary class encapsulated in a multichannel v4 command class
Relay 1 State Off
? ? ? ? ? ? ? 0x60 0x0D 0x01 0x00 0x25 0x03 0x00 0x00 ? ?
Relay 1 State On
? ? ? ? ? ? ? 0x60 0x0D 0x01 0x00 0x25 0x03 0xFF 0xFF ? ?

Relay 2 State Off
? ? ? ? ? ? ? 0x60 0x0D 0x02 0x00 0x25 0x03 0x00 0x00 ? ?
Relay 2 State On
? ? ? ? ? ? ? 0x60 0x0D 0x02 0x00 0x25 0x03 0xFF 0xFF ? ?

Though you can still use the indigo device commands to turn the relays on and off, you must trigger on the raw Zwave commands above to maintain state in variables of both the relays and the S inputs. This technique seems to be pretty solid so far. Given that I am not attempting to change the association within Indigo, I simply modified the appropriate configuration parameters and enabled the triggers to get things working.

Hope this info is helpful to someone else.

-- Jeff

Your work (below) is greatly appreciated, this is the functionality that I am looking for. Can you provide sample code showing how you programmed the device and are triggering on the raw data?

turtle,

I went ahead and associated the Zen17 as usual and assigned it to an indigo zwave device. It shows up as a root device with two binary switch endpoints/devices.

As for configuring the Zen17 device, I set the following parameters. These settings decouple the S1/2 inputs from their respective relays, and set them to report status as open/closed.
p2 => 10 (set S1 to on/off report)
p3 => 10 (set S2 to on/off report)
p10 => 0 (relay 1 trigger disabled)
p11 => 0 (relay 2 trigger disabled)

No need to re-associate the Zen17 or change the device assignment.

The relay outputs can be controlled as normal through the indigo device instance. However, you cannot use or trust the device state reported for the relays as the current indigo device implementation updates the relay device states when receiving either relay status updates or S1/2 input status updates. This means that if you set a relay to on, if the corresponding S input is subsequently reported as off the reported relay on state condition will be set to off even though it does not actually change the relay output state.

To correctly monitor the states of the relays and S1/2 inputs, I created triggers for on and off of each endpoint/device. These triggers execute on zwave command received using the patterns I indicated above. The triggers are used to update a variable which represents the respective endpoint/device state. The variables can then be used wherever the device state representation is needed, including other triggers, control pages, etc.

For example, I have a variable defined as MainWaterValveState. This variable is set to true when a Relay 1 State On status command trigger is executed. The variable is set to false when a Relay 1 State Off command trigger is executed. Whenever indigo sends the command to change the relay output, the Zen17 reports the status of the relay, which in turn is used to update the variable.

There is no corresponding indigo device associated with the S1/2 input in this configuration, so a variable implemented as in the previous example becomes your state indication of the S1/2 input. Once again, this variable is used for other triggers and status reporting on control pages.

I do need to reiterate that you cannot use the indigo reported device state for the relays when the Zen17 is configured in this way. This includes both the device indicated in the home window and status update messages in the log which can be a little confusing. You will need to create a use a custom control page that shows the true state of your assigned variables.

Hope this is helpful.

Sorry for reviving an old thread here but I'm a little lost. I have a ZEN17 installed and can control my garage door with it, however I don't know how to read the dry contacts. Can someone help me out?

I also don't know how to send a command to it as an action - I would think it would be an input/output control but it doesn't show up there (though the three devices are showing up in the Devices list).

I have firmware 1.20.
Thanks

Joe

Not getting much of a response here. Let me ask the question differently - is the only way to control this (and hear dry contact changes) through raw ZWave control?

Thanks
Joe

(though the three devices are showing up in the Devices list).

Have you tried controlling the devices?

Going by instinct, I think these would be simple on / off relays (no I/O).

Not getting much of a response here. Let me ask the question differently - is the only way to control this (and hear dry contact changes) through raw ZWave control?

Thanks
Joe

Short answer: maybe

Long answer: With this device, that should depend on the parameter settings.

Unfortunately, I may be guessing beyond that point. (Because now I'm also second guessing my own Zooz17 configuration). I know that the important parameters for you: Relay 1: Paremter 2 & 10. For Relay 2: Paremeter 3 & 11,

2 and 3 state what the device is and also dictate the behavior of the device. 10 & 11 will remove the physical relay from the dry contact.

Does that get you pointed in the right direction?

For my z-wave garage application, I'm having good success using the Virtual Garage Door plugin. It ties it together nicely. https://www.indigodomo.com/pluginstore/267/

Long answer: With this device, that should depend on the parameter settings.

Unfortunately, I may be guessing beyond that point. (Because now I'm also second guessing my own Zooz17 configuration). I know that the important parameters for you: Relay 1: Paremter 2 & 10. For Relay 2: Paremeter 3 & 11,

2 and 3 state what the device is and also dictate the behavior of the device. 10 & 11 will remove the physical relay from the dry contact.

Does that get you pointed in the right direction?

How do you get to these parameters?
Thanks
Joe

Have you tried controlling the devices?

Going by instinct, I think these would be simple on / off relays (no I/O).

I finally was able to control them by calling them a Light/Appliance control. Still working on trying to get the statuses from the Zooz without polling it. I'm guessing there is no way to listen for a trigger to hear contact closure changes but I don't know yet...