search

openhab / openhab1-addons

Add-ons for openHAB 1.x
Eclipse Public License 2.0
3.43k stars 1.69k forks source link

[KNX] binding in OpenHAB2 generates lots of bus traffic #4547

Closed tkuehne71 closed 5 years ago

tkuehne71 commented 8 years ago

After I switching to OH2 (2.0b3), I frequently get the problem that OH2 is spamming the KNX bus with the same messages over and over again:

2016-07-18 08:45:33.748 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.0.247 for Group address 12/0/11. 2016-07-18 08:45:33.794 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'gEG_DI_BWM_SollHelligkeit' received command 21.0 2016-07-18 08:45:33.794 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.0.247 for Group address 12/0/10. 2016-07-18 08:45:33.840 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'gOG_FL_BWM_SollHelligkeit' received command 20.0 2016-07-18 08:45:33.840 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.0.247 for Group address 12/0/11. 2016-07-18 08:45:33.886 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'gEG_DI_BWM_SollHelligkeit' received command 21.0 2016-07-18 08:45:33.886 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.0.247 for Group address 12/0/10. 2016-07-18 08:45:33.909 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'gOG_FL_BWM_SollHelligkeit' received command 20.0 2016-07-18 08:45:33.909 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.0.247 for Group address 12/0/11. 2016-07-18 08:45:33.978 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'gEG_DI_BWM_SollHelligkeit' received command 21.0 2016-07-18 08:45:33.979 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.0.247 for Group address 12/0/10. 2016-07-18 08:45:34.025 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'gOG_FL_BWM_SollHelligkeit' received command 20.0 2016-07-18 08:45:34.025 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.0.247 for Group address 12/0/11. 2016-07-18 08:45:34.047 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'gEG_DI_BWM_SollHelligkeit' received command 21.0 2016-07-18 08:45:34.048 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 1.0.247 for Group address 12/0/10. 2016-07-18 08:45:34.117 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'gOG_FL_BWM_SollHelligkeit' received command 20.0

and so on, indefinitely.

this is my knx.cfg (only non-defaults shown. local IP is set to the local IP address of the ethernet interface):

busaddr=1.0.247 ignorelocalevents=true type=ROUTER localIp=192.168.x.y autoReconnectPeriod=30 numberOfThreads=1

What confuses me is why the binding is sending knx messages to the bus at all, since I configured 'ignorelocalevents=true".

This also does not occur directly after startup, but sometime during the runtime. The version of the binding bundled with 2.0b3 is called 1.9.0.b3,

This configuration ran in 1.8.3 without issues, and I am not aware that I changed anything on the knx side of things.

any ideas?

alramlechner commented 7 years ago

@lewie: are there any updates? do you need any additional information?

lewie commented 7 years ago

sorry, takes me a while...

Bakkashan commented 7 years ago

Hi all.

I´m having exactly the same problem with echoes and only with number items. Actually I´m running OH2.0.0 (apt installation) on a bananapi m1 with Raspian Jessie lite. For several months everything worked pretty well. No problems with this setup. But after my upgrade last weekend to OH 2.1.0 (including knx binding 2.1.0), I always have the problems described above. What I have done so far is, I tested several older knx binding (1.8.1, 1.9.0 rc, 1.9.0_20171125, etc.). Always the same problem. What really confuses me, after I deinstalled OH 2.1.0 and reinstalled OH 2.0.0 RC (apt and manual installations, I tried both) with exactly the same configuration, that worked for several months, I also have the problems with echo now with OH 2.0.0. This really sucks and is driving me crazy. I spend so much time and efforts to create a working OH sytem and now after the upgrade, this happens...

Additionally I like to point out, I have an "older" OH 2.0.0 running with knx binding 1.9.0 on an Raspi3 with Openhabian 2.0.0, which I used before for test configurations; this system doesn´t show up those problems with knx echoes. There are some other (older) config files on my test system, but overall, no changes in config with the knx binding.

I have no more ideas what to try next. There is only one thing I'm gonna try at next weekend, a whole new installation of Raspian Jesse lite on my Bananapi. I don´t think this will help, but I´ll give it a try.

So, I´m not really deep into programming and developing software, not a professional. But I like to offer my help, if anyone want to test something or need some information of my both system configurations, just let me know.

lewie commented 7 years ago

@Bakkashan, did you test if there are not running two knx-binding versions?

Using the Console: openhab> list

Bakkashan commented 7 years ago

@lewie

Thanks for the tip. I´m not 100% sure, but I think I checked that. I guess there was only one knx binding running after the update. Anyway, after I set up my bananpi totally new last weekend with openhab 2.1.0, the problem still remains. KNX Bus is flooded.

bundle:list -s | grep knx throws out: 207 | Active | 80 | 1.10.0 | openHAB KNX Binding | org.openhab.binding.knx

I can´t remember exactly, but when I started using OH2.0.0 nearly a year ago, I believe, I had the same problem at my first steps. I guess I used another knx binding to solve the problem, but like I said, I´m not really sure. On my other system Raspi3 with Openhabian it still works (with the same configs). For test purposes I tried just a few items (ROLLERSHUTER, DIMMER, NUMBER, CONTACT, SWITCH) step by step, to see what works and what doesn't.

Here is an example of a test item: Number Helligkeit_draussen "Helligkeit [%.0f %%]" (gHelligkeit) { knx="6/0/16" } On KNX side, "6/0/16" send's every 30 seconds the value to bus (just for testing). On my Bananapi the echo appears directly. On my Openhabian system this item works as expected. I use on both system the same knx.cfg. ip=192.168.178.12 ignorelocalevents=true type=TUNNEL localIp=192.168.178.XX (XX = 80(raspi) or 15(bananapi)

I also tried the item with Number Helligkeit_draussen "Helligkeit [%.0f %%]" (gHelligkeit) {autoupdate="false", knx="<6/0/16" } or Number Helligkeit_draussen "Helligkeit [%.0f %%]" (gHelligkeit) {autoupdate="true", knx="<6/0/16" }

"True" ends in endless echoes - "false" is no possibility, because the item in basicui and habmin does not update.

feature:list -s | grep knx throws out on Bananapi: openhab-binding-knx1 | 1.10.0 | x | Started | addons-2.1.0 | KNX Binding on Raspi3: openhab-binding-knx1 | 1.9.0 | x | Started | addons-2.0.0 | KNX Binding

Maybe a silly question, but is there a chance to "copy" the knx binding from raspy to bananapi? I took a look to /usr/share/openhab2/addons on my openhabian system, but there is no ...knx....jar file. So I guess, it is the "normal" knx binding 1.9.0, which came with Openhabian - installation via paperui.

Any hints, further advices and help is appreciated. I do not have anymore ideas what to try... Thanks a lot!

lewie commented 7 years ago

@Bakkashan,

do find / -name 'org.openhab.binding.knx*' 2>/dev/null to find all org.openhab.binding.knx-*.jar files on your linux machine. The org.openhab.binding.knx-*.jar file can be put to /usr/share/openhab2/addons.

But think about to uninstall the original knx binding/jar first by paper UI. If not, both are trying to start!

Bakkashan commented 7 years ago

Thanks a lot for your support Lewie. But that did not help. I had the echoes also with the other knx binding 1.9.

I fixed the problem for now. I guess the problem was, that two OH systems were running at the same time on my network. I forgot that I had to edit the knx.cfg when running two OH systems. Local KNX Binding bus address. Use it, when two or more openHAB Instances are connected to the same KNX bus. (optional, defaults to 0.0.0) busaddr=0.0.3

alramlechner commented 7 years ago

for me the issue seems also to be solved. i don't know what the root cause was. what i did: installed the OS image from scratch (because i want to move from SD to built in MMC on my banana pi). installed OH in same way as before (apt-get). one main difference might be, that i never installed the KNX plugin via paper ui, instead copied org.openhab.binding.knx-1.11.0-20170827.jar to addons folder. now i have no echo telegrams on bus and all items are updated in UI and persistence. thanks Alram

juelicher commented 7 years ago

I am a bit late, but previously I had no time for a further attempt to migrate to openHAB2

Today I installed to current openHAB 2.1 runtime and the KNX binding from this thread, including the serial1 binding. With this setup I see two issues, but I do not know if they are a problem:

  1. The list command in the console shows two KNX bindings, 1.11 as active and 1.10 as resolved, but the Paper UI shows only the 1.10 binding. Even if I uninstall the 1.10 version in the Paper UI it reappers after restarting openHAB

  2. In the openhab.log is an error message, that the KNX configuration is not present, but also a message, that the binding has established a connection to the KNX bus. Switching KNX items works, so the error message is probably not correct or might be related to the two KNX bindings?!

Thanks for your help!

Juelicher

udo1toni commented 7 years ago

In question of point 1: Is knx1 listed in addons.cfg? As the version 1.11 is installed in a completely manual way, this would not emerge in paper UI at all.

juelicher commented 7 years ago

Yes, KNX1 is listened in the addons.cfg. Maybe I got it wrong, but I thougt that the addons must be listened there and than openHAB would take the jar file it finds in the addons directory or load it from the internet, if no file is present. Or does openHAB load all jar files from the addons directory, regardless if they are listed in the configuration or not.

Currently I am stopping and unloading the 1.10 version via the karaf console after openHAB has been loaded and this seems to work.

The KNX 1.11 binding seems to work well too! Great that there is finally a solution for that problem and thanks a lot for the effort and the work!!

hefn commented 7 years ago

@lewie: thanks for providing your org.openhab.binding.knx-1.11.0-20170827.jar.

Could you please also filter the disturbing knx echo routines for rollershutter items? Your knx binding stops e.g. the knx telegram echos for Switch items, but not for rollershutters. Repeating these telegrams on knx bus by openhab2 instantly stops my louver drive or causes unforeseeable events.

The unwanted echos by openhab2 have been recorded with ETS and a selfmade layer1 busmonitor. It does not matter which knx interface is in use - it is exactly the same problem which has been discussed above in #4547.

Many thanks for your help!

juelicher commented 7 years ago

I am sorry to say, but I still notice echo telegrams by openHAB, even with with the org.openhab.binding.knx-1.11.0-20170827.jar

I also noticed, that openHAB rules trigger when receiving an echo diagram from openHAB,

It is interesting, that not all telegrams are echoed by openHAB.

Here is a log of my KNX telegrams, 1.1.145 is the sensor who is supposed to send the telegram, 1.1.235 is the address of my openHAB installation.

2017-11-10 19:47:34.015,A_GroupValue_Write,1.1.145,11/0/230,00 09 13 9F,594847,DPT_Value_4_Count,13.001,0,low,6,T_DATA_XXX_REQ,0 2017-11-10 19:47:34.068,A_GroupValue_Write,1.1.145,11/0/230,00 09 13 9F,594847,DPT_Value_4_Count,13.001,0,low,6,T_DATA_XXX_REQ,0 2017-11-10 19:47:34.097,A_GroupValue_Write,1.1.235,11/0/230,00 09 13 9F,594847,DPT_Value_4_Count,13.001,0,low,5,T_DATA_XXX_REQ,0 2017-11-10 19:47:34.140,A_GroupValue_Write,1.1.235,11/0/230,00 09 13 9F,594847,DPT_Value_4_Count,13.001,0,low,5,T_DATA_XXX_REQ,0 2017-11-10 19:54:54.766,A_GroupValue_Write,1.1.145,11/0/230,00 09 13 A9,594857,DPT_Value_4_Count,13.001,0,low,6,T_DATA_XXX_REQ,0 2017-11-10 19:59:04.523,A_GroupValue_Write,1.1.145,11/0/230,00 09 13 B3,594867,DPT_Value_4_Count,13.001,0,low,6,T_DATA_XXX_REQ,0 2017-11-10 20:01:13.398,A_GroupValue_Write,1.1.145,11/0/230,00 09 13 B8,594872,DPT_Value_4_Count,13.001,0,low,6,T_DATA_XXX_REQ,0 2017-11-10 20:02:37.846,A_GroupValue_Write,1.1.145,11/0/230,00 09 13 BD,594877,DPT_Value_4_Count,13.001,0,low,6,T_DATA_XXX_REQ,0 2017-11-10 20:05:47.840,A_GroupValue_Write,1.1.145,11/0/230,00 09 13 C7,594887,DPT_Value_4_Count,13.001,0,low,6,T_DATA_XXX_REQ,0 2017-11-10 20:05:47.893,A_GroupValue_Write,1.1.145,11/0/230,00 09 13 C7,594887,DPT_Value_4_Count,13.001,0,low,6,T_DATA_XXX_REQ,0 2017-11-10 20:05:47.922,A_GroupValue_Write,1.1.235,11/0/230,00 09 13 C7,594887,DPT_Value_4_Count,13.001,0,low,5,T_DATA_XXX_REQ,0 2017-11-10 20:05:47.965,A_GroupValue_Write,1.1.235,11/0/230,00 09 13 C7,594887,DPT_Value_4_Count,13.001,0,low,5,T_DATA_XXX_REQ,0 2017-11-10 20:08:43.591,A_GroupValue_Write,1.1.145,11/0/230,00 09 13 D1,594897,DPT_Value_4_Count,13.001,0,low,6,T_DATA_XXX_REQ,0 2017-11-10 20:08:43.648,A_GroupValue_Write,1.1.145,11/0/230,00 09 13 D1,594897,DPT_Value_4_Count,13.001,0,low,6,T_DATA_XXX_REQ,0 2017-11-10 20:08:43.707,A_GroupValue_Write,1.1.235,11/0/230,00 09 13 D1,594897,DPT_Value_4_Count,13.001,0,low,5,T_DATA_XXX_REQ,0

hefn commented 7 years ago

These problems with knx telegram echoes do not appear in OH1.8.3.

It is a disappointing step backward that OH2 causes incompatibility to previously stable working knx elements like rollershutters. So for me sadly OH2 is impossible to use at the moment.

tkuehne71 commented 6 years ago

Still not fixed in 2.2, it seems. Any idea on the status of the new 2.0 KNX binding?

juelicher commented 6 years ago

Somewhere in this forum there is s link to a version of the 1.x KNX binding, that fixes this issue by only sending commands to the KNX bus on a sendComand() not on a postUpdate(). This seems at least to mitigate the problem-

Sadly this fix did not make it into the official release, despite that it is from August.

tkuehne71 commented 6 years ago

and I remember that it only fixed certain instances, while others still displayed the same problem?

Von meinem iPhone gesendet

Am 24.12.2017 um 11:56 schrieb juelicher notifications@github.com:

Somewhere in this forum there is s link to a version of the 1.x KNX binding, that fixes this issue by only sending commands to the KNX bus on a sendComand() not on a postUpdate(). This seems at least to mitigate the problem-

Sadly this fix did not make it into the official release, despite that it is from August.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

hefn commented 6 years ago

Dear juelicher, i think i tried every link of the 1.x KNX bindings in this thread, especially from lewie, but non of them solved the repeating telegram problem for e.g. rollershutters or measuring value telegrams. It would be kind if you could please provide this link for us. Thanks

lewie commented 6 years ago

@juelicher, @hefn,

believe me, none of my attempts to solve the problem really solved!

In openHAB 2, the strict serialization of handleCommand and then after that (if State really has changed) a call of handleUpdate, has a little bit changed. This makes the simple filtering as done in openHAB 1 absolutely impossible.

Current State: https://github.com/openhab/openhab2-addons/pull/2323#issuecomment-306145855 https://github.com/eclipse/smarthome/pull/4674#issuecomment-350072013

udo1toni commented 6 years ago

As I'm no software developer, I'm surprised by the fact, that openHAB seems to work against itself. postUpdate() must not send anything to any binding, but it seems that knx1 does sending all postUpdates to the bus. sendCommand() shall only send to the first GA (given Dimmer {knx="1/1/0+1/1/10,1/1/1,1/1/2+<1/1/3"} a sendCommand(ON/OFF) is only allowed to 1/1/0, never 1/1/10, a sendCommand(INCREASE/DECREASE) is only allowed to 1/1/1 and a sendCommand(0...100) is only allowed to 1/1/2.) And of course openHAB must not repeat a received Command to the very same binding. This is basic functionality and I don't understand why openHAB2 behaves in another way than openHAB1.

lewie commented 6 years ago

@udo1toni, unfortunately it's not that easy!

see: https://github.com/openhab/openhab1-addons/blob/master/bundles/binding/org.openhab.binding.knx/src/main/java/org/openhab/binding/knx/internal/bus/KNXBinding.java#L109

Echos are filtered in internalReceiveCommand and internalReceiveUpdate. If the order is correct, then the binding remembers the last trigger of item x and can filter the upcoming Update. It knows for one cycle, that this Command/Update seams to be from itself (is not a clean 100% solution anyway). Apart from this it definitively only works for clean serialized sequence internalReceiveUpdate THEN internalReceiveCommand. OpenHAB 2 does to our chagrin not follow the logical order that you could expect from openHAB 1.

A contradiction: 1) It must be distinguished whether the status or command comes from intern or extern (Script or GUI vs. KNX-Bus) 2) KNX binding does normally not know where the Command/Update does come from. If from another binding, from internal evetbus, from itself.

I invite you to join us here. I would be very happy if you could find a solution.

J-N-K commented 6 years ago

I already proposed a Solution somewhere. Command should be extended so that the origin of the object can be identified. IIRC that has never been discussed.

lewie commented 6 years ago

@J-N-K, it has been discussed and will continue to hold discussions. Unfortunately, the proof and the insight for necessity are missing. It seems there is only too small a circle that stumbles over this problem.

See: https://github.com/eclipse/smarthome/pull/4674#issuecomment-350072013

J-N-K commented 6 years ago

I can‘t believe that noone uses KNX with OH2. But probably most Users do not notice the duplicated telegrams. However, my suggestion is different. I‘ll post an example later.

lewie commented 6 years ago

I think so, too!

Would be very sparse. I would be so happy about a useful solution for KNX1 binding in openHAB2!

coriet commented 6 years ago

Myself and some friends have the same issue with a KNX/OH2 installation. In my example the biggest pain point I have with the duplicated telegrams are my DALI lamps, controlled via KNX/DALI GW. For example, if a light bulb dims from 0 - 100% and sends it's state during this action, e.g at 34% -> OH sends 34% to the bulb and the light will never reach 100%. Imagine, I try to bring a bunch of bulbs on the same level but each individual stays at a different level. I do have the autoupdate=false "workaround" in place but with that I can't visualize and control the state of an individual spot in the OH2 app. I guess there are many people willing to spend some money (including me), to get at least a working KNX 1 binding.

J-N-K commented 6 years ago

What I was thinking about is not possible without major refactoring. Command and State are only interfaces that are implemented by the types, so they can't provide functionality by themself. I was (mistakenly) thinking that the Types inherit from State. My idea as to extend State (and/or Command) with something like

private String origin;

public void setOrigin(String origin) {
    this.origin = origin;
}

public String getOrigin() {
    return this.origin;
}

and probably additional constructors, e.g. PercentType(String value, String origin). So a binding not using this fucntionality would simply work as before and all others could set the origin to themself and check at least if they themself created that State/Command.

juelicher commented 6 years ago

Just for completness: I am using this version of the binding, provided by lewie: https://github.com/lewie/openhab/raw/Testfile20170827/org.openhab.binding.knx-1.11.0-20170827.jar

Probably the behaviour can not be fixed within the binding and should be fixed within the openHAB core. But I do not know, why the changes from OH1 to OH2 where introduced and why other bindings do not have similar problems.

I guess there are many people willing to spend some money (including me), to get at least a working KNX 1 binding.

Sure, you can add me to that list! Same think for start/stop dimming...

hefn commented 6 years ago

@lewie: Many thanks for all the hours you have spent here fixing this problem. I think it is not only a small circle who is having these problems. Presumably a fraction of the users would contact a forum for help. Most of them would change the software or hardware KNX binding before doing this step. At the moment the majority of my friends and colleagues do not use OH2. Not only the dimming problem is accurately described by sucre87, also the rollershutters don't work at our home in OH2 because they are used in "longterm/shortterm operation mode". A wrong placed shortterm telegram instantly causes the rollershutter to stop. This problem also can be found in another forum entry. Even CSMA/CA seems to work not correctly when OH2 repeats telegrams on our bus - but maybe this could a problem of calimero implementation too.

You wrote that KNX binding does normally not know where the Command/Update does come from - if from another binding, from internal eventbus or from itself. Wouldn't it be the simpliest solution that the knx binding would filter on triggering the Local KNX Binding bus address "knx:busaddr" from the .cfg file as a sufficient rule for not echoing the telegram again on the knx bus? What is done here in line 186 at https://github.com/openhab/openhab1-addons/blob/master/bundles/binding/org.openhab.binding.knx/src/main/java/org/openhab/binding/knx/internal/bus/KNXBinding.java#L186 ? Does it do this local group adress filtering or provides KNXConnection.getLocalSourceAddr anything else? Many thanks...

RK2904 commented 6 years ago

Dear OpenHAB developers, just to lat you know that the community of frustrated KNX users is bigger ... I'm a BIG fan of OpenHAB (not really the biggest contributor). I like this initiative, the concept and the software around it, and since a year I'm running it on 3 Raspberry PI 3 (1 OpenHAB, 1 ZWave Razberry, 1 backup) to manage and visualize my KNX installation. AND I also have troubles with these double messages, especially with my EnOcean gateway and the EnOcean actors behind. This issue exist now since ages, and it is really a pity, that this problem exist so long (I already changed some EnOcean dimmer because they behave crazy with these double messages). Unfortunately my software development skills are outdated sind 1985 (with Fortran and Cobol) and I'm not able to help (instantly). Don't understand me wrong: I love what all of you are doing, and I'm impressed about the results and dynamics. It would really be great if this issue can be fixed. @juelicher: I copy your statement:

_I guess there are many people willing to spend some money (including me), to get at least a working KNX 1 binding.__

My name can also be added to that list! AND: start/stop dimming would HIGHLY BE APPRICIATED for scenes creation within rules.

THANKS!

GoHoHa commented 6 years ago

I am another OH user with KNX. So far I have no apparent issues with the double messages, but complained about it as well in the OH community forum before. Recently I upgraded to OH2.2 release built with KNX 1.11.0 (from an older OH2.2 snapshot), and in ETS5 I see all the echoes for all messages. Typically they follow the original messages with a delay of 0-100ms and are from my OH easily distinguished by the source address (15.15.255 in my case). All normal traffic on KNX bus is on addresses 1.1.X

Please take this issue to the top of the ToDo-List for next KNX1 and KNX2 binding. Thank you!

rsterz commented 6 years ago

Yep, the group of affected people is much larger than the amount of people discussing in this thread. I run into exactly the same issue with OH2 (2.0.0, 2.1.0 and 2.2.0) and KNX 1.9. After every new release for OH2 I tried it again (including lewie's version). But I still have the echos flooding the KNX bus. I follow this thread for almost one year and appreciate the engagement of some key people in this forum.

I would love to see a KNX2 binding for OH2 or a fixed KNX1 binding for OH2. OH1 receives less support (e.g. Amazon Echo integration). I would definitely want to switch. If you have a donation link to finish work on the KNX2 binding, please share it.

mawa85 commented 6 years ago

I'm also very annoyed by this. Especially with central functions, a huge amount of telegrams is echoed to the bus. Thanks for your efforts investigating this issue. Sadly it does not look like there will be an easy fix.

starranger3 commented 6 years ago

I have the same issue with OH2 (2.2.0) and knx binding 1.11.0 with duplicated messages. See my separate issue https://github.com/openhab/openhab1-addons/issues/5399 Due to this issue, the OH2 is of no use right now for me. Thanks for your effort looking into this, a fix would be greatly appreciated.

crystollic commented 6 years ago

I have the same issue on OH 2.2.0. The autoupdate workaround stops the telegram loops but doesn't make for a great user experience as the UI doesnt reflect any meaningful state.

With autoupdate on my KNX system goes crazy. When you dim a light ON the actuator reports it’s ON state to the bus which OH echoes back which then switches the actuator back on, so lights are constantly on 100% and the bus is swamped. I also had underfloor heating constantly on at one point 😕

Re people raising the issue, I suspect it is larger than reported as most KNX systems have wall switches, etc to control actuators and therefore OH sits alongside a KNX system as opposed to being at the centre of it. For me OH is still critical as the rules and integration is what made my KNX installation rock 😎

Happy to help where I can but my coding skills would never pass a PR!!!

ypaindaveine commented 6 years ago

+1

See https://community.openhab.org/t/knx-binding-repeats-commands/37674 for details on my issue, which is the same unwanted echoing back to the KNX bus.

martenss commented 6 years ago

+1

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

affezibbl commented 6 years ago

+1 also from my side. The KNX binding is the only thing that prevents my from using OH2.x Also, +1 for willing to spend some euros to someone who takes care of this.

On first sight, @J-N-K 's suggestion to enrich the command by its sender, sounds like a clever idea. Same concepts for having the sender of an "event" retrievable on the message or event itself are well known by a couple of programming languages. So why not considering this as a possible solution?

J-N-K commented 6 years ago

Is it true, that this only Happens in items which have only one GA attached to it?

J-N-K commented 6 years ago

Please try this jar: org.openhab.binding.knx-1.12.0-SNAPSHOT.jar

starranger3 commented 6 years ago

Thanks for the update. I have installed the knx 1.12.0 snapshot and according to my test this is a good improvement in the right direction 👍 .

Following observations:

1. Auto refresh messages:

The echo telegrams were only there after starting the openhab, for example when the room temperature changes (just a reading group adress), the following autorefresh timeout message appear. Nevertheless, the temperature is displayed correctly in the VISU!

Corresponding item:

//--> EG Wohnen [3/1/x]
Number TIstEGWohnen "EG Wohnen Temperatur Ist [%.1f °C]"    (gWohnenEG, gTemp)      {knx = "<3/1/1"}

Log: 

==> /var/log/openhab2/events.log <==
2018-01-07 10:14:15.155 [ome.event.ItemCommandEvent] - Item 'TIstEGWohnen' received command 18.86
2018-01-07 10:14:15.158 [vent.ItemStateChangedEvent] - TIstEGWohnen changed from 18.89 to 18.86

==> /var/log/openhab2/openhab.log <==
2018-01-07 10:14:18.084 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'TIstEGWohnen' from KNX bus: no confirmation reply received for L-Data.req from 1.1.240 to 3/1/1, low priority hop count 6 repeat tpdu 00 00: timeout
2018-01-07 10:14:18.084 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.2.100:3671: response timeout waiting for confirmation
tuwien.auto.calimero.exception.KNXTimeoutException: no confirmation reply received for L-Data.req from 1.1.240 to 3/1/1, low priority hop count 6 repeat tpdu 00 00
        at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:236) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:269) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:149) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:263) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:304) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:240) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.readFromGroup(ProcessCommunicatorImpl.java:486) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.read(ProcessCommunicatorImpl.java:422) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at org.openhab.binding.knx.internal.bus.KNXBindingDatapointReaderTask.readFromKNXBus(KNXBindingDatapointReaderTask.java:99) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at org.openhab.binding.knx.internal.bus.KNXBindingDatapointReaderTask.run(KNXBindingDatapointReaderTask.java:67) [229:org.openhab.binding.knx:1.12.0.201801061831]
2018-01-07 10:14:18.089 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address '3/1/1' = '0'

However, after startup (5 minutes after starting openhab2), no more warning for the auto refresh messages are shown 👍 !!! Log:

==> /var/log/openhab2/events.log <==
2018-01-07 10:40:22.102 [vent.ItemStateChangedEvent] - Azimuth changed from 154.07 to 154.29
2018-01-07 10:40:22.111 [vent.ItemStateChangedEvent] - Elevation changed from 14.81 to 14.88
2018-01-07 10:40:22.115 [vent.ItemStateChangedEvent] - TotalRadiation changed from 130.05 to 130.97
2018-01-07 10:40:23.168 [vent.ItemStateChangedEvent] - ntp_ntp_local_dateTime changed from 2018-01-07T10:39:23.111+0100 to 2018-01-07T10:40:23.147+0100
2018-01-07 10:40:23.173 [vent.ItemStateChangedEvent] - CurrentDate changed from 2018-01-07T10:39:23.111+0100 to 2018-01-07T10:40:23.147+0100
2018-01-07 10:40:23.177 [vent.ItemStateChangedEvent] - ntp_ntp_local_string changed from 2018-01-07 10:39:23 CET to 2018-01-07 10:40:23 CET
2018-01-07 10:40:58.465 [ome.event.ItemCommandEvent] - Item 'TIstEGWohnen' received command 18.96
2018-01-07 10:40:58.478 [vent.ItemStateChangedEvent] - TIstEGWohnen changed from 18.93 to 18.96
2018-01-07 10:41:08.431 [ome.event.ItemCommandEvent] - Item 'TStellEGWohnen' received command 68
2018-01-07 10:41:08.448 [vent.ItemStateChangedEvent] - TStellEGWohnen changed from 70 to 68
2018-01-07 10:41:22.212 [vent.ItemStateChangedEvent] - Azimuth changed from 154.29 to 154.52
2018-01-07 10:41:22.222 [vent.ItemStateChangedEvent] - Elevation changed from 14.88 to 14.95
2018-01-07 10:41:22.234 [vent.ItemStateChangedEvent] - TotalRadiation changed from 130.97 to 131.90
2018-01-07 10:41:23.175 [vent.ItemStateChangedEvent] - ntp_ntp_local_dateTime changed from 2018-01-07T10:40:23.147+0100 to 2018-01-07T10:41:23.154+0100
2018-01-07 10:41:23.184 [vent.ItemStateChangedEvent] - ntp_ntp_local_string changed from 2018-01-07 10:40:23 CET to 2018-01-07 10:41:23 CET
2018-01-07 10:41:23.188 [vent.ItemStateChangedEvent] - CurrentDate changed from 2018-01-07T10:40:23.147+0100 to 2018-01-07T10:41:23.154+0100
2018-01-07 10:41:58.425 [ome.event.ItemCommandEvent] - Item 'TIstEGWohnen' received command 19.02
2018-01-07 10:41:58.437 [vent.ItemStateChangedEvent] - TIstEGWohnen changed from 18.96 to 19.02
2018-01-07 10:42:22.307 [vent.ItemStateChangedEvent] - Azimuth changed from 154.52 to 154.75
2018-01-07 10:42:22.318 [vent.ItemStateChangedEvent] - Elevation changed from 14.95 to 15.02
2018-01-07 10:42:22.332 [vent.ItemStateChangedEvent] - TotalRadiation changed from 131.90 to 132.82
2018-01-07 10:42:23.192 [vent.ItemStateChangedEvent] - ntp_ntp_local_dateTime changed from 2018-01-07T10:41:23.154+0100 to 2018-01-07T10:42:23.170+0100
2018-01-07 10:42:23.203 [vent.ItemStateChangedEvent] - CurrentDate changed from 2018-01-07T10:41:23.154+0100 to 2018-01-07T10:42:23.170+0100
2018-01-07 10:42:23.208 [vent.ItemStateChangedEvent] - ntp_ntp_local_string changed from 2018-01-07 10:41:23 CET to 2018-01-07 10:42:23 CET
2018-01-07 10:42:27.625 [ome.event.ItemCommandEvent] - Item 'TIstDGKind' received command 20.02
2018-01-07 10:42:27.652 [vent.ItemStateChangedEvent] - TIstDGKind changed from 19.990000000000002 to 20.02
2018-01-07 10:42:45.401 [ome.event.ItemCommandEvent] - Item 'TStellDGKind' received command 96
2018-01-07 10:42:45.411 [vent.ItemStateChangedEvent] - TStellDGKind changed from 98 to 96
2018-01-07 10:42:58.462 [ome.event.ItemCommandEvent] - Item 'TIstEGWohnen' received command 19.05
2018-01-07 10:42:58.471 [vent.ItemStateChangedEvent] - TIstEGWohnen changed from 19.02 to 19.05

2. Items with a write command to the bus

Items, which have a write command to the bus, e. g. rollershutter items with have more than one GA attached to it, generate still error and warnings on the bus. Nevertheless, the action is perfored successfully!

Item:

//--> Rolläden[0/x/x] {knx="LZ, KZ, Position+<Position_Rückmeldung}
//================================================================
//--> DG Kind [0/0/x]
Rollershutter RDGKind "Kind [%d %%]" (gKindDG, gRollo)                      {knx = "0/0/1,0/0/2,0/0/3+<0/0/4"}

Log:

2018-01-07 10:23:54.767 [ome.event.ItemCommandEvent] - Item 'RDGKind' received command 30

==> /var/log/openhab2/openhab.log <==
2018-01-07 10:23:57.784 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Value '30' could not be sent to the KNX bus using datapoint 'command DP 0/0/3 RDGKind, DPT main 0 id 5.001, low priority' - retrying one time: no confirmation reply received for L-Data.req from 1.1.240 to 0/0/3, low priority hop count 6 repeat tpdu 00 80 4d
2018-01-07 10:23:57.784 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.2.100:3671: response timeout waiting for confirmation
tuwien.auto.calimero.exception.KNXTimeoutException: no confirmation reply received for L-Data.req from 1.1.240 to 0/0/3, low priority hop count 6 repeat tpdu 00 80 4d
        at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:236) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:269) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:149) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:263) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:304) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:240) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:466) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:160) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveCommand(KNXBinding.java:112) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at org.openhab.core.binding.AbstractBinding.receiveCommand(AbstractBinding.java:94) [228:org.openhab.core.compat1x:2.2.0]
        at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:45) [228:org.openhab.core.compat1x:2.2.0]
        at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415) [3:org.apache.karaf.services.eventadmin:4.1.3]
        at org.apache.felix.eventadmin.impl.tasks.HandlerTask.runWithoutBlacklistTiming(HandlerTask.java:82) [3:org.apache.karaf.services.eventadmin:4.1.3]
        at org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:104) [3:org.apache.karaf.services.eventadmin:4.1.3]
        at org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks$TaskExecuter.run(AsyncDeliverTasks.java:166) [3:org.apache.karaf.services.eventadmin:4.1.3]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

==> /var/log/openhab2/events.log <==
2018-01-07 10:23:58.511 [vent.ItemStateChangedEvent] - RDGKind changed from 0 to 30

==> /var/log/openhab2/openhab.log <==
2018-01-07 10:24:00.801 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Value '30' could not be sent to the KNX bus using datapoint 'command DP 0/0/3 RDGKind, DPT main 0 id 5.001, low priority' - giving up after second try: no confirmation reply received for L-Data.req from 1.1.240 to 0/0/3, low priority hop count 6 repeat tpdu 00 80 4d
2018-01-07 10:24:00.801 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.2.100:3671: response timeout waiting for confirmation
tuwien.auto.calimero.exception.KNXTimeoutException: no confirmation reply received for L-Data.req from 1.1.240 to 0/0/3, low priority hop count 6 repeat tpdu 00 80 4d
        at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:236) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:269) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:149) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:263) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:304) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:240) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:466) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:169) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveCommand(KNXBinding.java:112) [229:org.openhab.binding.knx:1.12.0.201801061831]
        at org.openhab.core.binding.AbstractBinding.receiveCommand(AbstractBinding.java:94) [228:org.openhab.core.compat1x:2.2.0]
        at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:45) [228:org.openhab.core.compat1x:2.2.0]
        at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415) [3:org.apache.karaf.services.eventadmin:4.1.3]
        at org.apache.felix.eventadmin.impl.tasks.HandlerTask.runWithoutBlacklistTiming(HandlerTask.java:82) [3:org.apache.karaf.services.eventadmin:4.1.3]
        at org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:104) [3:org.apache.karaf.services.eventadmin:4.1.3]
        at org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks$TaskExecuter.run(AsyncDeliverTasks.java:166) [3:org.apache.karaf.services.eventadmin:4.1.3]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]
J-N-K commented 6 years ago

@starranger3, this seems to be a completely different issue as Calimero complains about not receiving a reply. There seems to be a communication error with you KNX interface. I have NEVER seen that here. However, I never managed to get tunneling working anyway. Try ROUTER mode if you interface supports it. Reading of values works here without echo.

GoHoHa commented 6 years ago

same as before at my setup:

paperui_knx-binding

ets5_diagnosemonitor

starranger3 commented 6 years ago

@J-N-K ; I have a MDT KNX Interface which unfortunately does not support router mode. I tried up to now every configuration, but only tunnel mode is working. Does that mean I have to buy a KNX interface which supports router mode? Or is there a fix available?

J-N-K commented 6 years ago

@GoHoHa, I have done another update, this also fixes #5417. Please install from the same location as before. And check that bundle:list shows 1.12.nmu1 as version. Second, what is your item definition and your knx.cfg. Do you use autoupdate-settings or did you set ignorelocalevents=false? If so, please remove the autoupdate-setting and set ignorelocalevents=true.

@starranger3: My interface does not support routing, too. I use eibd as router which connects to the IP interface via tunneling.

starranger3 commented 6 years ago

@J-N-K ; how do I setup eibd as router? This would be great if I can get this to work...

affezibbl commented 6 years ago

@J-N-K I'd also like to give your updated binding a try. However, the link you've posted to org.openhab.binding.knx-1.12.0-SNAPSHOT.jar points to a page showing only the text "Not Found" and nothing else. Where can I get a recent jar of your updated binding?

J-N-K commented 6 years ago

@affezibbl: I updated the link, https:// was missing. @starranger3: /usr/bin/eibd -e 1.1.254 -c -S -D -i -T -R -d -u --pid-file=/var/run/eibd.pid -c ipt:192.168.0.53, but we should continue this in the forum and not pollute this issue. 192.168.0.53 is the address of my IP interface. Then set ip=224.0.23.12 in knx.cfg.

starranger3 commented 6 years ago

@J-N-K ; I configured router mode with the above ip in the knx.cfg and with enabled knxd, entry in /etc/default/knxd: KNXD_OPTIONS="--eibaddr=1.1.240 --client-addrs=1.1.129:8 -d -D -T -R -S -i --listen-local=/tmp/knx -b ipt:192.168.2.100" The router mode is established successfully, however, I get now the following warning messages for reading items (values are shown!). However, I cannot write anymore to the bus at all...

==> /var/log/openhab2/openhab.log <==
2018-01-07 14:27:51.451 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'RDGSchlafen' from KNX bus: timeout waiting for group read response: timeout
2018-01-07 14:27:51.455 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Give up, could not read address '0/0/34' after '3' retries.
2018-01-07 14:28:01.509 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'REGWohnenOst' from KNX bus: timeout waiting for group read response: timeout
2018-01-07 14:28:01.512 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Give up, could not read address '0/1/13' after '3' retries.
2018-01-07 14:28:11.567 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'LEGWohnenSued' from KNX bus: timeout waiting for group read response: timeout
2018-01-07 14:28:11.570 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Give up, could not read address '0/1/6' after '3' retries.
2018-01-07 14:28:21.624 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'TSollDGKind' from KNX bus: timeout waiting for group read response: timeout
2018-01-07 14:28:21.626 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Give up, could not read address '3/0/4' after '3' retries.
2018-01-07 14:28:31.680 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'BelEGWohnenCouch' from KNX bus: timeout waiting for group read response: timeout
2018-01-07 14:28:31.682 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Give up, could not read address '1/1/2' after '3' retries.
coriet commented 6 years ago

@J-N-K I've enabled the latest SNAPSHOT version and changed my configuration according to your recommendation (removed autoupdate settings etc.) My KNX was set to TUNNEL mode because my Weinzierl 731 GW doesn't support Router mode. I couldn't identify any difference, changing my DALI lights ends in a echo loop.

Because you mentioned that it's more stable with ROUTER mode, I've installed eibd and configured OH2 to router mode. This config seems to stop the echo issue but my KNX communication gets very (unusable) slow. Changing the values for multiple spots takes forever. Sometimes up to 30-40 seconds, till the event shows up in the ETS console.

I had to switch back to TUNNEL mode without eibd. For me it looks like I would have to replace my KNX IP gateway with one that supports ROUTER mode?!

by the way, thanks a lot for your effort and let me know if any logfiles would help.