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).
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, 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.
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?).
I think you are overestimating the importance of this table. It was merely introduced to have a rough categorisation merely for the purpose to be able to render an appropriate icon for it. Bindings have always been free to NOT define any category for a channel and have whatever item type defined for it as it wants - so this table does not put any constraints on the bindings, but rather wants to help them to have a well-suited icon referenced.
If the user can have either a ContactItem, or a SwitchItem, then how does the system reconcile this?
It is not the user, it is your channel type, where it is defined, which item type is the right one. So YOU can decide this, not the user.
If you want to allow the user to have multiple choices for item types, the way to go is to simply offer alternative channels to him.
Yes, but this results in the problems we see now. I “decided” (through use of the table) that a DOOR was a SwitchItem, however others wanted something else… I’m happy to change, and if we don’t need to worry about the table in the docs, then that’s fine by me - Z-Wave users can then decide…
I can do that, but then we end up with multiple channels all doing the same thing which doesn’t seem like a good solution. In this example, we’d have two door channels - one a contact, and one a switch. It just seems that there should be a single channel?
Anyway, for now I’ll update the door to use a contact …
. 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.
…