I’m setting up a Zooz Zen16 (https://www.support.getzooz.com/kb/section/142/). I’ve updated my system to OH3.1.0 and installed the zwave binding 3.1.0 [NOTE - the device was not recognized using the older OH3.0.1 and zwave binding 3.1.0]. The zwave device has 3 switch inputs which control 3 relays. I am using a dry contact on one of the switches (essentially a standard momentary doorbell switch) which triggers the relay (as does an ON command from an Item linked to the Channel “Switch 1”. The problem is that triggering the switch manually at the device does not broadcast a zwave event.
I contacted Zooz support about this and their response was
As long as the doorbell doesn’t output any Voltage and you’re only looking to monitor the status, you can do that by monitoring the status of the relay. There isn’t a separate device created for the input part of the ZEN16 but anytime the input is triggered, it trips the relay and that status change is reflected in the Z-Wave interface.
In OH3, the channels exposed by the Zen16 Thing include Switch, Dimmer, Scene Number, three Electric meters (kWh, kVAh, watts), Battery Level and Switch 1, 2 and 3. There are no channels for the relays.
Questions:
Is it possible to add channels for the relays which will report relay activity - like ON/OFF?
Do the energy Channels monitor the electricity use going through the relays (such as landscape lighting)?
I can create an Item from from the Zen16 Thing, for example, the Switch 1 Channel and call it “Zen16_Switch1”. I then add a rule:
rule "Doorbell"
when
Item Zen16_Switch1 changed from OFF to ON
then
logInfo(logName, "Doorbell changed ...")
playSound("barking.mp3")
end
When I change the switch in OH3 the rule runs. When I short the contact on the Zen16, the relay clicks but there is no reporting of that in OH3. Per Zooz support, they seem to indicate that it is the relay that reports the zwave status, not the switch (that is, monitoring the status of the relay)
Yes, that’s the part that isn’t working.
Per Zooz support, “There isn’t a separate device created for the input part of the ZEN16 but anytime the input is triggered, it trips the relay and that status change is reflected in the Z-Wave interface.”
i.e. the “switch 1 2 3” channels that you see represent the relays. There just isn’t anything representing the wired inputs.
You already know that because …
so the problem becomes the perennial zwave issue of “my device isn’t reporting state to openHAB”, which is often about lifelines, association groups or some other device setting.
I can’t offer any further help on that, but at least you should be happy you have the right channels now?
Personally I’m not really sure what the problem is at all.
We need to know what functionality the device provides - can you please provide the XML for the node that OH created when it performed the device interview (it’s in the userdata/zwave folder). You talk about the relays as if it is different from the switch, but the protocol doesn’t differentiate - there’s just a BINARY_SWITCH command - and it can also return the state. If there are more endpoints supported than currently defined, then we can add channels, otherwise if there’s just a single endpoint, I would expect we send commands to set its state, and the device can send reports to update the state in the binding.
Really I have no idea - this is a question for the manufacturer.
I can only assume that the device reports that is supports these functions when the binding performs the interview to detect the functionality in the device. Since I don’t have this device I can only speculate, but it’s a good guess as I doubt the binding would invent it for no reason
This does raise a good point that 3.1.0 is now quite old and I would actually suggest that we should be testing with the latest snapshot since updates were made to this device in July.
Thanks. And can you please confirm that you’re now running the latest snapshot. As above, I think there were a number of changes for this device.
If you are, please just delete the thing, and go to the discovery and add it back again. There’s no need to exclude the device - this process just updates the thing configuration that OH stores.
