OH2 KNX 1.9 Binding - read from KNX results in a write

@vitalyb, only if you have more than one KNX address linked:

Switch Light_O_FB1 “Light fence back 1” {knx="<1/3/2"} <- here autoupdate=“true” is optional.

I have a lot of items in my setup, is it safe to say that I can add autoupdate=“true” to every knx binding in 2.0 to get same behavior like in 1.8? Testing every item will take a lot of time. Maybe there is a key in binding configuration to reach compatibility without modifying items files?

Please test it, using a few items and see if it works.

hey there @lewie,

I was playing around with this problem for a while now but wasn’t able to get a working combination.

Currently, I’m using your 20161125 jar with the debian packaged 2.0 openhab version.
Reading values from the Bus seems to work fine, but writing to it will result in two writes.

This might not be a priority and maybe I shouldn’t worry about it, but somehow I just can’t ignore it :slight_smile:

Anyway, my items do contain the autoupdate=“true” part. If I remove it or switch to false, no write is passed to the Bus anymore, eg I can’t control the items via WebIF (BasicUI) anymore.

Example of my items:

Dimmer Licht_Buero_Spots "Spots [%s]" (Lights) {autoupdate="true", knx="3/1/030+<3/1/033, 3/1/031, 3/1/032+<3/1/034" }

my config:

ip=10.6.91.8
busaddr=1.1.6
#type=ROUTER
type=TUNNEL
localIp=10.6.91.102
timeout=1000
readRetries=10
numberOfThreads=50

/* ignored anyway? */
CompatibilityOH2=true
ignorelocalevents=true

Result when sending a write via BasicUI:

Any ideas or comments? Do you need specific test cases or logs?
BTW, thanks in advance for any feedback.

Late… :frowning:

Hey Markus,
your config is ok, but I do not know if the comment ignored anyway should have a # at the beginning!

Does your IP-Router config NOT have anything enabled like reflect or repeat.

Please can you show me the openHAB log-file equivalent to your ETS Screenshot?

Let’s Test it.

EDIT:
Did you test the original Jar file?
What KNX jar console shows as Active? Therefore on openHAB console enter: list

Helmut

I have also the echos from openHAB posted to the knx system. Is there any solution? I read at different places, did not discover a solution.

running  2.2.0-SNAPSHOT Build #994   
204 | Active   |  80 | 1.11.0.201710230109    | openHAB KNX Binding

the ETS5 log:

the openhab log:

Summary
    21:14:24.502 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: indication from 1.1.26
    21:14:24.503 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Beweg_Ku_P1' received command ON
    21:14:24.505 [INFO ] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send message to 7/3/0, wait for confirmation
    21:14:24.505 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 15.15.255 to 7/3/0, low priority hop count 6 tpdu 00 81
    21:14:24.505 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 15.15.255 to 7/3/0, low priority hop count 6 tpdu 00 81
    21:14:24.505 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 11 29 00 bc e0 ff ff 3b 00 01 00 81
    21:14:24.505 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 15.15.255 to 7/3/0, low priority hop count 6 tpdu 00 81
    21:14:24.507 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send to 7/3/0 succeeded
    21:14:24.507 [DEBUG] [tuwien.auto.calimero                ] - process 224.0.23.12:3671: group write to 7/3/0 succeeded
    21:14:25.840 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: indication from 1.1.9
    21:14:25.842 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'E_K1_Soll_Temp' received command 18.0
    21:14:25.845 [INFO ] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send message to 2/3/42, wait for confirmation
    21:14:25.845 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 15.15.255 to 2/3/42, low priority hop count 6 tpdu 00 80 07 08
    21:14:25.845 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 15.15.255 to 2/3/42, low priority hop count 6 tpdu 00 80 07 08
    21:14:25.845 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 13 29 00 bc e0 ff ff 13 2a 03 00 80 07 08
    21:14:25.845 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 15.15.255 to 2/3/42, low priority hop count 6 tpdu 00 80 07 08
    21:14:25.845 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send to 2/3/42 succeeded
    21:14:25.845 [DEBUG] [tuwien.auto.calimero                ] - process 224.0.23.12:3671: group write to 2/3/42 succeeded

my corresponding items:

Switch Beweg_Ku_P1 "Bewegung Küche" (gBeweg, gEssen) { knx="7/3/0", expire="1m, command=OFF" }
Number E_K1_Soll_Temp "Solltemperatur K1 [%.1f °C]" (gKind, gHeiz) { autoupdate="true", knx="2/3/42+2/3/47" }

my knx.cfg file

ip=224.0.23.12
busaddr=15.15.255
ignorelocalevents=true
type=ROUTER
port=3671
localIp=192.168.1.123

The autoupdate=“true” option does not make a difference.
The echo does not cause any problems yet, but it shouldn’t be there anyway. Or?

I’m experiencing the same problem since beginning of this year, first on OH2.0 and now on 2.1.

Problem details see https://github.com/openhab/openhab1-addons/pull/4765#issuecomment-275856806

I have the same issue, not a problem yet but it is ugly if the knx bus is “spamed”

Same here. I have a Weinzierl EnOcean gateway, and some EnOcean dimmer show “strange” reactions when getting doubled messages from the KNX bus.
Does anyone work on this ? Does anyone have an idea how to avoid this message bouncing from the OpenHAB ?

Is there any update on this issue? Still having it with the 1.11 version of the knx binding and that on all types of items. This is actually rendering my openhab useless as everything is very slow. Strange that everything seemed to work untill a couple of weeks ago.

I’ve now setup my OH2 isntallation completely new, re-edited the KNX config file with just the need parameters. I’ve then tested it without any item definition: no double messages on the KNX bus. I’ve then added one item, and the the double messages are back.
It would really be great, if someone from the developers can help hear or give us a hint.

I am wiling to sponsor the bug fix as the KNX binding is very important for my setup. I run now into loop back issues as delayed write backs occur.
Who is the maintainer of the binding? I looked at github:


But I didn’t even find the binding.

In this repo, you would only find 2.xx bindings.
try to look at

Hmm, so the binding has to be rewritten sooner or later anyway to be conform with openhab2-addons?
So I suppose there is no active development or bug fixes on the KNX binding?

1 Like

someone knows if i can use
https://www.weinzierl.de/index.php/en/all-knx/knx-devices-en/produktarchiv-en/knx-ip-baos-770-en

Thanks

Kobi

For the most special DPT type except switch type - especially knx type “<13.010:x/x/x” (energi,Temperature,Humidity)
OH responds with a write on the knx-bus every time something is written on the knx-bus
I found a likely error in the code and changed line 132 ignoreEventList.remove to ignoreEventList.contains in KNXBinding.java

And now it´s works for me!
Edit!
it does not works, Works once and then no more response

Hi,
I am experiencing this now as well. I am on the most recent OH 2.2 stable.
Every time OH2 reads the Set-Temperature of my heating actor, it writes back the default value. So if default is 20.5 and current value is 22, after the read it is back to 20.5. This drives me nuts.
Autoupdate true or false does not make any difference. Unfortunately, this actor accepts writes on a status item (MDT). So while other devices separate clearly between input and output GA, maybe this is the reason why it only affects this device.
Am I wrong or is there really no way to define an item explicitly as read-only? The “<” in front of a GA indicates only, that this GA needs to be read on startup, but to my understanding this is not a read-only-flag. Correct?

Any ideas welcome

Correct. “<” send response to bus. And IF actor output programming for UPDATE and SEND then it send current value to bus.
But actor must resend NEW value set temp, because OH2 write new value before. Do you may say art. no for actor, I look in ETS…

I am using an MDT AKH-0400.02

Ah, solved it by accident :slight_smile:
It seems, as long as there are two GA linked to the item (one to write and one for the status), this does not appear anymore. Additionally, it was not the Set-Temp object but the HVAC-Mode that caused the trouble. So every time OH2 reads the HVAC Mode State, it writes back the same state. As my actor sets the default temp when changing the HVAC mode, it always went back to the standard temperature. Now I am using a separate HVAC-State-Item (GA) and everything works as expected (discovered this by accident, as I obviously had this item still active during my tests, must have been copied it accidentally).

Guess it would be great if we coulf have an option to specify an item as read-only explicitly.

Have a great one

Edit: Seems I have been too quick. It’s not reliable. Sometimes OH2 does not repeat messages, sometimes it does, despite the separat GA and object for state.

Edit 2: Seems a reboot of OH2 fixed it…let’s see for how long.