Discussion about OpenHAB Item types

Tags: #<Tag:0x00007f386ea2bec8>

I must say I did not understand a single thing of your explanation.

The (unofficial and closed source) binding for my Wavin under floor heating uses a Number (input) for the measured air temperature, and uses a Number (input/output) for the setpoint. Combined with the Setpoint sitemap item this works pretty well; I can change the setpoint by turning the knob on the wall, and the item in OH gets updated. And I can change the item in OH, either from a rule or through the sitemap, and the display on the wall gets updated. My point is that a Number works fine here, and could work in other cases as well.

Regarding the naming: for people who do not know OpenHAB, there are still a lot who have an idea of what a dimmer is. In other words when we have a Dimmer in OH, some would expect it to relate to a dimmer which outside of OH is normally used to control a light (occasionally a fan or something, but that is not what the name dimmer implies). If you go to the hardware store and ask for a dimmer to control your Windows they probably think you are crazy.

And since the Dimmer item in OpenHAB additionally handles ON/OFF and remembers the previous level when commanded OFF, and restores that when commanded ON, then that is a useful feature for a Dimmer when controlling a light, but makes less sense for e.g. a Window.

Let’s take another example from my floor heating: There is an input to OpenHAB indicating whether a particular heating circuit is currently heating. It cannot be commanded directly from OpenHAB, but if you change the setpoint the state will toggle. Since this is a binary input, should it be a contact? But I have defined a Switch, because my rules and sitemap make more sense when they say FloorHeating_UtilityRoom_Active == ON instead of FloorHeating_UtilityRoom_Active == CLOSED

I think I will try to ask him (kindly) what his opinion is about the type (RollerShutter vs Dimmer). It would be nice if the default representation in the sitemap works correctly :wink:

But I can understand that a binding developer can select the “wrong” type, because the generic type (Dimmer) has a name that implies a lot more than “something you can set between 0% and 100%”.

Umm, no it doesn’t. The “remembering” is a feature (or not) of any hardware device linked.
The OH Item type works whether or not the target device has this feature. It just passes ON along to the binding. The binding decides if that device accepts some form of ‘on’, or needs to be sent 100%, or whatever. Because this is technology dependent. Maybe this device doesn’t support on/off, in which case it’s up to the binding to translate on/off into 0%/100% as the best approximation, and send that instead.

Once stuff has happened, the binding updates the OH Item with an actual result - could be 100% or 75% or whatever the device did. The OH Item does not remember, but it does find out.

What makes you think you cannot send a target position to a RollerShutter? You can, and if the binding/technology supports it, it gets dealt with.

I think there is confusion between the widgets used on sitemaps for display and control, and the nature of Item types.

Example - you can represent a Dimmer type on a sitemap as a Switch. When you operate the UI switch, it sends on/off to the Item (and as we discussed dimmer type is happy with that).
You can represent a Dimmer type on a sitemap as a Slider. When you operate the UI slider, it sends number values to the Item.

You can argue that the name Switch for the sitemap widget is confusing, and maybe it ought to be Lever or something. So much of this thread is simply about names.
The name for the Slider widget makes it bit more obvious that this is not tied to any particular OH Item type.

Anyway, you can see where this is leading. You can represent a RollerShutter Item on a sitemap with a Slider widget. When you operate the slider, it sends numeric command to the OH Item. The Item passes this along to the binding. If the binding/device supports it, the number gets passed along in whatever form, it might need massaging from % to mm or something, but that’s the binding’s business.

Just because a RollerShutter Item supports up/down/stop, you don’t have to use them. Just because the obvious sitemap widget has up/down/stop buttons, you don’t have to use that.

EDIT - a late thought for a mind-boggle. You can represent a RollerShutter type on a sitemap with a Switch widget and get position control with a set of buttons.

Switch item=myRoller mappings=[0="Close",10="Lil bit",50="Mid",80="Nearly",100="Open"]
1 Like

Item types with capabilities :slight_smile:

Along the lines of “Color<RGB,HSV,Temperature>”

It’s also a question if rollershutter and Mediaplayer etc should be removed and only basic types remain ie binary_switch, number, text etc. There’s no difference from a Dimmer and a Rollershutter in code for example. It’s just existing because Kai required it once, I guess.

Commands like “Stop” are expressed as channel actions nowadays.

Thanks @rossko57,
Your post cleared up a few cunfusions on my part:

I just thought that the default widget for any given type would be the most capable or appropriate, and that overriding it in the sitemap was more of a way to make it simpler. In my opinion a slider for controlling the window to any position is superior to the up/stop/down, in particular when the latter is not working (because the device in question takes a position command).

Perhaps the main fault was believing that usind the Default widget would get me the most appropriate one. :wink:

I was not aware that the ON/OFF commands sent to a dimmer were actually sent to the binding in a different way than the numeric values. I just thought that overriding the sitemap widget with a switch would send values 0 and 100 to the item.

I do agree that the distinction between the Slider widget and the Dimmer item is nice, and that the clashes of nameing between some other widgets and items only adds to the confusion.

Your switch example is actually pretty clever IMO. For instance the velux windows has a “ventilation setting” where the window is closed but the air vent on top is open. This is obtained with a setting almost at the end (e.g. 99% since the scale is reversed), but that can be difficult when using the slider :wink:

Often we will get an article like this started as a new thread (probably in the Development Documentation category). Make a first draft as the OP of the thread and see if anyone has any feedback or ideas. Once you feel happy with it you can submit it as a PR to the openhab-docs repo. See How to file an Issue which ought to get you started. If not let us know and we will help you through the process.

Can does not mean must. The fact that a Dimmer can accept an ON/OFF command doesn’t mean one has to. Until this post you were unaware that this was even a possibility. For the rest, again, take it up with the Velux binding author. There may be a more appropriate Type to model the windows controls.

Also, it is important to draw a distinction between the Item Type and the Sitemap element. Often they don’t have much to do with each other. For example, I can put a String Item on a sitemap as a Switch or a Color Item on the sitemap as a Slider. Is your issue really that the binding is using a Rollershutter Item Type or that you chose a Rollershutter sitemap element where a slider or setpoint might make more sense?

But it makes perfect sense for a volume control, for example.

Yes, if OH cannot command it (i.e. turn it on or off) then a Contact would be the appropriate type.

We can go around and around and around on this forever. If you insist on taking the chosen states as literal then you will forever be unhappy with the Item types that exist in OH. None of us will convince you and if you feel compassionate about this you can submit the PRs to change all the names across the half dozen or so repos such a change would impact. I’m not hopeful that such a massive change for so little benefit would be accepted.

This is almost never going to be the case. Most OH users discover pretty quickly that the default representations of any Item type rarely works like you need it to. Part of this is because, as I said, the sitemap elements are not strictly tied to the Item types most of the time. For example, you could put the window Item on your sitemap as a Slider.

I guess I am used to some type of booleans in other programming languages, where the name of the variable makes the code readable. I have just not found an elegant way to do this with the item types available in OpenHAB. I would love to do it in a different way than what I am doing now, because I think the rules often need comments to explain what is being done, instead of the code just explaining it.

Is there a different way than creating proxy items and writing rules to map for instance a contact == OPEN to a window = “closed”? For instance if I want to write a rule that when the window is opened, the heat is turned off?

I think the rule DSL is perfect for creating logic for a home automation system, such as close the window if it starts raining. But do I need rules to do a simple mapping (contact open => window closed), or when I write rules do I need to always think about the contact on the window instead of the state of the window itself (open or closed)?

OK, maybe I just had too much faith in the Default widgets. I guess after this discussion I understand that there is a much looser coupling between the items and the sitemap widgets. I really thought in 95% ot the cases you would use the default widget, and then in rare circumstances you would use a different widget, such as using a switch in the sitemap when the item was actually a Dimmer.

You might be happier with JSR223 type Rules where you can do what ever Jython, JavaScript (Nashorn), or Groovy allows. It shouldn’t be hard to define your own mappings between these enums. And if your code is complex enough where you need comments to understand what it’s doing, you probably should be using JSR223 Rules anyway as you are either trying to do something really complex or you are trying to do it in a way that Rules DSL doesn’t like.

OH is super powerful and has a great community. But the software itself is opinionated and inflexible. You have to bend your style and preferred approach to OH’s way rather than making OH bend to your preferred approach. This is especially true of Rules DSL.

No, the heat and the window are completely separate devices and must be represented with separate Items (at least one per device). The behavior desired is defined using Rules. I don’t see the need for a proxy Item here at all.

rule "Window and heat"
when
    Item Window changed to OPEN
then
    Heat.sendCommand(OFF)
end

OK, so this is an issue of the sensor itself. I have all wired reed sensors configured in my house which are configured to be normally closed meaning that they don’t report OPEN unless the door or window is actually OPEN. Do you have the ability to modify your sensors in this way. In my case, there are three terminals on the sensor and which of the three you attach the two wires to dictates whether it’s normally open or normally closed. I know some zwave and zigbee sensors have a parameter to configure the sensor like this.

If not, well I think it was already mentioned in this thread having a universal invert feature, perhaps using Profiles. This would definitely be something worth filing an issue on.

In my experience it’s the opposite, but this is partially because so many bindings use Switches when Contacts would be more appropriate. It’s one of the reasons why the Group sitemap element is next to useless.
Also keep in mind that the sitemap is only one way to build your UI and interact with OH. There are others including HABPanel and HABot (which I’ve been playing with recently, it’s pretty fun) which have completely different approaches.

To elaborate on the initial topic (specialized item types), please also note the semantics/ontology capabilities will also be a way to “enrich” your items with valuable information, which could be used by UIs to present you a different experience - think a Dimmer item with a “color temperature” semantic property attached, which could be displayed as a blue-orange gradient in UIs instead of the vanilla slider.

I think/hope the semantic classification if done properly could be the future of openHAB, because they would help getting so much done without any additional configuration. The upcoming UI will allow you to define them more easily (example w/ disclaimer - not functional and subject to changes: https://ohui.azurewebsites.net/#!/settings/items-virtual/Temperature_FF_Daughter/edit).
Also have a look at the tabs on the home page - https://ohui.azurewebsites.net/ - while the Overview tab is basically still a mockup right now, the cards on the other tabs at the bottom (Locations, Equipments, Properties) are already using the ontology to group and display your semantically-tagged items depending on their class, without having to define a sitemap at all. So if you want to see everything in the Master Bedroom, or all Windows, or Temperatures, you would simply go to the right tab and open the card. Of course it’s very early and would need to be refined but I think it has tremendous potential.

Binding-specific quirks like OPEN/CLOSED/ON/OFF discrepancies could probably be addressed with additional Profiles to choose from when linking your Channels, like “open/closed to on/off” (and an “invert” option, you get the idea).

This was an example to illustrate the point that the sensor item state (in this case a contact which can be OPEN or CLOSED) does not map directly to the same named states of the actual object being sensed. I think it is kind of a coincidence that the sensors are contacts which are OPEN when the window is OPEN (most of my sensors are like this as well, but a few of them are not, which means I have to write the rule like

rule "Window and heat"
when
    // Switch state is inverted, this means window is OPEN
    Item WindowSwitch changed to CLOSED
then
    Heat.sendCommand(OFF)
end

That was what I meant about the comments in the rules, not because the rules are complex.

What about the case in my previous post where the state of the floor heating comes in as a contact? I would like to have a rule saying something like:

when
    Item FloorHeatingState changed to "HEATING"

But then I need to have FloorHeatingState a String item, and I need a different rule that maps FloorHeatingContact to FloorHeatingState (that was what I meant by a proxy item, I am sorry if I confuse even more by not using the correct term).

My point is that I often want to have a binary state of something, which is not controlled by OpenHAB (i.e. it is input only), and hence a Contact, but where the object being sensed does not have states OPEN and CLOSED.

En even funnier example would be if the input represents whether the oven is turned on (e.g. uses power), then talking about the oven being OPEN or CLOSED get really confusing :wink:

Well, it really depend on how you want to model your home automation. Do you want an Item to represent the Window’s sensor? Or do you want an Item to represent the Window? That’s kind of the point of Items. It models your home automation. You give the Items their meaning. You choose a proper name for what the Item actually represents and which makes sense to you.

For me, I could care less what or how I know that the door is open or closed. So my Item name is FrontDoor and the sensor is configured to normally closed.

We only see the things we are exposed to. But every door sensor I’ve encountered, wired or wireless, either reports CLOSED when the door/window is closed, or it can be wired/configured to choose how to report that state. From what I’ve seen, it’s the more usual case.

Depending on the binding used you probably don’t need a Rule. This is what a transformation is for. However, not all bindings support transformations in this way so indeed, a proxy Item would be required or continuing to use comments like this. However, if you are using 2.x version bindings, you can apply a transform to ANY Item using a Profile.

So just create a swapcontact.map file that swaps OPEN for CLOSED and vise versa and apply the MAP Profile to the Item.

This is relatively new and it’s not well covered in forum posts. But I think this is the correct approach, for now at least.

Then you can’t turn it OFF. Contacts are sensors. You can’t send a command to a sensor.

If the binding supports transformations, and pretty much all

Like I said before. The work involved to make that happen is huge! The benefits are IMHO minimal. But that’s just my opinion. You are more than free to file an issue and make your case to the developers and see if they would be willing to accept a PR from you that makes the changes to support something like this. Like I said before, conversations here are fun and enlightening but unless and until someone files an issue and a developer does the work it’s never going to lead anywhere.

But if the binding supports transformations or transformation profiles, I see no reason why you would need the Rule. Just use a String Item you can set to “Heating” or whatever then your Rule can read like your example.

But they´re both there, and they´re operating from the term of the device it handles. Ie open/close for shutters, windows etc… Switch on/off (or turn on/off) for switches etc… Fortunatly they only operate through openhab tags. But I think they got the right idea of whats “normal” og best to comprehend.

I´m not sure I understand.
If you use a slider or a knob, do you ever see the state of on/off for a dimmer? I only see 0 (zero) and number 1-100.
I just remembered - a coupple of weeks ago we had Blinds tag for Google Assistant. I actually tried that tag to see if I could use the voice command “open/close” for my garagedoor, by changing its item type from Switch to Dimmer type, because I was told, like you said, that ON/OFF would be working. I could not get it to work, cause whenever I said “open”, openhab sends a value of 100 to the item. And since the item is a switch it wont work. My point is, the dimmer type does not send on/off. It only sends numbers.

Ahh, yes, you can command a dimmer to turn ON, and it will turn on by a default value (most often 100%, unless else is specified). But to my understand, as descriped above, you can not send a ON command to the dimmer, or at least thats not the way openhab works. If it did, my test as descriped above should have worked.

I know… But there are alot of different hardware dimmers… Even a 1-10volt output is named a dimmer, even though it´s not a dimmer in it physical form, it´s just a electrical voltage regulator, which often is connected to the actual dimmer or driver/transformer.

As you may have read above, I do not agree with Rich on this one.

Hang on…
There are two kinds of Shutters (to my knowledge).

  1. Operating exactly like a dimmer.
  2. Operating with a puls operation… When to push the button, it sends a puls to the device which handles the motor on the shutter, and it starts moving. Next puls would stop the motor. A second button is need to change the direction, which is basic just switch over the two wires which handle the direction on the motor. And then it uses puls again, but now with changed wiring.
    You cant use a dimmer for the second type shutter. The shutter have to understand the value numbers for a dimmer to work.

My garagedoor works almost like the second shutter, beside I control it from one push button only. First push to the button will start the garagedoor moving, opposit direction of last movement. Next push to the button will stop the garagdoor from moving. And third push to the button will start the garagedoor moving, in opposit direction.
This could also have been a shutter. And now when I think of it, I do believe shutters like this excists as well.

As explained. The principal is the same for both when it´s the dimmer technique. I dont know why Guenther chose Rollershutter insted of dimmer types.
This is my items definition for my Velux windows:

Rollershutter Vindue01 "Vindue stue syd-øst 1 [%d]"      ["Blinds"] { velux="thing=actuator;channel=serial#56:08:1D:26:06:29:06:C7" }

And this is my sitemap… Notice I use the Slider:

      Slider item=Vindue01

It is, and to my believe Dimmers can´t operate with ON/OFF. It can probably report the state, but it cant operate using ON/OFF, and it cant send ON/OFF command either… At least I have never seen this.

I havn´t tried, but I guess if I change the item type to Dimmer for my Velux windows, it would probably work the same. If not, then it´s due to something different in the binding. It should still be sending the value number 0-100 to the KLF200 device. But I´m almost 100% certain, it wont send ON/OFF.

It could be done in the binding as well. Pauli Antila (creator of the IHC binding) have made an option to inverse a state through the binding. It´s really usefull. But I guess it would be better if there were a profile for that, so each developer doesnt have to create his own solution.

So OH needs to change everything to chase after what ever they are doing, keeping in mind that what they are doing changes about every month? Oh, and the change is one that will need to be made across half a dozen different repos and will touch just about every piece of code that makes up OH and the stuff around OH?

When OH was started, they created these Types. There have been a few new ones added here and there over the years. It’s not as simple as “Google’s doing something different, lets change everything!”. We will never progress at all if we spend all our time chasing after Google and Amazon.

We’re mixing things here. Every physical dimmer switch I’ve ever seen supports dimming as well as on and off. I’d never see a state as a number from a physical dimmer.

If I call MyDimmer.getStateAs(OnOffType) then yes, I can and do see the state of my Dimmer as ON or OFF. But that’s a translation because a Dimmer Item doesn’t store it’s state that way. It stores it’s state as a PercentType. But I can still send ON as a command to the Dimmer.

No, Google Assistant sends 100 to the Item. openHAB receives the 100. If Google Assistant sent ON, then if you looked at events.log you would see:

ItemBlah received a command ON
ItemBlah predicted to change state to 100
ItemBlah changed from 0 to 100

NOTE: I’m going from memory on how these log statements look in events.log.

If Google Assistant sent an ON command then you could trigger a Rule using received command ON and the Rule would trigger.

But you just said you switched from a Switch to a Dimmer Item. The point is that you can send an ON or OFF to a Dimmer type Item. Of course if you change the Item type to a Switch it won’t work if Google sends a 100 instead of ON or OFF.

I never said that Dimmer type sends ON/OFF. And you are not either. I said that Dimmer type can receive ON/OFF as a command. And you are saying that Google Assistant isn’t sending ON/OFF but 0/100. These are two very different and only barely related things.

Yes, you can send an ON to a Dimmer Item. You test above failed because Google Assistant doesn’t send ON and as best as I can tell you converted a Dimmer Item to a Switch Item which completely invalidates testing whether a Dimmer Item can receive an ON command.

If you really want to test this:

  1. Create a Dimmer Item
  2. Put the Dimmer Item on your sitemap as a Switch
  3. Watch events.log
  4. Toggle the switch and watch events.log. You will see that it receives command ON.

This isn’t an opinion. It’s objective and documented fact.

There are a number of Items which accept multiple state data types, for example DimmerItem , which accepts OnOffType and PercentType , RollershutterItem , which accepts PercentType and UpDownType , or ColorItem , which accepts HSBType , OnOffType and PercentType .

The test you ran didn’t actually test for this behavior. All you showed is that Google Assistant doesn’t send ON/OFF but 100/0.

That’s because Items never send commands. Items only receive commands or updates.

Only if the binding is OK with that. Most bindings are very specific about which Item types need to be linked to a given Channel and if you deviate from that it will not work.

OK, let’s step back here a second. Items are completely and totally passive. Not even Switch Items send ON/OFF. Items only ever receive commands or updates. Changing a Rollershutter to a Dimmer isn’t going to magically cause what ever is sending the commands (sitemap, HABPanel, binding, Rules) to start using ON/OFF. If you want an ON/OFF command, then you need to change what ever is sending the command. Changing the Item type does nothing. Items must conform to the things that command and update it, not the other way around.

The transform profile should be able to handle it, so long as you are using OH 2.x bindings.

Throwing in my twopenneth -
You can command ON to a Dimmer Item
The Item will pass this ON along to any and all bindings
It’s up to the binding to handle that into terms suitable for the device (or ignore)

Don’t get confused about actions of autoupdate muddying the water with it’s best guess prediction of likely outcome (such as 100%).

No thats not what I said. I said they (Google Assistant/Aleax and probably also Siri) is using terms which the users understand from the device it handles. As mentioned a few times… It´s confusing to use terms like “turn on/off the window” or “turn on/off the garagedoor”. Or like OP mentioned previously, “open/close the oven”. Terms like this makes it quite confusing. You´ll probably never see GA/Aleax or Siri doing the same.

But I can still send ON as a command to the Dimmer.
[/quote]

Hmm just made a fast test…And you´re right…

Test switch (virtual switch) and Dimmer item.

Switch DimTestSw            "Dummy switch for testing dimmer on/off"                           <switch>
Dimmer    spise_halo_styrke          "Spotlys ved spiseplads [%s %%]"                                          <cu_spot>        (vLys)                                           ["Lighting"]              { channel="ihc:controller:elko:spisespot_dimmer", autoupdate="false" }

Small rule to send the ON/OFF to one of my dimmer…

rule "Test dimmer switch"
when
    Item DimTestSw changed 
then
	if(DimTestSw.state == ON) {
           spise_halo_styrke.sendCommand(ON)
        logInfo("info", "Dimmer test switch ON")
    }
else
	if(DimTestSw.state == OFF)  {
           spise_halo_styrke.sendCommand(OFF)
        logInfo("info", "Dimmer test switch OFF")
    }


end

This is what happens turning ON:

2019-05-30 00:02:36.355 [ome.event.ItemCommandEvent] - Item 'DimTestSw' received command ON
2019-05-30 00:02:36.370 [vent.ItemStateChangedEvent] - DimTestSw changed from OFF to ON
2019-05-30 00:02:37.732 [INFO ] [.eclipse.smarthome.model.script.info] - Dimmer test switch ON
2019-05-30 00:02:37.734 [ome.event.ItemCommandEvent] - Item 'spise_halo_styrke' received command ON
2019-05-30 00:02:38.971 [vent.ItemStateChangedEvent] - spise_halo_styrke changed from 0 to 25

And this happens when OFF:

2019-05-30 00:07:20.187 [ome.event.ItemCommandEvent] - Item 'DimTestSw' received command OFF
2019-05-30 00:07:20.203 [INFO ] [.eclipse.smarthome.model.script.info] - Dimmer test switch OFF
2019-05-30 00:07:20.208 [vent.ItemStateChangedEvent] - DimTestSw changed from ON to OFF
2019-05-30 00:07:20.217 [ome.event.ItemCommandEvent] - Item 'spise_halo_styrke' received command OFF
2019-05-30 00:07:20.393 [vent.ItemStateChangedEvent] - spise_halo_styrke changed from 25 to 0

The Dimmer item receives ON/OFF fine, but it sends a value to the dimmer through the binding. (I have the Dimmer item pre-configure to 25 by default… an extra nice feature in the IHC binding. Wihtout it would have send the value of 100).
This explains why it didnt work when I tried for my garagedoor, cause if the binding “tranform” ON to a value, the switch wont be able to handle this…
But you´re right, the dimmer receives ON/OFF just fine. But the binding sends a value/number. And it wont work when the device is a switch, ofcouse.

Reminder: binding (technology) dependent.

Perhaps. But if the dimmer cant receive an ON/OFF, why should the binding pass it on?

Exactly. I don’t know how else to put this; one more try. It is the job of the binding to match up openHAB’s idealized model world to real devices with nasty variant technical interfaces.

openHAB’s model Dimmer supports percentage setting and on/off. That’s a design decision.

Any real device may require a “hey you, wake up!” followed by “here’s a command, x0AFB” followed by “here’s a parameter x0FC0”. That’s 1,999 design decisions by manufacturers past and present.

The whole point of the model is to insulate openHAB from this stuff.
In openHAB, all dimmers look alike. All can do on/off, all have a 0-100% range.

The bindings hide that this dimmer can’t do on/off and that that dimmer has 0-255 steps. The binding author (should) make sure that ON gets translated into something close or that 98% gets translated to step 250.