Dimmer vs Switch Items

I thought I had this correct but maybe now have confused myself. I had thought that you can set up a Dimmer in your items, and then include that Dimmer as both a switch and a slider in your SiteMap.

I have this Dimmer in my items

Dimmer Light_Family_Left “Family Left” (GF_Family, Lights) {hue=“4;brightness;30”, imperihab=“room:Family,label:Family Left,type:DevDimmer”}

And in my SiteMap I have both a Switch and Slider for the Item as follows:

Switch item=Light_Family_Left
Slider item=Light_Family_Left visibility=[Light_Family_Left==ON]

The Switch shows up in OH and I can control the light, but the ‘light bulb’ does not change from Off to On, and the slider will not hide and unhide itself correctly either.

Did I miss something?

Because your Dimmer Item is not a switch it never has the state ON or OFF and the sitemap depends on the state to choose the icon. If you:

cp light-on.png light-100.png
cp light-off.png light-0.png

It will at least show the “ON” light icon when it is 100% on, the “OFF” light icon when it is 0% on, and the default light.png icon for all other states.

Thanks for the help. And that’s where some of my confusion came into play.

I was told in another topic that a Dimmer does have ON, OFF, and PERCENTTYPE.

So I guess I need to change things back and in my items file include both a Switch and Dimmer item for each light bulb, light switch, etc.

I also just checked here and I think a Dimmer does carry on the ONOFF state, so now i’m wondering again if i have something set incorrect in my item or site maps.

From the source for DimmerItem:

    static {


In other words, you can postUpdates ON, OFF, or a PercentType. You can sendCommand with ON, OFF, INCREASE, DECREASE, or a PercentType.

    public void setState(State state) {
        // we map ON/OFF values to the percent values 0 and 100
        if (state == OnOffType.OFF) {
        } else if (state == OnOffType.ON) {
        } else {

In other words, the state of a Dimmer item is always a PercentType, so it will never be ON or OFF.

Thanks for that. I have updated the wiki to hopefully reduce future confusion :slightly_smiling:

Do let me know if my understanding and explanation of it is misleading? Especially my removal of “OnOff” from the “Accepted Data Types” column.

Many thanks

You’re welcome! A worthwhile goal to help others!

Please put that back so the table agrees with the actual Dimmer item as mentioned above.

Please view as a strict rule, that one should only change the wiki once one is absolutely certain of the correctness of the changes.

I think that’s a bug. The DimmerItem should return ON / OFF if it’s displayed in the GUI as a switch.

What lead me to this opinion:

  1. The getStateAs method proves that different return values are provided according to the use. If the call of this method would ask for the OnOffType that problem would be fixed.
  2. I looked at the wiki and the community here. The example in the first post is a typical use of the DimmerItem. A SwitchItem for on and off and SliderItem for percentage.
  3. The DimmerItem extends SwitchItem. I think this was made to provide the whole switch functionality.

I would prefer to revert the changes in the wiki, because the problem is already noted here. Furthermore I would prefer to open an issue for this.

That’s not correct. Please only edit the wiki when you are absolutely certain of the correctness of your edits (this strict rule applies to everyone). Please revert all differences from previous that have been based on any misunderstandings. The wiki is not the place to evolve an understanding of how openHAB works, because that degrades the product and propagates these misunderstandings to others.

Thank you.

I think that’s a bug. The DimmerItem should return ON / OFF if it’s displayed in the GUI as a switch.

That’s not correct.

Would you be so kind to tell us why you have a different opinion?

Please only edit the wiki when you are absolutely certain of the correctness of your edits (this strict rule applies to everyone).

  1. I didn’t made any changes to the wiki related to this thread. Did you read my whole post?
  2. You already mentioned this the third time. :slightly_smiling:

The openHAB 1.x core is stable and working as intended in this area for years. The REST API has been delivering expected output to stable clients also for years. The functioning of these two interdependent areas is working as designed. While you may have a different opinion as to what the architecture ought to be, that is very different from the designation “bug.”

I’m sorry if my comment read as directed at you, it was meant to be generically applicable to everyone.

I am repeating myself because I am concerned that a very important wiki page is being changed by well meaning people who are only recently understanding the core of the system, and it worries me greatly that inaccuracies introduced into the documentation will propagate to other new users and degrade the project, which of course none of us wants!

Fair points, but perhaps a little harsh.

The main reason that openHAB is so hard to pick up is the poor “official” documentation.

The poor documentation is partly the result of people feeling too scared to update the wiki because they might get it wrong. But we should embrace the concept of a wiki and not be afraid. There are countless posts in threads that say things along the lines of “can someone update the wiki”.

Of course no one does, and why should they :slightly_smiling:

If there is official documentation then cool, don’t let anyone edit it. But as that is not going to happen any time soon, isn’t the only option to rely and use the concept of a “wiki” where if there are mistakes made by one person, then another can hopefully correct them.


(smiley face added to make sure the above is not read in anything other than the light hearted casual “no such thing as a stupid question” tone)

I am still confused about the differences between “Accepted Data Types” and “Accepted Command Types”.

In the case of a Dimmer, you can ‘sendCommand’ of OnOff, Percent and INCREASE/DECREASE. All will affect the actual light. But the only value that is saved in the state is the Percentage. That is why I made the edit to the table initially.

Thanks again.

1 Like

Sam and Hagen, I’m sorry if I sounded harsh. You are absolutely correct that the documentation is in need of improvement, and as it’s in the form of a wiki, it’s open to all to evolve it. My only point is that, as long as confusion remains about various aspects of openHAB, the confusion should be fully resolved before editing the wiki pages, lest that confusion enter the wiki pages and spread to others. While we should not be afraid to contribute, we should in fact be afraid to spread confusion to others.

I suppose any harshness in my comments comes from a frustration with the state of the documentation, and in no way with the people willing to step up to improve it. The last thing I want to do is discourage people willing to contribute.

The project owners are well aware of the situation with the documentation, and want to recruit people willing and able to improve it. That being said, openHAB 1.x is very near its end of life, so the real opportunity is to have a fresh plan to create solid documentation for openHAB 2. For openHAB 1.8, adding new wiki pages that offer guides and tutorials would be generally safer than altering core information in the basic pages, and after all doubts and confusion are eliminated (probably via this forum).

Thank you, Sam and Hagen, for your even tone and positive attitude towards contributing. Many will benefit from your efforts.

Kind regards,