There is something strange on Dimmer Items connected to a channel, which has a specific “Absolute Minimum” and “Absolute Maximum”.
I created a channel to a MQTT State/Command Topic to be able to change the brightness of a tuya light. The “Absolute Minimum”, which the light supports is “10” and the “Absolute Maximum” is 1000.
The connected item is a Dimmer.
If I want to set the brightness to 10.000 (Maximum) inisde rules, I have to send the value 100 to the item. openhab then send s 1.000 to the MQTT queue. This works fine. But on UI the Slider of the dimmer item has a range of 10 to 1.000 and all values above 100 results in an invalid value on the MQTT Queue.
I think, the slider should only have the values from 1 to 100, since openhab calculates the absolut values by itself?
mind the rules and don’t post everything vaguely related to the RC discussion post.
Only stuff of general interest and specific to RC.
It’s not easy for me to know if this is a RC specific issue or a general issue, since I don’t have this tuya configuration on OH2.5 running and testing and using OH since 2 weeks.
if I find issues in future, I will open a new topic.
You shoudl check the widget options. There are a lot. I had asimilar problem with color temperature and brigthness on a zigbee2mqtt. I solved it using a smal java script that covert values
I am a little bit confused. maybe I completely missunderstand the feature, but in my opinion, there is already a transformation enabled by default.
The “Absolute Minimum” is “10” and the “Absolute Maximum” is “1000”).
If I move the slider to 100, it sends the value 1000 to MQTT
If I move the slider to 10, it sends 108 to MQTT.
If It would be possible to move the slider to 0, I am sure it would send the value “10” to MQTT.
So this looks very fine. The only issue:
On “Settings --> Items --> [MY_ITEM]”, the Slider shows the wrong values. (10 to 1000).
I would confirm, that I am missing any transformation settings, if the OH would sends the same values to MQTT as the slider shows. But this does not happen.
In my opinion, there are two possibilities.
The slider shows values between 10 and 1000.
In this case it should send values between 10 and 1000, if no transformation is defined.
The slider shows values between 0 and 100.
In this case it should transform the values like it does, by default.
I searched for some settings, to change the slider UI, so that it shows only values between 0 and 100. But I was not able to find anything.
Hi. I could solve my issue by defining a Widget. Thanks @Dibbler42.
But why is it necessary to define a widget?
The values are converted by default without any special setting.
minValue = 10
maxValue = 1000
Here the values the slider sends to the queue:
Slider-Value --> Value in Queue
0 --> 10
100 —> 1000
1000 --> Error
It would be much better, if the slider shows only values from 0 to 100, independently, which maxValue and minValue is defined, since there is already a correct value conversion implemented by default.
The default behaviour is strange, but you don’t need to define a new widget - just set the State Description metadata of your Item: you’ll find
max settings which you can set to
I make this adjustment at the end of this tutorial.
@hafniumzinc Good point. Thanks. That works for me and is a much better solution than creating a widget.
Works perfectly. Thanks again!
I’d like to pick this up as I cannot believe that changing the state representation metadata for every single “Dimmer” Item defined by MQTT is the recommended solution…
Defining a channel of type dimmer with min/max/step definition leads to an automatic calculation of a percentage value (ref. MQTT Things and Channels - Bindings | openHAB, Section “Channel Type “dimmer””), that should be linked to to an item of type Rollershutter or Dimmer.
Dimmer is defined to be in the range of 0-100, whereas the UI by default tries to send values out of range to this item. For the UI, the metadata from the Things channel take precedence over the boundaries of the actual item.
If the channel and item would however be defined as a Number (=without any conversion), the default behaviour of the UI may be correct and understandable, but for dimmer items this seems to be rather a bug than a feature…
Perhaps it is a feature enhancement request. Open a GitHub iissue. OH3 development is still very young.