Okay, I follow that. Let’s say the device is a zwave contact on a door … it identifies itself to the binding, which knows the (main) data is about a binary open/closed sensor. I’m assuming this zwave device doesn’t report if its fitted to a door or window or catflap. Other devices might be more specific, say if we were getting this from an intruder alarm system. But here, the binding makes available a channel of “contact” type, the general case, How does it represent the status to the channel/Item, as open/closed? Is this a bit like existing numbers with units, we get a true-false payload and a unit of open-closed? EDIT - enumeration is I think the word I was groping for.
open/closed seems to cause a lot of gnashing of teeth in posts above. Let’s make it a fire alarm sensor. We get a type of “fire_alarm” because we don’t know more specific (e.g. smoke alarm, heat detector) but we do know its not a door. We get a payload of … ? true/false with “units” of okay/fire? i.e. different from a panic button with okay/alarm.
I’m trying to imagine how to deal with that in rules. I guess the type and type hierarchy can be examined. And the payload, expressed with or without the “units”
Absolutely- I completely agree, and the discussion is right. I’d just like to ensure these changes go into OH3 and try and get OH2 back to a stable condition as all the recent breaking changes have really made for a lot of instability that should have been reserved for a major release.
Perhaps, but that is not for the user nor the binding developer to decide. Maybe there is a general enable switch, but usually the boiler would have a setpoint (possibly controlled from OH) which would be compared to the measured temperature (which may also be available to OH), yet it would be nice to know when the heater is actually on.
And it is available in the current implementation of OH, which is also a big plus
I still think we are having a good discussion here, and I just hope that some of it is taken into consideration for OH3. Some of the other suggestions in this thread may very well be even better than mine. The whole point of the discussion is to get people to explain their ideas, and see if we can come up with something better than what we have so far.
I agree. And the impact is both on the different user interfaces as well as making the rules less expressive.
Exactly. Using the item name Dimmer makes it easy for people to understand when they have a dimmer, but also using it to control something different (like volume or window position) is confusing to people not familiar with what a Dimmer is in OH. Since Dimmer is a familiar word, it is very natural to think you know what it means. The long discussion about the Dimmer earlier in this thread shows that there are many different thoughts about what it is (and it appears that a lot of the confusion in this discussion is actually caused by the clashing of nomenclature).
I think this is a good point. Maybe instead of having separate types, the items could be tagged as read-only. Then the GUI rendering it would know if this item should have a control to manipulate it, or just show the current state.
Very interesting.
Yes, I think that will be needed for more generic interfaces/bindings, where the binding author has no chance of describing what the Item represents, but only what it is (for instance a binary input sensor). The user would add tags to signify that this sensor is actually a window contact.
It’s a tempting idea, but thinking through my practical installation, I want occasionally to be able to “force” a value e.g fake a temperature to test functions. Only an occasional need but difficult to manage with true read only.
It’s easy enough to not write to something by choice, we’ve all been doing that so far.
Maybe much depends on “read only, but by who?”
Perhaps we mean an “uncommandable” Item, which is rather more like the current Contact type.
I’ll object to UI part only, that how you choose to show it is not an Item property (though of course you should have defaults). e.g. I want this Item r/w for an admin user and r/o for ordinary user. This is one of the clever parts of existing sitemap, choice of widget.
What do we really mean by read-only? I was thinking mostly about whether the default in the UI should show a control to manipulate it. Since the default widget for a Number item does not allow manipulation of the number value, I think we currently only have a similar case for Switch/Contact?
When a binding developer decides that something is an input (read-only, or whatever we should call it), it conveys the fact that manipulating the Item (through whatever means) will not cause the binding to send this to the actual device, simply because that is not possible. And therefore it also makes sense that whichever GUI is used will not by default show a control to manipulate it.
In cases like the one you describe above (forcing a value on an item), it could be allowed, but it is important that the user knows that he/she is manipulating the Item state, not the actual device.
With richer Item types or metadata/tags as others have suggested, the default GUI widget for setting the temperature (setpoint) of my floor heating would of course have some controls allowing me to change the setpoint, whereas the default widget for showing the current room temperature would only show the number. Today those items are both Numbers, and I have to decide in the sitemap which widget should be used.
Yehbut … in OH2 at least, Items may have multiple bindings and link to both “out” and “in” channels. One binding’s read-only designation should not limit UI, rules, or other bindings.
Since we are on the topic of names of things, it is also one of the sources of confusion. I’m frequently helping people who assume that you can only use a Switch element to show a Switch Item on the sitemap.
Again, I’m not advocating for a change because I still do not necessarily see the disruption that would be created being worth the improvement in clarity in these cases to go and rename everything. But it would help avoid confusion if different names were used for sitemap elements and Item types. I think HABPanel does a good job in this regard.
It’s usually best to start a new thread instead of reopening a four year old thread. A lot can change even over a single release of OH, let alone 8 releases. What you see in this thread may no longer be relevant or correct an no one is going to re-read through 90 posts from four years ago to see what has already been said on the topic.
There are lots of ways to interpret that. Are we talking about a Thing? An Item? Both? Which “boolean”? Switch or Contact?
Assuming the Item is a Switch and linked to a Channel, you can link the second Item to the same channel as the first and apply a transform Profile useing a SCRIPT transformation or a MAP transformation to flip from ON to OFF and OFF to ON.
Though one would question the use case for this and wonder if some alternative approach that doesn’t require a second Item might be better.
Link new item to same channel as first one and use “inverse” profile. I am not sure if smarthome/j had such thing. If I’m not mistaken the coming OH4 changes will introduce option to turn script into a profile. Profile is a special piece of code which is called after binding reports its state, but before item receives it.
Well, since we are active here, I’ll leave this one here.
Yes. I KNOW that by design the “Location” Cards will show a Light Icon when the light is on, and no icon when the light is off. Or, a Door (open) Icon when the door is open, and no icon when the door is closed.
So - I’m going to make it the way I want it.
I want to create a “Door Closed” Icon. And create an inverse of the item (or tweak of the channel?) shown below so called Laundry Room Door Closed which will be active when Laundry Room Door is not. So - when the door is open, it shows the open door icon. When the door is closed, the Laundry Room Door Closed becomes active and shows my Closed Door icon.
Why? The door open icon displayed is very clear. The absence of an icon is ambiguous. It MAY mean that the door is closed (actually - there nothing there to even tell me that a door exists that I care about), or it MAY mean that something has happened or I screwed up and the original item no longer exists.
You could just invert the one Item and use the transform on the state description pattern to invert it back. So, for example, your door Item’s state would be OPEN when the door is actually closed controlling the icon on the Location card as you want. But the state will show as CLOSED in the UI. No need for a separate Item to do it that way.
You’ll just have to remember that what you see in the UI will be the opposite of what you’ll see in the logs and in rules and persistence for the actual state of the Item.
Even all other answeres regarding the inversion of states are correct, what you want to achieve will not work with the system location card, as it is not using the icons defined in the category but hardcoded ones AFAIK.
Only posibility would be to rebuild the location card with custom widgets.
You might find other topics where users tried to do the same. Just search for location or location card…
You simply cannot get there from here. You cannot have two “door” icons and each icon expects Items of a certain type to drive them. You can’t use Contact Items to drive the temperature icon on the Location card. That icon is driven by a Number. You can’t have more than one door icon on any one Location card.
What you want is simply not possible with the Location cards. As @hmerk said, you’ll need to create your own widget to do this. And of course, your own widget won’t appear on the Locations tab. You’ll have to put that on a page.
THAT would certainly make things much more clear. 
Oh well.