core
core copied to clipboard
home-assistant
KNX L_DATA_CON Data Link Layer confirmation timed out
The problem
Hi guys,
I'am facing a very strange behaviour with my installation. Before hand sorry for the this long message but I try to explain everything I've done
I do not change a thing on the KNX side and from sometime I have STATUS issues.
Looking at the ETS group monitor I can see the ON or OFF telegram and the almost immediate change on the actuator status group address as you can see on the picture.
But on the frontend I can see the switch turn ON then revert to OFF and finally turn ON If I turn OFF it's the same I can see the switch turn OFF then revert to ON and finally turn OFF
On the ETS Monitor there is only GroupValueWrite for the action and another for the status.
Another thing I can see it's a permanent switching between available and unavailable on the global frontendbut specialy looking at the climate card.
I've tried changing all the parameters on the KNX integration like I saw on others issues but no luck.
the interesting thing is I define 1.0.251 for my HASSIO individual address and the xKNX log shows Telegram direction="Outgoing" source_address="1.0.17"
Logger: xknx.log Source: /usr/local/lib/python3.10/site-packages/xknx/io/tunnel.py:304 First occurred: 8:47:09 AM (4 occurrences) Last logged: 8:53:48 AM
L_DATA_CON Data Link Layer confirmation timed out for <Telegram direction="Outgoing" source_address="1.0.17" destination_address="1/0/111" payload="<GroupValueWrite value="<DPTBinary value="True" />" />" /> L_DATA_CON Data Link Layer confirmation timed out for <Telegram direction="Outgoing" source_address="1.0.17" destination_address="3/1/86" payload="<GroupValueWrite value="<DPTBinary value="True" />" />" /> L_DATA_CON Data Link Layer confirmation timed out for <Telegram direction="Outgoing" source_address="1.0.17" destination_address="3/1/86" payload="<GroupValueWrite value="<DPTBinary value="False" />" />" />
The 1.0.17 It's one of my IP routers.
I have in the same instalation 1x Gira X1 1x Gira S1 1x Siemens N148
I've tried the IP tunneling With both and I always have the same behaviour.
Last thing I've tried with the same results it's to create a new HASSIO machine with only few KNX switch for test purposes.
What version of Home Assistant Core has the issue?
Core-8.1 - 8.3
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
KNX
Link to integration documentation on our website
No response
Diagnostics information
Could not sync group address '2/0/109' (S116 PCC fenetre centre - State) 8:30:27 AM – (WARNING) /usr/local/lib/python3.10/site-packages/xknx/remote_value/remote_value.py - message first occurred at 8:29:13 AM and shows up 38 times Error: KNX bus did not respond in time (2.0 secs) to GroupValueRead request for: 2/0/109 8:30:27 AM – (WARNING) /usr/local/lib/python3.10/site-packages/xknx/core/value_reader.py - message first occurred at 8:29:13 AM and shows up 38 times L_DATA_CON Data Link Layer confirmation timed out for <Telegram direction="Outgoing" source_address="1.0.17" destination_address="1/0/119" payload="<GroupValueRead />" /> 8:30:09 AM – (WARNING) /usr/local/lib/python3.10/site-packages/xknx/io/tunnel.py - message first occurred at 8:29:39 AM and shows up 7 times
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
Everything Is running on HYPER-V from longtime (at least 2 years) but I migrate from Windows 10 - to Windows 11
Maybe related: https://github.com/home-assistant/core/issues/75118#issuecomment-1186479722
Hello,
So uninstalling the Windows 10 KB5015807 or Windows 11 KB5015814 July 2022 Patch did the job for now.
But it's fairly unstable like that. And now I can't run VirtualBox anymore HASSIO is stuck booting on SLOT A
Oh dear, what a mess... we definitely send UDP frames with payloads <12 bytes.
The thing with your configured IA is that this is only used for routing. With tunneling the IS is assigned by the tunneling server - if you want to change it you'll have to do that in the devices configuration (ETS or web interface depending on age of that device).
The X1 (and probably the S1 too) should however support TCP tunneling - if the issue is only with UDP it should work that way.
![probot-home-assistant[bot] avatar](https://avatars.githubusercontent.com/in/36093?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hey there @julius2342, @marvin-w, mind taking a look at this issue as it has been labeled with an integration (knx) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
Oh dear, what a mess... we definitely send UDP frames with payloads <12 bytes.
The thing with your configured IA is that this is only used for routing. With tunneling the IS is assigned by the tunneling server - if you want to change it you'll have to do that in the devices configuration (ETS or web interface depending on age of that device).
The X1 (and probably the S1 too) should however support TCP tunneling - if the issue is only with UDP it should work that way.
@farmio I have the same problem and when i understand it correct, there is only one option: to uninstall KB5015827, or is there any other options? I don't want do uninstall a securtiy bugfix. Will there be a HA fix for this?
Oh dear, what a mess... we definitely send UDP frames with payloads <12 bytes. The thing with your configured IA is that this is only used for routing. With tunneling the IS is assigned by the tunneling server - if you want to change it you'll have to do that in the devices configuration (ETS or web interface depending on age of that device). The X1 (and probably the S1 too) should however support TCP tunneling - if the issue is only with UDP it should work that way.
@farmio I have the same problem and when i understand it correct, there is only one option: to uninstall KB5015827, or is there any other options? I don't want do uninstall a securtiy bugfix. Will there be a HA fix for this?
Unlikely to be fixable in HA. It should be reported to microsoft.
How can it be reportet to Microsoft? Which KB? is it, because i read about KB5015807, KB5015827, KB5015814, and KB5015811. Also, if someone can share the information how to uninstall it, it would be great.
I follow this guide, and taking the last KB from june. I hope it can help some others
https://www.howto-connect.com/uninstall-kb5015807-from-windows-10-21h2-21h1-20h2/
Hi, same problem after updatig to 2022.8.1. KNX integration it's working perfectly with Home Assistant 2022.7.7 Supervisor 2022.07.0 Operating System 8.4 Frontend 20220707.1 - latest My HW is Raspberry PI4.
After the update KNX IP communication work for 1 or 2 hours and then start with this error messages: "KNX L_DATA_CON Data Link Layer confirmation timed out". If I reload the KNX integration or I restart HA works again but after some hours it stops... For the moment I solved the problem restoring a two days old backup with version mentioned above. Maybe the problem it's different from the user on top because for sure Microsoft is not involved, but the error message it's the same.
Thanks for your Help
@Talor74 Hi 👋! This error usually pops up when there are any network related problems (we even had flaky cables causing this). There no other reports of any issues regarding the jump from 2022.7 to .8 yet 🤔 What kind of connection do you use (UDP / TCP / Secure) and which interface? Are there any other noteworthy logs - maybe even of 3rd party integrations?
Hi @farmio , thanks for the fast reponse. I have got an old KNX/IP interface from Siemens (5WG1 148-1AB22) in the main electrical cabinet of my home. Raspberry PI4 it's in the main cabinet too and attached to the main switch. All the ethernet cables are CAT6 and are in the walls. The connection is in UDP mode with no secure options, direct tunnelling mode. I've no network log except from HA logs. Should I sent you somehing? Is it possible that new release is more "sensible" to network problems? What kind of 3rd party integration may I install to discover my problems? Tank you
Is it possible that new release is more "sensible" to network problems? What kind of 3rd party integration may I install to discover my problems?
Not that I know of. It's not that there is a wrong packet, there is one missing (or way too late). You could use Wireshark / tcpdump to monitor if the confirmation frame, xknx reports missing, was actually sent by the interface (and when it was sent). Then we can dig deeper. Feel free to join xknx discord if you have questions regarding xknx debugging https://discord.gg/EuAQDXU
Hi, I had to revert to HA 2022.7.7 myself. I had a similar behavior as @Talor74. I‘m running inside a VM on Proxmox. At the moment I have no logs because I restored from backup instead of downgrading just HA. The VM and the IP interface are in the same VLAN.
We'd really need more information. Logs, tcpdumps, diagnostic info, used hardware, ... We had such issues before, but thought we fixed that. Unfortunately these are really hard to track down.
See eg. https://github.com/home-assistant/core/issues/59170
Hi @farmio,
I've installed Wireshark but I'm not very familiar with it and I'm spending some time to understand how to filter the messages from-to 192.168.1.150 (HA) and 192.168.1.101 (KNX-IP).
I've read in #76913 that also a HA log can be useful for you so my idea is to record a daily log with 2022.7.7 (version in use) and then a daily record with 2022.8.x. Could this be useful?
Sure, that can be useful.
With Wireshark I usually use the kip filter - that matches for Knx IP packets.
It should also be possible to only include packets from or to your Knx IP interface by IP address - I'm sure you can find instructions for that on the net.
I'm closing this issue as the original Windows Hyper-V problem is solved / can not be addressed by us. Please head to #76913 for tracking Hyper-V unrelated L_Data_Con warnings.