KNX dimmer slider is wrong when switching dimmer "on"

Hello, i am desperate with a KNX dimmer actuator. My device is an older Busch-Jaeger UP 6932 U-101 with a 6116 2f-Taster. It is an KNX Powernet device, if it is necessary. It offers the following communication objects:

  • switching: GA 1/3/9, Flags K-SÜ–, Type: 1.001
  • relative dimming: GA 1/3/10, Flags K-S—, Type 3.007
  • dimmer brightness: 1/3/11, Flags KLSÜ–, Type 5.001
  • dimmer feedback: 7/3/1, Flags KLSÜ–, Type 1.011
  • dimmer preset: 0/1/0, Flags K-SÜ–, Type 1.011

The dimmer device has two “onboard” touch button for using:

  • touch button 2 short -> switching: 1/3/9
  • touch button 2 long -> dimming: 1/3/10

Dimming time has a time base of 0.5ms, a faktor of 20 (value between 2…255) and will be calculated over timebase * faktor * 255.

Part of KNX.things:

Thing device bj_up_1_1_5_eg "Busch-Jaeger UP 6932 U-101 (1.1.5)" @ "Wohnzimmer" [ // Busch-Jaeger KNX Powernet UP-Dimmaktor 6932 U-101 & 6116 2f-Taster
        address="1.1.5",
        fetch=true,
        pingInterval=300,
        readInterval=3600
    ] {
        Type dimmer : k1   "Wandlampe Wohnzimmer"   [ switch="1.001:1/3/9", position="5.001:1/3/11+<1/3/11", increaseDecrease="3.007:1/3/10" ]
    }

Part of knx.items:

Switch      s_eg_wohnzimmer_wandlampe           "Wandlampe Wohnzimmer"                  <light>             (gWohnzimmer, gLicht, gSchalter)        { channel="knx:device:bridge:bj_up_1_1_5_eg:k1"}
Dimmer      d_eg_wohnzimmer_wandlampe           "Wandlampe Wohnzimmer [%d %%]"          <light>             (gWohnzimmer, gLicht, gDimmer)          { channel="knx:device:bridge:bj_up_1_1_5_eg:k1", autoupdate="false" }

Part of standard.sitemap:

Default item=s_eg_wohnzimmer_wandlampe label="Wandlampen"
Default item=d_eg_wohnzimmer_wandlampe label="Wandlampen"

Many of small things i read in this thread was as a test inside the configuration.

I have the behavior, that after a restart of the openHAB server, the slider in Basic UI and in the iOS App show the right value, when the dimmer is on and e.g. set to 50% brightness. So the read command works. Also switching on and of works, but: when i switch the dimmer with a short touch on the local button on, i can see on the bus monitor (ETS) the following:

1/3/9 GroupValueWrite 1.001 On
1/3/11 GroupValueWrite 5.001 50% (<- example)
1/3/9 GroupValueWrite 1.001 On
7/3/1 GroupValueWrite 1.011 Active

In Basic UI I mostly see the following behavior:

  • Switch goes from off to on
  • Dimmer jumps from 0 to 100, from 100 to 50 and from 50 to 100 and then stays there.

But the real brightness is 50%. So the slider shows not the right value. When i restart openHAB again, it reads from the bus and show on the slider the correct 50%. I have also a physical KNX display, which knows the correct value. So finally: :sob:

Shouldn’t there be a different channel for the dimmer? You are using a “switch” channel (so it seems) for a dimmer. So that is ON or OFF, so the behavior makes sense.

{ channel="knx:device:bridge:bj_up_1_1_5_eg:k1"}
{ channel="knx:device:bridge:bj_up_1_1_5_eg:k1", autoupdate="false" }

Yes, I read this in other threads that you can use one channel in case of a dimmer for dimming and switching. I had to search for the thread, but also the group addresses shows a switching address for the dimmer.

I can now refine the behavior of the dimmer. Yesterday I decided to integrate my openHAB over myopenHAB into Alexa over the official skill. It works really perfect, but the Basic UI did not show in every situation the right slider. The following things can I describe (the light is off):

  • I say, that Alexa should set the value of the (dimmer) light to 50%. The dimmer switches on the set the level to 50%. In the Basic UI, the switch button jumps to on and the slider from 0 to 100.
    [I own also a physical visualization hardware from Busch Jaeger, which shows then also the 50%]

  • The light is again off. I say, that Alexa should switch the light on. The dimmer jumps to 50% on and the slider in the Basic UI also from 0 to 50%.
    [The Busch Jaeger panel shows also the 50%]

  • The light is again off. I switch the light with the Busch Jaeger Panel on. The dimmer jumps to 50% on and the slider in the Basic UI also from 0 to 50%.

  • The light is again off. I switch the light with the physical button from the dimmer to on. The dimmer jumps to 50% on and the slider in the Basic UI again from 0 to 100%.

When I now finally use Alexa to switch the light off and on, the slider jumps from 0 to 100 and after some seconds it goes back to the 50%.

Please be aware that you don’t need to (and shouldn’t) set a group address twice, so change the channel to

Thing device bj_up_1_1_5_eg "Busch-Jaeger UP 6932 U-101 (1.1.5)" @ "Wohnzimmer" [ // Busch-Jaeger KNX Powernet UP-Dimmaktor 6932 U-101 & 6116 2f-Taster
        address="1.1.5",
        fetch=true,
        pingInterval=300,
        readInterval=3600
    ] {
        Type dimmer : k1   "Wandlampe Wohnzimmer"   [ switch="1.001:1/3/9", position="5.001:<1/3/11", increaseDecrease="3.007:1/3/10" ]
    }

Ok, I changed this in the things file. But it was not the reason. I made another test. The dimmer was on with 40% and it switched it off. At this time, in Basic UI it shows the 40%. So I wonder about, because I can swear that there was 100 when I leave the Basic UI. Then I switched it again at the local switch on. The slider jumps to 40% and then to 100%. Here is the log from the Karaf console:

20:33:17.052 [DEBUG] [g.knx.handler.AbstractKNXThingHandler] - Polling individual address '1.1.5'
20:33:17.358 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.5' to '7/3/1' with value '[0]'
20:33:19.095 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.5' to '7/3/1' with value '[1]'
20:33:20.740 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.5' to '1/3/11'
with value '[102]'
20:33:20.745 [DEBUG] [x.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:bridge:bj_up_1_1_5_eg' received a GroupValueWrite telegram from '1.1.5' for destination '1/3/11'
20:33:20.748 [TRACE] [x.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:bridge:bj_up_1_1_5_eg' processes a GroupValueWrite telegram for destination '1/3/11' for channel 'knx:device:bridge:bj_up_1_1_5_eg:k1'
20:33:20.752 [TRACE] [ng.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 5.001
20:33:22.369 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.5' to '1/3/9' with value '[1]'
20:33:22.378 [DEBUG] [x.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:bridge:bj_up_1_1_5_eg' received a GroupValueWrite telegram from '1.1.5' for destination '1/3/9'
20:33:22.382 [TRACE] [x.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:bridge:bj_up_1_1_5_eg' processes a GroupValueWrite telegram for destination '1/3/9' for channel 'knx:device:bridge:bj_up_1_1_5_eg:k1'
20:33:22.385 [TRACE] [ng.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
20:33:23.282 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.5' to '1/3/9' with value '[1]'
20:33:23.291 [DEBUG] [x.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:bridge:bj_up_1_1_5_eg' received a GroupValueWrite telegram from '1.1.5' for destination '1/3/9'
20:33:23.295 [TRACE] [x.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:bridge:bj_up_1_1_5_eg' processes a GroupValueWrite telegram for destination '1/3/9' for channel 'knx:device:bridge:bj_up_1_1_5_eg:k1'
20:33:23.298 [TRACE] [ng.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001

Perhaps somebody see something, I did not. :slight_smile:

What BasicUI does has nothing directly to do with KNX. You’ll want the events.log that shows how the KNX is affecting your openHAB Items at the same time.

Ok, here it is and there is the 40 to 100 jump:

2019-12-13 20:33:11.939 [vent.ItemStateChangedEvent] - s_eg_wohnzimmer_wandlampe changed from ON to OFF
2019-12-13 20:33:11.942 [vent.ItemStateChangedEvent] - d_eg_wohnzimmer_wandlampe changed from 40 to 0
2019-12-13 20:33:20.771 [vent.ItemStateChangedEvent] - s_eg_wohnzimmer_wandlampe changed from OFF to ON
2019-12-13 20:33:20.772 [vent.ItemStateChangedEvent] - d_eg_wohnzimmer_wandlampe changed from 0 to 40
2019-12-13 20:33:22.395 [vent.ItemStateChangedEvent] - d_eg_wohnzimmer_wandlampe changed from 40 to 100

Okay, at 20:33:22 your dimmer reports ON but no % value, so openHAB just does a default “ON” at 100%

Is there anything I can do to clarify why this happens? I saw the double telegram now from 1.1.5 with 1/3/9 and value 1. But I did not understand why this happened? I attached a screenshot from my device settings from ETS.

The original documentation in German can be found here.

When I wait long enough, the slider go back to the right position. I think it is the waiting time when openHAB fetches again the status of the KNX devices and get then the right value.

And one additional information about the feedback object of the actuator. It can’t be changed to an other value then on or off with 1 Bit.

Isn’t the “Dimmer - Ruckmeldung” the one you should use for the actual status?
and the “Dimmer - rel. dimmer” for setting a new value?
and the “Ausgang - Schalten” for ON/OFF switching?

Isn’t the “Dimmer - Ruckmeldung” the one you should use for the actual status?

Yes, I think you are right if the status would be an 1 byte value for the brightness. This device could only give the feedback on or off over the 1 bit value. So I decided to made the brightness read able to get the status at startup. The Busch-Jaeger Panel uses the 1 bit response value for whatever.
If you compare the thinks settings from the first posting, I think it should be correct.

So this panel presumably remembers old settings and guesses that they are still valid.

Is it working now?
Would like to see the final config in that case…curiousity

No, it works not like expected. I can use it, but when I only switch the dimmer from off to on, the slider position is actually mostly wrong.