After updating to 2.1.17 no connection to knx interface anymore

[Lorilatschki]

I have absolutly no idea what happend, but after updating from 2.1.16 to 2.1.17 I get no working connection to my MDT KNX Interface gateway anymore.

Before everything worked as expected. Now the connection cannot be established, it tries to reconnect but at the end the knx device says "Queue Deleted TX". What I did was updated the version from the editor and restarted my docker container.

To Reproduce I have persisted my flows (by the export function). I have completly setup a new environment by: 1) created a new nodered container v3.0.2 from the scretch 2) installed all required modules used by my nodes 3) imported the whole flows Even after that the connection cannot be established. I have already restarted by raspberry pi as well as the whole knx devices, no changce.

Expected behavior Connection works as before.

Screenshots If applicable, add screenshots to help explain your problem.

Knx-Ultimate Version

• V2.1.17

Are you running node-red behind homematic, docker or anything similar?

• Node-Red running on a RaspberryPi inside a docker container

I have also tried to setup a new container and installed the version 2.1.16 of the node-red-contrib-knx-ultimate but with the same result. Is there any further debug output which points me to what went wrong? The output from the configuration is attached.

[debug] 7/3/2023, 11:05:52 PM.736 knxUltimate-config: Waiting next cycle to reconect. node.LinkStatus: disconnected, node.autoReconnect:true
[debug] 7/3/2023, 11:06:02 PM.736 knxUltimate-config: Auto Reconect by timerKNXUltimateCheckState in progress. node.LinkStatus: disconnected, node.autoReconnect:true
[info] 7/3/2023, 11:06:02 PM.737 KNXUltimate-config: Bind KNX Bus to interface (Auto). Node KNX Gateway
[debug] 7/3/2023, 11:06:02 PM.738 knxUltimate-config: Disconnect: already not connected:disconnected, node.autoReconnect:true
[debug] 7/3/2023, 11:06:02 PM.738 knxUltimate-config: removing old handlers. Node KNX Gateway
[debug] 7/3/2023, 11:06:02 PM.740 KNXUltimate-KNXEngine: ipAddressHelper.js: parsing interface: lo ({"address":"127.0.0.1","netmask":"255.0.0.0","family":"IPv4","mac":"00:00:00:00:00:00","internal":true,"cidr":"127.0.0.1/8"})
[debug] 7/3/2023, 11:06:02 PM.741 KNXUltimate-KNXEngine: ipAddressHelper.js: parsing interface: eth0 ({"address":"172.17.0.4","netmask":"255.255.0.0","family":"IPv4","mac":"02:42:ac:11:00:04","internal":false,"cidr":"172.17.0.4/16"})
[info] 7/3/2023, 11:06:02 PM.746 knxUltimate-config: perform websocket connection on KNX Gateway
[info] 7/3/2023, 11:06:02 PM.747 KNXUltimate-config: Connecting... KNX Gateway
[debug] 7/3/2023, 11:06:02 PM.747 knxUltimate-config: Connecting to192.168.1.6
[debug] 7/3/2023, 11:06:04 PM.753 KNXUltimate-KNXEngine: Sending KNX packet: KNXConnectRequest Host:192.168.1.6:3671
[error] 7/3/2023, 11:06:12 PM.753 knxUltimate-config: received KNXClientEvents.error: Connection timeout to 192.168.1.6:3671
[debug] 7/3/2023, 11:06:12 PM.753 knxUltimate-config: Disconnected: node.knxConnection.Disconnect() KNX Socket is already disconnected , node.autoReconnect:true
[debug] 7/3/2023, 11:06:12 PM.755 knxUltimate-config: Disconnected, node.autoReconnect:true
[error] 7/3/2023, 11:06:12 PM.755 knxUltimate-config: Disconnected by: Connection timeout to 192.168.1.6:3671
[debug] 7/3/2023, 11:06:12 PM.756 knxUltimate-config: KNXClient socket closed.

When I ping the knx interface, it is reachable from within the container:

ping 192.168.1.6
PING 192.168.1.6 (192.168.1.6) 56(84) bytes of data.
64 bytes from 192.168.1.6: icmp_seq=1 ttl=254 time=0.372 ms
64 bytes from 192.168.1.6: icmp_seq=2 ttl=254 time=0.402 ms
64 bytes from 192.168.1.6: icmp_seq=3 ttl=254 time=0.406 ms
64 bytes from 192.168.1.6: icmp_seq=4 ttl=254 time=0.568 ms
64 bytes from 192.168.1.6: icmp_seq=5 ttl=254 time=0.695 ms
64 bytes from 192.168.1.6: icmp_seq=6 ttl=254 time=0.697 ms
64 bytes from 192.168.1.6: icmp_seq=7 ttl=254 time=0.606 ms
64 bytes from 192.168.1.6: icmp_seq=8 ttl=254 time=0.646 ms
64 bytes from 192.168.1.6: icmp_seq=9 ttl=254 time=0.630 ms
64 bytes from 192.168.1.6: icmp_seq=10 ttl=254 time=0.801 ms
64 bytes from 192.168.1.6: icmp_seq=11 ttl=254 time=0.764 ms
64 bytes from 192.168.1.6: icmp_seq=12 ttl=254 time=0.543 ms
64 bytes from 192.168.1.6: icmp_seq=13 ttl=254 time=0.291 ms

The knx interface settings can be found here:

[sumnerboy12]

I am seeing the same with my Weinzierl 732. Constant Connection timeout errors. Home Assistant is still connecting fine, as is ETS. And everything was fine before upgrading to 2.1.17.

I also tried downgrading to 2.1.16 and was seeing the same thing, so thought something else must have been causing this issue. But after seeing someone else report it I now think it is probably related to this.

I am also running NodeRED inside docker, if that is relevant.

[Supergiovane]

Hi Please revert to a previous version. But before, please set the debug level to “debug” , in the gateway config node, and post the log again. Thanks.

[Lorilatschki]

The crazy thing is that I have already reverted to 2.1.16 with the same result. I will try out a version from may and report the result today evening.

[Supergiovane]

Hi Try two or three previous versions, and restart nodered everytime.

[Supergiovane]

I'l be helpful to see the debug log. The priority is to make both your systems working again.

[Supergiovane]

V 2.1.18 is out with a possible quick fix for both of your interfaces.

[Lorilatschki]

Awesome! Will try it when back home from office and give feedback.

[sumnerboy12]

I will be able to test in an hour. Will report back ASAP.

[Lorilatschki]

I can confirm that the new version works again 🙏 What was the reason?

[Supergiovane]

Hi Lori The reason is, that in the version not working, i've followed the KNX standard and i've sent the correct HPAI frame during a connection request to the KNX/IP interface. The HPAI frame contains the IP and port of the client, trying to connect to the KNX interface. Maybe due to the fact that you're running node-red dockerized, your HPAI IP/port could be wrong or hidden somehow, behind the docker routing functionality. In this case, the KNX Interface is responding to a wrong IP address, causing KNX-Ultimate to wait for a 'response' packet, that will never reach it, falling into timeout issue. That's my opinion, as i've not tested node-red behind docker since now, but i'll try in the future...

[sumnerboy12]

I can also confirm v2.1.18 has resolved the issue - thank you for your very prompt support!! I think your theory sounds very plausible. The IP address of NodeRED running in a container will be completely different to the one something on the outside "sees". Perhaps there needs to be an option to manually set the client IP address if running in docker?

Thanks again for providing such a wonderful tool!

[Supergiovane]

Hi Ben Yes, you're right and i'm doing that in the config gateway's advanced option section. A little question: what is the name of the docker you're using? I wanna test the matter with it. Thank you to you for using my node!

[sumnerboy12]

I am using this docker image - https://hub.docker.com/r/nodered/node-red/.

Is that what you mean? I am running my docker containers in a docker swarm configuration across 3x nodes, so it is not your typical setup. But I would be more than happy to help if I am able.

[Supergiovane]

Thank you so much! I'll keep in touch with you if i need further help.

[Noschvie]

Perhaps there needs to be an option to manually set the client IP address if running in docker?

This parameter shall not be required, shall be handled by the docker network. In case of copying a flow from development to production using the same KNX IP interface no changes shall be needed.

[Lorilatschki]

I am using the same docker image. If you need help setting up the docker container I can help you as well. I would prefer a solution where you can select a option that the knx-ultimate is running i a docker container and therefor routes the external IP to the docker internal one.