Discussion about OpenHAB Item types

Sure, this is much about words and language.
But no matter where you are ind the world, no matter what language you speak, you probably know, what function a device have. Ie… If it´s a door/window, you know, no matter from where you are, that this devices can either be opened or they can be closed.

Problem is today, openhab needs a item definition ofcouse. But in some cases depending on which interface/binding your using, its on/off. Another binding is open/close. Some devices with the same interface don´t arent even equal, like z-wave devices.

Now what if the item type was just plain and simple - Window or Door type?
And for automatic window it could be a simple as - AutomaticWindow - Which btw could be a controled by a dimmer, if it handles on/off :slight_smile:
The same goes for a simple light… It´s on/off… Well, the item could just be as simple as - Light or Lighting.
If it´s a dimmable light, again,plain and simple - DimmLigthing

This way the users dont have to think that hard. And the user certainly dont have to wonder, how come a contact sometimes is defined as a contact, and other times its a switch.

I agree, the nomenclature throws a lot of new users. Perhaps is even better then a glossary is a more thorough explanation of OpenHAB’s specific nomenclature in the concepts.
Folks totally don’t get that a dimmer item can be a light dimmer or a volume knob. (or any number of other things) People are constantly bamboozled by the fact a color item can be a switch item.

If a system is bad, why keeping it and building a bunch of workarounds around it.
If a ton of documentation is necessary because item types have bad names, I mean seriously. Just rename the item types.

This is open source. Either the mediocracy like voted opinion wins, or a better fork appears.

I personally agree that OHs item types are not well thought through, so I’d be more than happy to see this rationalised… However, this should be in OH3 - not OH2. At the moment, we need some stability as there are two many significant/breaking changes going on right now :sunglasses:

That’s fine, let’s do the simplest case. (and yep an OH3 topic)

type Binary_Sensor
A read only Item. People don’t like state On/Off for doors, or Open/Closed for boiler operating indicator, or True/False for windows. 0/1 brings challenges too, 0 implies off or not-something so that will not do. It would in any case get confused with real numeric values.
We’d better have states X and Y to prevent confusion, so that it deliberately conveys no particular association at all.
That does leave some room for confusion with strings of course, but we’re not in a position to invent new characters I guess.

type Binary_Actor
A read/write Item.
It’s an interesting debate whether this should have the same states as its partner sensor. It does seem reasonable to treat an ‘actor’ as an enhancement of the ‘sensor’, so let’s assume X and Y is okay here too.
There arises endless confusion between commands and states, so these ought to be different here. We could make sure to avoid confusion using A and B, but it would be even more confusing to hide any connection between whether A is expecting result X or Y.
Maybe actX and actY would be suitable; obviously not the same as state but clearly related, with an expected outcome.

For myself, I’m not very convinced about having both types - the read-only Contact (binary_sensor) type is a real oddball unless you planned also to introduce read only numerics etc. I’ve not seen any issue arising from lack of read-only numbers for e.g. temperature sensor, can’t see the need?
Bin Contact type and keep Switch with ON/OFF. People who can’t handle the abstraction of “this switch is ON means my door is closed” are going to really struggle with the rest of openHAB.

I would just call it binary. It is not what the users sees anyway, only interesting for a binding developer and the runtime. Binary is unfortunately conflicting with “binary data” like images. Internally that is already called binary.

What I have in mind is in line with Yannicks vision. The binding author MUST assign semantics to a channel, according to the Brick Schema (http://brickschema.org/structure/). Instead of defining an item type semantic tags for Point, Equipment, Location, and MeasurementProperty (and some other meta data like number limits, read-only etc) are given. The value type (boolean, number, string, binary) can actually be derived from those tags. If no tag is matching, a binding author may assign raw types (boolean, number, string, binary) as last resort.

An item may override those suggested tags.

Because those tags are hierarchically organised, a UI can always render fallbacks. So if no “Heat-Pump-Valve” specific widget is existing, and also no “Valve” one, the widget for Number will be rendered. But if a specific widget is available the user will get the best possible experience out of the box. No additional documentation necessary.

1 Like

Afaik as soon as OH 2.5 is out (which should be imminent), the 3.0 cycle starts. So that is soonish and it makes sense to reason about those topics.

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.

1 Like

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 :grinning:
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.

Good points.

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.

3 Likes

Here’s one for you.
MyThing1 (Actually, MyThing1.MyItem1) = boolean
I want a way to create a NEW ITEM that is the inverse of the first.

MyItem2 = !MyItem1

Can this (easily) be done?

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.

image

Rich is right, BTW. I should have checked how stale the thread was.

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.