Remove Velux KLF disconnection on HA stop event#47465
Remove Velux KLF disconnection on HA stop event#47465pawlizio wants to merge 2 commits intohome-assistant:devfrom pawlizio:velux_on_stop
Conversation
|
Hey there @Julius2342, mind taking a look at this pull request as its been labeled with an integration ( |
| async def on_hass_stop(event): | ||
| """Close connection when hass stops.""" | ||
| _LOGGER.debug("Velux interface terminated") | ||
| await self.pyvlx.disconnect() |
There was a problem hiding this comment.
It seems weird that we would not cleanly disconnect. Why is an automation even necessary to reboot. Seems like we're now asking each used to solve the same problem
There was a problem hiding this comment.
After some hours of operation the KLF200 Gateway refuses new connections. If HA restarts, the connection build-up run into timeout during SSL Handshake. So if I start a reboot of the KLF200 before HA shutdown I can establish a new connection after HA is rebooted. Finall it's just a workaround. A disconnect function is considered in the destructor of pyvlx.connection, so I think it will not change much to remove this functionality on HA component side.
There was a problem hiding this comment.
Yes of course it would be much simpler for the user if we hardcode that, so they will not need to create an automation for that. Only point to consider is that KLF200 starts a wifi access point after each reboot where you can perform configurations. It's usually protected by a password if the user does not remove that. In the standard configuration this access point will be closed after some minutes. Finally my safety concerns are the reason not to hardcode this automation.
There was a problem hiding this comment.
@pawlizio : IMO all explicit disconnects are preferred bc then the disconnects happen in a controlled way. I guess als hass-shutdown process waits untill the disconnect is finished.
But yes, this buggy behavior of the KLF 200 gateway is annoying. There is another PR from you #42773 - where you implemented an explicit service to reboot the gateway from time to time. Isn't this the better approach?
There was a problem hiding this comment.
Only point to consider is that KLF200 starts a wifi access point after each reboot where you can perform configurations. [...] Finally my safety concerns are the reason not to hardcode this automation.
Valid point m-/ .
There was a problem hiding this comment.
The reboot service is already available in the component and yes you can start them periodically. But my preferred way was to initiate the reboot in parallel to a HA restart. Main concern was to reduce the amount of unnecessary KLF reboots and the corresponding opening of the Wifi Access Point to a bare minimum.
|
i can confirm this PR is now working, my gateway is now rebooting on shutdown event with automation |
|
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. |
Proposed change
The newly merged workaround #43198 for to the issue #34844 does not work if the disconnection command is initiated on HA stop event. So in order to be able to reboot the velux KLF gateway as discribed in the automation example it is necessary to remove this functionality.
Type of change
Additional information
Checklist
black --fast homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all..coveragerc.The integration reached or maintains the following Integration Quality Scale:
To help with the load of incoming pull requests: