Since the Zwave2 returns ON OFF for door/window sensors I tried to alter that with MAP transform
I thougth
^^ THIS map file and calling:
should result in the altered string?
but it still shows Off On 
I suspect this isnât a ZWave issue⊠Iâve not looked at transformations, but something I have noticed is the channel options donât seem to workâŠ
So, to explain, in the ZWave binding, it sets the transformation options for the channels by default, so they shouldnât read ON/OFF anyway (for most channel types). You can see the list in the database documentation. However, Iâm not sure where this is actually used - I know @xsnrg has commented to me that the UI always shows on/off. Maybe the UI isnât using these options, or maybe Iâve configured something wrong in the binding (although I do see the options being presented in the REST interface, so I think itâs ok in the binding), and maybe the issue is also true of the transformations?
Ok so this is for:
Contact WD1_Binary "Fenster ist [MAP(fenster.map):%s]" <contact> (Schlafzimmer,DCH_Kontakt_Chart) { channel="zwave:dlink_dchz110_00_000:15348538564:node11:sensor_binary" }
I wouldnât try to use MAP conversion at all if the value on the UI would OPEN / CLOSED as in OH1
but in OH2 it says ON / OFF for door window binary sensor as default
Currently, this channel has states of OPEN/CLOSED already set within the binding.
The other thing to note is that according to the ESH documentation, your item should be a SWITCH, not a CONTACT. I know there has already been some discussion about this⊠I also note that DOOR and WINDOW have different types for some reason, but thatâs another issueâŠ
However, because ESH states that the type must be a SWITCH, the Z-Wave binding creates a state of type OnOffType - not ContactType. The binding canât know that youâve changed the type to something else and maybe elsewhere in the system, this conversion isnât allowed.
that one I dont understand⊠you mean even when the log says ON / OFF there are multiple states just can not be seen by the user? how can I influence that OPEN / CLOSE is shown on the ui then?
I tried all different types with different outcome. also SWITCH âŠ
just didnât like that its displayed as a toggle switch on ui
No - in the channel configuration file, itâs possible to set transformations (well, âstatesâ) so that sensible values are already provided to the user. So the user should already see Open and Closed if this is working. Take a look here - it might help to see what I mean. These channels are what are used in the database, so when you say this data is a âsensor_binaryâ thatâs what it should display (at least thatâs my understanding).
well it doesnât ⊠no clue if the bug is within ESH or ZWave
sensor_binary is also used by motion detection âŠ
No, I know. The issue must be in ESH I think. As far as I know, thereâs nothing the binding can do with this other than to set the states into the XML, which is working as I can see them in the REST interface so the system must be reading them.
@kai - any comment on the use of states for switches?
The state description from the channel definition is only used, if you do NOT provide any state formatting in the label in the item file. So if you remove it from the item file, you should see what is defined by the binding. If you have a -section in your label, this will be used and the map will have to map the values the item can have (i.e. ON/OFF here).
just didnât like that its displayed as a toggle switch on ui
If you use a Text widget in your sitemap, this wonât happen.
I removed any formatting from the item. It reports still as OFF ON. According to what I understand from above this should be OPEN CLOSE because its a âsensor_binaryâ. This is not working.
In my sitemap I only call the Group (which is a room).
As a member of that room the item just comes up one level deeper. So I canât have it a text widget in the sitemap.
To test this I also added the item as a Text item=name aswell.
Here happens another bug?. When I open the window the status in basic ui comes up as ON. However that state gets lost just by F5. Itâs not permanently there.
This is a good statement. In the case of OH2 with zwave2.0, you never need to touch the items file, so the state description from the channel definition will always be used. There is no items file. Here is an example of a door sensor in my system with everything the latest build:
the item being edited goes with the bottom channel. In my case it says ON/OFF as well. I changed my rules to match ON/OFF, which works, but is not intuitive. A door is not ON/OFF, it is OPEN/CLOSED, and it is a contact sensor, though this matters less to a user than state names I think.
What is the proper way to have this device report OPEN/CLOSED?
Well, the item type must be Contact and not Switch, so it is a matter of the thing defintion that must be changed.
ESH Documentation
says a Switch, but also CONTACT returns ON OFF
and when its a CONTACT it also has that problem in basic ui:
Where do you read this? If there is such a statement, it is a bug.
Here it clearly says that a contact is open/close.
Well, itâs wrong if the documentation is wrong 
. Currently, I think the implementation in Z-Wave is inline with the ESH documentation which states that a DOOR and WINDOW category should be a SWITCH.
Iâm more than happy to change it if itâs wrong, but in that case we should update the documentation. @kai - are you happy to change DOOR and WINDOW to be CONTACT rather than SWITCH (or as well as SWITCH - maybe switch was there to support locks?). If so, Iâll make a PR on the docs?
I had actually never looked so closely into this category table. Having done so now, I think we should add more item types to a few lines. I think âDoorâ is actually fuzzy and it is currently a Switch, because it is about being locked and not about being opened. And thatâs why it is also RW, since you can lock it through commands.
So for all (Door, Windows, GarageDoor) I would actually allow âContactâ to be a possible item type. And thus for a âdoor sensorâ as the one we talk about here, Contact would be the most natural fit.
@chris: Yes, very happy to accept PRs for the documentation!
Please add Rollershutter as an allowed item type if categories are restricting how to represent a garage door. Is there a document that describes how and why ESH/OH2 imposes constraints like these? I would like to understand the big picture, and how itâs not leading towards problems like Vera has with trying to fit the world into pre-imagined UPnP services.
Thanks for any pointers.
How does the binding know what state to provide for a channel update when there are multiple item types? In OH1, the binding had visibility of the items so could provide a compatible state, but in OH2 we donât see the item. If the user can have either a ContactItem, or a SwitchItem, then how does the system reconcile this?
Itâs obviously fine for commands sent to the binding, so multiple item types is fine in this direction, but when updating a state, shouldnât there be only one item type? (or am I missing something fundamental - I suspect I must be?).
This leaves many bindings un-port-able to OH2, in that the context of the item is needed to determine how to represent the state update.