compatibilityOH2 = true is obsolete, but does not worry.
Your config is perfect!
How you start KNX bundle does not matter. But there should only be one…
I don’t know why, but I have another Bundle:
204 | Active | 80 | 1.9.0.201611251544 | openHAB KNX Binding You can test mine.
Now using a testItem to see if there are echoes:
Switch TEST_AKTOR_1_1_27 "TEST AKTOR 1.1.27" { autoupdate="true", knx="7/2/1+<(30)7/2/7" }
15.15.229 is the OH2 KNX Bundle.
At 8:31:27 you see a normal GroupValueRead from OH2 and then the GroupValueResponse from the KNX-Actor. Got no echo!
At 8:31:57 there I have shortly disconnected the IP-Router, then I switched the actor from OFF to ON and connected the IP-Router again. To see if a changed Value generates an echo. OH2 logged this change with:
08:31:57.437 [INFO ] [marthome.event.ItemStateChangedEvent] - TEST_AKTOR_1_1_27 changed from OFF to ON
Got no echo!
At 8:32:27 again you see a normal GroupValueRead from OH2 and then the GroupValueResponse from the KNX-Actor. Got no echo again!
EDIT: A possible cause for echoes: GroupValueResponse at 9:56:38 in your screen comes from KNX IP BAOS 772, this is your IP-Router. Your router seems to be configured to respond? I think there is a configuration fault. The GroupValueResponse must come from an actuator directly!
@lewie
Your bundle-snapshot (from november 25th) worked! Thank you very much!
Your previous link leads to a jar-snapshot dating oktober 31th. This last link is a snapshot from november and it works!
Some background-infos to understand the idea of using a IP-BAOS-device:
This device is not used as IP-Router! We use 11 ‘real’ IP-Routers to couple the knx-lines. The IP-BAOS-device is used to cache knx-group-adresses or to deliver vaules for devices that may not or should not respond to GroupReadValue-telegramms. IP-Baos-modules have the capability to listen on telegramms and store the last values that were communicated within the knx-lines. Due to the IP-Tunnel capabilities we use the IP-BAOS-device to deliver the ‘last known’ value of a knx group address to a network device. Because the IP-Baos-device can answer to a ReadValue itself there is no traffic on the knx-lines to gain that value from the original knx-device… Therefore we can reduce the traffic on all lines.
here is a small hint regarding your screenshot to gain more clarity: Maybe you want to define a “dummy application” for your device 15.15.229 (witch seems top be your openHAB) and name it for example “openHAB2”. You can add a “virtual line” and use a copy of a IP-Router application or even better: use a gira “dummy application”. You could also create a line 1.2 and declare openHAB2 to use for example 1.2.2 as KNX-phyisical device adress with this setting within knx.cfg:
busaddr=1.1.2
But I guess I am telling you boring stuff…
@lewie, I am sorry but with your snapshot now GroupValueWrite(s) seem to have problems. Last time I made the tests regarding my “GroupValueRead”-Problem. That was fine with your snapshot.
But now normal switch-items do not write to knx any more. I use amazon echo (alexa) to switch on knx devices by voice commands via openHAB2. I monitored the knx communication - nothing happens on the knx side with last snapshot of knx-binding. With same itemconfig everything works fine knx binding 1.9.0.b5.
Therefore I reverted to 1.9.0.b5 and added a listeningGA to solve my problem. Now everything works fine.
This is my item definition to read from knx bus every 60 seconds without an echo:
I read through your discussion, tried all ideal, no success yet.
I have clean OpenHAB 2.0.0 install and migrating from 1.8. Original problem is that OpenHAB2 writes to KNX after read. In most cases it’s just extra traffic, but some KNX devices I have respond back with status on same GA, which in turn causes another reply from OpenHAB.
My knx.cfg has this, everything else is commented out:
ip=ip addr of interface
ignorelocalevents=true
type=TUNNEL
C_A works well, reads 7/0/132 on refresh and sends commands to 7/0/32
C_B generates unnecessary writes to KNX. I tried knx="<7/0/209+7/0/209", as recommended above, in this case I get exception on config refresh:
2017-02-14 18:47:42.707 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'Power.items’
2017-02-14 18:47:42.723 [ERROR] [el.item.internal.GenericItemProvider] - Binding configuration of type ‘knx’ of item ‘C_B’ could not be parsed correctly.
org.eclipse.smarthome.model.item.BindingConfigParseException: Datapoint ‘1.001’ already exists for item ‘C_B’.
at org.openhab.core.binding.internal.BindingConfigReaderDelegate.processBindingConfiguration(BindingConfigReaderDelegate.java:50)[176:org.openhab.core.compat1x:2.0.0]
@lewie, thank you. Did as you described, except adding autoupdate=“true” and it works now without extra writes, on .items files I moved from 1.8. In some other thread I read that ‘autoupdate’ is true by default, and false is something that needs to be specified. Anyway, it works without it, so I’m fine.
Just curious, why 2.0 comes with different KNX bundle, which creates this problem? Is there anything else i should be aware of?
Switch Light_O_FF1 “Light fence front 1” {autoupdate=“true”, knx=“1/3/0+<1/3/100”}
Switch Light_O_FF2 “Light fence front 2” {knx=“1/3/1+<1/3/101”}
Switch Light_O_FB1 “Light fence back 1” {knx=“<1/3/2”}
In all cases I do not get any extra writes, but for the second item (Switch Light_O_FF2) I do not get any write to KNX when I change it through UI. The first and somehow the third items seem to work well. Is it supposed to work like this?
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?
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
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.
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.
This should Help since KNX2 Bundle is out!
