Yes it does. A map file can be used in the part of a Contact Item’s label. Or a Contact Item can be presented as a Switch type in a sitemap, with mappings= to produce a button effect. The buttons won’t have any effect, of course.
Contact ct_occup "occupied [MAP(occup.map):%s]" <occup>
Switch item=ct_occup mappings=[OPEN="YEP",CLOSED="NOPE"]
This simply means that we should be using the notification channels. Instead of just deleting the other channels, the database can mark them as deprecated which means that one day, we’ll delete them, but for now they are still available (one day = about a year).
I’ve found your account so have updated it…
Correct.
Yes it does. A map file can be used in the part of a Contact Item’s label. Or a Contact Item can be presented as a Switch type in a sitemap, with mappings= to produce a button effect. The buttons won’t have any effect, of course.
So I must be doing something wrong.
I am using the DWZWAVE which identifies as Switch. I need it to be a Contact.
sitemap:
Default item=DoorSlidingSwitch
Default item=DoorSlidingContact
Contact item=DoorSlidingSwitch mappings=[OPEN="ON",CLOSED="OFF"] // does not compile
contacts.map:
OPEN=ON
CLOSED=OFF
items:
Switch DoorSlidingSwitch "Sliding door switch is [%s]" (gDoorSwitches, test) { channel = "zwave:device:d8092b29:node11:sensor_binary"}
Contact DoorSlidingContact "Door Sliding Contact is [%s]" (gDoorSwitches, test) { channel = "zwave:device:d8092b29:node11:sensor_binary"}
Contact DoorSlidingContactMapped "Door Sliding Contact Mapped is [MAP(contacts.map):%s]" { channel = "zwave:device:d8092b29:node11:sensor_binary"}
rule:
when
Time cron "0 * * * * ?"
then
logInfo("Logger","DoorSlidingContact " + DoorSlidingContact.state + " " + (DoorSlidingContact==OPEN))
logInfo("Logger","DoorSlidingSwitch " + DoorSlidingSwitch.state + " " + (DoorSlidingSwitch==OPEN))
logInfo("Logger","DoorSlidingSwitchMapped " + DoorSlidingSwitchMapped.state + " " + (DoorSlidingSwitchMapped==OPEN))
end
and the results:
2019-01-13 14:35:01.773 [INFO ] [clipse.smarthome.model.script.Logger] - DoorSlidingContact NULL false
2019-01-13 14:35:01.779 [INFO ] [clipse.smarthome.model.script.Logger] - DoorSlidingSwitch OFF false
2019-01-13 14:35:01.783 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Switch Vs Contact': The name 'DoorSlidingSwitchMapped' cannot be resolved to an item or type; line 9, column 51, length 23
Start with the easy one, there isn’t a Contact type element for sitemaps.
https://www.openhab.org/docs/configuration/sitemaps.html
Usually you’d use a Text element, because you don’t want any input kind of widget.
I defer to those who know zwave. I don’t think you can, without an intermediary. Can this new profile feature be used here?
Seems to be true.
You did show us a DoorSlidingContactMapped item?
In my original post:
So, what is the best way to solve this? I would really like to be able to transform or map thing channels in my items file. Is there a way to be able to use these items in my rules without making virtual items and special rules?
I want to use the mapped items in rules. I have a doors group, and all members of that group need to be the same type, hence my original statement that I’d like to do a map in the Item. I did make virtual contacts that have a rule just to manipulate them according to the Switches as self-identified by the ZWave Items. This works, and is better at least for me, because the sitemap approach seems to apply to presentation rather than implementation.
It seems like this is a problem that is never going to go away completely. Has it been discussed a way to transform one type of item to another, perhaps in the binding braces? One would also be required to supply the map.
I’m an OH novice, so I may be missing something. I’m willing to learn.
Update: I just saw your last comment. I’m checking that now.
Have fun reading:
Oh, I read that post several times because it kept coming back as results in my searches. It is exactly the problem I have, and the OP solution is exactly what I implemented.
It’s a philosophical debate as to what it should be and can’t be determined at compile time – meaning by the ZWave (or other) database maintainer. I never used OH1, but apparently OH1 allowed one to remap one type of Item to another type of Item.
So, as far as I know, the workarounds require virtual items and rules as proxies to the proper types, or working in the sitemap and parsing values as strings, or remapping there.
There is probably a developer discussion somewhere that discusses this issue. It used to be in OH1, and it’s not in OH2, so someone must have discussed it, or maybe it’s on the OH2 roadmap. I haven’t discovered this discussion yet.
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.]