KNX Dimmer problem with Openhab 2.3

Hi,
i just switched to openhab 2.3 and I’m facing a problem with Dimmers.

I have a KNX compliant Vimar ByMe system that I can interface with through a USB dongle by Busware.

The dimmer supports the Switch on/off, Percentage set and Increase/Decrease, and everything works almost perfectly well with an exception.

The Dimmer will publish the percentage it is at when increasing and decreasing but not when switching ON and OFF. (I sniffed the bus to find out the correct GAs)
So when I switch ON the Dimmer, change it to 40% and then switch OFF and then ON again, the dimmer will be at 40% but the BasicUI (or any other UI) shows 100%, as when I switch ON Openhab assumes the percentage is 100%.

Is there a way to issue a read where the percentage is published (the listening GA I guess) when the Dimmer is switched ON?
I tried reading aroung bu could not find how to read a state, just how to send commands around.

Can anyone help?
Thank you!
Marco

First thing I’d do is set autoupdate=“false” on your Dimmer Item, so that you can be sure you’re getting a status from the binding, instead of autoupdate’s hoped-for state.

v2 binding author’s can implement a REFRESH command, I don’t know if KNX supports this.

If the GA is readable (R-Flag is set for communication object “absolute brightness” in the dimmer), you can use the readInterval to force openHAB to read the GA, but be aware that this might increase data traffic at knx bus.
Another option is to define a rule which is triggered by ON and OFF. Then postUpdate the correct value.
I guess that 40% is fixed for ON command?
If not, you have to get the last state != 0 through persistence for to postUpdate the last known brightness, this would be “when switching the dimmer ON, use the last Brightness level before switching OFF”.

Thank you both for your reply!
@Udo_Hartmann so there is no way in Openhab to explicitly read the real state (percentage) of the dimmer with a command?

No, there isn’t. Either configure the dimmer to send its state periodically or configure openHAB to read the state periodically.

But there is a workaround, if you are using knxd/eibd. Write a script to read the value and use the exec binding to trigger this script.
To be honest, if the dimmer is knx compliant, it should report its state when it’s changed :wink: or at least it should be configurable.

I found an easy way to do it… Through a Rule, i can issue a Refresh every time the dimmer gets switched on.

import org.eclipse.smarthome.core.types.RefreshType

rule luce_studio_on

	when
	   Item luce_studio received command ON
	then
	   logInfo("luce_studio", "luce_studio switch was turned " + receivedCommand.toString)
	   Thread::sleep(3000)
	   luce_studio.sendCommand(RefreshType.REFRESH)  
	   
end

It works but there is an issue, the percentage of the Dimmer in the User Interface gets updated to 100% when the Dimmer is switched on. The Refresh polls first the Percentage GA and then the Switch on GA, so when it receives the answers, it updates correctly the percentage at the real ones, but then receives the read-update from the refresh from the Switch on address and updates the percentage to 100%.

Is there a Way to stop the percentage being updated to 100% when a dimmer gets switched on?

Thank you!
Marco

1 Like

the Autoupdate=false does not really work, the behaviour remains the same…

this is my item configuration now:

Dimmer luce_studio "Luce Studio [%s %%]" { channel="knx:device:RasPI:generic:luce_studio", autoupdate="false" }

but still, if I set the Dimmer at 65%, switch it off and then on again, the User interface goes shortly at 65% before going at 100%, since it receives the ON status for the Switch…

does the autoupdate=false work in openhab2.3?

Marco

Yes.
It doesn’t influence binding updates of course.
Can you show us the events log for the sequence?
Those who know KNX will probably want to see your Things too.

of course: here are my Things:

Bridge	knx:ip:RasPI "RaspBerry PI Serial Bridge" @ "KNX" [
	type="ROUTER",
	readingPause=50,
	responseTimeout=10,
	readRetriesLimit=3,
	autoReconnectPeriod=1
	] {
    Thing device generic [
        
    ]{
        
        Type dimmer        : luce_studio        				"Luce Studio [%s %%]"        		[ switch="1.001:1/6/49+<1/6/52", position="5.001:1/6/51+<1/6/53", increaseDecrease="3.007:1/6/50" ]
		
    }
}

and this is the events log:

13:21:49.990 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'luce_studio' received command ON
13:21:50.017 [INFO ] [se.smarthome.model.script.luce_studio] - luce_studio switch was turned ON
13:21:52.682 [INFO ] [smarthome.event.ItemStateChangedEvent] - luce_studio changed from 0 to 100
13:21:53.046 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'luce_studio' received command REFRESH
13:21:53.160 [INFO ] [smarthome.event.ItemStateChangedEvent] - luce_studio changed from 100 to 80
13:21:53.344 [INFO ] [smarthome.event.ItemStateChangedEvent] - luce_studio changed from 80 to 100

you can see that when switching on the Dimmer goes by default to 100%, then receives the refresh (checking the BUS I noticed that openhab asks forst the percentage and then the status of the switch) it gets set to 80% when receiving the percentage but reverts to 100 when openhab reads the status ON on the switch…

thanx
Marco

End of my knowledge. I guess you need the binding to ‘ignore’ device on/off state, is that something to do with “<” ? Over to @Udo_Hartmann

Yes, the best way is not to set a readable GA to ON/OFF at all :slight_smile:

1 Like

Hello!

I know it´s been a while but where to get that information?
I mean the group address. I´m using KNX IP Interface for my vimar by-me system with ETS5 and found out that the target group address is 1/6/33 - but what´s the prefix? (in your post 1/6/49?)

Thank you and best regards,
Mario

What do you mean by prefix? In knx there is no such thing as a prefix.
In knx there is

  • an individual address (i.e. the device address),
  • the group address (i.e. the “communication channel” to connect several communication objects of different devices),
  • the data point (i.e. how to interpret the data sent from or to a communication object) and
  • flags (i.e. to control if and how a communication object reacts on incomming data)