Hello @lukqw,
thank you for the output: the communication looks good now except for the timeouts.
If those errors still occur, please try to increase the timeoutMsecs parameter. BTW please check the basic connectivity to the KLF: does an ICMP roundtrip (ping command) works fine?
Did you have success now?
Hi @johannesbonn,
do you hear a difference between normal mode and silent mode (via scenes)? If so, it could be worth to mention this solution within the documentationâŚ
Regards, Guenther
Hi guenther,
sorry for my late feedback, but it seems that there is no possibility to drive a scene in silent mode, even if its activated inside the klf webfronted.
Is there no other way to drive in silent mode?
regards, johannes
Hello Johannes,
in fact, the KLF gateway is able to work on groups of actuators with an optional velocity flag (with meaning normal and silent mode). But the way to define such group of settings is complicated, so that there should be a real benefit before heading to such an implementation.
Therefore Iâd like to know whether there is a hearable difference for anyone as my shutters sound more or less similar in normal versus silent mode.
Ahhhh, now I understand your question. Yes there is a very big difference for the smaller rollershutters. Only for big ones (sk08) I canât hear a big difference. In my opinion there is a real benefit for an implementation.
I hear no differences with my windows. They´re sat to silent mode, but no matter if its scene or direct control, I hear the same.
On the GitHub page there is a hint that one could use a spare wifi connection e.g. of a RPi to âbridgeâ to the KLF admin web ui:
For example the Raspberry PI can directly be connected via WLAN to the Velux gateway and providing the other services via the LAN interface
Has anybody tried that, and if yes, how do you set that up?
Right now after an unrelated OpenHAB restart, I do no longer get the KLF to connect properly :-(. I attached an trace log, maybe that helps to find whatâs going wrong here:log.txt (30.6 KB)
Yes, exactly as stated there.
IP-Autoconfiguration of LAN based on /etc/dhcpcd.conf plus configuration of WLAN based on /etc/wpa_supplicant/wpa_supplicant.conf which looks like:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=DE
network={
ssid="VELUX_KLF_8XYZ"
psk="asJKHKJBEldj78wljhEs"
key_mgmt=WPA-PSK
}
With this, the PI is able to connect to the WebUI and to the SLIP API.
Is the KLF reachable via ICMP echo requests (ping command)?
Yes. Device pingable, WebUI online, actuators visible in the UI. No suspicious log entry in the WebUI. Only the openHAB binding seems to connect only by chance to the API. Happens for me after each binding update, openHab or box restart, it seems.
I guess I have to do a factory reset.
Btw, is there any âofficialâ software for the KLF in order to try if it works with it? I donât quite get Veluxâ business case for the KLF, as this seems to be only usable with 3rd party home automation systems and not, like all the other smart home devices, with some app of the original vendor. Not that I need a Velux app, but it would be great to test the basic functionality of the boxâŚ
If I connect the Pi to the box by WLAN,
Thanks for your support, btw!
ad 1) Yes, but you will limit yourself to start an action with neither response nor status update.
ad 2) If you configure the PI correctly, it works as described.
FYI: it is documented in the README on GitHub, where youâll find the recent comments (hopefully being incorporated into official OH release by PR#5833): please take a look at the recent three sections of this document.
This binding was originated on contact with Velux product mgmt and lateron engineers: they did a great job in documenting their internal APIs. Officially you can choose the Netatmo/Velux solution which IMHO has the caveats of being dependant on their cloud service: I prefer my privacy.
I also prefer the privacy. However, when having a pricky device like me, using the âreferenceâ implementation could help narrow down the problems.
Hi @Nosepull,
thanks for the logfile. Just for your information: the relevant lines had been the following:
04:35:58.301 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet with 7 bytes: C0 00 03 00 0C 0F C0
04:35:58.303 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - send() called, writing 7 bytes.
04:35:58.305 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during sending: Connection closed by remote host.
04:35:58.307 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): wait time 2000 msecs.
04:36:00.309 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): receiving bytes.
04:36:00.314 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - receive() called.
04:36:00.318 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): method io() raised an error: null.
04:36:15.754 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet with 7 bytes: C0 00 03 00 0C 0F C0
04:36:15.757 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - send() called, writing 7 bytes.
04:36:15.761 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during sending: Connection closed by remote host.
04:36:15.765 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): wait time 2000 msecs.
04:36:17.769 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): receiving bytes.
04:36:17.776 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - receive() called.
04:36:17.783 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): method io() raised an error: null.
04:36:33.219 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): sending packet with 7 bytes: C0 00 03 00 0C 0F C0
04:36:33.222 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - send() called, writing 7 bytes.
04:36:33.227 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): raised an error during sending: Connection closed by remote host.
04:36:33.233 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): wait time 2000 msecs.
04:36:35.238 [TRACE] [ing.velux.bridge.slip.SlipVeluxBridge] - io(): receiving bytes.
04:36:35.246 [TRACE] [ng.velux.bridge.slip.io.SSLconnection] - receive() called.
04:36:35.252 [WARN ] [ing.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(): method io() raised an error: null.
In fact, I was able to reproduce this scenario by running more than one separate instance of OH directing requests onto one KLF: in that case, the gateway is responding by dropping the connection. According to the KLF-API spec this should occur with the third connection to be established. Will keep you informed.
I had the same idea, somehow. However, nothing else in my net should access the bridge besides OpenHAB.
However, my problem has slightly changed, doing the factory reset (both by the reset button at the back and with the UI) has f**ked up the box completely: Now I can not even pair my existing actuators any more, the pairing process does not find any products (rollershutter remotes pressed at the settings button, rollershutters move up and down, KLF finds nothing).
Tried to re-update the firmware, too, but that was rejected as âtoo oldâ?!
Grrrr! Is there something more I can do? I guess Iâll have to look for a refund,!
Edit: System log shows errors, too
Screenshot_20190712-125602_Bromite|281x500
Your new problem is that your devices (rollershutters etc.) now also have to be factory-reset (and thus reprogrammed) before you can pair them again. See my revious post here: https://community.openhab.org/t/io-homecontrol-velux-somethings-in-the-bush/11413/120.
I feared something like that :-(. Unfortunately neither the Velux WebUI nor the instructions for the KLF200 hint at something like that.
Is the procedure for Velux shutters the same as for Somfy shutters?
However, the error messages in the protocol after the firmware reset (in connection with the problems I had already before the reset) make me tend to be believe that there is something else wrong with the boxâŚ
