KNX Dimmers behaving strangely

Setup, Configuration and Use Beginners
1

Hi there,

Just started experimenting with OpenHAB 2.3.0 and KNX.
For the time being, all configurations are done in PaperUI since I reckon this protects me (a bit) against stupid beginner’s mistakes :wink:
For starters, I have created a small setup to play with lights. I have a 4-channel Dimmer “Thing”, which, in KNX, is linked to a number of group addresses:
2/1/9 = Switch light on/off (command);
2/1/8 = Switch light on/off status;
2/1/11 = Dimmer step up/down;
2/1/10 = Dimmer brightness absolute value;
2/1/14 = Dimmer brightness status;

So, I configured the OpenHAB dimmer channel as follows:
Toggle on/off: 2/1/9+<2/1/8
Set absolute position: 2/1/10+<2/1/14
Increase/decrease dimmer: 2/1/11

When switching to control view and moving the slide to, say, 34%, I noticed that the slider moved briefly to 100% and then returns to 34%. The light worked perfectly. Since I had the Dimmer ‘Thing’ configured to poll for status changes every 30 seconds, I noticed the slider moving to 100% and back to 34% every 30 seconds.
The event log showed similar entries:

2018-11-12 21:37:12.890 [vent.ItemStateChangedEvent] - E1_1m changed from 100 to 34
2018-11-12 21:37:42.737 [vent.ItemStateChangedEvent] - E1_1m changed from 34 to 100
2018-11-12 21:37:42.882 [vent.ItemStateChangedEvent] - E1_1m changed from 100 to 34
2018-11-12 21:38:12.756 [vent.ItemStateChangedEvent] - E1_1m changed from 34 to 100
2018-11-12 21:38:12.903 [vent.ItemStateChangedEvent] - E1_1m changed from 100 to 34

Even worse, sometimes after playing with the dimmer configuration, the slider would move the other way around: being stuck at 100% and every 30 seconds moving briefly back to 34%.
Checking the ETS logfiles revealed that there were status inquiries from the IP Gateway every 30 seconds: once for the switch status and once for the brightness. I never saw a 100% brightness value being passed on the bus and there are no other rules associated with these addresses.

This made me thinking: could it be that the dimmer channel treated the switch status as a brightness value? Off = 0%, on = 100%. So first of all, I removed the status “read” address from the switch configuration, leaving only the command address 2/1/9. This did not solve the issue. Even though the switch status requests did not appear on the bus anymore, I still got the 34% - 100% toggle.
Next I removed the switch address altogether, leaving only the absolute and relative brightness addresses. And now the dimmer worked flawlessly! I added a separate switch channel (next to the dimmer) to be able to switch the light on and off and this combination works just fine.
All the DPT’s match de OpenHAB defaults for the switch so I did not explicitly specify any DPT’s.

So, my questions: is this behavior “by design”? Am I doing anything wrong here? I reckon it must be possible to have both the switch and the brightness settings in the same channel, right?

Communication with KNX is through a Gira KNX/IP Router, configured in openHAB as a ROUTER (when set in TUNNEL mode, none of the KNX things came online and communication seemed to be very unreliable, in ROUTER mode all works fine).

Any advice would be appreciated :wink:
Best regards,
Wouter

Configuration:
###############################################################################
############### openHABianPi ################################################
###############################################################################

Ip = 192.168.1.110

Release = Raspbian GNU/Linux 9 (stretch)

Kernel = Linux 4.14.71-v7+

Platform = Raspberry Pi 3 Model B Rev 1.2

Uptime = 1 day(s). 2:25:57

CPU Usage = 2.99% avg over 4 cpu(s) (4 core(s) x 1 socket(s))

CPU Load = 1m: 0.06, 5m: 0.09, 15m: 0.09

Memory = Free: 0.33GB (35%), Used: 0.61GB (65%), Total: 0.95GB

Swap = Free: 0.09GB (100%), Used: 0.00GB (0%), Total: 0.09GB

Root = Free: 11.43GB (82%), Used: 2.48GB (18%), Total: 14.53GB

Updates = 0 apt updates available.

Sessions = 1 sessions

Processes = 101 running processes of 32768 maximum processes

###############################################################################
openHAB 2.3.0-1 (Release Build)

Java:
openjdk version “1.8.0_152”
OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76)
OpenJDK Client VM (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 25.152-b76, mixed mode, Evaluation)

2

I upgraded from OpenHAB 1.8.1 to 2.3 and migrated my setup from KNX1 to KNX2 in the process. I also noticed that my sliders in the Android app jump sometimes to the previous value. I don’t think this happens at regular interval, I just noticed it happens when I change the value. Sometimes the slider stays at the wrong position.

I thought it was a minor Habdroid bug so I didn’t even bother looking at the group monitor. I’ll see if I find time to look at what is going on my KNX bus. Just wanted to say, you’re not alone :wink:

3 
2018-11-13 21:31:35.986 [vent.ItemStateChangedEvent] - OG_Vorraum_Licht changed from 100 to 30
2018-11-13 21:31:36.005 [vent.ItemStateChangedEvent] - OG_Vorraum_Licht changed from 30 to 100
2018-11-13 21:31:42.440 [vent.ItemStateChangedEvent] - OG_Vorraum_Licht changed from 100 to 30
2018-11-13 21:31:42.467 [vent.ItemStateChangedEvent] - OG_Vorraum_Licht changed from 30 to 100
2018-11-13 21:31:49.997 [vent.ItemStateChangedEvent] - OG_Vorraum_Licht changed from 100 to 30
2018-11-13 21:31:50.023 [vent.ItemStateChangedEvent] - OG_Vorraum_Licht changed from 30 to 100
2018-11-13 21:31:50.791 [vent.ItemStateChangedEvent] - OG_Vorraum_Licht changed from 100 to 30
2018-11-13 21:31:50.805 [vent.ItemStateChangedEvent] - OG_Vorraum_Licht changed from 30 to 100

Same problem here.
Peter

4

This is what I see:

==> /var/log/openhab2/events.log <==
2018-11-13 21:38:46.977 [ome.event.ItemCommandEvent] - Item 'Lumiere_Etage_Sejour_Spots' received command 68
2018-11-13 21:38:47.010 [nt.ItemStatePredictedEvent] - Lumiere_Etage_Sejour_Spots predicted to become 68

==> /var/log/openhab2/openhab.log <==

2018-11-13 21:38:47.531 [DEBUG] [.internal.handler.DeviceThingHandler] - Thing 'knx:device:bridge:generic' received a Group Write telegram from '0.0.6' for destination '1/5/210'
2018-11-13 21:38:47.599 [DEBUG] [pdb.internal.MapDBPersistenceService] - store called for Lumiere_Etage_Sejour_Spots

==> /var/log/openhab2/events.log <==
2018-11-13 21:38:47.661 [vent.ItemStateChangedEvent] - Lumiere_Etage_Sejour_Spots changed from 68 to 100

==> /var/log/openhab2/openhab.log <==
2018-11-13 21:38:47.665 [DEBUG] [pdb.internal.MapDBPersistenceService] - Stored 'Lumiere_Etage_Sejour_Spots' with state '100' in mapdb database
2018-11-13 21:38:47.673 [DEBUG] [pdb.internal.MapDBPersistenceService] - store called for Lumiere_Etage_Sejour_Spots
2018-11-13 21:38:47.675 [DEBUG] [pdb.internal.MapDBPersistenceService] - Stored 'Lumiere_Etage_Sejour_Spots' with state '68' in mapdb database

==> /var/log/openhab2/events.log <==
2018-11-13 21:38:47.687 [vent.ItemStateChangedEvent] - Lumiere_Etage_Sejour_Spots changed from 100 to 68

1/5/210 is the GA of status object of that dimmer channel. This is how the thing is defined:

Type dimmer : Lumiere_Etage_Sejour_Spots "Spots" [ switch="1/1/210+<1/4/210", position="1/3/210+<1/5/210", increaseDecrease="1/2/210" ]

I didn’t yet check how it looks like on my KNX bus.

5

Maybe more interesting is this:

2018-11-13 21:51:22.739 [ome.event.ItemCommandEvent] - Item 'Lumiere_Etage_Sejour_Spots' received command 71
2018-11-13 21:51:22.744 [nt.ItemStatePredictedEvent] - Lumiere_Etage_Sejour_Spots predicted to become 71

==> /var/log/openhab2/openhab.log <==
2018-11-13 21:51:22.748 [DEBUG] [calimero.link.192.168.1.10:3671     ] - send (wait for confirmation) 0.0.0->1/3/210 L_Data.req, low priority hop count 6 repeat, tpdu 00 80 b5

==> /var/log/openhab2/events.log <==
2018-11-13 21:51:22.757 [vent.ItemStateChangedEvent] - Lumiere_Etage_Sejour_Spots changed from 0 to 71

==> /var/log/openhab2/openhab.log <==
2018-11-13 21:51:22.773 [DEBUG] [NXnet/IP Tunneling 192.168.1.10:3671] - received request seq 194 (channel 89) cEMI L-Data.con 0.0.41->1/3/210
2018-11-13 21:51:22.776 [DEBUG] [calimero.link.192.168.1.10:3671     ] - confirmation of 1/3/210
2018-11-13 21:51:23.032 [DEBUG] [calimero.link.192.168.1.10:3671     ] - indication 0.0.6->1/4/210 L_Data.ind, low priority hop count 6, tpdu 00 81

==> /var/log/openhab2/events.log <==
2018-11-13 21:51:23.051 [vent.ItemStateChangedEvent] - Lumiere_Etage_Sejour_Spots changed from 71 to 100

==> /var/log/openhab2/openhab.log <==
2018-11-13 21:51:23.070 [DEBUG] [calimero.link.192.168.1.10:3671     ] - indication 0.0.6->1/5/210 L_Data.ind, low priority hop count 6, tpdu 00 80 b5

==> /var/log/openhab2/events.log <==
2018-11-13 21:51:23.089 [vent.ItemStateChangedEvent] - Lumiere_Etage_Sejour_Spots changed from 100 to 71

Seems like the actuator sends a switch status ON (1/4/210) which is interpreted as 100% by OpenHAB and then the dimmer status (1/5/210) arrives and sets the value properly. Pretty sure the KNX1 binding did not behave like that. I don’t know if my actuators will send a dimming status if it receives just a switch command in which case I could probably remove 1/4/210 from the listening GA.

6

It definitely has to do with the switch status response. If I remove the “switch status read” (2/1/8 in my case), things work a bit better. Since the switch status is not polled anymore, the “100%” event now only appears when the light is switched on- or off. Will do some more testing tonight and post results. What I have seen already is that, when you switch on the light, the slider again moves to 100% for a second or so, before returning to the correct position so I’m pretty sure there’s a bug that misinterprets switch events as brightness events.

7

I did some more digging and collected a bit more logging. The result is in the table below. It shows the ETS logging for the Dimmer channel and in yellow the corresponding entries from the OpenHAB event log:

image
image.png2402×1316 880 KB

2/1/9 is the “switch light on/off” address;
2/1/8 is the “switch status” response address;
2/1/14 is the “brightness” response address;

Device addresses in the log:
1.2.30 = Dimmer button (sensor);
1.2.3 = Dimmer actor (Gira quad channel dimmer);
1.0.0 = Gira KNX/IP router;

Since I have two channels (the dimmer and a separate switch), the event log shows the dimmer events (E1_1m) and the switch event (E1_1m_Switch).
At line #151 I switched the lights from off to on using a KNX sensor. Line #152 shows the actor response with the switch status (01 for “on”). Line #153 shows the brightness response from the actor (34,1%).
From the eventlog entries it is clear that the dimmer switches from 0 to 100% (I assume as a result of the switch status change on address 2/1/8) and subsequently switches to 34% (I assume as a result of the received brightness value).
Lines #154 - 157 shows an OpenHAB status poll request where the same behavior can be observed. Unfortunately, OpenHAB FIRST request the brightness (#154-155) and NEXT the switch status (#156-157). As a result of this, the dimmer slide first moves to 34 (which is correct) and subsequently to 100 (which is definitely not correct).

Can somebody who knows about the KNX 2 binding please respond and explain what’s going on here? Thanks in advance.
Regards,
Wouter

8

I found something similar here (but old): https://github.com/openhab/openhab2-addons/issues/2782#issuecomment-366383076

If this does not properly cover the issue (most likely it doesn’t), I suggest that you open up a new one on https://github.com/openhab/openhab2-addons/issues

9

Be sure to set autoupdate=“false” where you want to have the Item track the actual device state.
If you do not, autoupdate will helpfully apply state 100% when commanded ON.

10

Thanks for the pointer, looks indeed to be the same problem. From the comments and various analysis, it looks like the OpenHAB dimmer is “broken by design” since it does not seem to implement a real switch, but instead treats the switch as two brightness values (0% and 100%).
My simple solution: forget about the “switch” property of the dimmer channel and create a second “real switch” channel to switch the light on- or off.

1 Like
11

More limited by design. It represents a dimmer only, and as you point out there is no ON/OFF component to that. There are real devices that work in that way.

However, OH allows you to send ON/OFF to a Dimmer. What the binding does with it is down to binding design, in turn reflecting the technology. I guess for KNX the binding is capable of doing something different with ON/OFF than with 62%. That’ll be down to device-appropriate channel configuration I think.

Also working behind the scenes is autoupdate. Unless you tell it not to, it will attempt to do something sensible with commands. In this case, it helpfully translates ON to 100% and autoupdates the Item .state. You can’t please everyone by default. If you’re getting valid and timely updates from the device/binding, you generally won’t want autoupdate interfering.

I guess I’m saying that it’s not the Dimmer Item that treats ON/OFF as 100/0%, it’s the binding and/or the autoupdate psuedo-binding.

I don’t know KNX but I do think you only need one Item.

12

Well, having two items (dimming + switch) sounds a bit overkill to me. This concept is good for wall switch where short press triggers on/off and long press triggers dimming. But in the UI, the slider makes it very easy to dim to any value (0% and 100% included) by just move the control where it should be.

I think I’ll just remove the listening GA for the switching state on my dimmer things. As far as I remember I configured my KNX dimmers (MDT) to send the dimming value whenever it changes. So an on/off event from a wall switch should update the item in OH properly.

By the way, in my case, I don’t have any recurring changes from e.g. 34 to 100 back and forth as some people seems to see. Only happens once when changing the dimming value. And most of the time things are consistent after the glitch. Still, not super nice. I don’t think I ever noticed that behavior with KNX1.

13

That sounds sensible. The advantage of having a switch is that you can switch the light on- or off without disturbing the saved brightness of the dimmer, which is what I want since OH is not the only tool controlling my dimmers.
Since my KNX dimmers all have a separate switch control, I think I will control them using a dedicated OH channel and ignore the “switch part” of the OH dimmer.

If I don’t want to use autoupdate, how can I disable this?

14

Well, I like my dimmer to not go to their latest value but to 100%. This is how I configured them in my KNX installation. So yes, if you like to restore the previous state, the slider is not a good option.

You can add autoupdate=“false” to your items.

15

Of course, it all depends on personal preference :slight_smile:
In OH, I agree that you don’t necessary need a separate switch, but as I stated earlier, I like to distinguish between the state of the light (on or off) and a predefined brightness value. Switching the light on is in fact defined as “goto stored brightness value”, which is subtly different from changing the brightness with the slider, in which case there is no such thing as a stored value :sunglasses:.

16

Sorry, my posting crossed yours :roll_eyes:
But how to you specify autoupdate in PaperUI? Can’t find any documentation and/or references to it in the UI?

17

In PaperUI there is an autoupdate setting for the item:

Screenshot%20from%202018-11-18%2021-58-54
Screenshot from 2018-11-18 21-58-54.png1600×873 57.1 KB

If you have your items in a *.items file, you can add { autoupdate=“false” }

18

I just removed the “switch status” from my dimmer things. I don’t get the jump anymore which is a good thing. However, it seems that now when I switch off the light with a global switch (with a GA that is not directly linked to the dimmer thing) the state of that dimmer item is not going to “OFF”. I have to check but maybe my dimmers do not send a real zero for the dimming value in this case!? I know they only send a value if the dimming value changed at least with a 2% step.

Also the icon don’t turn on in Habdroid anymore, I have to do an explicit refresh to see the updated icon. But I guess this is another problem…

So no nice solution so far unfortunately :slightly_frowning_face:

What if the KNX binding reacts to an OFF event and set the value to 0 but ignore the ON event since a dimming value will arrive anyhow on a different GA?

19

Weird, I also see some item going to UNDEF instead off an expected 0 value!!???

2018-11-21 19:37:35.893 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 100 to 0
2018-11-21 19:38:13.371 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 0 to UNDEF
2018-11-21 19:38:19.098 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from UNDEF to 8
2018-11-21 19:38:19.610 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 8 to 16
2018-11-21 19:38:19.969 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 16 to 24
2018-11-21 19:38:20.296 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 24 to 31
2018-11-21 19:38:20.699 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 31 to 39
2018-11-21 19:38:21.094 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 39 to 47
2018-11-21 19:38:21.561 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 47 to 54
2018-11-21 19:38:21.967 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 54 to 62
2018-11-21 19:38:22.373 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 62 to 70
2018-11-21 19:38:22.776 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 70 to 77
2018-11-21 19:38:23.100 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 77 to 85
2018-11-21 19:38:23.605 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 85 to 93
2018-11-21 19:38:23.962 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 93 to 100
2018-11-21 19:38:24.129 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from 100 to UNDEF
2018-11-21 19:48:44.109 [ome.event.ItemCommandEvent] - Item 'Lumiere_Etage_Degagement_Spots' received command 0
2018-11-21 19:48:44.138 [nt.ItemStatePredictedEvent] - Lumiere_Etage_Degagement_Spots predicted to become 0
2018-11-21 19:48:44.172 [vent.ItemStateChangedEvent] - Lumiere_Etage_Degagement_Spots changed from UNDEF to 0
20

I don’t know KNX, but the UNDEF log suggests the binding gets something it no longer knows what to do with …