Absolutely correct.
he formatting in the Item “label ” section has something of an oddball or magical power though, it gets used in non-sitemap ways as well.
Here’s an old, but useful discussion. In OH1 bindings, the author could provide features to “map” say a binary input to a Switch or Contact Item.
In OH2 things/channel world, this is no longer so easy.
I understand profiles should address this restriction. New for 2.4, I don’t know how extensive the implementation is yet.
No - I used the original item/channel types that were original stated in the ESH documentation. As I’ve stated earlier, OH is meant to be system agnostic, so ALL bindings should do the same thing, and the only way that this can happen is if everyone follows a single set of guidelines. I suspect that is not happening, but there were guidelines at one point, and that’s what I followed.
Well OH1 was very different. In OH1 the user can specify whatever type they like, and the binding can get this information. In OH2 the binding doesn’t know anything about the items that the user configures, so we have to choose a single type and not allow the user to specify it.
Personally, I don’t mind changing everything if there are new guidelines and channel types etc - although it would be a major task to do so as there are nearly 1000 devices in the database!
Well, yes. If I sit here today, and write my FOOBARomatic system that repurposes the WADWAZ device to use the magnetic sensor for door OPEN/CLOSE, that means what it means. One year from today, I want to repurpose that switch with a magnetic float, and it needs to mean FULL/EMPTY. There’s no way for me to predict the future, nor you, the ESH guys, or even the ZWave company. Like you said, as long as everyone agrees to the same thing, it works. We wouldn’t be having this thread if I didn’t have Contacts and Switch items show up on my doors.
the programmer in me thinks the binding should stay as stupid as possible, and report 1/0, and let the Item handle what to do with that information. It does make the code more verbose. This is going to be an ongoing discussion, I can feel it now.
Sorry - I’m just confused now. My point was simply that I was following the guidelines - I don’t really know what you mean here?
But that’s not how OH/ESH works. We have to turn the 1/0 into a type - a switch, or a contact, a string, or a number etc so that it can be used by users. This is the level of abstraction defined by the system.
I’m not super sure what you mean?
I meant that the creators cannot possibly know what the end user will use a device for. If the user wants to use a door switch as a rain gauge, push that detail down on him. Otherwise, if he wants to use it as intended, build out the proper boilerplate that works, or let the user override the default. And by user I’m not talking about you, I’m talking about me.
It feels like one of those dead horse topics, like Star Trek vs Star Wars. In six months someone else is either going to bump this thread or start a new one.
This discussion has been very informative for me.
You can use the device for something else - just map the type to something else, or display it differently…
As I said, the system is designed around a specific concept, and bindings need to work within this concept. This is a fundamental point with OH so that all bindings look the same to the user (and yes, that’s you, AND me 
).
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?
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
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.
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.
