I am in the process of installing a watercop in my house. I need to have two momentary contact relays to turn the unit on or off. I also needed to monitor the status of the unit, this is in case a remote sensor turns the water off this should let me know. I discussed it with Zooz via email. This is their response:
As we understand it, you would like to remotely trigger the Watercop with a momentary signal from the ZEN17 relays on the output side and you would also like to monitor the Watercop open/close operation on the input side by connecting contacts 2, 3, and 4 to the low-voltage input terminals on the ZEN17 - is that correct?
In that scenario, there will be no external wall switch or manual push button switches connected to the watercop or the relays, all connections will be done directly between the Watercop and the ZEN17. If that’s the case, then it will work just fine. Note that you could only use the ZEN17 here and not the ZEN16 (since it can’t accept low-voltage inputs) but we haven’t verified compatibility of the ZEN17 with OpenHAB unfortunately so it’s possible not all features are available and you would be purchasing the device at your own risk.
Please note that they say what everyone is discussing is within the capability of the unit, however they are not sure if we can access this in openHAB. I ordered a unit, with the intention of trying to use it. If I cannot, then I will use the relays and monitor the unit through some other means.
I’d like to add to this discussion. I think I’ve read it over enough to have something to add. That being said I’m a pleb with this stuff and do it for fun and to learn. Forgive me if I’m ignorant to something here.
The earlier provided XML differs from mine. This unit has options for a couple contacts to be set as sensors. I have the unit set as such, excluded and reincluded. The XML refers to a SENSOR_BINARY in addition to the SWITCH_BINARY. I didn’t see this in the earlier XML. I assume it was for the other mode of operation option for this. Could this be the reference to the channels that should be a contact sensors? The idea is that I could connect a couple magnetic reeds to act as a switch to sense whether the door is closed or not.
Same for me. I bought a ZEN17 today, and it’s supposed to show two inputs (S1 and S2) and have two output “buttons” (R1 and R2).
However, only the output buttons are showing up in OpenHab 3.2.0.
I have emailed Zooz, asking for help.
It’s also possible that the two channels provide both functions - ie send a command and it changes the relays, and when the device sends a status, it’s the input status. This depends on how the device is programmed.
That I can rule out. The switches represent the status of the relay (ON or OFF) and is not related to the input sensors.
(The device can be configured so that the input sensors connect directly to the output relays, but once you disable that and configure the input sensors as independent, there are supposed to be 4 endpoints (2 input and 2 output). Not sure how the device is supposed to do that magic. It says in the manual you have to exclude and re-add the device to your Z-Wave network once you make such a change to make the new endpoints visible, but they are not showing up for me, despite multiple attempts.)
The database is only configured for these two channels, so no matter how many times you include and exclude, this will simply not change unless the extra channels are added to the database.
Interesting. I mainly come from Zigbee where the device is reporting its capabilities and what channels it has. Sorry for the confusion.
Is there a way to play around with the XML defintions on a live OpenHab system?
(I’d prefer to not having to shut it down / restarting repeatedly because of the fussy Aqara sensors I have connected…)
ZWave also does this, but when the ZWave binding was written, it was not possible for the binding to define channels dynamically - they had to be defined in the XML file. When the Zigbee binding was written, it was then possible to define the channels dynamically - hence the different approach in the way the bindings work.
To rewrite the ZWave binding is a big task, so it’s stuck with this limitation.
Not really - it must be defined in the binding - it’s the only way that OH allows this to be done.
Looking at the official documentation for other Smart Home platforms, I am guessing the device is reporting additional command classes besides the ones defined in the database.
To create additional sensor devices to monitor the inputs separately from the relays , choose a sensor type (options 5-10) under Input Type for Relay 1 or Input Type for Relay 2. Exit the settings once you select the new input type and look for the new device under “No room assigned” in your app under Devices.
Since you have to predefine what type of sensor the input is monitoring, my naive assumption is I can manually add sensors for all ~10 types of inputs, and only the one configured will receive updates.
If that works, we could use it as a static config with 9 out of 10 useless/defunct sensors, depending on your configuration, but at least it’ll work for the one sensor type configured.
I’d like to try that out.
Not really - it must be defined in the binding - it’s the only way that OH allows this to be done.
So that means for me:
Download the binding sources
Find the database and make the changes to the ZEN17 device definition
Compile a binding package
Upload the package to my OH addons folder, and OH will upgrade automatically
Pray Zigbee doesn’t break while playing around with Z-Wave.
Does that sound about right?
Any pointers where this database is sitting in the repo?
There’s no need to guess what it is reporting. The binding does an interview of the device and saves all the information required to define the channels in an XML file (it’s in the userdata/zwave folder - in another folder named after the controller, and then a file named after the node).
This XML file lists all the command classes etc and can be used to generate the database.
A couple of findings:
The device reports different command classes depending on the configuration:
You’ll have to exclude and re-add the device for the command classes to get the XML to change.
Not sure if that’s a limitation of OpenHab or the device, but not important.
I am attaching three XML files for various settings.
As you can see, when the input is configured as a “toggle switch” (value 1), it does not report a sensor command (COMMAND_CLASS_SENSOR_BINARY is missing):
When configured as “open/close alert” (value 7) or “on/off report” (value 10), it is reporting COMMAND_CLASS_SENSOR_BINARY.
I will now try to modify the local XML in my local clone and see if I can hardcode the command class.
I am assuming, when the command class is defined in the XML but not actually reported on the device, nothing bad is going to happen at runtime(?).
It’s a limitation of ZWave. It’s not possible for a device to change command classes once included as the system assumes it is static. This is also why things like changing power (eg from battery to USB) also required reinclusion.
I’d suggest we create a new device with the maximum configuration (whatever that ends up being). We can’t support different thing types depending on the device configuration.
Now I have two switches and two sensors and they work independently, i.e. the sensors are reporting the input and the switches report/control the output relays:
I didn’t even have to compile the zwave bundle. I simply downloaded the 3.2.0 release jar, modified the XML inside, and uploaded it into the addons folder.
OH did the right thing and reload the modified package.
One big question:
What would you consider the “maximum configuration” for all sensor types?
I haven’t tried out all 6 possible configurations, but the few I tried only seem to differ in terms of sensor type:
Do these differences have any notable implications for OH, or can we ignore them and only add the two sensor command classes so people can independently query the sensors and control the relays?
PS: The (only?) difference between sensor type 4 (leak alarm) and type 7 (open/close alert) is that the former is NO (normally open), i.e. ON represents a closed circuit and the latter is NC (normally closed), where ON means the circuit is open,but it does not change anything on the OH side, only how the device reports the sensor. (Hope I got NO and NC right, but you get the gist…)
Yes, as I said above, the best option was to delete the existing entry and create a new one with the new XML.
I’m not sure - we want to try and provide channels that expose most of the features of the device. If we miss some, then we can have a discussion when/if someone finds themselves wanting the additional functionality.
Alternatively, we just add the channels that you use, and ensure that the ones that were there originally are still there.
If you’re adding back the entry, consider using the file I attached (7 doorsensor.xml). It should expose the 4 channels (2 switches and 2 sensors marked as ALARM and sensor type DOORWINDOW), which should be good enough for now.
I’d gladly test this end to end (need instructions though, because I’m not sure how the DB from OpenSmartHouse gets into the package sources for OH.).
