I hope so…
I just have to create a pull request then I guess it will be part of the official component.
I’ve done countless hass.io reboots since the last patch and I haven’t seen one single hickup
I hope so…
I just have to create a pull request then I guess it will be part of the official component.
I’ve done countless hass.io reboots since the last patch and I haven’t seen one single hickup
@gibman
Have you had a chance to look at my logs which failed?
Is there anything I can test at my end which might help?
@jasebob : yeah… They don’t really tell much, other than not being able to establish a connection within the allowed timeout period.
hass.io seems to dispose the old log file upon boot. It’s the “old” log file that is more interesting, as it says something about velux klf disconnect being called or not.
btw. if you hard reset your hass.io then I guess the problem could still occur.
This patch only works when hass.io is being soft booted.
But I guess you already know this
regards
gibman
If by hard reset you mean pulling the power, and soft reset you mean clicking / calling restart server, then yes that’s understood.
But we also want hard reset to work eventually, especially in case of power outage. Is there a possible race condition between the boot of the Velux hub and HA on the rasberry Pi. If the Velux is not ready will HA hang or fail and then be unable to access all of the Velux devices?
Anyone know you you can disable the rain sensors build into the Velux units?
Ideally I’d be able to send a command which force disabled them for a period using node-red but didn’t disable fully (or a node-red command can reinstate)
Use Case: Ability to force open for cooking to 30% open
If needed if someone knows how you can just disable them but just thinking if the velux component goes down at some point then not great if it rains.
Found this which might be helpful but not sure how do go about it after that - http://klf200.renejosefsen.dk/KLF200_API.pdf
Hi all,
After a fair bit of research, I finally bought and installed a Velux blind for my fixed skylight here in the U.S. along with a KLF200 and wanted to share for those looking to do the same. (Probably information overload for others)
Velux Components:
Theses particular blinds are controlled by the io-homecontrol at 2.4GHz.
Specifically (looking through FCC docs), it uses the same radio channel(s) as Zigbee for channels 15, 20, and 25 (but no indication it runs Zigbee’s higher layer protocols). The power levels are around 10mW. Compared to WiFi of around 100mW, the io-home control power is quite a bit less, but then the bandwidths (around 250kbps) are much smaller and thus the higher power is not required.
KLF 200 comes with
Home Assistant
Hope this is helpful to others.
Could you repeat the instructions for including your component, I’m sure it’s me but I couldn’t quite follow them.
I’ve copied in the folder, but then got lost with the init and import part. I’m on Hassio.
I’ve done 8 consecutive reboots and no problems so far
Latest file for reference is here:
https://github.com/home-assistant/home-assistant/blob/789ad38c38917c8a9ec730038c8c2e8e6164d889/homeassistant/components/velux/ init .pyI’ll create a branch a pull request for this if others are seeing good results
I can confirm this latest patch is very stable across reboots also for me.
Very strongly suggested to create a pull request!
Great job!
Are there any suggestions about demonstrating whether the KLF200 can be reached via LAN? I have set up the KLF200 with the KLR200 so that I can operate the Velux window with my PC connected to the KLF200 using the VELUX_KLF_XXXX wifi connection.
I have connected the KLF200 to the house LAN and I get a successful ping using its LAN IP address (192.168.1.241).
But I cannot then connect my PC to the KLF200 using its LAN IP address. Typing in 192.168.1.241 gives me the “Unable to connect” error.
Having added the Velux configuration to configuration.yaml (tried using the wifi password, and “velux123”) I get an error message in the logger that includes “Login to KLF 200 failed, check credentials” .
Should I be able to log on to the IP address of the KLF200 (192.168.1.241) from my PC? If not, will the custom components mentioned on this page work (I use hassbian, not hassio).
Thank you for advice!
See if my write-up from above helps:
In short, the WiFi is good for initial setup, but after that the LAN port has to be used by HA.
Thank you for your advice @wmaker. Looking at your explanation, it looks like I have got as far as the end of the first bullet point of the section headed Home Assistant. In spite of rebooting both my Pi 3B and the KLF200 I continue to get the error message “Login to KLF 200 failed, check credentials”.
Does anyone know if it is possible getting access to the KLF200 via it’s IP address. I have tried 192.168.1.241 but that doesn’t work. Is there something I should add on to the IP address that opens the Velux home page? I have tried 192.168.1.241/klf200.velux but no success. If I could do that at least I could prove that the KLF200 is satisfactorily configured to work on the intranet.
You can only get to the Velux Web page via wifi using your mobile device and using the SSID VELUX_KLF_xxxx. (xxx is some number) and use the password printed on the back of the KLF200. After you first power up the KLF200, it goes into AP mode for about 10 minutes and provides this SSID and Web page. You have to use the URL: http://klf200.velux
The LAN port IP Address is either configured as static using the Web page or is auto-configured using DHCP from your router. I set mine up for static IP address that Home Assistant can use in its configuration.
I have another weird issue: I have 12 windows and blinds, and using automatically created scenes (as defined in the KLF 200) works, e.g. open all windows in a room. But it also imports every window and blind separately into HA. Which causes major headaches because they get sorted differently on every HA restart as it seems.
E.g.: window_4 is sometimes one in the living room, sometimes one in the office. There is no real pattern here, it seems completely random.
for automations I use the scenes, which is fine, but I’d like to have the ability to control individual windows from within HA, which is now impossible due to the randomness.
Any ideas?
Interesting behavior with the KLF scenes…in my case, I setup my skylight covers individually with the KLF configuring a name for each cover, and then let HA discover them which it does likewise as individual covers, each with the name that I configured in the KLF (so is consistent across restarts)). I can HA group them, put them in HA scenes, etc.
Hello, is anybody else experiencing connection (drop) problems? Here, the connection drops quite often, something like every few days (at least). Power cycling the KLF helps, but this problem prevents productive use of HASS for controlling my blinds… It’s simply way too unreliable in my setup. I’m running HASS 0.99.2
Henning
Upgrade at latest HA: it includes some fixes in that respect
@henning I was one of the very earliest users and I have never had drop out problems.
My one and only problem is on restarts, about 10% of the time HA cannot reconnect to the KLF. This is related to the quote you made about KLF only allowing two sockets. There are fixes earlier in this thread for that, and they improved it dramatically but were never a 100% fix.
FYI - I am still running around on 0.97.2, and a custom velux component from this thread.
I do get drop outs, but rare as I’m always rebooting HA for a new this or new that (and hitting the problem jasebob talked about), but today my automation fired to close my skylight blinds and I got another ConnectionRefusedError: [Errno 111] Connect call failed
. Around 10 minutes later HA reconnected on its own, I clicked my icon on HA to close the skylight blinds and it worked no problem. So yes communication with the KLF could be better (just not sure how).
If I understood it correctly, FHEM uses KLF’s second socket to initiate a reboot as soon as the connection to the first socket fails. It’s kind of a brutal approach, but maybe worth looking into