[SOLVED] KNX problems after OH2.4 upgrade

Add-ons Bindings
1

Hi,
I’ve recently updated my OH2.3 to OH2.4 stable build.
Update was done by installation of a new OH2.4 instance and then copying the conf folder from 2.3 to 2.4 installation. NO changes done in config files. OH is running on Windows, using a Gira 216700 KNX-IP router. System configuration was working flawlessly on OH2.3

Problem statement 1
I experience some problems with KNX binding after OH2.4 update:
When switching on a light in BasicUI, the switch widget immediatly jumps back to OFF position.
there are 2 log entries:

  • Item XXX received command ON
  • XXX predicted to become OFF

Switched device (in my case a light) is switched on, but can not be switched off in Basic UI because widget is back in OFF-position.
This behavior applies to all Switch devices.
When shutting down OH2.4 instance and starting OH2.3 instance with exactly same config there are no problems at all.

Things config
All switch devices are defined this way:
Type switch : Light_OG2_Arbeitszimmer “Arbeitszimmer” [ ga=“1/0/26” ]

Problem statement 2
Rollershutter devices work, but have a significanly longer delay than with OH2.3 (up to 4 seconds until rollershutter device shows a reaction.
Delay of reaction of rollershutter devices was much shorter in OH2.3 (< 1sec).

I assume there are some KNX installations which were recently upgraded to OH2.4 and may have experienced similar behaviours.

Any suggestions how to fix these problems?

Regards,

Peter

2

Hi Peter,

I’ve also upgraded to OH 2.4 and I’m experimenting the same problem.

The items doesn’t update the status when is modified from OH (on basic UI, paper UI or classic ui) but it changes when receives an update directly from KNX.

I’m also using only one knx address to send & receive messages to items (same format as Peter).

And finally comment that I’ve also seen the ItemStatePredictedEvent, but only when I switch the items from OH and not when doing it from KNX.

Manuel

3

It seems that is some kind of feature: What is ItemStatePredictedEvent?

They say that “autoupdate” is now cleverer than before…

I’ve done some tests and if I force autoupdate=“true” on my switches then the items changes when updated from OH, like in OH 2.3.

Anyway, it would be nice to know a bit more of this subject.

Hope it helps,

Manuel

4

Thanks for looking into this.

Tried autoupdate=“true” -> no result
I tried the autoupdate=“true” option in the Things-definition but it still has the same behaviour.
Hope I did it right, because I found no documentation regarding “autoupdate” in the KNX 2.x binding docs.

Type switch : Light_OG2_Arbeitszimmer “Arbeitszimmer” [ ga=“1/0/26” , autoupdate=“true”]

Further Research

  1. When I switch on the item, the switch widget goes to ON-position and immediately goes back to OFF-Position,
  2. KNX device is switched ON.
  3. Icon still shows a grey bulb
  4. The internal state of all switches seems to be OFF. I checked this in the OH console AFTER switching on a light and see the item status is set to off

Light_OG2_Arbeitszimmer (Type=SwitchItem, State=OFF, Label=Arbeitszimmer, Category=light, Tags=[Lighting], Groups=[gOG2_Arbeitszimmer, gLights, gLightsOn])

log entries when switching ON:
Item ‘Light_OG2_Arbeitszimmer’ received command ON
Light_OG2_Arbeitszimmer predicted to become OFF

My conclusion
So if I Interpret this right, OH does not only predict the switch to become off, it actually sets the state to OFF internally.

There must have been some changes in KNX binding from 2.3 to 2.4 that cause this behavior.

Is somebody in the position to suggest a workaround or check the KNX binding code associated with this “prediction” message?

5

I’m using autoupdate on the item definition:

Switch Light_GF_Despacho “Despacho [%s]” (GF_Despacho, Lights) { channel=“knx:device:bridge:generic:luzDespachoTecho”, autoupdate=“true” }

It works for me.

Regards,

Manuel

6

Thanks for the details.
This works for me too.

7

Always interesting to see, that there are different ways to success, depending on the systems mood :slight_smile:
In my case, I had noticed this behavior already with the 2.4 nightly builds, but in my case an [autoupdate=“false”] did the job :slight_smile: and still does it with the 2.4 stable release.

8

Hi all,
I was experiencing the same issue described above (please note I am a new user, jumping straight to 2.4, so no experience of past releases).
I tried both versions of autoupdate=true and false, the result is the same, it “works” BUT…
it takes up to 5 seconds or more to execute a command when launched from OH (meaning when switching ON or OFF from the GUI).
In the other direction (toggle on or off in KNX) it’s instead visualised immediately on the GUI.
Any idea why this delay?

I still see a lot of warning in the logs:

15:13:32.323 [WARN ] [KNXnet/IP Tunneling 192.168.7.50:3671] - response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 1.1.2->1.1.3 L_Data.req, system priority hop count 6 repeat, tpdu 81
at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:244) ~[?:?]
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258) ~[?:?]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:178) ~[?:?]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:243) ~[?:?]