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

Add-ons Bindings
1

Hello,

I have the problem that the rollershutter states will not updated when there are changes in the KNX bus.

With an KNX App on my smartphone I can see the events with the BUS-monitor.
With a tracedump I have checked that the raspy get the igmp messages, too.

I have an KNX IP Gateway in Router Mode for communication between ETS and the Smartphone. Router mode with openhab works fine, too. Lights switch on/off and shutters go up and down by openhab. But I get no feedback from the bus.

Log Entrys for KNX in Debug Mode:
[DEBUG] [.o.b.knx.internal.KNXActivator:31 ] - KNX binding has been started.
[DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘gH_EG_KR_R1 (Type=RollershutterItem, State=Uninitialized)’ with ‘KNXGenericBindingProvider’ reader.

[DEBUG] [.b.knx.internal.bus.KNXBinding:71 ] - Calimero library version 2.2.0-alpha
[DEBUG] [.k.i.bus.KNXBusReaderScheduler:52 ] - Starting reader task.
[DEBUG] [.k.i.bus.KNXBusReaderScheduler:56 ] - Starting schedule executor.
[DEBUG] [.KNXBindingDatapointReaderTask:58 ] - Autorefresh: Waiting for new item in reader queue
[DEBUG] [b.k.i.connection.KNXConnection:296 ] - KNXBinding configuration present. Setting up KNX bus connection.
[DEBUG] [b.k.i.connection.KNXConnection:408 ] - Not connected yet. Trying to connect.
[INFO ] [b.k.i.connection.KNXConnection:212 ] - Established connection to KNX bus on 224.0.23.12:3671 in mode ROUTER.
[DEBUG] [.k.i.bus.KNXBusReaderScheduler:147 ] - Datapoint ‘gH_EG_KR_R1’: one time reading scheduled.
[DEBUG] [.KNXBindingDatapointReaderTask:60 ] - Autorefresh: got new item gH_EG_KR_R1 in reader queue
[DEBUG] [.KNXBindingDatapointReaderTask:64 ] - Autorefresh: Trying to read form KNX bus: state DP 11/2/122 gH_EG_KR_R1, DPT main 0 id 5.001, low priority
[DEBUG] [.KNXBindingDatapointReaderTask:92 ] - Autorefresh: Sending read request to KNX for item ‘gH_EG_KR_R1’ DPT ‘5.001’
[DEBUG] [b.k.i.connection.KNXConnection:419 ] - Success: connected.
[DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
[WARN ] [.KNXBindingDatapointReaderTask:103 ] - Autorefresh: Cannot read value for item ‘gH_EG_KR_R1’ from KNX bus: timeout waiting for group read response: timeout
[WARN ] [.KNXBindingDatapointReaderTask:127 ] - Autorefresh: Remaining retries for address ‘11/2/122’ = ‘0’
[DEBUG] [.KNXBindingDatapointReaderTask:70 ] - Autorefresh: DatapointReaderTask Waiting 50 msecs to prevent KNX bus overload
[DEBUG] [.KNXBindingDatapointReaderTask:58 ] - Autorefresh: Waiting for new item in reader queue

If I switched off knx:ignorelocalevents in openhab.cfg I found this entry in the log files:

[DEBUG] [.b.knx.internal.bus.KNXBinding:169 ] - Received groupWrite Event.
[WARN ] [.b.knx.internal.bus.KNXBinding:172 ] - Ignoring local Event, received from my local Source address 15.15.250 for Group address 11/2/122.
[WARN ] [.KNXBindingDatapointReaderTask:103 ] - Autorefresh: Cannot read value for item ‘gH_EG_KR_R1’ from KNX bus: timeout waiting for group read response: timeout

Maybe,I think, this will be the messages with the state updates. The GA is one of outsending states if states changed. But why have they been ignored? What is wrong on my configuration or what have I forgotten to config?
Please help me. I have searched for two days in the web and cannot find any hint what I have to change.

Kind Regard
Andreas

2

Show us your items (and OH1 knx:) config to see if there is something wrong there.

The issue appears only for the Rollershutters or for the Light statuses also?

One thing that maybe wrong would be the Group Address settings in your items for the Status GAs

Since the telegrams reach OH1 but OH1 ignores them and times out waiting for a response
 I can only think of that


Also, try to set the knx:busaddr= to something different (change it from 15.15.250 to some other number like 2.2.2) and see if this helps.

3

Ok, yes that’s important:
Items config like this for:
Rollershutters:
Rollershutter gH_EG_KR_R1 "W Kitchen [%d %%]" (gH_EG_KR, gH_AL_RL_EG_KR) {knx="1.008:3/2/120,1.010:3/2/121,5.001:3/2/122+<5.001:11/2/122"}3/2/120 "Up/Down"
3/2/121 "Move/Stop"3/2/122 "Position"
11/2/122 "Position State" Lamps:Switch gH_EG_KR_LA “Central Light” (gH_EG_KR) {knx=“1.001:2/2/52+<1.001:2/2/57”}
2/2/52 "On/Off"2/2/57 “State”

OH Config:
[INFO ] [.o.core.internal.CoreActivator] - openHAB runtime has been started (v1.8.3).
All Bindings are only get by apt-get.
General:
security:netmask=192.168.78.0/24#servicediscovery:bind_address=127.0.0.1

KNX:
knx:ip=224.0.23.12knx:busaddr=15.15.250
#knx:ignorelocalevents=trueknx:type=ROUTER
knx:port=3671knx:localIp=192.168.78.26 #Local IP of Raspi in the network
#knx:serialPort=#knx:pause=
knx:timeout=5000knx:readRetries=1
#knx:autoReconnectPeriod=30#knx:maxRefreshQueueEntries=
#knx:numberOfThreads=#knx:scheduledExecutorServiceShutdownTimeoutString=

The issue is for all incoming messages from KNX Window Contacts, Lights, Rollershutters 

It looks like all incoming messages are ignored. Need I a daemon like eibd? I don’t think so.

My network configuration for eth0:
[Match]Name=eth*

[Network]Address=192.168.78.26/24
Gateway=192.168.78.1DNS=192.168.78.1/24

On other devices I get the state messages like the app “KNX Controller” for android. If I switch the Router mode to tunnel the same behavior appears.
I think there is a problem in config between the network config for eth and oh, that they matching not correct.

I’m sorry, but the change of the knx:busaddr don’t helped


Kind Regard
Andreas

4

Nice and clean items config
 I don’t see anything wrong in your items definitions


Your knx settings look correct also


I really can’t see why the KNX Binding on OH1 is timing out on the bus responses


You don’t need another daemon (eibs/knxd)
 It should work properly with only the KNX Binding.

I would recommend to check the Filter Table on your KNXnet/IP Router but you wrote that the status telegrams reach your raspy


Just for testing: try without the Data Types in your items:

Rollershutter gH_EG_KR_R1 "W Kitchen [%d %%]" (gH_EG_KR, gH_AL_RL_EG_KR) {knx="3/2/120,3/2/121,3/2/122+<11/2/122"}

I don’t think that this will help
 but you never know :slight_smile:

Other than that
 I don’t know what to recommend 


More trace logs on both the KNX binding as well as the calimero library may help to identify the problem


5

Thanks for helping.
I insered this into logback.xml:
<logger name="tuwien.auto.calimero" level="TRACE" />
<logger name="org.openhab.binding.knx" level="TRACE" />
You are right, there is no change if I use the item without the Data Types.

[DEBUG] [.o.b.knx.internal.KNXActivator] - KNX binding has been started.
[TRACE] [.o.b.k.i.dpt.KNXCoreTypeMapper] - toTypeClass looking for dptId = 1.001
2


[TRACE] [.o.b.k.i.dpt.KNXCoreTypeMapper] - toTypeClass looking for dptId = 5.001
[TRACE] [.b.knx.internal.bus.KNXBinding] - allBindingsChanged() msg received.
[DEBUG] [.b.knx.internal.bus.KNXBinding] - Calimero library version 2.2.0-alpha
[TRACE] [.b.knx.internal.bus.KNXBinding] - KNXBinding: activating
[TRACE] [.k.i.bus.KNXBusReaderScheduler] - Starting auto refresh scheduler
[DEBUG] [.k.i.bus.KNXBusReaderScheduler] - Starting reader task.
[DEBUG] [.k.i.bus.KNXBusReaderScheduler] - Starting schedule executor.
[DEBUG] [.KNXBindingDatapointReaderTask] - Autorefresh: Waiting for new item in reader queue
[DEBUG] [b.k.i.connection.KNXConnection] - KNXBinding configuration present. Setting up KNX bus connection.
[DEBUG] [b.k.i.connection.KNXConnection] - Not connected yet. Trying to connect.
[INFO ] [tuwien.auto.calimero ] - [ManagedService Update Queue] KNXnet/IP Routing 224.0.23.12:3671: multicast loopback mode enabled
[INFO ] [b.k.i.connection.KNXConnection] - Established connection to KNX bus on 224.0.23.12:3671 in mode ROUTER.
[TRACE] [.b.knx.internal.bus.KNXBinding] - connectionEstablished() msg received. Initializing readable DPs.
[DEBUG] [.k.i.bus.KNXBusReaderScheduler] - Datapoint ‘gH_EG_ED_R1’: one time reading scheduled.
[DEBUG] [.KNXBindingDatapointReaderTask] - Autorefresh: got new item gH_EG_ED_R1 in reader queue
[DEBUG] [.k.i.bus.KNXBusReaderScheduler] - Datapoint ‘gH_EG_KR_R1’: one time reading scheduled.
[DEBUG] [.k.i.bus.KNXBusReaderScheduler] - Datapoint ‘gH_EG_BW_R1’: one time reading scheduled.
[DEBUG] [.KNXBindingDatapointReaderTask] - Autorefresh: Trying to read form KNX bus: state DP 11/2/122 gH_EG_ED_R1, DPT main 0 id 5.001, low priority
[DEBUG] [.KNXBindingDatapointReaderTask] - Autorefresh: Sending read request to KNX for item ‘gH_EG_ED_R1’ DPT ‘5.001’
[DEBUG] [b.k.i.connection.KNXConnection] - Success: connected.
[INFO ] [tuwien.auto.calimero ] - [KNXBinding/DatapointReaderTask] link 224.0.23.12:3671: send message to 11/2/122, wait for confirmation
[DEBUG] [tuwien.auto.calimero ] - [KNXBinding/DatapointReaderTask] link 224.0.23.12:3671: cEMI L-Data.ind from 2.2.2 to 11/2/122, low priority hop count 6 repeat tpdu 00 00
[DEBUG] [tuwien.auto.calimero ] - [KNXBinding/DatapointReaderTask] KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame, non-blocking, attempt 1
[DEBUG] [tuwien.auto.calimero ] - [KNXBinding/DatapointReaderTask] link 224.0.23.12:3671: send to 11/2/122 succeeded
[DEBUG] [tuwien.auto.calimero ] - [KNXBinding/DatapointReaderTask] process link 224.0.23.12:3671: sent group read request to 11/2/122
[INFO ] [tuwien.auto.calimero ] - [KNXnet/IP receiver] link 224.0.23.12:3671: indication from 2.2.2
[DEBUG] [.b.knx.internal.bus.KNXBinding] - Received groupWrite Event.
[WARN ] [.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item ‘gH_EG_ED_R1’ from KNX bus: timeout waiting for group read response: timeout
[INFO ] [tuwien.auto.calimero ] - [KNXBinding/DatapointReaderTask] process link 224.0.23.12:3671: timeout waiting for group read response
[WARN ] [.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address ‘11/2/122’ = ‘0’
[DEBUG] [.KNXBindingDatapointReaderTask] - Autorefresh: DatapointReaderTask Waiting 50 msecs to prevent KNX bus overload

**Next Item same behavior:
[DEBUG] [.KNXBindingDatapointReaderTask] - Autorefresh: Waiting for new item in reader queue
[DEBUG] [.KNXBindingDatapointReaderTask] - Autorefresh: got new item gH_EG_KR_R1 in reader queue
[DEBUG] [.KNXBindingDatapointReaderTask] - Autorefresh: Trying to read form KNX bus: state DP 11/2/132 gH_EG_KR_R1, DPT main 0 id 5.001, low priority
[DEBUG] [.KNXBindingDatapointReaderTask] - Autorefresh: Sending read request to KNX for item ‘gH_EG_KR_R1’ DPT ‘5.001’
[INFO ] [tuwien.auto.calimero ] - [KNXBinding/DatapointReaderTask] link 224.0.23.12:3671: send message to 11/2/132, wait for confirmation



**For example I switched a light on:
[TRACE] [.b.knx.internal.bus.KNXBinding] - Received command (item=‘gH_OG_K1_LD’, command=‘ON’)
[TRACE] [.o.b.k.i.dpt.KNXCoreTypeMapper] - toTypeClass looking for dptId = 1.001
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: Boolean (main type 1) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: Boolean controlled (main type 2 loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: 3 Bit controlled (main type 3) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: 8 Bit unsigned value (main type 5) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: 2 octet unsigned value (main type 7) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: 2 octet float value (main type 9) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: Time (main type 10) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: Date (main type 11) loaded
[DEBUG] [.b.knx.internal.bus.KNXBinding] - Received groupWrite Event.
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: 4 octet unsigned value (main type 12) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: 4 octet signed value (main type 13) loaded
[DEBUG] [.b.knx.internal.bus.KNXBinding] - Wrote value ‘ON’ to datapoint ‘command DP 2/3/30 gH_OG_K1_LD, DPT main 0 id 1.001, low priority’
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: 4 octet float value (main type 14) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: String (main type 16) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: Scene number (main type 17) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: Scene control (main type 18) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: Date with time (main type 19) loaded
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] DPTXlator: RGB color value (main type 232) loaded
[INFO ] [tuwien.auto.calimero ] - [qtp9005330-97] link 224.0.23.12:3671: send message to 2/3/30, wait for confirmation
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] link 224.0.23.12:3671: cEMI L-Data.ind from 2.2.2 to 2/3/30, low priority hop count 6 repeat tpdu 00 81
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame, non-blocking, attempt 1
[INFO ] [tuwien.auto.calimero ] - [KNXnet/IP receiver] link 224.0.23.12:3671: indication from 2.2.2
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] link 224.0.23.12:3671: send to 2/3/30 succeeded
[TRACE] [.o.b.k.i.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
[DEBUG] [tuwien.auto.calimero ] - [qtp9005330-97] process link 224.0.23.12:3671: group write to 2/3/30 succeeded
[TRACE] [.b.knx.internal.bus.KNXBinding] - Added event (item=‘gH_OG_K1_LD’, type=‘ON’) to the ignore event list
[TRACE] [.b.knx.internal.bus.KNXBinding] - Received command (item=‘gH_OG_K1_LD’, command=‘ON’)
[TRACE] [.b.knx.internal.bus.KNXBinding] - We received this event (item=‘gH_OG_K1_LD’, state=‘ON’) from KNX, so we don’t send it back again -> ignore!
[TRACE] [.b.knx.internal.bus.KNXBinding] - Processed event (item=‘gH_OG_K1_LD’, type=‘ON’, destination=‘2/3/30’)

How can I check my network config if there is all correct and nothing is missing for a correct working?
I will do new tracedumps to isolate IGMP messages and look int them.

6

I found out something interesting point during tcpdump running.
So long tcpdump is running openhab works fine with the reponses:
[DEBUG] [.b.knx.internal.bus.KNXBinding] - Received groupWrite Event.
[INFO ] [tuwien.auto.calimero ] - [KNXnet/IP receiver] link 224.0.23.12:3671: indication from 1.1.12
[TRACE] [.o.b.k.i.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 5.001
[INFO ] [tuwien.auto.calimero ] - [KNXnet/IP receiver] link 224.0.23.12:3671: indication from 1.1.12
[TRACE] [.o.b.k.i.dpt.KNXCoreTypeMapper] - toTypeClass looking for dptId = 5.001
[TRACE] [.b.knx.internal.bus.KNXBinding] - Added event (item=‘gH_EG_SZ_R1’, type=‘0’) to the ignore event list
[DEBUG] [.b.knx.internal.bus.KNXBinding] - Received update (item=‘gH_EG_SZ_R1’, state=‘0’)
[TRACE] [.b.knx.internal.bus.KNXBinding] - We received this event (item=‘gH_EG_SZ_R1’, state=‘0’) from KNX, so we don’t send it back again -> ignore!
[TRACE] [.b.knx.internal.bus.KNXBinding] - Processed event (item=‘gH_EG_SZ_R1’, type=‘0’, destination=‘11/2/152’)
[DEBUG] [.b.knx.internal.bus.KNXBinding] - Received groupWrite Event.
[DEBUG] [.b.knx.internal.bus.KNXBinding] - Received telegram for unknown group address 11/2/150

If tcpdump is finished or stopped on raspi I never get the responses.

So the binding works fine, i think. Great.
But what is wrong or missing in networkconfig for this behavior?

7

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 netstat)

Not sure if this is related to your networking issue


1 Like
8

netstat -i
Kernel-Schnittstellentabelle
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 20831 0 491 0 7154 0 0 0 BMRU
lo 65536 0 151887 0 0 0 151887 0 0 0 LRU

ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether MAC brd ff:ff:ff:ff:ff:ff
inet 192.168.78.26/24 brd 192.168.78.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 IPv6 scope global deprecated mngtmpaddr dynamic
valid_lft 4568sec preferred_lft 0sec
inet6 fe80::2e0:4cff:fe53:4458/64 scope link
valid_lft forever preferred_lft forever

ip link set eth0 promisc on

netstat -i
Kernel-Schnittstellentabelle
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 21092 0 491 0 7261 0 0 0 BMPRU
lo 65536 0 154073 0 0 0 154073 0 0 0 LRU

Thank you very much. Thats it. Now states are changed actualy.

I will me inform now about this mode. Thank you.

1 Like
9

You should find the root cause of this networking issue and try to resolve it


Running your eth0 in promiscuous mode all the time is not really recommended


Try rebooting your KNXnet/IP Router and/or your network switch

Maybe your raspy’s MAC Address is cached wrongly on them. (by the way: did you change the raspy’s MAC by any chance?)

1 Like
10

Ok,

I switched this mode Off. But now I know were I can look for.
I don’t do any changes on the MAC Address.
First Time after installing the OS I had a problem with the eth0 and the wlan0.
There was the eth0 reachable by the address of the wlan0.
I don’t know why and after a rebot all was normal and as expectet.

I see, I have to look for.
Thank you very much.

1 Like
11

I found out, that my cheap China Adapter was the root cause.

I tested the sd card in a raspi B with ether on board. No problem during running. KNX worked as aspected.
I get an other otg LAN Addapter from a colleague and this works without problems on my zero, too.

I searched about my otg LAN adapter and his components and found a lot of errors.

Now I’m looking for a new otg LAN Adapter. Thank you very much. Without this help, I searched much time longer for the root cause. I’m searched on the wrong place.
Topic can be closed.

1 Like