Dimmer bgrightness issue

Hey,

I have added a first dimmer to my OpenHub setup. It is a basic ebay grade zigbee dimmer connected to zigbee2mqtt. It reports on
{“state”: “ON”, “linkquality”: 102, “brightness”: 90}
Now regardless if I do it by sending message directly using mqtt or from openhab (hence it does not seem to be a config issue, just awkward dimmer) it acts strangely. i can change brightness to anything and it works as charm. I can send message to dimmer/set topic with On or OFF message and it will toggle on and off. But then if I set brightness to 0 it will change state to OFF, but brightness will toggle for a second to 0 and back to original value from before sending 0. So all good, lamp is off, state is good, just brightness doesn’t go down to 0 in reported values.
Now when I use slider in sitemap, and slide it all the way down to 0 and release it switches the dimmer off but then jumps back to the original value. Light is off but interface then reports as of it would not be off. A bit annoying.
Is there a way I could get openhab to read 0 as brightness or override the brioghtness for slider and each item where I want to report it (if I for example use it within a group) to 0 when state is OFF? Or do you maybe have any other suggestion to overcome this? Happy to share some config etc, but as I said issue persist when I send raw {“brightness”: 0} to dimmer/set topic via MQTT Explorer.

Hi Dawid,
As a newbie myself I only have an idea of how it could be solved, no ready-to-use solution.
As a Thing can be just a variable not hooked to a device, it should be possible to create a variable as a proxy for your real thing. Then add a couple of rules to update your virtual dimmer variable on state changes of your real one.
I wouldn’t expect this to be achievable though Paper UI; you would need to configure through files, which IMHO is by far more powerful (and complex) anyways.

Markus

That is a good shout. I am not using PaperUI, it is a nice tool but yeah you can do more in files.
I’ll give it a try! Thanks!

Hi @Dawid_Walkowiak

I think that the reason the switch jumps back to the original value is so that it will know what to return to when you switch it to ON. If it didn’t do that, then ON would give a brightness value of 0. So, you actually need it to return to that value in order to use the state channel.

@Schwabix is on the right track. Rather than a variable, you’ll need to create an unbound string item that serves as a proxy for brightness in OH, then use that in your sitemap.

  • If state is OFF, then proxy item = 0
  • If state is ON, then proxy item = brightness state
  • If proxy item changes to 0, then state = OFF
  • If proxy item changes to more than 0, set brightness to that value and state to ON

Truth be told, I would probably just keep things simple and change the way I think about and use the dimmer, but this should cover the bases if you’re set on having it show you a brightness level of 0.

1 Like

@Schwabix, I just want to clarify that this would be an Item, not a Thing. The terms can be confusing when you’re just getting started. :wink:

I see the idea. I am a key worker so might be a while since i get enough time to test it but it makes perfect sense. I would not be bothered about it but then the interface would indicate that the lamp is on when it isn’t, so I’ll try it out. Thank you all for the quick response!

That’s why I suggest that the easier/better thing to do is change perspective on how the dimmer works. If you view the brightness state as “how bright the lamp is when it’s on” instead of, “the lamp is on or off”, then no workaround is needed. It’s only indicating that the lamp is on because you’re interpreting it that way. Your state channel can tell you if the lamp is on or off.

This is a good way to learn how to use rules since it’s a relatively easy scenario to code and troubleshoot. I just generally think it’s better to adapt to how something works instead of forcing it to fit into my predefined worldview.

Cheers!

1 Like

I get it. Maybe I should add switch item to control the state since state in that dimmer is read/write, then use the switch to toggle on/off and slider to control brightness. That actually makes sense. Agree that it is better not to solve an issue that isn’t actually an issue, I thought it is not a correct behaviour, but since you’ve explained otherwise I may as well just deal with it. Thanks!

1 Like

No problem. I think you’ll actually find that this is more convenient in the long run. I use rules to set my kitchen to 75% during the day and 20% after I go to bed, so that I don’t get blasted with light if I go to the kitchen at night. I never have to think about what level I’m setting for my dimmer, since OH does the work for me.

Makes sense. Already did that bit and works well. Now i set var to store last state for me as i will have those dimmers in a staircase and i want to use 20% for night with movement sensors when i go to loo not to feel like interrogated every time and last stored brightness for pressing rocker buttons. Thanks again, after all what i considered a fault was just feature.

1 Like

That’s a good solution. You might also want to check out the Time of Day design pattern, which many people use to define behaviours within certain periods of time.

Personally, I use unbound items to define modes for my system. I have a Night mode that I turn on when I go to bed and an Away mode that I turn on when I leave the house. Many of my rules check for these states to determine if they should act.

Yeah that is my plan. For now I have basic stuff programmed for the switches, tomorrow I am going to use day/night setting (good idea about unbound item to use globally and have correct sunrise time) to switch on/off the movement sensors.