MAP transform for zwave items?

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 :frowning:

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(]" <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.

@chris that means the thing definition in zwave is wrong isnt it?

Well, it’s wrong if the documentation is wrong :wink:. 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.