[velux] New OpenHAB2 binding - feedback welcome!

AndrewFG · April 26, 2022, 2:02pm

@GeVaSta a couple of comments…

I don’t have any roller shutters with tilt in my system. And nothing from Somfy. So I do need your feedback if either (or both) of the two JARs works.
I do however have a Velux roller shade on a Velux roof window, which reports different values for Functional Parameter 1 depending on whether the existing/legacy or new/alternate API calls are used (in the former FP1=F7FF (undefined) and in the latter FP1=0). The latter is more likely to be a proper value, so this evidence makes me think that the new/alternate API is more accurate. So my guess is that the new/alternate JAR is more likely to work for your case as well.

GeVaSta · April 26, 2022, 3:28pm

Looks like you are betting on the right horse now😉.
Perhaps it is not a coincidence HA uses this 300-api calls.

I hope this solves the problems also for my Somfy blinds.

hmerk · May 10, 2022, 11:10am

Hi Andrew,
just got my velux windows and shutters installed yesterday and would like to describe my experience so far:

Connecting openHAB to KLF 200 (actual firmware)
Documentation needs to be precised, as I could not establish a connection as long KLF access point is open. User should not change the settings for access point beeing always on.

openHAB Milestone 5 Binding version
Even the documentation states different, items bound to the position channels stay UNDEF when window or shutters are opened/closed completely, no percentage values shown.

PR Binding version with new API calls
position channels ignore STOP command.

AndrewFG · May 10, 2022, 1:27pm

Can you please be more specific about what you mean by “access point”?

What items do you mean? Can you please post your items and things definitions?

Again can you please be more specific? If the items are UNDEF as you say above, then any command to those items would fail anyway.

hmerk · May 10, 2022, 1:38pm

The webpage for configuring the KLF 200 is only avalable with it’s own WiFi access point (SSID VELUX_KLF_xxx). As long as this one is active, the KLF is not communication over LAN.

ID: velux:rollershutter:192_168_0_113:Roller_Shutter_Office
label: Roller Shutter Office
thingTypeUID: velux:rollershutter
configuration:
  name: Roller Shutter Office
  inverted: false
  serial: 53:12:3F:32:15:31:03:B3
bridgeUID: velux:klf200:192_168_0_113

Did not check if the state is schown as UNDEF with you new API version, but UP/DOWN commands are working, just the stop command fails.

AndrewFG · May 11, 2022, 7:29am

In your screenshot it shows the channel defined as ‘velux:window:…:position’ whereas your item definition seems to be for ‘velux:rollershutter:…:position’ — so which one of these is not working?

In any case, there should not be any difference between the release version of the binding and the version in my PR concerning commands to the ‘position’ channels. I did not touch that code. I only added code for a new channel to handle vane/slat angle.

This is true. After you have finished configuring the KLF via its private AP, you need to power cycle it before it will accept connections on the LAN.

PS you may have seen in this thread that the KLF is very quirky concerning LAN reconnections. So while you are initially playing around with the configuration, I would recommend to disable the bridge thing in OH, then power cycle the KLF, and then re enable the bridge thing.

hmerk · May 11, 2022, 8:25am

Sorry for the confusion, copied the wrong screenshot.
Nevertheless, without any changes, It started reporting correct values a couple of minutes ago…
Strange …

What I would like to mention is not to change the WiFi AP to be permanently on, what I did by mistake. Even after a power cycle, LAN connection was not working. Only after changing WiFi AP back to default, shutting down after 10 minutes, the bridge thing came ONLINE.

AndrewFG · May 11, 2022, 9:00am

Ok. I can add something about that to the ReadMe.

EDIT: I forgot to ask: is the Stop command now working for you as well?

hmerk · May 11, 2022, 11:09am

It was always working with the original binding, but it is not working with the new API.

AndrewFG · May 11, 2022, 11:23am

Could you please turn on log:trace and post the log when your the stop command fails?

hmerk · May 11, 2022, 11:30am

I will try later today…

AndrewFG · May 15, 2022, 5:52pm

I have added a paragraph to the Read Me.

Please let me know if you have a log, so I can eventually fix your issue…

hmerk · May 15, 2022, 6:22pm

Thanks !

Sorry, did not find the time to try again the new version. Will try the next couple of days…

AndrewFG · May 15, 2022, 6:38pm

I think I may have found and fixed the problem. I uploaded the two latest JAR files (new API and legacy API) to the Pull Request page on GitHub. So please let me know if it is now fixed.

acfischer42 · June 1, 2022, 5:12pm

Hello,
having troubles getting actuator information back to Openhab. Typically during the winter I am not using my windows and don’t check if the connections are working. But now already for some weeks I am trying to get them to work again without success.
Issue: Position is UNDEF
System:
Openhab 3.2 stable
Velux Binding - the official one, and as well the last to jars posted here.
Velux Integra Windows, KLF 200 with FW 2.0.0.71
Windows move when commanded by Velux Remote control.
Windows get detected properly in the binding, I can set up the position items in the GUI.

from the Trace log

2022-06-01 18:43:57.559 [TRACE] [internal.things.VeluxProductPosition] - VeluxProductPosition(constructur with 63487 as veluxPosition) called.
2022-06-01 18:43:57.559 [TRACE] [internal.things.VeluxProductPosition] - VeluxProductPosition() gives up.
2022-06-01 18:43:57.559 [DEBUG] [.internal.handler.VeluxBridgeHandler] - handleCommandCommsJob(): updating channel velux:window:192_168_188_222:Window_Bed:position to UNDEF.

trace.txt (352.1 KB)

Any ideas? my next one would be to factory reset the KLF and start from scratch there.

thanks a lot
Achim

AndrewFG · June 1, 2022, 5:46pm

Don’t do that. Just try a power cycle.

acfischer42 · June 1, 2022, 6:31pm

Andrew, thanks a lot for the quick reaction,

I just did another power cycle as I had realized I had not done so after updating the Binding, but still with the same results.

Thanks

Achim

AndrewFG · June 1, 2022, 7:07pm

Ok. I will look at your trace tomorrow.

acfischer42 · June 1, 2022, 7:31pm

Thanks a lot for the help. I just discovered that removing and re-adding one of my windows to the KLF made another one work. !?!
I guess I will do the reset. will report back if still needed to look at the trace.
Achim

[update] - did the Factory Reset and that fixed the problem. Something must have gotten stuck in the KLF, not sure what that would be. Anyway - Again thanks for the help and sorry for causing work.
Appreciate you work on the binding!

AndrewFG · June 2, 2022, 7:10pm

That is good to hear.

Indeed. In fact your log also says that something got stuck. To be precise, the KLF was reporting the position value 63487 (i.e. F7FF hex) which is a special value meaning “No feed-back value known”. The binding was correct to show that as UNDEF in the UI, and the error did indeed come from the KLF.

2022-06-01 18:43:57.559 [TRACE] [internal.things.VeluxProductPosition] - VeluxProductPosition(constructur with 63487 as veluxPosition) called.
2022-06-01 18:43:57.559 [TRACE] [internal.things.VeluxProductPosition] - VeluxProductPosition() gives up.