Out of interest what’s people’s experience on reboot from power cycle of the whole circuit?
i.e. Blackout or circuit breaker that runs HA and the KLF?
I see intermittent success on reboot and I am wondering if a delay is needed before starting HA to allow the KLF to come up.
I’ve not looked into trying it yet, but would be good to know if others have experimented with this.
Having some issues today with the communications, so decided to do a little investigation.
Surprisingly I found that 3 TCP connections were up between HA and KLF200:
$ netstat -ntlapee | grep <VELUX IP>
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 <HA IP>:54526 <VELUX IP>:51200 ESTABLISHED 1000 1590411 3116/python3.7
tcp 0 0 <HA IP>:36386 <VELUX IP>:51200 ESTABLISHED 1000 8446952 3116/python3.7
tcp 0 0 <HA IP>:42790 <VELUX IP>:51200 ESTABLISHED 1000 6604188 3116/python3.7
where 3116 is the PID for hass.
I then ran $sudo systemctl stop <systemd-HA-name>
and for about the next 60-75 seconds or so, two connections remain (albeit not established).
$ netstat -ntlapee | grep <VELUX IP>
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 <HA IP>:36386 <VELUX IP>:51200 TIME_WAIT 0 0 -
tcp 0 0 <HA IP>:42790 <VELUX IP>:51200 TIME_WAIT 0 0 -
Afterwards these two remaining tcp connections finally timeout and disappear.
I then start HA again and see there is only one connection (as expected):
$ netstat -ntlapee | grep <VELUX IP>
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 <HA IP>:55658 <VELUX IP>:51200 ESTABLISHED 1000 8474305 3002/python3.7
I’m speculating, but it appears that the work-around on_hass_stop(event) which tears down the connection when hass is stopped, is working as it tears down what is probably the “working” tcp connection… but sometime in the past when communications was deemed lost by HA, the original socket instead of being torn down remains up yet a new one is established.
Having difficulty getting HA to connect to the KLF200 after a restart of both (KLF200 then HA) using HA 0.104.3. Logs show a first connection attempt aborted then a second connection that succeeds however HA could not setup the Velux platform. Logs with debug on for velux and pyvlx show the following:
2020-01-27 17:46:32 DEBUG (MainThread) [homeassistant.components.velux] Velux interface started
2020-01-27 17:46:32 WARNING (MainThread) [pyvlx] Connecting to KLF 200.
2020-01-27 17:47:28 WARNING (MainThread) [homeassistant.setup] Setup of velux is taking over 10 seconds.
2020-01-27 17:47:45 WARNING (MainThread) [pyvlx] Connecting to KLF 200.
2020-01-27 17:47:45 ERROR (MainThread) [homeassistant.setup] Error during setup of component velux
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 170, in _async_setup_component
hass, processed_config
File "/usr/src/homeassistant/homeassistant/components/velux/__init__.py", line 31, in async_setup
await hass.data[DATA_VELUX].async_start()
File "/usr/src/homeassistant/homeassistant/components/velux/__init__.py", line 69, in async_start
await self.pyvlx.load_scenes()
File "/usr/local/lib/python3.7/site-packages/pyvlx/pyvlx.py", line 87, in load_scenes
await self.scenes.load()
File "/usr/local/lib/python3.7/site-packages/pyvlx/scenes.py", line 51, in load
await get_scene_list.do_api_call()
File "/usr/local/lib/python3.7/site-packages/pyvlx/api_event.py", line 22, in do_api_call
await self.send_frame()
File "/usr/local/lib/python3.7/site-packages/pyvlx/api_event.py", line 34, in send_frame
await self.pyvlx.send_frame(self.request_frame())
File "/usr/local/lib/python3.7/site-packages/pyvlx/pyvlx.py", line 70, in send_frame
await self.connect()
File "/usr/local/lib/python3.7/site-packages/pyvlx/pyvlx.py", line 45, in connect
await self.connection.connect()
File "/usr/local/lib/python3.7/site-packages/pyvlx/connection.py", line 89, in connect
ssl=self.create_ssl_context())
File "/usr/local/lib/python3.7/asyncio/base_events.py", line 985, in create_connection
ssl_handshake_timeout=ssl_handshake_timeout)
File "/usr/local/lib/python3.7/asyncio/base_events.py", line 1013, in _create_connection_transport
await waiter
ConnectionAbortedError: SSL handshake is taking longer than 60.0 seconds: aborting the connection
2020-01-27 17:47:49 DEBUG (MainThread) [pyvlx] SEND: <FramePasswordEnterRequest password=kd****/>
2020-01-27 17:47:49 DEBUG (MainThread) [pyvlx] REC: <FramePasswordEnterConfirmation status='PasswordEnterConfirmationStatus.SUCCESSFUL'/>
2020-01-27 17:47:49 DEBUG (MainThread) [pyvlx] SEND: <FrameGetVersionRequest/>
2020-01-27 17:47:49 DEBUG (MainThread) [pyvlx] REC: <FrameGetVersionConfirmation software_version="0.2.0.0.71.0" harware_version="5" product="KLF 200"/>
2020-01-27 17:47:49 DEBUG (MainThread) [pyvlx] SEND: <FrameGetProtocolVersionRequest/>
2020-01-27 17:47:50 DEBUG (MainThread) [pyvlx] REC: <FrameGetProtocolVersionConfirmation version="3.14"/>
2020-01-27 17:47:50 WARNING (MainThread) [pyvlx] Connected to: KLF 200: Software version: 0.2.0.0.71.0, hardware version: 5, protocol version: 3.14
netstat shows the following connections when this happens, 16107 is the PID for hass:
tcp 0 0 <HA IP>:36964 <VELUX IP>:51200 TIME_WAIT 0 0 -
tcp 0 0 <HA IP>:50934 <VELUX IP>:51200 ESTABLISHED 1000 8474305 3002/python3.7
Its not clear what is causing the first connection attempt to experience a SSL handshake issue.
I don’t understand as well why the second connection gets established yet it ends up failing (maybe pyvlx declares a failure due to the first connection?).
Anyway, when I encounter the same situation as you do, I reboot the KLF and then restart HA and it usually comes up successfully (and with only one connection).
Power cycling the KLF200, waiting for it to startup and then restarting HA appears to make no difference as I every time I have tried since updating to 0.104.3 I observe the two connections from HA. I’m planning to do a pcap next to see if I can observe the SSL handshake and see if there is an issue causing the first connection to terminate.
Are you using the velux integration within 0.104.3 or the custom code posted in this thread months ago?
I admit I lost track whether @gibman’s commits made it to a release.
I am using 0.104.3, but still have the custom code from this thread. I do not see the problem you report.
I have occasional problems on restart where Velux does not come up, I would say 90% ok, 10% I need to reboot the Velux. Similar on power cycling everything (i.e. blackout), the system comes up cleanly 90% of the time.
I can see @gibman’s commits in init.py on my HA so it’s part of the release now. Everything was power cycled earlier today and still I’m having the same issue with two connections during start up of HA.
OK - I’ll disable my custom install and rely on the released version and see if I notice a difference.
I’ve been testing for nearly a week now with numerous reboots and the clean 0.104.3 works just as well as the custom code from this thread.
I am also going to purchase some Velux roof Windows with that klf 200 module…
But do you also need a LAN cable connected to it? Or is it optional? Can it also be configured to a WiFi access point?
You’ll need a LAN cable. This is the path HA uses to talk to the KLF 200.
Ok, thnx for info… But what’s the wifi sticker then on the product?
It could be used to connect to klf directly in a web browser and thing’s like that.
But it do not allow API access.
Ah ok, it’s to setup…
Ok thnx for info, looking forward to my velux
Can I use KLF 200 via WiFi and not the LAN port? I don’t see any options to add it to my WiFi. I’m on the latest Velux FW.
Hi,
no you can’t you need to use LAN as far as I know
ok, next month they are about 2 install our 2 new velux with klf 200
just a question, i want to automize it later with HA , but i also have a maze at the inside for the mosquitos… so if you open the covers, can you say like, only open for some xx % only ?
yes you can open by a percentage and HA can control it just as the Velux remote can.
Yes, you can control the percentage. There is a neat card called “Vertical Slider Cover Card”, available in HACS. There you can control the windows and also shutters manually and also have a visual feedback on the state. It is not realtime though, because the KLF seems to report the status only if the movement is finished.
The KLF 200 is quite a crude component. Web access is only available for a certain time after restart, and the connection is sometimes not re-established when HA restarts (I guess the KLF supports only one active connection). I suggest using a smartplug to power the KLF, so in the event the connection is not established you can powercyle it remotely or even automate it.
Ok, good tips! Thnx for this