Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Adds ability to set timeouts for a knxdclient.KNXDConnection #2
Adds ability to set timeouts for a knxdclient.KNXDConnection #2
Changes from 5 commits
aa34d5e
eba2006
b7837b0
42f4e45
d1c7cca
7467f1e
4a81f2c
7451cdb
a1cccfe
859ecf2
aa2aa16
a453745
71c959a
ca9b4f4
324c8dc
b2b6bf8
c38e417
15b2f98
26e06a6
b5882cc
73c0aa5
9e2e56c
43e7c0e
34e21ff
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be cool to have some kind of "keep alive" feature here, i.e. trigger some request to KNXD every few seconds or so, so that we can be sure to receive a packet from KNXD regularly. Then we don't have to rely on KNX bus activity to avoid false timeouts and can chose an even shorter timeout value.
I will take a look at the KNXD protocol spec to see if there is a function that we can (mis)use as a keepalive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm. Unfortunately, according to the BCUSDK docs about EIBD's/KNXD's interface, there is no appropriate function to use as a keepalive, that reliably sends a response packet, once we opened the 'group socket' connection.
I'm somehow unconvinced to rely on KNX bus traffic to avoid running into timeouts.
Have you tested whether the event notification mechanism, you implemented today, is sufficient to detect the connection loss and stop the receive loop, when your KNXD server reboots – without the timeout here in the
run()
coroutine (or with a very very long timeout)?If it doesn't work: Can you test whether setting up TCP keepalive for the socket here allows us to detect the connection loss reliably?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested the mechanism manually by connecting to a Debian docker image with KNXD installed and used
knxtool
to simulate some traffic which then I stopped and it seems to work.It's possible that there is some stuff about coroutines / tasks that goes over my head as I am seeing the CI/CD failing.
The definitive test will come in 5h and 20 minutes :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was enough as I kept receiving data throughout the night! 🎉
But I see how setting the TCP props on the socket will also be of use.