If i use the slider for an KNX-Dali dimmer, the slider jumps at first always on 100%. This is regardless of which value i choose for the dimmer.
In the events.log, i could trace the problem so far, that i can see, that the dimmer item at first becomes the right value (line 1-5 in the events.log), but immediately also the switch switches to “ON” and the slider jumps to 100% (last line of the events.log).
here is the events log:
2021-02-24 00:42:25.382 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Licht_WoZi' received command 53
2021-02-24 00:42:25.397 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Licht_WoZi' predicted to become 53
2021-02-24 00:42:25.426 [INFO ] [openhab.event.ItemStateEvent ] - Item 'Licht_WoZi' updated to 53
2021-02-24 00:42:25.430 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Licht_WoZi' changed from NULL to 53
2021-02-24 00:42:25.571 [INFO ] [openhab.event.ItemStateEvent ] - Item 'Licht_WoZi' updated to 53
2021-02-24 00:42:25.601 [INFO ] [openhab.event.ItemStateEvent ] - Item 'Licht_WoZi' updated to ON
2021-02-24 00:42:25.609 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Licht_WoZi' changed from 53 to 100
It seems to be a OH problem, because the state ot the dimmer position is right, but the slider shows 100%. Also the value in the KNX is right (53%).
If I use the slider again, the it shows the right value. But I have no idea, why the switch switches to “ON”, or how to solve the problem.
I guess, i have the problem since i installed OH3 (from OH2.5 before), but i’m not sure.
but I think in this case the ON that gives the effect of 100% is coming from here [ switch ="1/3/80+<1/3/83",
i.e.dimmer reports ON and binding converts to 100%.
Try it with [ switch ="1/3/80",
so that you rely on dimmer numeric position reports only.
I confirm I had the same (or similar) problem (and I am still on OH 2.x as I do not dare updating) and the solution suggested by rossko57 worked fine; the only thing I lost is a real time update of the slider when I move it (I need to wait a fraction of a second till I see the effective percentage).
I know this is an old post and i dont know if this is the right place to put it but i just need to say: Thanks that just made my day…
I Observed this strange behavior now for quite some time (years) and this solved it and i understand now why… this happens. - And thats very important for me.
I always find it “unsetteling” if my system does something strange and i don’t understand why… My log was full of stuff like this.
2022-10-16 22:56:03.037 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'DG_Zimmer1_Ledstripe_Brightness' changed from 34 to 100
2022-10-16 22:56:03.202 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'DG_Zimmer1_Ledstripe_Brightness' changed from 100 to 34
It always made me think “Openhab is always doing some weird unpredictable things” It was not promoting my trust in OH (- Does that sentence make sense in english?)
Since:
i do not seem to be the only one to have that problem.
It is “normal” for KNX Dimmers if configured properly to send % and On/OFF (imho).
And the Binding accepts both for a “Dimmer Thing” (Position in % and On/Off)
But acts strange if both are configured on a “non-control” Dimmer Thing
Should we note this in the docs somehow?
I mean in the docs example it is done properly (no query on the On/Off Adress) but it is a very easy “mistake” to make if you want your whole KNX bus in OH… Maybe just put a warning there…
depends alot on the dimmers … on the new ones you can change in ets how often to send the value or after a certain threshold and also use the autoupdate false
The issue is if configurring the Thing to listen to Position (Value in %) and On/OFF things get weired… so you should not do it even if you can. (Exceptions are control-things - Wich are propably very rare if you are not using openhab as a bridge to an non knx dimmer)
because the dimmer on the bus will update the status and say:
the light is on on the Groupaddress of On/OFF status
The light is at 30% on the Groupadress of the %Value
Yet the binding thinks: (depending on what comes first/last…) Oh it is switched on… → lets put it to 100%. overriding the % Value…
In KNX those Adresses are indipendent. And in my case this is wanted. for example i like the small led on the switch to change color if a light is on or off, no matter if it is 1% or 100% since it is on… so i use the On/Off Groupadress for that…)
In the Binding they are not Independent (because its one thing wich makes also sense). If it is switched on → Value jumps to 100%.
→ Solution do not configure the switch parameter of the Dimmer-Thing to check the Groupadress for On /OFF
Thats ok. But i thought it would be worth to note that in the docs since there are at least 3 Topics about this behavior here where people like me get confused about oh…
For me Homeautomation is a hobby not a profession. I do not always grasp the full inner workings of to different systems at first glance and I am always happy to find some hints in the docs…
It’s not KNX specific.
The openHAB Dimmer type Item is an idealized model. It has no on/off property by design, just a 0-100% state. That means representing any real-world “On” condition report will always be compromised.
Binding channels are intended to interface to OH Items, so their structure and assumptions tend to follow the internal model.
If users find this untenable, they can simulate a more complex “Item” by using both a Dimmer and Switch type Item, maybe associated in a Group, and have rules manage he relationship between the components and between the real-world inputs and outputs.
Same as there is no openHAB “Thermostat” Item but we can simulate with a collection of simple temperature and on/off Items.
Hmm. Thing is, openHAB knows how things work, doesn’t it?
So everything >0 is indeed “ON” as far as the real world concerns…?
I don’t know the specifics, but perhaps letting the KNX binding not scale immediately to 100 should do the trick? If an KNX item is updated via the “switch”-GA => it should not bring the item up to 100, if it is already >0.
Same is the KNX-logic. the feedback-GA “I’m ON” triggers the light, regardless, if it’s 1, 40 or 100. and it does not change the GA for brightness.
So, if I have a dimmer item without the feedback-GA for ON, it “works”, but I don’t have the chance anymore for the “item is ON”-logic. I have to use “item > 0” for it, which could break existing logics[1] and is not understandable for beginners as they don’t have the simple UI-rule clicking in openHAB and Blockly for this.
In my point of view, that would be a change to the behaviour of the KNX binding?
.
.
[1] it does in my case, because I had a bunch of rules which depend on “is the light in room XY on”?, so I’ve gotta change a lot of them - only because I switched my lights to 40% standard, which is enough, but saves a ton of energy over the year for us. => but if I don’t, I get messy persistence and charts and …
Yes. So the point here is … a message comes from the real world saying “I’m ON!”. An openHAB Dimmer type has no ON state, only a numeric. That’s fine, all we have to do is to set some arbitrary non-zero value to indicate ON.
Would you like to guess what arbitrary value is used? It’s 100 in fact. If they’d chosen 1 or 50 it would be same problem.
It’s not a KNX problem
The user has configured a switch-type channel (that happens to be KNX) and linked it to update a Dimmer type Item.
When an ON message comes it sets the arbitrary 100 state, there’s no choice, it’s inherent in the openHAB architecture.
You’ll get exactly the same effect in any other technology.
The trick is NOT to configure your channel to use ON messages to update a Dimmer - when you also have a reliable “real numeric” coming as well.
No idea what you mean. The behaviour of Dimmer type Items has not changed sionce invention in openHAB1, it has never had an ON state.
What kind of binding it is linked to can never change that.
It’s always been possible to treat any Dimmer test in rules using something like
if (DimmerItem.getStateAs(OnOffType) == ON) { ....
There is no Problem with the dimmer type, nor with the KNX binding. Both work as intended. The only problem is that you need to understand both and how they work together to configure your KNX ↔ openHAB communication correctly. And for a Person like me this is not an easy thing.
My Point was only to help “new” users and ask if this special beavior should be noted in the KNX binding docs? Since for me it was not obvious (even after reading the docs carefuly and this behavior frustraded me) for years until it was explained to me.
For explanation:
In the “Dimmer Channel in the KNX Binding” can be configured to send and recieve:
% Value on the Bus
Increase /Decrease
ON/OFF. on the Bus
Type dimmer : Light [ switch ="1/3/80+<1/3/83", position="1/3/82+<1/3/84", increaseDecrease="1/3/81" ]
This represents 5 independant “Variables/Telegramms” on the KNX-Bus
I always try to configure everything that is possible (and this is the problem here).
The Dimmer Channel then is Linked to a Dimmer Item. that only knows % as i understand. So 1 Variable.
Most Dimmers on the KNX Bus(as i configure them) will update the ON/OFF State-“Variable” if they receive a comand that switches a light on or even in given time intervalls.
Now this happens if you configure everything: →
change in % from 0 to 30%. in the Set “Variable” for %
the Physical-Dimmer will dimm the Light to 30%
the Physical-Dimmer will send ON on the ON/OFF “Variable” as well as 30% on the feedback “Variable”
the Dimmer-Thing will receive the ON → Sets the Dimmer Value to 100%
the Dimmer-Thing will receive 30% on the State “Variable” → Sets the Dimmer Value to 30%
4 and 5 happened sometimes also in different orders… so sometimes OH told me my light was at 100% but it was at 30.
Maybe one sentence like " Do not Configure the switch Groupadress because you dont need it if your dimmer is not a Control-Thing(meaning you have not actuall dimmer on the bus but the Light connected to OH)"
and I am always happy to find some hints in the docs…