I post this in the off-topic category, as there doesn’t seem to be an appropriate forum for discussing core OpenHAB stuff. Sorry if this belongs in a different place.
Secondly, please don’t take this as a criticism. I am very impressed with OpenHAB, and all the possibilities it gives me of integrating so many different technologies in a smart home. So thank you to all developers and contributers. Your efforts are really appreciated!
That said, I would like to start a discussion about “Items” in OpenHAB; specifically if it would make sense to add or change some Item Types. Of course I hope at some point that some of the developers will also think this discussion is good, so that some of these suggestions are somehow adopted. But I would also like to hear your opinion if you think the suggestions below are stupid; maybe there is something I did not consider.
The topic there was the use of the Rollershutter item for something which is not a roller shutter (in that particular case a Velux Integra motorized roof window).
In my opinion it would make sense to either have some other item types for this (for instance MotorizedWindow), or a more abstract Item (LinearPosition). Any opinions or thoughts?
Another question is how inverting (or mapping/transforming) such an Item could be enhanced. In the thread linked above, the discussion was regarding a rollershutter where it makes sense that 0% is fully open and 100% is fully shut. But when using it with a window it seems more logical that 0% is closed and 100% is fully open. In some cases the bindings have an option to invert the input/output, but maybe this could be more generically supported? I know that much of this can be achieved with a map/transform, but I think it is a little cumbersome.
I also find it a little confusing with switches and contacts. As I understand, contacts are inputs (to OpenHAB) only, whereas switches are normally outputs from OpenHAB. However, they differ in other ways (switches being on/off, contacts being open/closed), and in fact often bindings use switches for something that is input only, probably because they are better represented with an on/off state than with an open/closed state. I have some inputs (contact items) for various devices, all coming in through MQTT with values 0 or 1, but I had to create two different maps because some inputs are inverted, and some are not. And a separate map is needed for the text to show in sitemap (for instance the PIR sensors state should not be shown as OPEN or CLOSED).
A related problem occurs when using dynamic icons in the sitemap. For instance I have the following in my sitemap to set the thermostat in the master bedroom: Setpoint item=Heating_MasterBedroom_ManualTemp label="Setpunkt" icon="heating" minValue=15 maxValue=28 step=0.5
The problem is that the dynamic icon uses the scale from 0 to 100, but in this particular case it might be more logical if the range was 15-28. However, I don’t think it is possible to use a transform for the dynamic icon, and I don’t want the setpoint to be set in percent
I’m not sure what your difficulty is with icons in your example. You can create a set of numbered icons with “boundaries” wherever you want (in 0-100 range), each icon covering a range. The boundaries between ranges do have to be integer, though. You might have icon.svg, icon-16.svg, icon-19.svg etc. When state is 17.5, icon-16 will be displayed.
Not handling negative numbers is quite a restriction on dynamic icons and difficult to overcome without scaling and dummy Items etc.
As a general comment … for every issue, you actually seems to have dealt with it ok? So far as I can see, the whole OH philosophy is to build on simple blocks to allow tailored complexity. Of course flexibility comes with a cost of, well, cumbersome but this seems to validate the approach.
Every one of us has different devices, the design philosophy is to reduce to simplest model - or combination of models. Having said that, things that don’t fit can be modelled as new Item types - for example geo position Location type is relatively new.
The switches/contact debate is very long running. Not all binding authors have the same view, so yes there are inconsistencies.
Part of the problem is the familiar names - Switch , on/off, open/closed.
I find treating them as “binary output”, with state X and Y, and “binary input”, with state A and B covers most usage.
Whatever you decided to name A and B, people would want different languages and interpretations of which was up or down!
There is a valid observation - why then don’t we have read/write Numbers and also read-only input-only Numbers (for sensors)?
I think it’s just inherited from early design decisions. Maybe in OH3 they might do away with Contact types and have a single binary “Switch” type.
To my understanding:
A Switch is something you do by hand/finger/manually etc.
A Contact is an indirect handling of an automation, like a relay etc.
A switch do contain contacts, but that doesnt make them contacts in a principal manner.
A Switch should always report state ON/OFF
A contact should always report state OPEN/CLOSED
Think of what you do, when you want to turn/switch on the light… You do not “contact on the light”. You either turn or switch.
You can turn on a switch, which have an influence on a relay, which then open/close a contact.
A switch which report state OPEN/CLOSED could become a problem, if you need to verify wether a device is open/closed from its contact. Likeweise, a contact which report state ON/OFF could become a problem if the situation calls for open/closed.
When this happens, someone has to deal with it, (in openhab, often by the use of mapping). But by not mixing up the terms, we could avoid having to deal with it like this.
The bad thing is openhab is, that it´s mixed up. It shouldn´t be like that.
Well as an English-speaking electrician, I do close the contacts (inside the switch) to make the light go on. As I said, a lot of this is about the names that happened to chosen to represent binary devices. We really wouldn’t be having this debate about binary devices with state X.
So, if you ask someone to lit the light, you tell them to “close the contact inside the switch” ?
But the binary state cant be set, unless you have pre-defined it´s state… (ie A = open, B = closed… or 0 = Open, 1 = Closed). Someway or another, you´ll have to define the binary state to make it usefull.
Well, I get your point, although in my opinion a dimmer is something used to dim the light, not something representing some other continuous function (as in this case the position of a window). Maybe this should actually just be a Number item, and in the sitemap there could be a Slider, which could have a minimum and maximum (perhaps even steps like the Setpoint).
Yes, I am aware of this. However I would have to create several sets of icons if for instance one item was used to set the temperature of a room (e.g. 15-28 degrees C), another to set the hot water boiler (maybe 40-60 degrees), and one for the oven (50-250 degrees).
Like I said in the other thread. They all use the same principal. You think of a dimmer as its for lighting. But it´s just an “device” which sends dynamic values. Thats why a dimmer type will work for blinds, rollershutters, windows, garagedoors, gates etc… anything which makes use of this dynamic values (commands).
Nope, that would not do… Number item is a static number or a static state of a none-moving device, and cant be controled with an slider, as it requires dynamic values to controle the movement.
Ofcouse they´re all just numbers, but with static number type, you´ll have to create a rule for the calculation of the “movement” based on the static number. In a dimmer, this calculation is already done.
I guess it´s easier to just use a dimmer rather than doing this sort of calculation and rules
It really isn´t that difficult… I have created 12 icons for my downlight (spot light) which is controled by a dimmer. For each step 1-10%, 11-20%, 21-30% etc… a icon indicating how much light (yellow blur). It takes only a few minutes to do in Inkscape. Whenever the dimmer value is between 1-10% it shows that icon. When the dimmer value is between 11-20% is shows the next etc.
Again, it’s just a naming thing. In the openHAB model, a dimmer type is just a special case of a number type - limited in its range, plus you can send it special commands to go directly to the limits of the range. “dimmer” is shorthand, the same model would suit a powered window.
Nope, I’ll say “flip the switch” or something. Maybe we need a FLIP command in openHAB?
Now ask me to describe in technical terms what happens inside the switch.
Perhaps I’m just used to the abstraction, but it really doesn’t matter what a binary I/O model is named in one language or another, we have to name it and it’s states something.
I think that’s what you’re saying too? no-one cares what OPEN and CLOSED are as OH states, so long as they can assign their own meanings like “Fire Alarm!” and “ok”. All the tools exist to do that, except mind-read the requirement.
Yes, that’s right. Some folk would different icons anyway for room/boiler/cooker, but that’s not the point.
I guess you want some indirection, let’s say a MAP/SCALE/JS transform for icon selection independent of any state transform for display. I don’t know what they’re thinking of for sitemap-like capability in OH3, but it would be a valid suggestion.
I did start topic Flexibility of framework supplied types with Eclipse SmartHome a while ago. I was looking beyond existing types, especially towards more complex structures such List, Time (Instant), Range, Schedule and more.
Currently there are no chances to introduce new types as openHAB (former ESH) core is not able to pick types dynamically. We need to remove a bit of legacy from rest layer and core in order to solve this trouble.
If you’ll take a look on forums you will find that there are a lot of situations where people work around issues with lack of complex enough types with various JSON combinations and parsing of it all over the places. This is far from good. I know we can do better!
I would say that support for “flip” command for On/Off types and other elements is something we should definitely consider. I can think already about many cases when “inverse” is necessary.
I am aware of the difference between a switch and a contact, but I fail to see how making that distinction in OpenHAB is of any benefit.
For instance I have a (magnetic) contact on a window, but the fact is I am not interested in the state of the contact, I am interested in the state of the window. When I look at the sitemap, I want it to show that the window is open, not that the switch on the window is open, because depending on how the switch is wired, and how the input comes into OpenHAB that may be different things (i.e switch is closed when window is open). I just believe that this is such a common case that having to make a transformation for it is silly.
I must say that personally I wouldn’t mind adopting the naming from switches so that an input also used on/off, rather than open/closed. Maybe it makes less sense to talk about the window being on or off.
With dynamic icons in the sitemap, for instance, we have window-open.svg and window-closed.svg, but we have alarm-on.svg and alarm-off.svg. That just seems complicated to me, without gaining anything. I just find it akward that I have to rename or copy the icons in order to show the correct ones. If for instance I have a mechanical wall switch turning on a light, but also have an input monitoring the state. Since this is an input only, should that be a contact? Then I have to copy light-on.svg to light-closed.svg and light-off.svg to light-open.svg. It seems counterproductive to me.
Yes, a transform for the dynamic icons would be a more elegant solution than making copies of the icon files. But I already find it somewhat annoying that I have to have different map transforms for contacts, depending on whether they are inverted.
Anyways, as I started out saying, this is not criticism, but just a discussion to see if we can come up with something that is even better (easier to comprehend).
We can absolutely have a conversation here among us users. But to get anything like this in front of the developers you will need to file an issue on GitHub. There are various reasons why this must be.
So everyone, please remember and realize that no one contributing to this conversation speaks for the OH project. And I doubt any of the developers will actually take place in the conversation. Let’s not anyone get angry, worried, scared, or upset. Let’s keep it civil and productive, but remember, unless and until anything discussed here gets presented to the developers in the form of an issue, nothing will be acted upon.
Personally, I think it is a mistake to take the name of an Item too literally as they are not intended to be taken as such. For example, a Dimmer can and should be used for any device that represents it’s state between 0 and 100 and can be turned off. Thus it can and should be used for lights as well as volume controls, for example.
Thus, a Rollershutter Item can and should be used for any device that goes up and down and responds to those types of commands. (NOTE: there are other distinctions between Dimmer and Rollershutter that means the two are separate types including the fact that a Dimmer is also a Switch but a Rollershutter is not).
Except for the fact that we have basically had most of these Items from the beginning I don’t have a lot of heart burn if someone came up with a more generic naming scheme. But I personally do not think that any benefit that results would be worth the very massive amount of work that would be involved to change the names of all the Items. In essence, the Rollershutter Item already is intended to be your more abstract “LinearPosition”.
I am very much against having more than one Item type that does the exact same thing.
I’m not a developer so I don’t know how feasible this is. Traditionally this has been handled by the binding because it is the binding developer who is the closest to the devices and knows whether this is needed. There are other generic services that have been created, such as Profiles, so I’m not going to say it’s impossible or even hard to do.
Unfortunately binding developers do not properly follow the convention. A Switch should only be used for something you can control from OH. A Contact should only be used for sensor values. This should be the hard and fast Rule. But it’s not be enforced very well.
There is one other major difference between a Switch and a Contact that isn’t mentioned. You cannot send a command to a Contact. It’s a sensor, it makes no sense to command a sensor.
My recommendation is to file Issues on bindings that do not follow this convention. I know of at least one binding developer who is willing to accept such Issues. Each binding has it’s own developers so we may not get a positive response in all cases. But by filing the issues we at least bring the issue to the developer’s attention.
As for your MAPs, with MQTT 2 you wouldn’t need the MAPs at all. You can define that the values are inverted at the Channel definition without needing a transformation.
I’m not sure how any of the previous discussion would change this issue one bit. Look at https://www.openhab.org/docs/configuration/sitemaps.html#icons to familiarize yourself for how dynamic icons actually work and you will see why monkeying around with types would not be relevant to this specific problem.
If you want to change the range used by the dynamic icons, then you need to make copies of the icons and change the file names as appropriate.
Now I do agree that there are many cases with the built in icons that the names should be different. For example, if the Network binding were doing it right and using Contacts instead of Switches, the network icons should be network-open.svg and network-closed.svg, not on and off.
That’s a very good point.
That’s a good idea actually. I like it.
That’s not correct. It really is Switch is something OH can command (i.e. an actuator) and a Contact is a binary sensor reading.
Correct. It just so happens that the Contact and Switch Items chose OPEN/CLOSED and ON/OFF respectively. But they could have just as easily chosen 0/1 or true/false or anything else. I think rossko57’s point is that we need not focus too much on the fact that ON/OFF and OPEN/CLOSED were chosen for the states (or that Switch and Contact were chosen for their names). The “correct” term for the state is going to vary from one device to the next. The key distinction is:
Switch: can be used by OH to cause something to happen; it responds to a command
Contact: can be used to report a binary sensor value to OH; OH cannot command such an Item as it makes no sense.
The distinction between a Dimmer and a Rollershutter is a Dimmer is also Switch and therefore responds to ON/OFF commands which doesn’t make sense for a Rollershutter. A Rollershutter, on-the-other-hand, responds to UP/DOWN/STOP commands and Dimmer’s do not.
The correct choice for Item is determined not on what the type of the Item is named, but in how the device is used. Almost all the time, the choice of which Item gets chosen is a decision made by the binding developer who looks at the devices they need to control and chooses the Item type that most closely models the way that device works. Like I’ve said a couple times already, don’t get hung up on what these Types are actually named. The important part is how the interactions are modeled.
Therefore a Dimmer should be used any time you have a device that uses a state consisting of integer values from 0 to 100 only and for which ON and OFF are meaningful (e.g. for a volume control ON/OFF would mean mute/unmute). The fact that it’s called a Dimmer does not and should not be taken to mean it should only be used for lights.
A Number, on-the-other-hand can be negative and can represent decimal values with no practical limit in the valid values.
Very true. Given how dynamic icons work I don’t see any way around that. You either need to create separate copies of the icons or normalize your values to work with the 0-100 range.
I’m not sure about Sliders, but you can use a Number Item with a Setpoint and you can define how much the Item increases or decreases for each up/down press. Thermostats often represent both current temp and the target temp using a Number Item.
That’s why a Contact would be the appropriate Item type for this binary sensor. It makes no sensor for OH to send a command to this sensor.
But even though you may only want to know whether or not the window is open, all that OH knows about is the sensor. Only you as the person can give that sensor reading a meaning (i.e. when the sensor says OPEN or ON then the window is OPEN). It will be impossible for the developers to predict all the possible meanings that one might need to apply to a given sensor’s ON/OPEN and OFF/CLOSED state so OH gives you the tools to define that meaning.
I think that is because in many/most cases, OH has the power to turn an alarm ON. This requires a Switch since you cannot command a Contact.
But the ability to have OH command a window to open is rare. So the default icons assume that we have sensors that tell us whether or not the window is open or not, meaning a Contact is the appropriate Item type.
In the cases where OH can command a window to open, a Dimmer or Rollershutter type Item would be most appropriate as those most closely model how such a window would work. But because this cases is rare, you the user would be responsible for building the icons if you don’t want to use the default ones.
In this case you should link both Channels to the same Switch Item and set autoupdate=false. Your Item represents the light. The fact that the command and the status come from different Channels does not mean you should create separate Items. The autoupdate=false will cause the Item to not change state when you issue a command to it and instead wait until the monitor reports that the light toggled.
Here is one thing that I’ve come to realize over the years. Everything in OH is there for a reason. Often there is a really good reason. And if you think about it, the fact that OH has come up with a mere 13 types to model all the ways that OH can interact with all the devices and APIs that it supports (around 350 I think if you count those awaiting merge into the baseline) is pretty amazing. But because the interactions have been reduced to a mere 13 models of interaction, it is impossible to build the right naming and representation for every possible use case. So we have built in tools to allow you to adjust the defaults to suit your needs.
Yes, you need to do some work, but someone will always need to do some extra work because it’s impossible to predict every use case.
I think the main thing that caused me to start this discussion was exactly the specific/generic naming. I know (mostly) how the different items are used, and I understand why the states and actions are named like they are. I just have a tendency to think that either there should be specific names (for instance dimmer, windowMotor, curtain) that does mostly the same, except they use domain specific naming (like a window can open or close), or there should be a more generic item (I think this would be my preference) with more generic actions.
Anyways, I see your point about the amount of work that would go into changing to a more generic naming scheme, versus the benefit.
Still, I must say it bothers me, probably more with the RollerShutter which is quite a specific thing. And maybe I am further confused about the Velux binding where the windows are rollershutters, but when using the default representation in the sitemap i get up/stop/down buttons which do not work. Then in the sitemap I have to specify that although this is a rollershutter item I want it represented as a dimmer, and then I can operate the window. Very confusing, I think.
OK, I will look into that. Thanks.
Yey, that is how it is now, I am aware of that. I still think adding a transform for the dynamic icon could be helpful (if is is possible).
I have once made a PR to introduce a new item type and Kai denied. He didn’t want new types at that time. But openHab is no longer a Deutsche Telekom project with Kai as project lead so it might make sense to just decide that new item types are necessary.
Personally I agree with Lukas. More complex types are required and the current ones need different names. It’s an OH3 thing of course. Fortunately it will not break the binding interface (but user scripts might be affected).
I have doubts about the need for more complex Items. This will inevitably trend towards Items of type LeftHandedGarageDoorTypeSix.
All we really need are
Binary
Number
String
Group
You can build anything else with rules and a group of these.
Of course we should have convenience types over and above these - datetime, dimmer are just numbers with special rules, and very useful too.
We don’t need geolocation or colour - it’s only numbers and some rules for handling - but convenience factor is high.
I’m actually not convinced about the value of rollershutter types - by the time we get to fixing that level of model complexity, it seems to become a poor fit to many different manufacturers offerings. I’m basing that on seeing a fair few kludges in these forums to “match things up”, involving timers and all sorts. Some have position sensing, some don’t, some have slats tilt …
Perhaps an alternate approach is a means for users to define their own Item type, basing it on a collection of basic Items and some user-defined behaviours. People could share their LeftHandedGarageDoorTypeSix.constructions.
On the endless switch/contact debate, I’ve never really understood why OH provides a binary-actor and binary-sensor separately without e.g. the same for numbers. Bin it in OH3, let’s just have “Switch”
Binding developers should define semantics. Not users. And of course color as channel type is required. But at the moment there is for example no white light temperature and that need to be defined as dimmer type atm.
Common types should be in OH. Each binding does it different otherwise.
Naah, Flip or Switch, it´s the same, (the meaning is the same).
I know whats happen inside at switch. As I said previously, a switch contain a contact. But that doesnt make it a contact in a technical term.
As Rich points, (later). A contact can not be controlled. It´s a state, wether or not it´s ON/OFF, OPEN/CLOSE or 0/1, it´s a state. Problem comes when you need to work futher with this state. If it´s far from it´s purpose (ie a window can either be open or closed), then you´ll somehow need to define the I/O, 1/0 or ON/OFF to something like open/closed. But if the state is already open/close, you can make use of it without any futher hassle.
Also open/closed for windows, blinds, shutters, doors etc is much easier to comprehend.
Partly agree… Ofcouse you´re right, that o matter whats it´s called, it´s the state which is important. But as said there is a difference between Switch and Contact in a technical term. If you tell me to flip the contact, I´ll probably look very strange at you asking you what you mean. But if you say, flip the switch, I´ll know exactly what you mean.
To give you a real live example.
Atm Google Home (assistant) do not know what open/close means, (i know those who have routines can make this work, but routines havn´t been released in all countries yet)… Routines would be like making a rule in Openhab. So lets not focus on routines for now).
Anyway - I´ve got this garagedoor which is beeing triggered from a switch. (a puls will make the garagedoor run, either closing or opening). To be able to control this garagedoor from Google Home (Assistant) I´ll have to say, “switch on the garagedoor”. And since this is a momentary device, I´ll have to say the same to close the door as well.
If Google knew how to open/close, then I would be able to at least use one term correctly. I will still have to use the same, ie “open door” for opening, and again “open door” for closing. BUT - If Google knew its state (ie open or closed), it would be possible to say “open” for opening the door, and “close” for closing the door. This is why the state is important… Ofcouse it would still work for 1/0 or ON/OFF. But then there will be a need to tranform this into the “real” state, either open or closed.
I hope you can see where I´m getting at. I dont disagree with you, that on/off, 1/0 or whatever could do. Butt the meaning itself is pointless, when there already is a much more suitable term for this, open/closed.
Next problem is, if you use transform, you´ll not be able to use the transform state in dynamic icons. And I think rules got a problem as well, (not sure about that though). But this is openhab issues.
Hmm I´m not really sure why this is suppose to be a problem. Unless the magnetic has fall off the window, you´ll be told from the sensor, that the window is either open or closed. Or, in a technical term, the relay contact is either open or closed. How you use this for anything is all up to you. But thats what the sensor can tell you and nothing more.
But then you´ll not be able to tell, if it´s a contact or a switch, (ie a device you can controle or a device which is just able to report its state).
I believe by using common sense, on/off, open/closed should be use from its purpose of the device. A window can be either open or closed, not on/off. Why should the reported state be on/off then?
If it´s a binary sensor its state can be anything. But it doesnt tell its purpose. Not untill you put the binary sensor on a door/window, then it has an purpose, and should report the state of the device.
Yes, it´s a binary reading like anything else. Normally binary readins are 1/0 or I/O, could also be ON/OFF. But very seldom it´s open/closed as the term open/closed indicate a state of something, which itself has the state either open or closed. It doesnt mean you can´t use 1/0, I/O or ON/OFF, but if you put these states into a window controller, the output would have to be changed (ie the state transformed), to make any sense. Ofcouse you go continue till the end, and end up with the state “windows is I” or “Windows is O”. But I doubt you´ll find any humans out there finding this statement beeing logic to comprehend. It will work allright though.
Exactly. Thats why there is a need to have both switch and contacts.
I have never heard of or seen a dimmer which could respond to ON/OFF. I have seen dimmers combined with a switch, but then you have a different device or two devices.
Why should the dimmer use ON/OFF anyway? It doesnt need it, since the value of zero is OFF, and anything above is ON.
Hmm I assume you speak from openhab perspective now?
A Rollershutter makes use of the very same as a dimmer. A dimmer has a STOP as well, (normally when you release the button, if it´s a push button or simular). UP/DOWN is just terms of the very same behaviour. But ON/OFF makes it a bit difficult, cause it´s never ON or OFF. The best I can think of is a state of standby. But again, it´s exactly the same as a dimmer. The reason why UP/DOWN and STOP is beeing used is to make sense for a human. You actually open up or close down the shutter. Stop is use depending on how the controle is done, (one button or two buttons, maybe even three buttons controled). If its a pulse (like my garagedoor) and you need it to stop somewhere before the end, then you either need to remove you push to the button, press another button to make it stop half way all depending on, how it´s made. This is exactly the same as my Garagedoor. It could have made sense using UP/DOWN/STOP as well. I control my garagedoor from one pushbutton.
Agree, but this “technique” isnt really usefull as dimmer control. Insted of a number/value, you could make use of ON insted… For each ON, increase with 10% or something simular. Doubble press for changing direction etc… But it a real pain to control a dimmer like that. And I wouldnt actually call it a dimmer, just a very bad working dimmer-like behaviour.
I partly agree with Rossko on this… I dont see any need of more item types, cause in a principal manner, what OH already have will cover most.
The problem is when people like OP think a dimmer is for light only. (He is not alone on this as I have seen others saying exactly the same). Then things starts to get confused.
So what OH could do is to have better/more clear definitions, but still using the same type. Ie
Dimmer is the main type for shutters, blinds, windows (dimmer controlable windows) and things like that. The user will define his item as a “window” type, but “behind the scene”, its actually a dimmer type.
But I havn´t given that much thoughts wether we need more or new types of items…
Consider commanding a dimmer ON. Do you mean turn on at last % setting, or turn on at 100%? Dimmers with both behaviours exist in the real world. The openHAB abstract model supports either type, and lets the binding sort out what the real device does, because the binding is the real-world interface.
Thats why I dont see the need for ON/OFF for dimmers. Demanding a dimmer to ON would in most cases I´ve seen set it to 100%. Philips Hue bulb is the best example I can think of right now. Untill a coupple of months ago, they didn´t even save their previous state. Switching on the bulb, it went to 100%. Other dimmers with a build in switch (to control ON/OFF) remember its previous state.
But I fail to understand the need for ON/OFF? Whats the difference between 0 (zero) and OFF?
but this seems to validate the approach.
