openHAB 2 + KNX Binding 1.9 + ROUTER Mode

[ArPa (Artur)]

Hi guys,

yesterday I made a clean installation of openHAB2. Now I´m trying a very first simple test with my KNX installation. Simply receiving a temperature value from living room, nothing special.

In TUNNEL mode everything works fine and I receive the value immediately after restarting openHAB2. In ROUTER mode I get some errors in log…

2017-02-09 20:09:25.399 [INFO ] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: using network interface eth0
2017-02-09 20:09:25.425 [INFO ] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: multicast loopback mode enabled
2017-02-09 20:09:25.471 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 224.0.23.12:3671 in mode ROUTER.
2017-02-09 20:09:25.556 [INFO ] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send message to 1/2/2, wait for confirmation
2017-02-09 20:09:25.560 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 0.0.0 to 1/2/2, low priority hop count 6 tpdu 00 00
2017-02-09 20:09:25.565 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 0.0.0 to 1/2/2, low p$
2017-02-09 20:09:25.572 [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 $
2017-02-09 20:09:25.581 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 0.0.0 to 1/2/2, low pr$
2017-02-09 20:09:25.586 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send to 1/2/2 succeeded
2017-02-09 20:09:25.606 [DEBUG] [tuwien.auto.calimero                ] - process 224.0.23.12:3671: sent group read request to 1/2/2
2017-02-09 20:09:35.590 [INFO ] [tuwien.auto.calimero                ] - process 224.0.23.12:3671: timeout waiting for group read response
2017-02-09 20:09:35.594 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'Temperature_GF_Living' from KNX bus: timeout waiting for group read resp$
2017-02-09 20:09:35.598 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address '1/2/2' = '2'
2017-02-09 20:09:35.653 [INFO ] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send message to 1/2/2, wait for confirmation
2017-02-09 20:09:35.656 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 0.0.0 to 1/2/2, low priority hop count 6 tpdu 00 00
2017-02-09 20:09:35.661 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 0.0.0 to 1/2/2, low p$
2017-02-09 20:09:35.666 [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 $
2017-02-09 20:09:35.670 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 0.0.0 to 1/2/2, low pr$
2017-02-09 20:09:35.675 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send to 1/2/2 succeeded
2017-02-09 20:09:35.679 [DEBUG] [tuwien.auto.calimero                ] - process 224.0.23.12:3671: sent group read request to 1/2/2
2017-02-09 20:09:45.658 [INFO ] [tuwien.auto.calimero                ] - process 224.0.23.12:3671: timeout waiting for group read response
2017-02-09 20:09:45.658 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'Temperature_GF_Living' from KNX bus: timeout waiting for group read resp$
2017-02-09 20:09:45.666 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address '1/2/2' = '1'
2017-02-09 20:09:45.722 [INFO ] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send message to 1/2/2, wait for confirmation
2017-02-09 20:09:45.724 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 0.0.0 to 1/2/2, low priority hop count 6 tpdu 00 00
2017-02-09 20:09:45.729 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 0.0.0 to 1/2/2, low p$
2017-02-09 20:09:45.734 [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 $
2017-02-09 20:09:45.738 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 0.0.0 to 1/2/2, low pr$
2017-02-09 20:09:45.742 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send to 1/2/2 succeeded
2017-02-09 20:09:45.748 [DEBUG] [tuwien.auto.calimero                ] - process 224.0.23.12:3671: sent group read request to 1/2/2
2017-02-09 20:09:55.725 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'Temperature_GF_Living' from KNX bus: timeout waiting for group read resp$
2017-02-09 20:09:55.728 [INFO ] [tuwien.auto.calimero                ] - process 224.0.23.12:3671: timeout waiting for group read response
2017-02-09 20:09:55.731 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address '1/2/2' = '0'
2017-02-09 20:09:55.787 [INFO ] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send message to 1/2/2, wait for confirmation
2017-02-09 20:09:55.790 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 0.0.0 to 1/2/2, low priority hop count 6 tpdu 00 00
2017-02-09 20:09:55.795 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 0.0.0 to 1/2/2, low p$
2017-02-09 20:09:55.798 [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 $
2017-02-09 20:09:55.804 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 0.0.0 to 1/2/2, low pr$
2017-02-09 20:09:55.809 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.224.0.23.12:3671: send to 1/2/2 succeeded
2017-02-09 20:09:55.813 [DEBUG] [tuwien.auto.calimero                ] - process 224.0.23.12:3671: sent group read request to 1/2/2
2017-02-09 20:10:05.791 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'Temperature_GF_Living' from KNX bus: timeout waiting for group read resp$
2017-02-09 20:10:05.794 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Give up, could not read address '1/2/2' after '3' retries.
2017-02-09 20:10:05.794 [INFO ] [tuwien.auto.calimero                ] - process 224.0.23.12:3671: timeout waiting for group read response

Is this a known issue? Does the combination openHAB2 and KNX 1.9 binding not work in ROUTER mode?

Best regards!

[Dim (Angelos)]

@ArPa

Does the combination openHAB2 and KNX 1.9 binding not work in ROUTER mode?

It works fine.
There could be several reasons why the read request is timing out…
Let’s check the basics first: What is your interface to the KNX system?
Can you also post your knx.cfg file and the output of the following command in the console (ssh openhab@localhost -p 8101 with password: habopen):

config:list "(service.pid=org.openhab.knx)"

[ArPa (Artur)]

Hi!

The KNX Router is an ABB IPR/S2.1 (http://www.knx-gebaeudesysteme.de/sto_g/Deutsch/Deutschland/ABB_ibus_KNX/_HTML/product_2CDG110061R0011.htm) which worked fine in openHab 1.x in ROUTER mode.

knx.cfg is very simple:

########## KNX Binding
knx:type=ROUTER
knx:localIp=172.40.10.3

The output of config:list “(service.pid=org.openhab.knx)” I will check in the afternoon…

[george.erhan]

Hi,

Have you checked the filter tables on the KNX router? The telegrams might not pass through if the KNX router does not allow it.

If you have no filter table configuration in ETS for the KNX router, try configurating a dummy device in ETS!

Don’t forget to set the bus address (like 1.1.xx) in knx.cfg and the local IP address (Sometimes there are issues if you do not set the local IP address - especially for Linux OS)

Best regards,

George

[ArPa (Artur)]

Already tested it. Setting the router ip to the official knx multicast ip in config does not fix it.

The local ip of my openHAB instance is already set in config as you can see.

As far as I read setting the bus address for openHAB is only for TUNNEL mode?

Unfortunately the same hardware worked in openHAB 1.x… Maybe I will go the Long way and install a clean 1.8.3 again for comparison reasons.

[Dim (Angelos)]

@ArPa

As far as I read setting the bus address for openHAB is only for TUNNEL mode?

It’s for both connection types (ROUTER and TUNNEL).

See here:

OH2 - KNX - infinite command loop

Hi @yphyph01, However, I wonder why, with the new OH2 release, the knx binding is not updated to fix this issue. The knx 1.9 binding is not a OH2 Binding, it’s a OH1 Binding with OH2 compatibility. Do not know the state of the KNX OH2 Binding yet, but yes indeed this will be fixed. I don’t understand the ‘busaddr’ parameter. It is used for openHAB to identify and filtering like: Ignoring local Event, received from my local Source address 15.10.1 The default used KNX Groupadress for ope…

I use another KNX/IP Router but here is my /etc/openhab2/services/knx.cfg:

ip=224.0.23.12
busaddr=1.2.200
ignorelocalevents=true
type=ROUTER
localIp=172.16.13.100

[kip (dennis)]

@ArPa Did you ever solved this? I have exactly the same problem (with the same KNX IP Router).

[kip (dennis)]

It seems my problem is just that the knx binding does not join the multicast group. I tried to debug the problem with tcpdump, and the moment I run this tcpdump command:

tcpdump -i br0 -s0 -vv host 224.0.23.12

openhab starts to receive knx messages! As soon as I cancel the tcpdump command, I no longer get knx messages …

[Dim (Angelos)]

@kip

As soon as I cancel the tcpdump command, I no longer get knx messages …

sounds very similar to:

[Solved] KNX Binding ignores state responses for KNX BUS Events

Hmm… One quick thought that I have (I may be wrong) is that tcpdump is putting your ethernet interface in promiscuous mode and as a result, your raspy / OpenHab can read the packets originating from the KNXnet/IP Router (multicast) Without tcpdump running, check the output of netstat -i see if the flags include "M" if not, enable multicast: ip link set eth0 multicast on or set the ethernet interface to always on promiscuous mode: ip link set eth0 promisc on (check for the “P” flag in netst…

maybe try another ethernet interface?