“#153” (3rd entry) is definetly wrong and should not appear!
I searched the web and other topics in the community. And I tried to learn from other results:
I am working with 2.00b5 and KNX binding 1.9.0.b5.
I use “compatibilityOH2 = true” and “ignorelocalevents=true” in my “knx.cfg”
remarkable environment:
The physical knx-address for openHAB2 is configured: “busaddr=10.1.201”
A placeholder within ETS5 is configured (IP-Router filter)
I tried with and without that setting. There where several posts witch had the same problem. In one of that posts this setting was the solution with a earlier code-branch (I think it was a branch from 1.8 but I am not sure).
As I can see in your post this problem is acually on work? That would be great!
At this time I made a workaround and definied a ‘read-only’ group-adress. Therefore the reply from openHAB doesn’t mess my data and leads to a “queue of death” flooding the knx-bus.
There has been effort to correct the problem, but I don’t know what the current status is. A part of the cause of problems with the 1.9 KNX binding on OH2 is likely due to this: On openHAB 1.x runtime, if an item receives a command and the autoupdate logic isn’t suppressed, the item’s state is updated to be the same as the command, but no update event is put on the event bus. Under Eclipse SmartHome (and thus OH2), this was quite sensibly changed so that the update that follows the command is put on the event bus. The KNX binding will now be receiving an update event on OH2 when it wasn’t on OH1. The KNX binding and a few others have a nice feature where they respond to updates to the state of items they are bound to, and passes that along to the remote system. This is really useful for creating a gateway between bindings in the item definition. These handful of bindings have internal logic to suppress responding to state updates that they themselves generate (“echoes”), but they don’t handle the extra internalReceiveUpdate that happens on OH2. When running on OH2, I suspect that both the command to the item and the subsequent state update are both going out to the remote system (since the binding didn’t initiate either). More investigation and code changes appear to be needed to resolve this issue.
I don’t know much about the internal structure of the event bus. But if there is a way to store the source of that event (in this case “knx”) you can decide not to write that “GroupValueWrite” back to the source bus if the source of this event was “knx”.
By the way: it could be a solution to look for an acknowledge-write “ack”. Maybe this GroupValueWrite formerly was an “ack”-telegram to the knx-bus?
For switches for me the solution was to define at least one listening GA: Switch Light_Office "Licht Büro" <light> (gEG, gLight) {knx="2/1/30+<2/1/31"}
No idea why, but the Echo disappears.
But now I want to persist temperatures so I created Item Numbers like: Number Temp_Living "Wohnen [%.1f °C]" <temperature> (gTemperature, gEG) {knx="<4/1/12"}
Also here, OpenHab creates an echo for each temperature value commited.
Listening GA’s make no sense here, but I will try to create a Dummy one. You never know.
When I add “autoupdate=true” into the item-definition - SmartHome Designer marks this line as error. Do I also have to use a newer version of SmartHome Designer?
But I saved the file and tried it with openHAB2 b5 - with this item-definition nothing happens on the knx-side regarding “autoupdate=true” group adress / thing.
I previously worked with “binding-knx1 - 1.9.0.b5”. I installed the “pre-version” from your link. Here is the line from “bundle::list”:
214 | Active | 80 | 1.9.0.201610310808 | openHAB KNX Binding
Do I have to change/update other components of openHAB to try this setting?
@lewie, thanks again. I made the changes (I could have noticed this myself - sorry for that), but unfortunately it is still the same. There is still a “GroupValueWrite” generated by openHAB.
this is my item definition now:
Switch Geraet_OG3_Chef_SchreibtischFreigabe “Schreibtisch Freigabe” (OG3_Chef, Geraete) {autoupdate=“true”, knx="<(60)2/2/239"}
I already tried to remove the item via paper UI and I renamed it to prevent “old item data”. Still the same.
@lewie
I checked the “ignorelocalevents=true” setting within my “knx.cfg”-file. It is correct.
I made thge following changes / have the following settings:
compatibilityOH2 = true
ip=224.12.23.12
=> Multicast adress => works fine
busaddr=10.1.201
=> the physical KNX-device adress displayed in the Bus => works fine
type=ROUTER
port=3671
Yes I downloaded the “Snapshot”-KNX-Binding. since I installed that snapshot the Version of “openHAB KNX Binding” displays as “1.9.0.201610310808” before it was 1.9.0.b5:
bundle:list =>
214 | Active | 80 | 1.9.0.201610310808 | openHAB KNX Binding
After install it was displayed as “Resolved” in the list. Then I used “bundle:start 214”.
But I didn’t copy it manualy. I used “bundle:install” with your URL that leads to your jar-file. Should I install it by hand?
@lewie
Did you notice that my problem occurs on a scheduled read from openHAB on a given knx-group-address? Every 60 seconds a GroupValueRead is generated by openHAB and (as planned) a GroupValueResponse-Answer is generated by the knx-device. This answer is processed by openHAB and the value is saved / changed. But openHAB answers with a “GroupValueWrite”. It may be a different way to the other echo-problems.
Could you please try a scheduled read within your configuration?
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]
This should Help since KNX2 Bundle is out!
