Closed hilsonp closed 7 months ago
Hi, I'm actually thinking whether these options should be adjustable by users or not. Finally those are quire technical two fields.
pyvlx Heartbeat intervall (value in seconds) => Default is 30 seconds pyvlx load_all_states during heartbeat (True or False) => Default is true
A pyvlx Heartbeat intervall defines how ofter per second HA sends a get_state command to KLF200. It's original idea was to keep the communication between HA and KLF200 open.
KLF200 has a function called House Status Monitor, which shall provide state change information of the io-homecontrol devices.
However those states are not always complete and therefore some developers started to pull the states separately on this Heartbeat, espeacially for states of some devices which are always not provided correctly.
Those values however are provided in a status request which can be send to KLF200.
This second option is about sending a status request for all devices managed by the KLF200 on each heartbeat intervall.
Now depending on the set intervall and the amount of devices which are managed by KLF200 you quitely can block your API with a lot of communication between HA and KLF200.
I don't think each user is quite aware about those technical details and I'm thinking to remove this options again.
@dumpfheimer: As I'm working on it to prepare this custom for a merge into HA native velux component, do you think this option is really necessary on UserInterface. Currently on my update branch (which is the one I prepare for a HA native velux) I moved them into Configuration Options of the KLF200, but I'm thinking to remove this options completely. Otherwise they should be documented for normal users.
I can't help you decide but...
I'm soooooo happy to read that you work on collaboration with the official integration ❤️
I must say that I was having a lot of problems with the official integration. Every now and then I had to power cycle the KLF200 and sometimes restart HA. I also never found how to activate logs to further debug.
I switched to your integration and since then:
I'll make another report in a few weeks. Stability is the most important aspect.
I believe the official integration overloads the KLF200 somehow.
Thank you.
Note: this is not a criticism of the official integration but a factual feedback.
@pawlizio I would prefer some sort of configurability. In the end the hardware belongs to the user and the user should be able to do whatever with it. I would like to see it being configurable somewhere. I recognize this will not be changed or considered by probably 99% of people and can absolutely get behind the idea of moving it away from the UI and into e.g. yaml but would prefer any of them over being nit configurable at all.
So, my vote - without considering complexity - would be:
It's great to hear that you are preparing a merge!
@hilsonp It's less like the original VELUX integration overloads the device. The truth is more like: this integration does more to prevent the device from locking up.
The KLF200 is not what one could call reliable.
@dumpfheimer
`The truth is more like: this integration does more to prevent the device from locking up.
The KLF200 is not what one could call reliable.`
This is probably what I ment 😌
Concerning the unreliable device, I tried to setup an automation power cycling the KLF200 but failed to find a trigger. I still have to see the KLF200 failing with this integration to try to deduce a trigger from the reported states.
Thank you anyway to both of you for the work done for the community ❤️
Unfortunately this additional stability is paid with a security issue. When HA stop we force the KLF200 to reboot. After reboot the KLF200 opens it's WiFi Access Point for 15 mins if I remember correct. If then the default password has not been changed, this is a gate opener to get control over io-homecontrol devices.
Is there maybe some way to test if the default password has bee changed? Without connecting to wifi..
Seems that I had this topic never finally evaluated. Just now I tried to access my the WiFi Access Point again and figured out, that it has the same password as used to access the API via pyvlx, this password is quite individual. The weak password is just behind the the WiFi Access Point, it is the Login password on the web UI.. so it is not really unprotected.
This is closed, those two configuration fields are now available as configuration entities of KLF200 Gateway device and can be changed at any time and also from automations.
@dumpfheimer
`The truth is more like: this integration does more to prevent the device from locking up.
The KLF200 is not what one could call reliable.`
This is probably what I ment 😌
Concerning the unreliable device, I tried to setup an automation power cycling the KLF200 but failed to find a trigger. I still have to see the KLF200 failing with this integration to try to deduce a trigger from the reported states.
Thank you anyway to both of you for the work done for the community ❤️
I wanted to drop a feedback. I have been using your integration for the last month and it has been rock solid. I had no one glitch while the standard HA integration was, from my experience, very fragile. Additionally, your integration gives me the 'opening' and 'closing' states which is really useful when managing several velux as a group. Thank you so much !
I gave a try to your integration and installed the 2.9.5 version.
While adding the klf200, the configuration shows 4 fields:
I suggest you add a small description to the 2 latest fields.
Thank you for this integration !
Note: Just in case, reading through the changes, I saw that you had a typo "Abstraction for al Velux" where you probably ment "Abstraction for all Velux". I just took note but finally did not fork your repo to submit a PR... So I give you the info here. Sorry if this is not precise.