OH2.3 with KNX2 - not connecting to KNX Bus

knx
knx2
Tags: #<Tag:0x00007fd314387658> #<Tag:0x00007fd3143874a0>

(Andreas) #1

Hello,

since quite some time I am really struggeling with setting up OH2.3 & KNX2. With the same setup, the binding sometimes finds the connection to the KNX Bus and sometimes it doesn’t.
The same setup with the KNX1 Binding always finds the conneciton - but there I do have the echos.

My Setup:

  • Running OH2.3 in Docker within Synology DS218+
  • KNX2 Binding
  • MDT IP Router

My Binding Setup in .things file:

Bridge knx:ip:bridge  [ 
    ipAddress="192.168.178.29", 
    portNumber=3671, 
    localIp="192.168.178.55", 
    type="TUNNEL", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=1,
    localSourceAddr="1.0.242"
] 

The logging in Karaf:
Here it seems to me that the Bridge tries to connect to the bus over and over again - but I am not sure how to interpret the Trace and where to touch to fix this?!

09:42:24.641 [TRACE] [calimero.mgmt.TL 192.168.178.29:3671 ] - sending data connected to 1.0.16, attempt 2
09:42:24.643 [DEBUG] [calimero.link.192.168.178.29:3671    ] - send (wait for confirmation) 1.0.242->1.0.16 L_Data.req, low priority hop count 6 repeat, tpdu 43 00
09:42:24.644 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - sending cEMI frame seq 71, WaitForCon, attempt 1 (channel 2) 06 10 04 20 00 15 04 02 47 00 11 00 bc 60 10 f2 10 10 01 43 00
09:42:24.647 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - received service ack 71 from /192.168.178.29:3671 (channel 2)
09:42:24.667 [DEBUG] [Xnet/IP Tunneling 192.168.178.29:3671] - received request seq 104 (channel 2) cEMI L-Data.con 1.0.242->1.0.16
09:42:24.669 [DEBUG] [calimero.link.192.168.178.29:3671    ] - confirmation of 1.0.16
09:42:24.671 [TRACE] [calimero.link.192.168.178.29:3671    ] - send 1.0.242->1.0.16 succeeded
09:42:27.672 [TRACE] [calimero.mgmt.TL 192.168.178.29:3671 ] - sending data connected to 1.0.16, attempt 3
09:42:27.674 [DEBUG] [calimero.link.192.168.178.29:3671    ] - send (wait for confirmation) 1.0.242->1.0.16 L_Data.req, low priority hop count 6 repeat, tpdu 43 00
09:42:27.676 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - sending cEMI frame seq 72, WaitForCon, attempt 1 (channel 2) 06 10 04 20 00 15 04 02 48 00 11 00 bc 60 10 f2 10 10 01 43 00
09:42:27.679 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - received service ack 72 from /192.168.178.29:3671 (channel 2)
09:42:27.696 [DEBUG] [Xnet/IP Tunneling 192.168.178.29:3671] - received request seq 105 (channel 2) cEMI L-Data.con 1.0.242->1.0.16
09:42:27.702 [DEBUG] [calimero.link.192.168.178.29:3671    ] - confirmation of 1.0.16
09:42:27.704 [TRACE] [calimero.link.192.168.178.29:3671    ] - send 1.0.242->1.0.16 succeeded
09:42:30.706 [TRACE] [calimero.mgmt.TL 192.168.178.29:3671 ] - sending data connected to 1.0.16, attempt 4
09:42:30.708 [DEBUG] [calimero.link.192.168.178.29:3671    ] - send (wait for confirmation) 1.0.242->1.0.16 L_Data.req, low priority hop count 6 repeat, tpdu 43 00
09:42:30.710 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - sending cEMI frame seq 73, WaitForCon, attempt 1 (channel 2) 06 10 04 20 00 15 04 02 49 00 11 00 bc 60 10 f2 10 10 01 43 00
09:42:30.712 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - received service ack 73 from /192.168.178.29:3671 (channel 2)
09:42:30.729 [DEBUG] [Xnet/IP Tunneling 192.168.178.29:3671] - received request seq 106 (channel 2) cEMI L-Data.con 1.0.242->1.0.16
09:42:30.731 [DEBUG] [calimero.link.192.168.178.29:3671    ] - confirmation of 1.0.16
09:42:30.733 [TRACE] [calimero.link.192.168.178.29:3671    ] - send 1.0.242->1.0.16 succeeded
09:42:31.748 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - received request seq 107 (channel 2) cEMI 29 00 bc e0 10 62 35 36 03 00 80 00 7f```

Also in VSCode - the Things don’t appear as connected:

Things

Not sure if it’s relevant - but I also have another effect - for some reason whenever I restart OH2.3 then the timezone defaults back to UTC.

Can anyone help me with this?


(Andreas) #2

Hello,

not sure if that was the reason - but I was researching the comminity a bit and found this post by @Udo_Hartmann
https://community.openhab.org/t/knx-2-0-configuration-not-working/45227/3?u=drcoffee

Thus I updated my KNX Bridge Config in the .things file with the

autoReconnectPeriod=60,

So if this is really the fix - then it would be great if someone could update the official KNX2 Doku:
https://www.openhab.org/addons/bindings/knx/#things

My (currently) working KNX Config now looks as follows:

Bridge knx:ip:bridge  [ 
    ipAddress="192.168.178.29", 
    portNumber=3671, 
    localIp="192.168.178.55", 
    type="TUNNEL", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=60,
    localSourceAddr="1.0.242"
] 

But my I still ask someone “Knowledgeable” to review my problem above if you find anything “strange” looking?!

thanks


No sending from KNX2 binding
(Andreas) #3

Hello,

bad news - after restarting my docker container I now get the same log entries again - which I now interpret as that Openhab is reading from the KNX Bus - some of the read requests I also see in the ETS5 Log others not.

But overall it appears that OH2.3 is reading extremely slow which I also see when I turn on a light - the light reacts only after ~30seconds.

Another thing - if I check the Web Interface of my MDT Router I see that the OH picked up the first free Bus Adress (1.0.240) instead of the configured 1.0.243.

pretty strange behavior?!

Here’s an extract from the Log

14:11:33.578 [TRACE] [calimero.mgmt.TL 192.168.178.29:3671 ] - created co destination for 1.0.33
14:11:33.585 [DEBUG] [calimero.link.192.168.178.29:3671    ] - send (wait for confirmation) 1.0.242->1.0.33 L_Data.req, system priority hop count 6 repeat, tpdu 80
14:11:33.599 [DEBUG] [Xnet/IP Tunneling 192.168.178.29:3671] - received request seq 111 (channel 7) cEMI L-Data.con 1.0.242->1/3/49
14:11:33.601 [DEBUG] [calimero.link.192.168.178.29:3671    ] - confirmation of 1/3/49
14:11:33.602 [TRACE] [calimero.link.192.168.178.29:3671    ] - send 1.0.242->1/3/49 succeeded
14:11:33.604 [TRACE] [o.process.process 192.168.178.29:3671] - sent group read request to 1/3/49
14:11:33.606 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - sending cEMI frame seq 55, WaitForCon, attempt 1 (channel 7) 06 10 04 20 00 14 04 07 37 00 11 00 b0 60 10 f2 10 21 00 80
14:11:33.609 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - received service ack 55 from /192.168.178.29:3671 (channel 7)
14:11:33.624 [DEBUG] [Xnet/IP Tunneling 192.168.178.29:3671] - received request seq 112 (channel 7) cEMI L-Data.con 1.0.242->1.0.33
14:11:33.630 [DEBUG] [calimero.link.192.168.178.29:3671    ] - confirmation of 1.0.33
14:11:33.633 [TRACE] [calimero.link.192.168.178.29:3671    ] - send 1.0.242->1.0.33 succeeded
14:11:33.635 [TRACE] [calimero.mgmt.TL 192.168.178.29:3671 ] - connected with 1.0.33
14:11:33.636 [TRACE] [calimero.mgmt.TL 192.168.178.29:3671 ] - sending data connected to 1.0.33, attempt 1
14:11:33.637 [DEBUG] [calimero.link.192.168.178.29:3671    ] - send (wait for confirmation) 1.0.242->1.0.33 L_Data.req, low priority hop count 6 repeat, tpdu 43 00
14:11:33.639 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - sending cEMI frame seq 56, WaitForCon, attempt 1 (channel 7) 06 10 04 20 00 15 04 07 38 00 11 00 bc 60 10 f2 10 21 01 43 00
14:11:33.642 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - received service ack 56 from /192.168.178.29:3671 (channel 7)
14:11:33.644 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - received request seq 113 (channel 7) cEMI 29 00 bc e0 10 07 0b 31 02 00 40 00
14:11:33.649 [DEBUG] [calimero.link.192.168.178.29:3671    ] - indication 1.0.7->1/3/49 L_Data.ind, low priority hop count 6, tpdu 00 40 00
14:11:33.653 [INFO ] [smarthome.event.ItemStateChangedEvent] - AchterDimmaktor_DimOGMagdalena changed from NULL to 0
14:11:33.667 [DEBUG] [Xnet/IP Tunneling 192.168.178.29:3671] - received request seq 114 (channel 7) cEMI L-Data.con 1.0.242->1.0.33
14:11:33.668 [DEBUG] [calimero.link.192.168.178.29:3671    ] - confirmation of 1.0.33
14:11:33.670 [TRACE] [calimero.link.192.168.178.29:3671    ] - send 1.0.242->1.0.33 succeeded
14:11:36.672 [TRACE] [calimero.mgmt.TL 192.168.178.29:3671 ] - sending data connected to 1.0.33, attempt 2
14:11:36.674 [DEBUG] [calimero.link.192.168.178.29:3671    ] - send (wait for confirmation) 1.0.242->1.0.33 L_Data.req, low priority hop count 6 repeat, tpdu 43 00
14:11:36.675 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - sending cEMI frame seq 57, WaitForCon, attempt 1 (channel 7) 06 10 04 20 00 15 04 07 39 00 11 00 bc 60 10 f2 10 21 01 43 00
14:11:36.676 [TRACE] [Xnet/IP Tunneling 192.168.178.29:3671] - received service ack 57 from /192.168.178.29:3671 (channel 7)
14:11:36.694 [DEBUG] [Xnet/IP Tunneling 192.168.178.29:3671] - received request seq 115 (channel 7) cEMI L-Data.con 1.0.242->1.0.33
14:11:36.695 [DEBUG] [calimero.link.192.168.178.29:3671    ] - confirmation of 1.0.33
14:11:36.697 [TRACE] [calimero.link.192.168.178.29:3671    ] - send 1.0.242->1.0.33 succeeded

Also the KNX Things in VSCode won’t get back to online?!

Things2

So for now - I have to go back to my KNX1 installation with the many echos :confused:

can anyone help?


(markus_pfleger) #4

Hi,

I had a similar problem, so switches reacted very slow, I got exceptions,… (see KNX2 sending commands twice which leads to errors and slowdowns)

In my environment I had a wrong localSourceAddr configured. Maybe double check with what your IP Router says (I got the correct address through telnet).

Markus


(Udo Hartmann) #5

The first thing is, openHAB shall not use a physical address which is configured to another device - even the MDT Router should use its own addresses.
Second: If you are using da knx/IP Router, why not using ROUTER Mode? afaik this will work with much less problems (and even with knx1 without echoes)
For me the device ping works properly (well most time…) but I don’t know why :wink: maybe switching that part off would give you a better responsiveness.


(Andreas) #6

Hi Markus,

thanks a lot for your help! Actually you appeared to be right - I used a “free tunneling adress”( 1.0.242).

So when I changed my knx.things to the 1.0.240 it suddenly worked quickly.

BUT - then I tried Udo’s suggestion (router) which didn’t work, then I changed back to TUNNEL and once the sudden I was back on “slow mode”

Now it’s this - and back slow again?!

Bridge knx:ip:bridge  [ 
    ipAddress="192.168.178.29", 
    portNumber=3671, 
    localIp="192.168.178.55", 
    type="TUNNEL", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=60,
    localSourceAddr="1.0.240" // was 1.0.242
] 

(Andreas) #7

Hello Udo,

thanks a lot for your help - I guess I have to appologize before I even write since I have quite some problems understanding what you are trying to tell me…

Could you elaborate what you mean by

openHAB shall not use a physical address which is configured to another device

About the router mode - I tried to reconfig to Router mode:

Bridge knx:ip:bridge  [ 
    ipAddress="224.0.23.12", 
    portNumber=3671, 
    localIp="192.168.178.55", 
    type="ROUTER", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=60,
    localSourceAddr="1.0.240" 
] 

With this I get in ETS5 Diagnose the following entries:

|#|Zeit|Dienst|Flags |Prio|Quelladresse|Quellname|Zieladresse|Zielname|Rout|Typ|DPT|Info|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|599|11.07.2018 21:16:32,690|vom Bus||Niedrig|1.0.18|EG Flur Beweg Pille NEU|1.0.240|Router Tunnel 1|6|DeviceDescriptorResponse (S=0)||DescriptorType=0, DescriptorData=07 05|
|600|11.07.2018 21:16:32,733|vom Bus||System|1.0.18|EG Flur Beweg Pille NEU|1.0.240|Router Tunnel 1|6|T_ACK (S=0)|||
|601|11.07.2018 21:16:35,687|vom Bus||Niedrig|1.0.18|EG Flur Beweg Pille NEU|1.0.240|Router Tunnel 1|6|DeviceDescriptorResponse (S=0)||DescriptorType=0, DescriptorData=07 05|
|602|11.07.2018 21:16:35,732|vom Bus||System|1.0.18|EG Flur Beweg Pille NEU|1.0.240|Router Tunnel 1|6|T_ACK (S=0)|||
|603|11.07.2018 21:16:38,687|vom Bus||Niedrig|1.0.18|EG Flur Beweg Pille NEU|1.0.240|Router Tunnel 1|6|DeviceDescriptorResponse (S=0)||DescriptorType=0, DescriptorData=07 05|
|604|11.07.2018 21:16:38,736|vom Bus||System|1.0.18|EG Flur Beweg Pille NEU|1.0.240|Router Tunnel 1|6|T_ACK (S=0)|||
|605|11.07.2018 21:16:41,679|vom Bus||System|1.0.18|EG Flur Beweg Pille NEU|1.0.240|Router Tunnel 1|6|T_Disconnect|||
|606|11.07.2018 21:16:41,769|vom Bus||System|1.0.33|Bewegungsmelder Flur OG|1.0.240|Router Tunnel 1|6|T_ACK (S=0)|||
|607|11.07.2018 21:16:41,795|vom Bus||Niedrig|1.0.33|Bewegungsmelder Flur OG|1.0.240|Router Tunnel 1|6|DeviceDescriptorResponse (S=0)||DescriptorType=0, DescriptorData=07 B0|
|608|11.07.2018 21:16:44,749|vom Bus||System|1.0.33|Bewegungsmelder Flur OG|1.0.240|Router Tunnel 1|6|T_ACK (S=0)|||
|609|11.07.2018 21:16:46,051|vom Bus||Niedrig|1.0.98|Wetterstation|6/5/54|Wind Gesschwindigkeit|6|GroupValueWrite|  9.005 Geschwindigkeit (m/s)|00 3A | 0,58 m/s|

Also tried to do a “Minimum” Router Config:

Bridge knx:ip:bridge  [ 
    type="ROUTER"
] 

This resulted pretty much in the same ETS5 responses:

#	Zeit	Dienst	Flags 	Prio	Quelladresse	Quellname	Zieladresse	Zielname	Rout	Typ	DPT	Info
699	11.07.2018 21:18:55,908	vom Bus		System	0.0.0	-	1.0.5	SCN-IP100.02 IP Router mit Email Funktion	5	T_Connect		
700	11.07.2018 21:18:55,926	vom Bus		Niedrig	0.0.0	-	1.0.5	SCN-IP100.02 IP Router mit Email Funktion	5	DeviceDescriptorRead (S=0)		DescriptorType=0
701	11.07.2018 21:18:55,934	vom Bus		System	0.0.0	-	1.0.5	SCN-IP100.02 IP Router mit Email Funktion	5	T_Disconnect		
702	11.07.2018 21:18:55,942	vom Bus		System	0.0.0	-	1.0.5	SCN-IP100.02 IP Router mit Email Funktion	5	T_ACK (S=0)		
703	11.07.2018 21:18:55,945	vom Bus		System	0.0.0	-	1.0.5	SCN-IP100.02 IP Router mit Email Funktion	5	T_Disconnect		
704	11.07.2018 21:18:55,950	vom Bus		System	0.0.0	-	1.0.5	SCN-IP100.02 IP Router mit Email Funktion	5	T_Disconnect		

I have had this Problem before - somehow I also couldn’t get Router mode to work with the KNX1 Binding.
Do you see anything that I do wrong?

Lastly… what do you mean by

device ping works properly (well most time…)

I can’t identify where I do ping my devices and where to turn that off?!

Again - very sorry if my questions are stupid… could you again try to point me in the right direction?

Additional note - I tried in my KNX1 Installation the Router Mode with the following KNX.cfg
But this didn’t even get me any connection to the KNX Bus

busaddr=1.0.240
ignorelocalevents=true
type=ROUTER
localIp=224.0.23.12

whereas the TUNNEL Mode gives me a connection…

ip=192.168.178.29
busaddr=1.0.240
ignorelocalevents=true
type=TUNNEL
port=3671
localIp=192.168.178.55

but with the repeated echos…

#	Zeit	Dienst	Flags 	Prio	Quelladresse	Quellname	Zieladresse	Zielname	Rout	Typ	DPT	Info
245	11.07.2018 21:37:05,901	vom Bus		Niedrig	1.0.98	Wetterstation	6/5/54	Wind Gesschwindigkeit	6	GroupValueWrite	  9.005 Geschwindigkeit (m/s)	00 2F | 0,47 m/s
246	11.07.2018 21:37:05,918	vom Bus		Niedrig	1.0.240	Router Tunnel 1	6/5/54	Wind Gesschwindigkeit	6	GroupValueWrite	  9.005 Geschwindigkeit (m/s)	00 2F | 0,47 m/s
247	11.07.2018 21:37:12,960	vom Bus		Niedrig	1.0.240	Router Tunnel 1	4/0/11	EG Status einzelner Kanal Komfort oder Standy	6	GroupValueRead		
248	11.07.2018 21:37:13,039	vom Bus		Niedrig	1.0.12	Heizungsaktor EG	4/0/11	EG Status einzelner Kanal Komfort oder Standy	6	GroupValueResponse	  16.000 Zeichen (ASCII)	53 6F 20 48 20 47 65 73 70 65 72 72 74 30 | So H Gesperrt0
249	11.07.2018 21:37:13,048	vom Bus		Niedrig	1.0.240	Router Tunnel 1	4/0/11	EG Status einzelner Kanal Komfort oder Standy	6	GroupValueWrite	  16.000 Zeichen (ASCII)	53 6F 20 48 20 47 65 73 70 65 72 72 74 30 | So H Gesperrt0
250	11.07.2018 21:37:13,096	vom Bus		Niedrig	1.0.240	Router Tunnel 1	4/0/21	OG Status einzelner Kanal Komfort oder Standy	6	GroupValueRead		
251	11.07.2018 21:37:13,172	vom Bus		Niedrig	1.0.13	Heizungsaktor OG	4/0/21	OG Status einzelner Kanal Komfort oder Standy	6	GroupValueResponse	  16.000 Zeichen (ASCII)	53 6F 20 48 20 47 65 73 70 65 72 72 74 30 | So H Gesperrt0
252	11.07.2018 21:37:13,185	vom Bus		Niedrig	1.0.240	Router Tunnel 1	4/0/21	OG Status einzelner Kanal Komfort oder Standy	6	GroupValueWrite	  16.000 Zeichen (ASCII)	53 6F 20 48 20 47 65 73 70 65 72 72 74 30 | So H Gesperrt0
253	11.07.2018 21:37:13,227	vom Bus		Niedrig	1.0.240	Router Tunnel 1	4/2/3	2.1-2-Erdgeschoss.Windfang-Heizung.HMDT-Heizen-MDT-Aktueller Sollwert	6	GroupValueRead		


(Angelos) #8

just a note: when using KNXv1 and ROUTER type, the localIp setting should be the local IP (192.168.178.55)
If you want to set the multicast address use: ip=224.0.23.12 (this is optional)

What is the problem when using KNXv2 and ROUTER mode?


(Udo Hartmann) #9

Sure. localSourceAddr should be a completely unused Address (for example 1.0.244 if this address is not occupied by another device) It should not be one of the tunnel addresses.

This may also be the cause of disconnection in ROUTER mode.

For Router mode, localIp is essential, so the minimum configuration would be

Bridge knx:ip:bridge  [ 
    type="ROUTER"
    localIp="192.168.178.55"
] 

while all other parameters may stay on default value.

When using the router mode, it is also essential to provide a “no filter” setting in the knx/IP-Router itself.

In question of pinging knx devices…
Given this configuration:

Bridge knx:ip:bridge  [ 
    type="ROUTER"
    localIp="192.168.178.55"
] 
    {
    Thing device generic [
        address="1.2.3",
        fetch=true,
        pingInterval=300,
        readInterval=3600
    ] {
            ...
    }
}

openHAB will

  • ping the device 1.2.3 every 300 Seconds, (disable by setting pingInterval=0)
  • will try to read additional information (such as ROM Mask, Manufacturer, Serial No…) (disable by setting fetch=false) and
  • try to read all channels which are configured as requestable every 3600 Seconds (disable by setting readInterval=0).

If pinging is disabled, the Thing will always be displayed as ONLINE, where the Thing may be displayed OFFLINE if pinging is enabled and is unsuccessful - but this won’t disturb communication compellingly (wow, always learning new english words… :wink: )


(markus_pfleger) #10

I have no router so I can say nothing to the router mode. But with the tunnel mode I had to enter the individual address which seems to be 1.0.0 in your case, not 1.0.140.


(Andreas) #11

Hello Udo, Hello Dim

@Udo_Hartmann
@Dim

thanks a lot for your help - your advise appears to work great - looks like learning english for you is easier than “openHABish” for me :slight_smile:.

I think the key was the:

essential to provide a “no filter” setting in the knx/IP-Router itself.

I now use the following .things config:

Bridge knx:ip:bridge  [ 
    type="ROUTER",
    localIp="192.168.178.55",
    localSourceAddr="1.0.244"
] 

Also I have disabled “ping” completely.

My Switches now react quickly and without Echos in ETS
So it appears now I can continue working on the functional side - one thing that looks funny is the ETS5 Log - I get a lot of grey entries…

On a sidenote - I also got the ROUTER mode working in my KNX1 installation - but I still have the many echos. But with KNX2 now functional I guess I will live with the echos for the short time until I have completed the migration to KNX2.

Thanks so much for your help!
Andreas


(Andreas) #12

Hello Markus,
thanks for your help - I switched in my KNX1 & 2 to 1.0.244 (an unused Adress) and this does the trick - together with turning off the filters in my KNX Router.

Andreas


(Udo Hartmann) #13

Yes, that’s correct, as ETS5 has no listed device for 1.0.244. If you want to get rid of the grey color, you can install a dummy device. On the other hand, you can see all openHAB data at once :wink:


(Angelos) #14

additionally, you could also use a dummy application and re-enable the filter on the KNX/IP Router :slight_smile:
It does takes more configuration work (in ETS to link all the GAs that you want to allow on the filter table to this new dummy app)


(Andreas) #15

Hello

after playing a little more with my now functioning KNX2 Binding, it appears that the Binding does not pickup all received GA values.

E.g. my Floor Heating - servermotor response:

Trigger from my Heating Actor - within ETS5:
Here’s the “GroupValueWrite” of 0% which I would expect to subsequently show up in my screenshot below?!

|#|Zeit|Dienst|Flags |Prio|Quelladresse|Quellname|Zieladresse|Zielname|Rout|Typ|DPT|Info|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|2423|13.07.2018 10:21:19,394|vom Bus||Niedrig|1.0.13|Heizungsaktor OG|4/3/21|3.3-3-Obergeschoss.Bad-OG-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|

Received by OH2.3 - KNX2:
Honestly I can not really interpret this response - I would have expected to read the 0%

10:21:19.419 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.13->4/3/21 L_Data.ind, low priority hop count 5, tpdu 00 80 00
10:21:19.420 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.13' to '4/3/21'

But nothing being displayed in OH:

My KNX.things entries:

Thing device OG_Heizungsaktor "OG Heizungsaktor" 
        [
            address="1.0.13",
            fetch=false,
            pingInterval=0,
            readInterval=3600
        ] 
        {  Type number : Heat_OG_Bad_Stellwert                     "Bad Stellmotor"            [ ga="5.001:<4/3/21" ]
         }

My KNX.items entry:

Number   OGHeizungsaktor_HeatOGBadStellwert                      "Bad Stellmotor"                     {channel="knx:device:bridge:OG_Heizungsaktor:Heat_OG_Bad_Stellwert"}

My KNX.sitemap entry:

Frame item=OGHeizungsaktor_HeatOGBadISTTemp {
				Setpoint item=OGHeizungsaktor_HeatOGBadSOLLTemp minValue=17 maxValue=25 step=0.5
				Text item=OGHeizungsaktor_HeatOGBadStellwert
			}

Do you guys see anything obvious - or do I have to go back to my Binding Config - maybe I made some config mistake there?


(Angelos) #16

edit: I don’t see any error…
there should be more log entries that can give us a hint…


(Andreas) #17

Hello Dim,

so after the weekend I now tried your advise - but unfortunately I do not get many entries in the log.
I did in Karaf:

Log:set TRACE org.openhab.binding.knx
Log:set TRACE calimero

And here’s the Screenshot of the Log and the ETS5 Side-by-side. You can see the values that are being written by the bus, and you see in the log the entries that these had been received - but nothing appears in the visu.
Also - wouldn’t I typically see the Status of each GA also in the log in cleartext (e.g. 18°C) - instead of the tpdu 00 80 00 or so…?

Here’s also a subset of readable Log file text and the corresponding ETS5 Text:

Logfile:

20:34:14.475 [INFO ] [smarthome.event.ItemStateChangedEvent] - ntp_ntp_local_dateTime changed from 2018-07-16T20:33:14.465+0200 to 2018-07-16T20:34:14.466+0200
20:34:14.478 [INFO ] [smarthome.event.ItemStateChangedEvent] - ntp_ntp_local_string changed from 2018-07-16 20:33:14 CEST to 2018-07-16 20:34:14 CEST
20:34:15.286 [INFO ] [smarthome.event.ItemStateChangedEvent] - Heizung_Aussen_Temperature changed from 19.699999999999999289457264239899814128875732421875 to 19.5
20:34:16.705 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.5->6/1/0 L_Data.ind, low priority hop count 5, tpdu 00 80 34 22 0f
20:34:16.705 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.5' to '6/1/0'
20:34:16.905 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.5->6/1/1 L_Data.ind, low priority hop count 5, tpdu 00 80 10 07 12
20:34:16.905 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.5' to '6/1/1'
20:34:17.105 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.5->6/1/2 L_Data.ind, low priority hop count 5, tpdu 00 80 76 07 10 34 22 0f 40 80
20:34:17.105 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.5' to '6/1/2'
20:34:18.918 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.98->6/5/54 L_Data.ind, low priority hop count 5, tpdu 00 80 00 27
20:34:18.918 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.98' to '6/5/54'
20:34:24.918 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.98->6/5/34 L_Data.ind, low priority hop count 5, tpdu 00 80 57 04
20:34:24.918 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.98' to '6/5/34'
20:34:35.948 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.12->4/2/51 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:35.948 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.12' to '4/2/51'
20:34:36.950 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.12->4/2/23 L_Data.ind, low priority hop count 5, tpdu 00 80 05 dc
20:34:36.950 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.12' to '4/2/23'
20:34:36.988 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.12->4/2/21 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:36.988 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.12' to '4/2/21'
20:34:37.950 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.12->4/2/3 L_Data.ind, low priority hop count 5, tpdu 00 80 05 78
20:34:37.950 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.12' to '4/2/3'
20:34:37.987 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.12->4/2/1 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:37.988 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.12' to '4/2/1'
20:34:38.947 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.12->4/2/41 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:38.947 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.12' to '4/2/41'
20:34:38.982 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.12->4/2/11 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:38.982 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.12' to '4/2/11'
20:34:44.630 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.13->4/3/11 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:44.630 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.13' to '4/3/11'
20:34:44.665 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.13->4/3/41 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:44.665 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.13' to '4/3/41'
20:34:45.633 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.13->4/3/33 L_Data.ind, low priority hop count 5, tpdu 00 80 07 08
20:34:45.633 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.13' to '4/3/33'
20:34:45.667 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.13->4/3/1 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:45.668 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.13' to '4/3/1'
20:34:45.703 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.13' to '4/3/31'
20:34:45.704 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.13->4/3/31 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:46.634 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.13->4/3/33 L_Data.ind, low priority hop count 5, tpdu 00 80 07 08
20:34:46.634 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.13' to '4/3/33'
20:34:46.668 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.13->4/3/51 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:46.669 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.13' to '4/3/51'
20:34:46.703 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.13->4/3/71 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:46.703 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.13' to '4/3/71'
20:34:46.907 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.98->6/5/55 L_Data.ind, low priority hop count 5, tpdu 00 80 0c 65
20:34:46.907 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.98' to '6/5/55'
20:34:47.630 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.13->4/3/61 L_Data.ind, low priority hop count 5, tpdu 00 80 00
20:34:47.630 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.13' to '4/3/61'
20:34:53.786 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.27->4/2/50 L_Data.ind, low priority hop count 5, tpdu 00 80 0c 8d
20:34:53.786 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.27' to '4/2/50'
20:35:00.913 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.98->6/5/0 L_Data.ind, low priority hop count 5, tpdu 00 80 4e 49
20:35:00.913 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.98' to '6/5/0'
20:35:02.673 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.21->4/2/0 L_Data.ind, low priority hop count 5, tpdu 00 80 0c e7
20:35:02.673 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.21' to '4/2/0'
20:35:02.913 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.98->6/5/17 L_Data.ind, low priority hop count 5, tpdu 00 80 4e 49
20:35:02.913 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.98' to '6/5/17'
20:35:08.912 [DEBUG] [calimero.link.224.0.23.12:3671       ] - indication 1.0.98->6/5/54 L_Data.ind, low priority hop count 5, tpdu 00 80 00 23
20:35:08.912 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.0.98' to '6/5/54'
20:35:14.474 [INFO ] [smarthome.event.ItemStateChangedEvent] - ntp_ntp_local_dateTime changed from 2018-07-16T20:34:14.466+0200 to 2018-07-16T20:35:14.468+0200
20:35:14.476 [INFO ] [smarthome.event.ItemStateChangedEvent] - ntp_ntp_local_string changed from 2018-07-16 20:34:14 CEST to 2018-07-16 20:35:14 CEST

And the ETS5:

|#|Zeit|Dienst|Flags |Prio|Quelladresse|Quellname|Zieladresse|Zielname|Rout|Typ|DPT|Info|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|310|16.07.2018 20:34:11,402|vom Bus||Niedrig|1.0.5|SCN-IP100.02 IP Router mit Email Funktion|6/1/0|Uhrzeit|6|GroupValueWrite|  10.001 Tageszeit|34 22 0F | Montag, 20:34:15|
|311|16.07.2018 20:34:11,602|vom Bus||Niedrig|1.0.5|SCN-IP100.02 IP Router mit Email Funktion|6/1/1|Datum|6|GroupValueWrite|  11.001 Datum|10 07 12 | 16.07.2018|
|312|16.07.2018 20:34:11,803|vom Bus||Niedrig|1.0.5|SCN-IP100.02 IP Router mit Email Funktion|6/1/2|Datum/Uhrzeit|6|GroupValueWrite|  19.001 Datum/Zeit|76 07 10 34 22 0F 40 80 | Montag, 16.07.2018, 20:34:15 (-W------Q) = (Fault: Normal (no fault), Working Day: Working day, No WD: WD field valid, No Year: Year field valid, No Date: Month and Day of Month fields valid, No Day of Week: Day of week field valid, No Time: Hour of day, Minutes and Seconds field valid, Standard Summer Time: Time = UT+X, Qualitiy of clock: clock with ext. sync signal)|
|313|16.07.2018 20:34:13,616|vom Bus||Niedrig|1.0.98|Wetterstation|6/5/54|Wind Gesschwindigkeit|6|GroupValueWrite|  9.005 Geschwindigkeit (m/s)|00 27 | 0,39 m/s|
|314|16.07.2018 20:34:19,616|vom Bus||Niedrig|1.0.98|Wetterstation|6/5/34|Helligkeit West Messert|6|GroupValueWrite|  9.004 Lux (Lux)|57 04 | 18391,04 Lux|
|315|16.07.2018 20:34:30,645|vom Bus||Niedrig|1.0.12|Heizungsaktor EG|4/2/51|2.6-2-Erdgeschoss.Wohnzimmer/Eszimmer/Küche-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|316|16.07.2018 20:34:31,647|vom Bus||Niedrig|1.0.12|Heizungsaktor EG|4/2/23|2.3-2-Erdgeschoss.HWR-Heizung.HMDT-Heizen-MDT-Aktueller Sollwert|6|GroupValueWrite|  9.001 Temperatur (°C)|05 DC | 15 °C|
|317|16.07.2018 20:34:31,685|vom Bus||Niedrig|1.0.12|Heizungsaktor EG|4/2/21|2.3-2-Erdgeschoss.HWR-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|318|16.07.2018 20:34:32,647|vom Bus||Niedrig|1.0.12|Heizungsaktor EG|4/2/3|2.1-2-Erdgeschoss.Windfang-Heizung.HMDT-Heizen-MDT-Aktueller Sollwert|6|GroupValueWrite|  9.001 Temperatur (°C)|05 78 | 14 °C|
|319|16.07.2018 20:34:32,686|vom Bus||Niedrig|1.0.12|Heizungsaktor EG|4/2/1|2.1-2-Erdgeschoss.Windfang-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|320|16.07.2018 20:34:33,644|vom Bus||Niedrig|1.0.12|Heizungsaktor EG|4/2/41|2.5-2-Erdgeschoss.Gästezimmer-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|321|16.07.2018 20:34:33,679|vom Bus||Niedrig|1.0.12|Heizungsaktor EG|4/2/11|2.2-2-Erdgeschoss.Flur-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|322|16.07.2018 20:34:39,329|vom Bus||Niedrig|1.0.13|Heizungsaktor OG|4/3/11|3.2-3-Obergeschoss.WC-OG-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|323|16.07.2018 20:34:39,363|vom Bus||Niedrig|1.0.13|Heizungsaktor OG|4/3/41|3.5-3-Obergeschoss.Büro-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|324|16.07.2018 20:34:40,330|vom Bus||Niedrig|1.0.13|Heizungsaktor OG|4/3/33|3.4-3-Obergeschoss.Schlafzimmer-Heizung.HMDT-Heizen-MDT-Aktueller Sollwert|6|GroupValueWrite|  9.001 Temperatur (°C)|07 08 | 18 °C|
|325|16.07.2018 20:34:40,365|vom Bus||Niedrig|1.0.13|Heizungsaktor OG|4/3/1|3.1-3-Obergeschoss.Flur-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|326|16.07.2018 20:34:40,401|vom Bus||Niedrig|1.0.13|Heizungsaktor OG|4/3/31|3.4-3-Obergeschoss.Schlafzimmer-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|327|16.07.2018 20:34:41,330|vom Bus||Niedrig|1.0.13|Heizungsaktor OG|4/3/33|3.4-3-Obergeschoss.Schlafzimmer-Heizung.HMDT-Heizen-MDT-Aktueller Sollwert|6|GroupValueWrite|  9.001 Temperatur (°C)|07 08 | 18 °C|
|328|16.07.2018 20:34:41,365|vom Bus||Niedrig|1.0.13|Heizungsaktor OG|4/3/51|3.6-3-Obergeschoss.lll-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|329|16.07.2018 20:34:41,400|vom Bus||Niedrig|1.0.13|Heizungsaktor OG|4/3/71|3.4-3-Obergeschoss.Ankleide-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|330|16.07.2018 20:34:41,604|vom Bus||Niedrig|1.0.98|Wetterstation|6/5/55|Außentemperatur|6|GroupValueWrite|  9.001 Temperatur (°C)|0C 65 | 22,5 °C|
|331|16.07.2018 20:34:42,328|vom Bus||Niedrig|1.0.13|Heizungsaktor OG|4/3/61|3.7-3-Obergeschoss.mmmmmm-Heizung.HMDT-Heizen-MDT-Status Stellwert|6|GroupValueWrite|  5.001 Prozent (0..100%)|$00 | 0 %|
|332|16.07.2018 20:34:48,483|vom Bus||Niedrig|1.0.27|Wohnzimmer Glastaster|4/2/50|2.6-2-Erdgeschoss.Wohnzimmer/Eszimmer/Küche-Heizung.HMDT-Heizen-MDT-Temperaturmesswert|6|GroupValueWrite|  9.001 Temperatur (°C)|0C 8D | 23,3 °C|
|333|16.07.2018 20:34:55,610|vom Bus||Niedrig|1.0.98|Wetterstation|6/5/0|Helligkeit Ost Messert|6|GroupValueWrite|  9.004 Lux (Lux)|4E 49 | 8238,08 Lux|
|334|16.07.2018 20:34:57,370|vom Bus||Niedrig|1.0.21|Windfang Glastaster|4/2/0|2.1-2-Erdgeschoss.Windfang-Heizung.HMDT-Heizen-MDT-Temperaturmesswert|6|GroupValueWrite|  9.001 Temperatur (°C)|0C E7 | 25,1 °C|
|335|16.07.2018 20:34:57,610|vom Bus||Niedrig|1.0.98|Wetterstation|6/5/17|Helligkeit Süd Messert|6|GroupValueWrite|  9.004 Lux (Lux)|4E 49 | 8238,08 Lux|
|336|16.07.2018 20:35:03,609|vom Bus||Niedrig|1.0.98|Wetterstation|6/5/54|Wind Gesschwindigkeit|6|GroupValueWrite|  9.005 Geschwindigkeit (m/s)|00 23 | 0,35 m/s|

I am really struggeling - what do you think, could this be tied to a bad config? Or would you think I should open a new topic for this?

thanks
Andreas


(Angelos) #18

In your latest post, I see that the GA being logged is 4/2/21 ? (I didn’t see 4/3/21 in there)


(Andreas) #19

Hello Dim,

thanks for your repeated help!
You are right, the 4/3/21 didn’t show up in the latest ETS/KARAF Log - but all the other Rooms Heating Actors work the same way that they post their actual “Position” and “ToBe Temperature” and yet nothing shows up in the “Basic UI”?!

It appears that I am the only one having this issue - so I assume that the error is somewhere burried in my config. I am currently thinking if I should setup an entirely new docker image and redo my entire config step by step… just not sure if that will only endup being a waste of time…

again - thanks so much for your continued support!


(Angelos) #20

Did you try to use a different label formatting also?

something like:

Number   OGHeizungsaktor_HeatOGBadStellwert	"Bad Stellmotor [%d %%]"	{channel="knx:device:bridge:OG_Heizungsaktor:Heat_OG_Bad_Stellwert"}

is the state of the item getting updated or not at all?

you can check the state in the OH2 console with the command:

items list |grep OGHeizungsaktor_HeatOGBadStellwert