The Velux integration does not reflect the correct position of the covers - No integration Errors Reported

[frr032]

The problem

The Velux integration thinks my Skylights are open when they are actually CLOSED. This is verified visually, and the ElkM1 Sensors are window sensors that are Normal when the skylight is closed and Violated when open. The Velux integration does NOT report errors.

What version of Home Assistant Core has the issue?

core-2024.7.2

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

Velux

Link to integration documentation on our website

(https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+velux%22)

Diagnostics information

Images showing the incorrect state of the Skylights When I click on the scene Skylight Window OPEN ALL, nothing happens and there is no log entry. When I click on the Down Arrow for a skylight, the following error pops up briefly after about a minute. There is no log entry, "Failed to call service cover/close cover. SSL handshake is taking longer than 60.0 seconds: aborting the connection"

There is no indication that the Velux integration is having a problem on the integrations page or anywhere else. The KLF200 responds to pings, so it is reachable.

My automation that is intended to close all skylights when it is raining fired last night and did NOT run properly as it appears to have run into an issue communicating with the KLF 200. There is an error in the automation trace log "Error: SSL handshake is taking longer than 60.0 seconds: aborting the connection" Thankfully the skylights must have closed via the Velux internal rain sensors. The concern with these sensors is that it needs to be raining very hard before they activate.
Why doesn't the integration not reflect the correct current cover state? Why no integration errors reported even though the integration is clearly not working?

ALSO What happened to the other entities that were in the Velux Custom Integration like Velocity and others? See the snip below.

This history shows that the automation closes the skylights most of the time when it is raining > .1 in/hr. However, there are times where the integration does not report the state of the skylights and also when the integration state does not match the actual state.

Example YAML snippet

No response

Anything in the logs that might be useful for us?

When I reload the Velux integration I finally get an error in the log. The KLF 200 is still on the network and responding to pings.

Reloading the integration several times does not resolve the issue.
Rebooting the KLF 200 several times does not resolve the issue. Restarting HA after the steps above did resolve this issue for now.

I did not have these kinds of issues very often when I was using the Velux Custom Integration.

Logger: homeassistant.config_entries Source: config_entries.py:586 First occurred: 3:40:10 PM (1 occurrences) Last logged: 3:40:10 PM

Error setting up entry 192.168.1.159 for velux Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/config_entries.py", line 586, in async_setup result = await component.async_setup_entry(hass, self) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/velux/init.py", line 52, in async_setup_entry await module.async_start() File "/usr/src/homeassistant/homeassistant/components/velux/init.py", line 102, in async_start await self.pyvlx.load_scenes() File "/usr/local/lib/python3.12/site-packages/pyvlx/pyvlx.py", line 106, in load_scenes await self.scenes.load() File "/usr/local/lib/python3.12/site-packages/pyvlx/scenes.py", line 56, in load await get_scene_list.do_api_call() File "/usr/local/lib/python3.12/site-packages/pyvlx/api/api_event.py", line 29, in do_api_call await self.pyvlx.check_connected() File "/usr/local/lib/python3.12/site-packages/pyvlx/pyvlx.py", line 83, in check_connected await self.connect() File "/usr/local/lib/python3.12/site-packages/pyvlx/pyvlx.py", line 58, in connect await self.connection.connect() File "/usr/local/lib/python3.12/site-packages/pyvlx/connection.py", line 103, in connect self.transport, _ = await self.loop.create_connection( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1149, in create_connection transport, protocol = await self._create_connection_transport( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1182, in _create_connection_transport await waiter ConnectionAbortedError: SSL handshake is taking longer than 60.0 seconds: aborting the connection

===================================== Logger: homeassistant.config_entries Source: config_entries.py:586 First occurred: 3:35:19 PM (1 occurrences) Last logged: 3:35:19 PM

Error setting up entry 192.168.1.159 for velux Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/config_entries.py", line 586, in async_setup result = await component.async_setup_entry(hass, self) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/velux/init.py", line 52, in async_setup_entry await module.async_start() File "/usr/src/homeassistant/homeassistant/components/velux/init.py", line 102, in async_start await self.pyvlx.load_scenes() File "/usr/local/lib/python3.12/site-packages/pyvlx/pyvlx.py", line 106, in load_scenes await self.scenes.load() File "/usr/local/lib/python3.12/site-packages/pyvlx/scenes.py", line 56, in load await get_scene_list.do_api_call() File "/usr/local/lib/python3.12/site-packages/pyvlx/api/api_event.py", line 29, in do_api_call await self.pyvlx.check_connected() File "/usr/local/lib/python3.12/site-packages/pyvlx/pyvlx.py", line 83, in check_connected await self.connect() File "/usr/local/lib/python3.12/site-packages/pyvlx/pyvlx.py", line 58, in connect await self.connection.connect() File "/usr/local/lib/python3.12/site-packages/pyvlx/connection.py", line 103, in connect self.transport, _ = await self.loop.create_connection( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1122, in create_connection raise exceptions[0] File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1104, in create_connection sock = await self._connect_sock( ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1007, in _connect_sock await self.sock_connect(sock, address) File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 641, in sock_connect return await fut ^^^^^^^^^ File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 681, in _sock_connect_cb raise OSError(err, f'Connect call failed {address}') ConnectionRefusedError: [Errno 111] Connect call failed ('192.168.1.159', 51200)

Additional information

No response

[home-assistant[bot]]

Hey there @julius2342, @deermaximum, mind taking a look at this issue as it has been labeled with an integration (velux) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of velux can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign velux Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

velux documentation velux source _{^{(message by IssueLinks)}}

[pergolafabio]

Guys, are you using the reboot service ? the KLF only allows one connection, so when you restart HA, the next connection sometimes fails its described here: https://www.home-assistant.io/integrations/velux/#service-veluxreboot_gateway

[frr032]

Hi pergolafabio Thanks for your reply. Yes, I have ALWAYS had a reboot automation.

[mmoelli]

any update here? I also experience this issue quite recently. Nothing works, not even the reboot script is working and throwing the same error.

[frr032]

Unfortunately, we have been still waiting. Also, the entities that were in the custom integration have not been added back this integration either.

[RALFISBORN]

Are there any updates regarding the shutter position?

[lorot19]

I solved this problem with HW workaround. Reactions of KLF200 was so unpredictable that I decided to use digital inputs of KLF200 together with PLC controller but any ESP microcontroller would do same job as well. Using digital inputs has zero latency and 100% success. Additional benefit is that you dont need velux integration which requires device reset after HA restart. For me its best and futureproof solution for this old gateway with old fw.

[RALFISBORN]

I solved this problem with HW workaround. Reactions of KLF200 was so unpredictable that I decided to use digital inputs of KLF200 together with PLC controller but any ESP microcontroller would do same job as well. Using digital inputs has zero latency and 100% success. Additional benefit is that you dont need velux integration which requires device reset after HA restart. For me its best and futureproof solution for this old gateway with old fw.

Yes, ok, but that shouldn't be the general solution. After all, there is the shutter position in the KLF and it's actually just an integration bug that needs to be fixed :)

[lorot19]

I solved this problem with HW workaround. Reactions of KLF200 was so unpredictable that I decided to use digital inputs of KLF200 together with PLC controller but any ESP microcontroller would do same job as well. Using digital inputs has zero latency and 100% success. Additional benefit is that you dont need velux integration which requires device reset after HA restart. For me its best and futureproof solution for this old gateway with old fw.

Yes, ok, but that shouldn't be the general solution. After all, there is the shutter position in the KLF and it's actually just an integration bug that needs to be fixed :)

Yes, I agree with you, integration needs to be fixed and I mentioned that its just workaround, however for someone facing same problem and reaching this conversation it could be immediate future-proof solution. Additionally this is more secure way as KLF200 is using old FW from 2018 and exposing it to the network could be considered as insecure within few years (if its not isolated). Maybe we should consider adding this workaround as third integration option for velux documentation. (KLF200 over TCP/IP, KIX300 and hardwired KLF200) https://www.home-assistant.io/integrations/velux/

[RALFISBORN]

Yes, I agree with you, integration needs to be fixed and I mentioned that its just workaround, however for someone facing same problem and reaching this conversation it could be immediate future-proof solution. Additionally this is more secure way as KLF200 is using old FW from 2018 and exposing it to the network could be considered as insecure within few years (if its not isolated). Maybe we should consider adding this workaround as third integration option for velux documentation. (KLF200 over TCP/IP, KIX300 and hardwired KLF200) https://www.home-assistant.io/integrations/velux/

I completely agree with you about the safety of the KLF and yes, measures are also needed there to reduce or prevent damage.

Why not? It's certainly a good option to include them in the integration.

I didn't mean any offence about the workaround either ;)

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[RALFISBORN]

Unfortunately, the problem in the standard integration has not yet been resolved. I am currently using the custom integration (https://github.com/pawlizio/my_velux) instead, which provides all functions and works.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[RALFISBORN]

The bug still exists, please do not close it

[frr032]

The bug still exists, please do not close it

Agreed. Many entities that were in the custom integration are missing in the standard integration.

[wollew]

So this issue seems to address at least two separate things:

1. connection problems with the KLF200: both this and the custom integration use the same logic (and very similar code) when it comes to dealing with the finickiness of the KLF200. They use the same library to disconnect from the KLF200 before HA is stopped which in turn will reboot the device. The automation to do this manually is not necessary any more, and its mention should probably be removed from the docs, I'll open a PR for this. What you can do if your KLF connection is still unstable is use a switched outlet to powercycle and reload the integration if entities become unavailable via an automation. What you should avoid is trying to connect to the same KLF200 from multiple installations, this will almost certainly lock up the device and only turning it off and on will allow new connections again. So, to summarize, start by removing the reboot automation, if you're still having problems providing debug logs would be the next step but also at the end of the day the KLF200 is and probably always will stay buggy, this integration and the pyvlx lib (used by both core and the custom integration) can only try to work around it.
2. features that exist in the custom integration and not in the core integration: yes this is true but to my understanding it doesn't belong in a bug report or rather should keep a bug open. Some of the code from the custom integration has made its way back into core (like the config flow stuff for example), I am not sure how @pawlizio decided when to do this and when not. It is certainly a lot easier to test and publish new code and features in a custom integration than in core, I suspect this being one of the reasons.