This is the heart of the thread. If you wanted to create a Contact item, and you have a Switch item, what is the proper approach?
1 Like
This is untried and I think you need to be OH 2.4
Where sensor_binary is a switch type channel
Contact myItem "contact from sw" { channel="xxx:sensor_binary"[profile="transform:MAP" function="swtoct.map"] }
swtoct.map
ON=OPEN
OFF=CLOSED
=UNDEF
I think you need an OH snapshot for that last default failsafe, that I know is very new
1 Like
Okay, this is very cool. When I get real work finished I will try this.
I was just cleaning up some emails and saw the Channel change to the WADWAZ SENSOR_BINARY CC, which led me to this thread, so sorry Iām late (please add the zwave tag to the topic).
I set the WADWAZ device up with both Switch and Contact Channels, as well as Switch for the external switch. This way, people can make the decision which Channel works best for them. I cannot see a diff of the changes until they are accepted/exported, it looks like the device is setup the same as when I modified (these other very similar devices):
SENSOR_BINARY: sensor_door (Contact)
ALARM/type=BURGLAR, event=3: alarm_entry (Switch)
ALARM/type=BURGLAR, event=254: sensor_binary (Switch)
ā¦ and I do not understand your comment in the dbā¦
[#](https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/9#comment-957) Brian Michalk 2019-01-13 14:58
Requested review. Change Sensor (Alarm) to Sensor (Binary) of type sensor_door. Not sure if this is the intent of the discussion on the OpenHab forum.
[community.openhab.org/.../4](https://community.openhab.org/t/z-wave-switches-vs-contacts-and-the-database/64053/4)
So, what did you change? It sounds like you are needing is for the DWZWAVE to use sensor_door. It also have both SENSOR_BINARY and ALARM, so why not change SENSOR_BINARY to use it, like the WADWAZ?
I prefer to use the SENSOR_BINARY CC, since the event is received from the device ~50ms sooner than the the ALARM event. I do the same for my motion sensor (WAPIR), which also has ALARM and SENSOR_BINARY CCs. As Iāve voiced before, I am very much against removing āduplicateā Channels, since I want the ability to choose! Suggestionā¦ instead of marking the Channel as Deprecated, use Redundant, and then put those Channels into a separate Chanel Group. This leaves the functionality for those who want it, but the Channels would be separated from the others. And mark them as hidden (I forget the actua term now), so that the user has to select āMoreā in Paper UI, or Tools> Advanced in Habmin, in order to see them.
There is only one Channel that supports Contacts (sensor_door), and most devices have been setup to use Switches, but have read-only Channels that should really be a Contact. Couldnāt all of the alarm Channel types be changed to support Contacts rather than Switches? Are any of these not read-only?
Unfortunately OH2 removed this ability. In OH1 the binding had visibility of the item type - there has been talk about adding this back to OH2, but at the moment, this is not possible. Another option might be to add some sort of proxy system into ESH so that it is able to convert between different types, but I donāt think the binding can really do much here.
That is fine, but these channels are the ones that I ultimately want to deprecate as this is the old command class. Ideally it would be good to have a consistent set of channels using notifications.
As Iāve said, when I defined the ZWave channels, I used the definition that came from ESH. I donāt mind changing all channels to use a different definition, but this should be defined consistently across all bindings so that the user has a consistent experience. Iāve tried pushing more system channels, and I have seen some coming through, but itās far from complete.
Since it would be a major upheaval to change all the channels, not to mention a lot of work, I would prefer not to change anything unless there was a clear direction on this, otherwise itās just changing for the sake of change and doesnāt necessarily meet the clear objectives of OH.
1 Like
Iām just a new guy here, so if anything I say doesnāt make sense, tell me, then ignore my comment. Itās not completely clear to me the process or patterns yet.
I agree with your point, but it looks like you thought I meant the ability to choose the Item type. I was actually meaning the ability to choose which Channel to use. My ability to choose would be taken away if you remove redundant Channels. I will continue to use SENSOR_BINARY, since the event arrives sooner than NOTIFICATION for all of my devices. An added bonus, with the current binding, is that by having both Channels available, also allows me to also choose the Item type, since there is both a Contact Channel and a Switch Channel (except for motion sensors, but Iāll get to that 
).
IMO, it makes sense for redundant Channels to be hidden from the view of the inexperienced to avert confusion, but removing them eliminates the possibility for the user to choose for themselves. My example of realizing a performance benefit of one Channel over another may be an edge case, but for those aware of it, it is likely much more than that (it is for me!). And there could be other unknown reasons why someone would choose one Channel over another. Iām sorry to be making noise about this, and I know youāre saying it would be a year out, but I want to get in front of this now, since I think it is the wrong direction to go in. I really hope some others will get behind me on this, as your decision could eventually cause people to turn away from this awesome binding for an alternative that hasnāt been intentionally dumbed down for the masses and stripped of functionality.
To summarize, IMO, the redundant Channels should be hidden by setting the āadvancedā property to true, possibly with some text in the description to warn of the other Channel, causing the user to need to select More (Paper UI), or Tools> Advanced (Habmin), to see them, rather than completely removing the Channels and the ability for an advanced user to select which one suits them best.
This is another great topic that deserves some attention. I absolutely agree, but how long do we wait? Motion sensors are read-onlyā¦ they report events and do not support commands. I do not understand the rationale behind making them Switches. If the Channel does not use a category, I thought it was up to the binding developer to decide how to define the Channels.
All of my motion sensors have sensor_binary and alarm_entry, both of which only support Switch Items. This needs to change, but the only Channel type available in the binding that supports a Contact Item is sensor_door. This could be used for motion sensors, but IMO that would be pretty ugly. If you donāt want/canāt change alarm_motion to a Contact, why not create a sensor_motion and have it support Contact Items?
[@chris , I had accidentally sent this before I was done writing, and had deleted it until I was done. I think you may have missed it.]
Hello, new guyā¦ welcome to the forum, and thank you for contributing, and sorry to hijack your topic! Iām just curious what changes you made in the db, since it looks like nothing was changed, but there is a pending change request. Maybe Chris can confirm this, and/or delete the change. Without any device changes, you could just link your Item to the other Channel in the WADWAZ (thereās one that supports Contacts and one for Switches) to keep your two Items consistent.
Thanks! Iāve been OHāing for almost a year now. Iāve been posting tutorials when I accomplish some automation. I find the tutorials very handy.
As for the database, the WADWAZ configuration is not a problem for me. The DWZWAVE-25 is. I thought I had requested a change for that one, and I tried to copy WADWAZ. I do completely agree about making a channel (switch/contact) for each thing, that solves the problem nicely.
@chris @5iver Are there any pending approvals for DWZWAVE25 https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/947 ? In the latest snapshot I am seeing alarm_burglar channel when I add the device, but the database says it is now sensor_door The last update says 2018-11-24 so I would have thought the changes would have made it into the nightly snapshot by now.
I tested the latest in the database by manually updating the jar with the xml for the database and it looks good.
Nopeā¦ youād see them at the top of the page. Have you deleted and readded your Thing, to get the updated definition? You need to do this when ever a Thing definition is updated, and that goes for all bindings, not just zwave.
i tried that before manually updating the zwave jar so Its not that, if you look at org.openhab.binding.zwave/ESH-INF/thing/eco/dwzwave25_0_0.xml at 053edf6480e8692eee79a188ac4f514a84126b4f Ā· openhab/org.openhab.binding.zwave Ā· GitHub it still shows alarm_burglar but https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/947 shows sensor_door and has no mention of alarm_burglar
I see what you meanā¦ it somehow was missed in the exportā¦ this will need @chris 's attention.
BTW, the first link you posted was not to the master branch. Github is tricky like that, and it always gets me too. But sensor_door isnāt in master either.
Looks like it git it updated and in the latest snapshot. The tamper switch doesnāt reset back when the cover is replaced, but that looks like as designed.