KNX Funny behavour

[ursus (Ursus Schneider)]

Hi

I have openHAB 2.2 up and running and all-in-all it is working quite well. I do have one problem and it’s a funny one! If I stop openHAB and try and dim my light everything dims nicely - I can go from about 10 % to 100% without any problems and by just keeping my finger on the switch. If I start openHAB I can only dim in 10% increments i.e. if I keep my finger on the switch it goes from e.g. 30% up to 40% perfectly (get brighter in 1 % increments) but then stops at 40%. I then need to take my finger off the dimmer and press dim again, it then goes from 40% to 50%. Very weird. Here is an example from the events.log file:

2018-01-21 17:17:48.678 [vent.ItemStateChangedEvent] - Dining_Dimmer changed from 30 to 40
2018-01-21 17:17:48.741 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command 40
2018-01-21 17:17:49.442 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command INCREASE
2018-01-21 17:17:50.138 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command INCREASE
2018-01-21 17:17:50.577 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command 50
2018-01-21 17:17:50.578 [vent.ItemStateChangedEvent] - Dining_Dimmer changed from 40 to 50
2018-01-21 17:17:51.335 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command INCREASE
2018-01-21 17:17:52.021 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command INCREASE
2018-01-21 17:17:52.457 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command 60
2018-01-21 17:17:52.458 [vent.ItemStateChangedEvent] - Dining_Dimmer changed from 50 to 60
2018-01-21 17:17:53.130 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command INCREASE
2018-01-21 17:17:53.860 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command INCREASE
2018-01-21 17:17:54.298 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command 70
2018-01-21 17:17:54.299 [vent.ItemStateChangedEvent] - Dining_Dimmer changed from 60 to 70
2018-01-21 17:17:54.362 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command 70
2018-01-21 17:17:54.770 [ome.event.ItemCommandEvent] - Item ‘Dining_Dimmer’ received command INCREASE

any ideas?

here is the relevant line in the items file:

Dimmer Dining_Dimmer “Dining Dimmer [%.1f]” (Dining, Lighting, myOpenHAB) [“Lighting”] {autoupdate=“true”, knx=“1/1/2+<1/3/2,1/2/2,<1/4/2”}

the services file just has the IPs added!

Too be perfectly clear - the switch works fine, I can turn the light on, off and can dim, only in 10% increments though?

Thank you for any help given
Ursus

[Zaphood1967 (Frank)]

There are three things I could think about, given my own experiences with KNX Dimmers and their sometimes strange behaviour:

1. Are you sure you haven’t configured the Dimmer itself to increase brightness in 10% steps? Dimmers can use absolute and relative dimming, so maybe you may wanna check the GA’s being used by the switch and by OH2

2. Try providing the datapoint Types (DPT), as in my experience this solved some problems for me;
   f.e. { knx = “1.001:1/1/45,3.007:1/2/45,5.001:1/3/45+5.001:1/5/45” }, where the first one is on/off, the second is dimming and the last is the status. The DPT may vary, please refer to your actors documentation (I am using a Theben Dimmer)
   Also, try to avoid the “<” as this caused some irritations on my system as well.

3. Does your dimmer report the current brightness constantly while dimming, only every 10% or just at the final setting? Having my dimmer reporting every 10% made my OH2 sliders go nuts. So again, there are a lot of dependencies in regards to the specific actor and its logic.

Good luck

[Udo_Hartmann]

A knx dimmer can be controlled with different commands, so, the question is, how do you control INCREASE/DECREASE within the knx system?

openHAB can’t send a stop command when dimming, so if using a dimmer with start/stop dimming, you can’t use INCREASE/DECREASE from openHAB side directly. *)

To define a dimmer item in openHAB, you will need at least one GA for absolute dimming (set level) and one GA for dimming state (get level).
Another GA would be for ON/OFF, and you will need this GA if you want to switch ON/OFF the dimmer through MyDimmer.sendCommand(ON|OFF).
However, you don’t need the ON/OFF state from knx at all, as the state of the dimmer is always presented through a number value between 0 and 100.
If INCREASE/DECREASE shall be used in openHAB (by receiving these commands), you can use another GA to get this information, too. But if there are problems and you don’t need the information in openHAB, you simply can omit this part. So, the correct definition would be like this:

Dimmer Dining_Dimmer "Dining Dimmer [%d%%]" (Dining, Lighting, myOpenHAB) ["Lighting"] {knx="1/1/2,5.001:1/5/2+<5.001:1/4/2", autoupdate="false"}

You have to provide information about the DPT when omitting a GA. Be aware of the slightly different label, level is percentage.

If using ON/OFF, this will be sent through GA 1/1/2.
If using the slider to set the level, openHAB will send this level through GA 1/5/2 (you will have to add this to your knx configuration!).
If openHAB is (re-)started, openHAB will request the level through GA 1/4/2 once.
The dimmer shall not update the GA 1/4/2 while dimming but only at the end of dimming. **) I guess this is the reason why the dimming stops every now and then.
If dimming (whether through knx or openHAB), the dimmer will send its level to openHAB through GA 1/4/2 and openHAB will update the item accordingly, so there is no need for autoupdate="true", on the contrary, it will be better not to autoupdate the item but to wait for ‘acknowledge’.

*) But you can use rules to simulate relative dimming. When doing this, the GA for INCREASE/DECREASE must not be set.

**) Background information: The knx1 binding has known issues (only when using with openHAB2!), that is, every message that is received will be transmitted immediately. When using “update level while dimming” this will cause an ‘absolute level’ command sent to knx (another reason why to set up different group addresses for receive and transmit)

[ursus (Ursus Schneider)]

Hi Frank

thank you for taking time to answer my question

1. => Yes, I have rechecked and I am not increasing in 10% steps. If OH2 is not active I can dim without any problems

2. => I have updated and it did not make any difference

3. => It just reports the final setting

Thank you again
Cheers
Ursus

[ursus (Ursus Schneider)]

Hi Udo

Thank you for the info, I am a bit confused about your correct definition:

@Udo_Hartmann

{knx=“1/1/2,5.001:1/5/2+<5.001:1/4/2”, autoupdate=“false”}

Shouldn’t it be:

  {knx="1/2/2, 3.007:1/5/2+<5.001:1/4/2", autoupdate="false"}

i.e. the dimming value is 3.007 and not 5.001?

Thank you again
Ursus

[ursus (Ursus Schneider)]

One more thing that I did not make clear enough: I am having the problem when I use the switch and I have openHAB2 running. I do not have this problem when openHAB2 is not running. i.e. I can dim using the switch perfectly but as soon as I start openHAB2 the switch starts behaving differently!

[ursus (Ursus Schneider)]

Just some more info:

Here is the group monitor when I dim the light without openHAB2 running:

Time Service Flags Prio Source Address Source Name Destination Address Destination Name Rout Type DPT Info

2 23.01.2018 13:43:08,433 from bus Low 1.1.22 Tastsensor Komfort 3fach V2 1/2/2 Esstisch 6 GroupValueWrite 3.007 dimming control $01 | Decrease, 100 %
3 23.01.2018 13:43:08,878 from bus Low 1.1.27 6197/xx-500-101 Univ. Dimming Actuator 6-f, MDRC 1/4/2 Esstisch 6 GroupValueWrite 5.001 percentage (0…100%) $BA | 73 %
4 23.01.2018 13:43:09,257 from bus Low 1.1.27 6197/xx-500-101 Univ. Dimming Actuator 6-f, MDRC 1/4/2 Esstisch 6 GroupValueWrite 5.001 percentage (0…100%) $A1 | 63 %
5 23.01.2018 13:43:09,657 from bus Low 1.1.27 6197/xx-500-101 Univ. Dimming Actuator 6-f, MDRC 1/4/2 Esstisch 6 GroupValueWrite 5.001 percentage (0…100%) $88 | 53 %
6 23.01.2018 13:43:10,057 from bus Low 1.1.27 6197/xx-500-101 Univ. Dimming Actuator 6-f, MDRC 1/4/2 Esstisch 6 GroupValueWrite 5.001 percentage (0…100%) $6E | 43 %
7 23.01.2018 13:43:10,457 from bus Low 1.1.27 6197/xx-500-101 Univ. Dimming Actuator 6-f, MDRC 1/4/2 Esstisch 6 GroupValueWrite 5.001 percentage (0…100%) $55 | 33 %
8 23.01.2018 13:43:10,857 from bus Low 1.1.27 6197/xx-500-101 Univ. Dimming Actuator 6-f, MDRC 1/4/2 Esstisch 6 GroupValueWrite 5.001 percentage (0…100%) $3B | 23 %
9 23.01.2018 13:43:11,257 from bus Low 1.1.27 6197/xx-500-101 Univ. Dimming Actuator 6-f, MDRC 1/4/2 Esstisch 6 GroupValueWrite 5.001 percentage (0…100%) $22 | 13 %
10 23.01.2018 13:43:11,657 from bus Low 1.1.27 6197/xx-500-101 Univ. Dimming Actuator 6-f, MDRC 1/4/2 Esstisch 6 GroupValueWrite 5.001 percentage (0…100%) $08 | 3 %
11 23.01.2018 13:43:11,757 from bus Low 1.1.27 6197/xx-500-101 Univ. Dimming Actuator 6-f, MDRC 1/4/2 Esstisch 6 GroupValueWrite 5.001 percentage (0…100%) $02 | 1 %
12 23.01.2018 13:43:12,599 from bus Low 1.1.22 Tastsensor Komfort 3fach V2 1/2/2 Esstisch 6 GroupValueWrite 3.007 dimming control $00 | Decrease, Break

so 1/1/2 gets decreased line 2, the actor then sends the values via the group address 1/4/2 until it reaches 1% and then I stopped pressing the switch and get a 3.007 from 1/2/2

[Udo_Hartmann]

No, 3.007 is INCREASE/DECREASE or UP/DOWN. You have to setup absolute dimming. You need two GA for this, one for set and one for get the absolute level. These two GA are both bound to the level part of the dimmer item, thus using the +

[ursus (Ursus Schneider)]

Hi Udo

thank you for helping a noobie -> somehow I just cannot get my head around this

Here are my settings from ETS:

I have 4 settings that I can set in ETS. These have been set by me by the Electrition. Could you tell me what the correct openHAB2 line would be? I currently have:

Dimmer Island_Dimmer “Island Dimmer [%.1f]” (Kitchen, Lighting, myOpenHAB) [“Lighting”] {knx=“1.001:1/1/1,3.007:1/2/1,5.001:+1/4/1”, autoupdate=“false”}

if I understand you correctly I need:

{knx=“1/1/1,5.001:1/2/1+<5.001:1/4/1”, autoupdate=“false”}

is this correct?

Thank you for your help, it is greatly appreciated - I have a friend helping me here but we just cannot seem to get it right!

[Zaphood1967 (Frank)]

I’d say it should look like this:

{knx = “1.001:1/1/1+1.011:1/3/1, 3.007:1/2/1, 5.001:??+5.001:1/4/1” }

where

• 1.001:1/1/1+1.011:1/3/1 is Switching on/Off and the respective state
• 3.007:1/2/1 is dimming up/down, no state for this command
• 5.001:??+5.001:1/4/1 is setting absolute brightness and the respective state (unfortunately your screenshot does not show the GA for dimming value, only the status channel for it. So please replace the “??” with the respective GA.

Autoupdate=false I would not recommend, as this prevents OH2 from showing changed states in case you are using the wall-switch and not OH2 for operating the light.

Edit: There is a certain sequence the KNX binding expects the GA’s in when it comes to dimmers. So On/Off, Dimming Up/Down and Dimming absolute should be the order to prevent funny effects. I figured this out with my old dimmer which was a little bit nasty in how the states were reported.

Edit 2: Your electrician did not set the DPT types at all, which is considered not very professional. You should really add these and update the components, as it keeps some strange effects on the KNX bus away.

[ursus (Ursus Schneider)]

Hi Frank,

The screenshot show the only datapoints I have on the ETS i.e. I only have 4 places I can “link” a GA to. I do not have a Dimming absolut value in ETS. I can only see Switching (1/1/1), relative dimming (1/2/1), “value” (1/4/1) and finally feedback switching (1/3/1). My friends ETS actor has more datapoints that he could attach GA’s to. I just have the four - and you only use 3 of them.

See why I am confused now

Cheers

Edit 1: The Electrition has gone out of business else I would have got him to set this up / correct the errors. I got a quote from another but they want 3.000 € to fix it which seems a lot to me!

[Zaphood1967 (Frank)]

Hm, maybe the descriptions within ETS are wrong, in case they have been entered manually by the electrician?
You have 1/4/1 which is a status GA for the absolute brightness. So I’d assume there needs to be a corresponding GA for setting this.
Can you please give me the vendor and model of your dimmer please, so I can have a look at the docu.

[Zaphood1967 (Frank)]

Maybe that dimmer did the same like may old merten, used one GA for setting AND feedback (seemed to be a usual thing a couple of years ago.) Maybe you wanna test the following:

{knx = “1.001:1/1/1+1.011:1/3/1, 3.007:1/2/1, 5.001:1/4/1+5.001:1/4/1” }
As you can see, the last entry uses the same GA for setting the value as well as getting the state. Maybe this helps…

[Udo_Hartmann]

Please no guessing about wrong definitions

If there is no object for absolute dimming, you have to set the actuator to use this object. Which Dimmer is it?

[Zaphood1967 (Frank)]

Not sure what your point is. Given the details we have, we need to guess some things to move forward, as long as we do not know the dimmer maker and model. I have asked for the dimmer type already.
It might well be, that he has a dimmer that responds the dimmer value on the same object as it receives it. Strange, but this was the case with my Merten dimmer.
So just reading from his screenshot, the both of us can‘t tell, if the description field is correct.

[Udo_Hartmann]

Well, in most cases, there is always one state object and one set object for each parameter. But it’s quite possible, that the object is inactive. This can be configured through ETS by setting the correct parameter. Thus the question what kind of dimmer it is (I want to get the product database).

You can’t use the same object to receive and transmit. Let’s say you have two dimmers which shall receive the same GA. But how to get the state of one of them, if this would be sent through the same GA? And this case is very common, as often the power of dimmers is limited, and stacking is an easy way to dim more lamps at the same level.

As a workaround, you can define a second GA (which would be the second GA bound to the object) and use this one to send the level, and the other (the first GA bound to the object) to receive the level. Then it will also be possible to distinguish between more dimmers, by setting different GA as first GA.

[ursus (Ursus Schneider)]

Hi Udo

attached please find all the data I have about the actuator in ETS:

I cannot set any parameters with this actuator in ETS like I can with the others, I need an external program:

Here are all the group addresses in ETS for this actuator:

and finally the switch:

I don’t fully understand why some of the data is in English and some in German (I am a English speaker based in Austria) but I hope you can understand

I hope this helps

Thank you again
Ursus

[Udo_Hartmann]

What are the options under
Feedback objects → Status of dimming-value?
via value object is the actual setup.

I guess this is the correct manual https://search-ext.abb.com/library/Download.aspx?DocumentID=2CKA006197D0201&LanguageCode=en&DocumentPartId=&Action=Launch

It clearly states that there are two options, the second first, as this is the actual configuration:

The output is dimmed to the corresponding value via the following 1-byte communication object when a value telegram is received.
This communication object is only visible if the “Status dimming value” parameter is set to “via value object”. This means that if the dimming actuator is switched on or dimmed, a status telegram is also sent out with the corresponding dimming value via this object.

And now the other option:

The output is dimmed to the corresponding value via this 1-byte communication object for receipt of a value telegram.
This communication object is only visible if the “Status dimming value” parameter is set to “via own object”. This means that the object does not send out status telegrams.

and later:

14.6 Response value
The status of the dimming actuator is sent on the bus via this 1-byte communication object.
This communication object is only visible if the “Status dimming value” parameter is set to “via own object”. This means that if the dimming actuator is switched on or dimmed, a status telegram is also sent out with the corresponding dimming value via this object. This communication object is only visible if the “Switching status” parameter is set to “via own object”. This means that if the dimming actuator is switched on or dimmed, a status telegram is also sent out via this object. An ON telegram when switched on or the value greater than “0” was called up, and an OFF telegram when the output was switched off or was dimmed out.

[ursus (Ursus Schneider)]

Udo, I just checked the setting and it seems as if it is set correctly:

[Udo_Hartmann]

No, the correct setup is “via own object” and then connect the new emerging object (No. 5 for the first dimmer) to a new GA. given the new address is 1/5/2, the correct Item setup will be

Dimmer Dining_Dimmer "Dining Dimmer [%d%%]" (Dining, Lighting, myOpenHAB) ["Lighting"] {knx="1/1/2,5.001:1/4/2+<5.001:1/5/2", autoupdate="false"}

so openHAB will receive the state message on 1/5/2 but will transmit the level through 1/4/2. After that changing, there should be no unwanted dim stop any more.