Closed madzrobz closed 2 months ago
Julius2342
commented
4 years ago Hi @madzrobz !
yes, the problem is, that the lib cant connect to HASS at all - bc the KLF refuses to accept connections. This problem would persist independently of the set timeout.
The devices are only initialized on startup - i have no idea if it is possible to add devices asynchronously. May I ask you to connect to the HASS team and ask how we should change the integration.
Best
Julius
madzrobz
commented
4 years ago Hi @Julius2342 ,
thank you for the quick reply.
As you can see in the log, less than one minute later, the connection gets established - so the KLF itself (which I reboot before each restart of HA) accepts the connection. Thus I somehow don’t understand your reply - but this can easily be due to my lack of knowledge- sorry for that.
Best Robert
Julius2342
commented
4 years ago the problem is, we should not wait till the KLF has self-repaired. (bc it is not predictable how long this will take).
(we could try to set the timeout to less then a second and immediately retry? But im not sure if this is an elegant approach.
madzrobz
commented
4 years ago Hi @Julius2342,
I checked the content of the file /usr/local/lib/python3.8/site-packages/pyvlx/connection.py on my Home Assistant machine and found the following code:
async def connect(self):
"""Connect to gateway via SSL."""
tcp_client = TCPTransport(self.frame_received_cb, self.connection_closed_cb)
self.transport, _ = await self.loop.create_connection(
lambda: tcp_client,
host=self.config.host,
port=self.config.port,
ssl=self.create_ssl_context(),
ssl_handshake_timeout=5,
)Strangely, connection.py in your Git repository and part of the 0.2.17 release code looks as follows:
async def connect(self):
"""Connect to gateway via SSL."""
tcp_client = TCPTransport(self.frame_received_cb, self.connection_closed_cb)
self.transport, _ = await self.loop.create_connection(
lambda: tcp_client,
host=self.config.host,
port=self.config.port,
ssl=self.create_ssl_context(),
)I don't understand, how the parameter ssl_handshake_timeout=5 came into my local file. I have changed the value of the timeout to 60 which has solved the problem for me.
the problem is, we should not wait till the KLF has self-repaired. (bc it is not predictable how long this will take). (we could try to set the timeout to less then a second and immediately retry? But im not sure if this is an elegant approach.
I would prefer to wait as long as it takes during startup for the component to be set-up properly as I only restart the server during version updates - especially with the latest features which allow almost everything to be reloaded without a restart. Maybe the ssl_handshake_timeout and a repeat_counter during start-up could be exposed as parameters so everybody can configure the start-up behavior as preferred.
Best Robert
sbyx
commented
4 years ago @madzrobz seems there was an issue in the pip release of 0.2.17 since I was seeing the same thing. Julius released 0.2.18 and I just got the bump in Home Assistant approved: https://github.com/home-assistant/core/pull/42895 so hope we have this out of the way.
Since I have upgraded to Home Assistant release 116 (I have skipped 115) my Velux component will simply not set-up. To me it seems like the SSL timeout was reduced from 30s to 5s and during HA start this interval is too short.
Less than a minute later, the KLF200 connection is established again - this time succesfully. Subsequently KLF200 sends updates to HA which also are properly logged --> the connection is alive. However as the set-up of the component failed, the devices are invisible to HA and can't be controlled.