Hello @lukqw,
the QA has taken some more time. The newest version, being tested with JSON and SLIP, is now available at github with an updated README as well.
Regards, Guenther
Whats new in the latest version from 08.07.2019?
Hello @Kim_Andersen,
the new minor release includes:
- Bugfixes for the JSON/HTTP connectivity (which now works again fine even with firmware 2.x),
- Enhancements like detailled comments for activation with OH2, more information during actuator state modification for debugging, intensive logging for recognition of other io-homecontrol (i.e. Somfy) devices, and new channel timestamp for recognition of KLF-communication failures.
Regarding the latest mentioned point: There seem to be some KLFs in the world which suspend their communication activity⌠with this new channel (providing the timestamp of the recent successfull communication) it is easy to recognize such an issue and automaticly react on it (for example by powering off-and-on of the KLF).
Regards, Guenther
Regarding the inversed actuator representation, the first approach by adding a separate channel flag did break the OH1 pilot installations (other config syntax ;-( ). Currently thinking of introducing just a separate âinversed-actuatorâ for addressing the strange window level encoding.
Installation of the new version once again broke my Velux setup :-(. No actuators are found anymore on the bridge (v2 firmware).
Thanks, @nosepull, for your feedback.
Just to verify the setup: the KLF is completely configured and all the missing actuators are visible on the web interface of this gateway? In that case, please send me the logfile with level trace for org.openhab.binding.velux for your convenience my PM⌠it should report at that point each device as visible from the view of the gateway.
Thx, Guenther
Hi again,
the implementation of a convenient way for both OH1 and OH2 drove me a little bit crazy: For the time being a quick work-around implementation works fine for me: Appending a star to the serial number activates completely reversed behaviour:
Rollershutter V_Window "Fenster Bad [%d]" { velux="thing=actuator;channel=serial#56:12:3E:26:0C:1B:00:01" }
Rollershutter V_Window_Reversed "Fenster Bad [%d]" { velux="thing=actuator;channel=serial#56:12:3E:26:0C:1B:00:01*" }
Do you have interest in it?
Regards, Guenther
The actuators are still visible in the gateway. Right now I made the mistake (?) of restarting the gateway. The KLF LED is flashing, and the binding does not even connect anymore (connection refused in the logfile). Is there something Iâm missing in the setup of the KLF?
Edit: OK, two more restarts and the connection works at least. The status item reports the usual value. However, no actuators (yet?).
When I updated to the previous version, the actuators were missing at first, too. I donât know what I did then to make them reappear.
Edit 2: A few minutes later, the item âregistered productsâ at least contains a value (0_members). Is there some kind of veeeeeery long synchronisation with the bridge going on? Lots of entries like that in the log:
2019-07-10 07:13:41.704 [WARN ] [nding.velux.bridge.slip.SCgetProduct] - Gateway response GW_GET_ALL_NODES_INFORMATION_FINISHED_NTF (517) cannot be handled at this point of interaction.
Edit 3:
15 minutes after the restart the actuators are back. Obviously I need a (successful, i.e. no blinking LED) restart of the bridge after an update of the binding. I tried for hours fiddling around with OpenHAB and the binding, I admit I didnât think that the KLF should be restarted (why???).
From time to time the KLF disables the network interface on the LAN port if there is no traffic. According to the Velux manual, the âTCP/IP socket will be closed after 15 min, with no communication.â. In fact, Iâve recognized that the shutdown is not limited to established connections but even for the (hopefully) listening port. A power-cycle solves this issue - but the gateway should reappear with all actuators within 90 seconds.
Seemingly I have a very slow setup. As I said, 15 minutes until the actuators reappear. But as this only happens after updates and restarts (hopefully), I can live with it.
To put it in a nutshell: Are your actuators back and controlable after 15 minutes ?
Yes. I followed the logs and the Velux items came online after a time, with lots of warnings like âGateway response W_GET_ALL_NODES_INFORMATION_CFM (515) cannot be handled at this point of interactionâ in between. The actuators (products) are controllable.
As a sidenote: There are quite a few more âadministrativeâ subchannels for the bridge defined in the GitHub readme. Most of them donât work for me (not that they are necessary, I was just curious), they are empty most of the time.
The WLAN Password even fails with
Caused by: org.openhab.model.item.binding.BindingConfigParseException: Velux binding: item âitemNameâ is of type âStringItemâ, âSwitchItemâ is allowed - please check your *.items configuration (ignoring binding âthing=bridge;channel=WLANPasswordâ)
I have no scenes defined, the respective subtype is most of the time empty, but sometimes it contains a value like â0_membersâ or something like that.
So I have the impression that something somehow gets lost between the bindingâs items and the KLF.
If it works, ofcouse I´ll be interested⌠I hate to see my windows beeing at 100% and fully closed 
If you are willing to share them, it could lead to a bugfix (if there is a bug and not just bad time to ask).
Thx Guenther⌠I´ll give it a shot tonight and see what happens.
I really appreciate your hard work!
seems to be working now!
I occasionally get a
2019-07-10 15:22:14.367 [ERROR] [org.openhab.io.net.http.HttpUtil ] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
error, but it âreconnectsâ afterwards again.
thank you very much
longer log version:
2019-07-10 15:30:38.008 [TRACE] [ding.velux.bridge.json.JsonBridgeAPI] - bridgeDirectCommunicate(org.openhab.binding.velux.bridge.json.JCgetDeviceStatus@e52373,true) called.
2019-07-10 15:30:38.010 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeDirectCommunicate(get device status,authenticated) called.
2019-07-10 15:30:38.013 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeCommunicate(): using SAP http://10.3.0.10:80/api/v1/device.
2019-07-10 15:30:38.017 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() to http://10.3.0.10:80/api/v1/device using request {"action":"getDeviceStatus","params":{}}.
2019-07-10 15:30:43.030 [ERROR] [org.openhab.io.net.http.HttpUtil ] - Fatal transport error: java.net.SocketTimeoutException: Read timed out
2019-07-10 15:30:43.034 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): Exception occurred during I/O: transport error.
2019-07-10 15:30:43.039 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): wait time 5000 msecs.
2019-07-10 15:30:48.045 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() to http://10.3.0.10:80/api/v1/device using request {"action":"getDeviceStatus","params":{}}.
2019-07-10 15:30:48.145 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io(): wait time 5000 msecs.
2019-07-10 15:30:53.149 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() got response )]}',.{"token":"rFFfbPNKMzYSJTwnPWYVAw==","result":true,"deviceStatus":"IDLE","data":{},"errors":[]}.
2019-07-10 15:30:53.154 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - io() cleaned response {"token":"rFFfbPNKMzYSJTwnPWYVAw==","result":true,"deviceStatus":"IDLE","data":{},"errors":[]}.
2019-07-10 15:30:53.161 [TRACE] [ng.velux.bridge.json.JsonVeluxBridge] - bridgeCommunicate(): communication result is true, returning details.
Thanks for your efforts. Here the Velux-relevant log entries of my successful boot. The log contains no hint that the actuators were finally found, now that I look at it.
Thanks, @nosepull, for the log file. Have never seen such an amount of unusal events:
-
The KLF needed about 22 minutes to recover from a reboot (assuming that the log started after a reboot of this gateway). This should take not longer than a minute.
-
Many out-of-sequence or duplicate answers of the KLF (i.e. login request followed by two login-succeeded answers, get-scenes-request followed by two confirmations) during the initial five minutes after the KLF being alive again.
If the connectivity between OH and all actuators stays stable now, I would like to put this issue into category unknown magic. If there occurs some error in the next days, please increase the loglevel towards TRACE to verify that neither the Ethernet connection is broken or the KLF itself has got a damage.
Just installed the âmagicâ version⌠It seems to work fine using the â*â in the channel⌠Now he direction is correct, (BasicUI Rollershutter icons are wrong, but I can live with that and create my own icons 
).
1 Like
Since the reboot there have been no further log messages from the Velux binding, and it seems to work fine (I kind of hesitate to reboot itâŚ).
1 Like