-
-
Notifications
You must be signed in to change notification settings - Fork 29.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KNX entities switching constantly from available to unavailable #59170
Comments
Hey there @Julius2342, @farmio, @marvin-w, mind taking a look at this issue as it has been labeled with an integration ( knx documentation |
Hi 👋! So I think the actual problem is that your connection is unstable. Please check your logs to confirm For general KNX integration Troubleshooting and to get even more detailed logs see also https://www.home-assistant.io/integrations/knx/#troubleshooting--common-issues |
Hey! :) Could you please add more logs to this issue - as mentioned by @farmio. Otherwise it's quite hard to analyse the issue you are experiencing. Thanks! |
Here some more logs to better explain the issue. 2021-11-06 01:56:15 WARNING (MainThread) [xknx.log] Received DisconnectRequest from tunnelling sever. |
Ok. This line
means that your IP interface closed the connection - unfortunately we don't get any more infos when this happens. You could look if your IP interface has some kind of logs.
this could be a result of the missing connection and HA trying to initialize states. (these are less interesting for our debugging purposes) Does HA reconnect after some time or does it stay disconnected? There is no hint of a reconnection in your logs. Did you remove some loglines or is this everything you get from xknx? See my initial comment on how to get more logs by changing the log level of @marvin-w I wonder why not only the heartbeat task seems to keep running after the disconnect, but also the StateUpdater 🤔 |
I'd probably need debug logs in order to analyse this further, but agreed it looks strange. https://www.home-assistant.io/integrations/knx/#troubleshooting--common-issues |
My KNX->IP interface is a Zennio KIPI 1.0 (https://www.zennio.com/products/system/kipi)
After disconnecting from the BUS HA reconnects in 4-5 seconds. The entities becomes "not available" and then after 4-5 seconds the current state is correctly shown in the register. I did not remove any log lines from KNX integration. This is all I get !
I insert some more loglines and an image following. Thanx !
|
It would need to be |
Sorry guys, I was so focused on debugging the problem that I didn't see the missing "X" !!
|
I don't know if is the same problem, but after the upgrade to 2021.11 I have some issue with knx, that trigger some automations even if not necessary. I think the problem is in the communication & entity update. |
@arcano81 the disconnect is issued form your tunnelling server. How often does it occur? You can try to turn off the second device connecting to it and see if this is causing the problems. Alternatively try to use ETS bus monitor to get an idea what is happening. @sagitt without further information we can't help you. But your problems don't seem related to this issue (entities unavailable) so please open a new one providing as much information as possible. |
@farmio The disconnection occurs about 200 times in 24 hours. In attach you can find a query from HA DB that reports the states of a cover entity. You can see how often the disconnections occurs. Thanx |
@farmio I disconnected the second device but the problem is still there. |
So about every 8 minutes. Ok that is very often, but it makes it quite easy to log such an event. Is the KIPI device the only ip interface in your installation? |
I analyzed the situation and the problem is given by this change. I see that sometimes my entities go to "unavailable" and just after some seconds receive the correct state. This working mode is not a problem if all works fine, but I found this in logs when this happen: So this happen multiple times during the day. There is a way to restore the old working method? Thanks |
We did not change the connection behavior itself. It has been like this for a long time. The only difference is, that you are now able to see when the bus is not connected by updating the available property of each given entity. I'm almost certain that you had this issues before but they just weren't visually highlighted as they are now. |
of course, but this is a problem even if now is the right and before not Is possible an option to disable this behavior or add a configurable timeout? so the entites go to unavailble only after defined time occur |
I will think about it and talk to @farmio, I'm personally not feeling this but we will see. |
Thank you, this is like a breaking change and "break" lots of my automations. |
I have a similar issue. Sometimes, but not always, I get this disconnect every 30 minutes exactly. It is always at exactly X:00 or X:30.
It always reconnects after a few seconds but of course it triggers some automations etc. |
The disconnect is issued form your tunnelling gateway (what manufacturer and type is it?). Its hard for us to say why. Your best bet would be to see if it provides some kind of logging (maybe it has a web interface etc.). |
It is a MDT IP Interface SCN-IP000.03 which, unfortunately, has not any logs at all. I do understand that the actual problem is not related to HomeAssistant/XKNX and most likely has been there since ever. However, it would be great if there would be a (configurable) option to ignore such quick reconnects to the bus. Some of the "unavailable" automation triggers can be worked around but some not, for example HomeKit triggers notifications if locks jump from the "unavailable" state. |
@josiasmontag I'm more in the camp of finding and fixing the source of issues than to add code and complexity to hide them. If you need help in finding out what is causing this feel free to join the xknx Discord server. |
Hm... it is not included in 20220111 - was merged after that build - it should be in todays build though. That said there are other blocking calls than |
Hello all, since I upgraded my NAS with RAM, the KNX interface is running stable. -> my NAS no longer needs virtual memory Stable with HA 2021.12.9 and 2021.12.10 |
My problem disappeared when commenting our DWD app. (They were blocking the event loop, causing disconnects which then made some entities to be flaky.) |
So a new beta has started yesterday. Please try it and see if the connection problems with KNX disappear - or if there are any log messages regarding "timer_out_of_sync" (homeassistant.core debug) or similar. |
Great news !Thankyou. |
That depends on your installation method. A quick search at Google or HA community forum will tell you. |
I updated my production instance of HA to last beta versione (2022.2.0b3). |
@arcano81: Can you please add the KNX diagnostics to the issue? You can download it on the integrations page after clicking on the three dots on the KNX integration. Also, please send another log with
active in your |
@arcano81 thanks for these logs, we found a bug in the route_back logic. Try disabling route_back - you probably don't need it as your HA device and interface are on the same network anyway. |
@farmio Disabling the route back solved the problem of disconnection every 2/3 seconds. Last questions: How do I use the individual address in KNX configuration?Which address do I have to use? |
You don't need to configure any address here. A tunnelling server should assign an address for a client at connection. Some (rare) don't, yours does: What is this entity: It doesn't seem |
The |
@farmio |
This has just been fixed in beta 4 (#65252). |
Upgraded to HA 2022.2.0b4 I will roll back to HA 2022.2.0b3 which has a tolerable behaviour with KNX disconnection while waiting for a fix. |
@arcano81 to me it seems your HA instance is just a tick too big for the Raspberry, but I could be totally wrong there. There are just so many timeout occasions and asyncio warnings on different parts of the system. I'd like to try to enable threading for xknx on your HA to see if it fixes at least knx, if you are interested feel free to ping me at Discord |
Dear Folks, I have the same issue. My environment: HA 32bit Core Version: 2021.12.10 on Raspi 4 4 GB Till yesterday this error occurs nearly every 5 -6 minutes I Found the following issues: Node-Red
Normally I use the ultimate knx plugin which creates on own knx connection next to homeassistant. After that happens the connection got lost.
Integrations I've had a couple of buggy integrations that keep trying to connect to a network endpoint and fail.
I fixed that or deactivated the integrations. For now, it looks much better. The last disconnection was 15 hours ago -- |
Does it make sense to add hysteresis to the function that reports connection aborted? That this function does not report every single micro disconnect? |
This looks bad, but actually doesn't cause anything other than this log message:
Granted, it should be handled in a less alarming way, but other than that it is not a cause for a disconnect.
This however can really mess with your connection. |
I have (had?!) the same problem and after switching off the support of "slow tunneling connections" in my MDT IP Interface, I don't see any errors anymore regarding the disconnect in my log file. Edit: Yesterday I turned on the "slow tunneling connections" again and I got the errors with the disconnect again @farmio: What is the recommendation for this? |
The problem
After upgrading to HA last version 2021.11.1 the KNX entities continue switching from availble to Not avalable
![image](https://user-images.githubusercontent.com/76391221/140542894-053ef6e8-3ba0-4e4c-bd1b-d06a7d85faea.png)
What version of Home Assistant Core has the issue?
2021.11.1
What was the last working version of Home Assistant Core?
2021.10.9
What type of installation are you running?
Home Assistant OS
Integration causing the issue
KNX
Link to integration documentation on our website
https://www.home-assistant.io/integrations/knx/
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Additional information
No response
The text was updated successfully, but these errors were encountered: