Sliders for MQTT Dimmer Items Not Working After Upgrade to OpenHAB 4.3

Setup, Configuration and Use Migration
1

Hi everyone,

After upgrading to OpenHAB 4.3, I’ve encountered an issue where the sliders for all MQTT dimmer items are no longer functional in the graphical interface. The dimmers cannot be controlled via the UI and appear stuck at zero. However, the system continues to work perfectly through rules and voice assistants.

Screenshot 2025-01-04 102127
Screenshot 2025-01-04 102127641×647 24.4 KB

Interestingly, only the sliders are affected: switches and color wheels for other MQTT items function normally. I have also tried creating a completely new thing with its associated dimmer item, but the slider remains stuck.

Furthermore, I noticed that when I adjust the slider in Zigbee2MQTT, the numerical percentage value of the slider changes in OpenHAB, but the slider’s knob remains at zero and does not move. Similarly, when I use a group command to control the individual dimmers, the numerical values update, but the slider’s knob still doesn’t move. Additionally, the sliders no longer display the graduated scale.

It’s worth mentioning that dimmers from other bindings are working correctly, so this issue appears to be specific to MQTT dimmer items. Before the upgrade, everything was working perfectly. If there are any parameters I should check or settings to verify, please let me know which ones could potentially be causing this issue.

I would also like to take this opportunity to thank the community for all the hard work and the invaluable support you provide. It’s always appreciated!

Thanks in advance for your help!

2

This has been noted by several users in the OH 4.3 Discussion thread. What worked for me and others is to add a stateDescription metadata to the slider item with a step unit of 1.

huchMarkus Schuch

N1k145

15d

I also can confirm this. All sliders of dimmer items linked to an mqtt:dimmer channel are stuck at position 0 after upgrading to 4.3.

A workaround for me was setting a state description “step” of 1.

1 Like
3

Thank you so much for pointing this out and for sharing the workaround! I hadn’t gone that deep into the thread, but your suggestion about setting the state Description metadata with a step unit of 1 solved my issue perfectly. I really appreciate your help!

1 Like
4

@florian-h05 is this a UI thing, or a binding issue?

5

I would tend to point towards the binding, my KNX dimmers work fine and I don’t remember a change to the dimmer widget.

6

I posted an issue to MainUI with more details, but this was a change in the mqtt binding that revealed a bug in MainUI.

<Edit to add> This change has been checked in to MainUI and was backported to 4.3.X (pending a new release) </edit>

A recent change in the mqtt binding changed the channel’s default StateDescription logic away from using the user-provided step value (or defaulting to 1 when that isn’t provided), and started sending a calculated step value instead. In the case of, say, a brightness range of 0 - 254 with no step provided, this calculated step would be 100 * 1 / 254, or 0.3937007874015748.

MainUI would then take this value and try to use it to round some values to set up the Dimmer, but the logic was wrong and instead of counting the precision of the step value (in this case 16) it tried to round the values to 3937007874015748 digits and hit a Javascript RangeError exception causing the Dimmer/Slider to not get set up properly. If you check your browser console you should see a RangeError.

Based on the comments in MainUI code it looks like a bug in the UI that should be easily fixable.

2 Likes