[velux] New OpenHAB2 binding - feedback welcome!

Tags: #<Tag:0x00007f5c9eefad10> #<Tag:0x00007f5c9eefac20>

Found my issue: I was using a mix of 1.x and 2.x versions :slight_smile:
Now it works like a charm.

thanks
Andrea

edit:

Just for reference, I’m seeing in my logs this warning:

00:02:40.538 [WARN ] [al.handler.utils.Thing2VeluxActuator] - mapThing2Velux(): aborting processing as serial is not set.
00:05:04.688 [WARN ] [al.handler.utils.Thing2VeluxActuator] - mapThing2Velux(): aborting processing as serial is not set.
00:06:04.731 [WARN ] [al.handler.utils.Thing2VeluxActuator] - mapThing2Velux(): aborting processing as serial is not set.
00:16:45.301 [WARN ] [al.handler.utils.Thing2VeluxActuator] - mapThing2Velux(): aborting processing as serial is not set.
00:22:19.613 [WARN ] [al.handler.utils.Thing2VeluxActuator] - mapThing2Velux(): aborting processing as serial is not set.
00:31:36.118 [WARN ] [al.handler.utils.Thing2VeluxActuator] - mapThing2Velux(): aborting processing as serial is not set.

@gs4711

Hi Guenther,

today I’ve re-created everything from scratch, as some Velux changed their security keys (how to prevent that?). So I’ve removed all products from KLF-200, then re-imported … and now I have also issues with some timeouts (some Velux start working after a while).

Here my .things file:

Bridge velux:klf200:home [ipAddress="192.168.100.240", tcpPort="51200", password="xxxxxx", timeoutMsecs="1000", retries="10"]

and here the log I can see any time I send a command via OH

14:43:59.113 [WARN ] [al.handler.utils.Thing2VeluxActuator] - mapThing2Velux(): aborting processing as serial is not set.
14:45:19.221 [WARN ] [al.handler.utils.Thing2VeluxActuator] - mapThing2Velux(): aborting processing as serial is not set.

here my TRACE:

https://justpaste.it/5ykqu

Can you please help me?

thanks
Andrea

1 Like

Hi Guenther @gs4711
I tried to go to your Github repository here to report an error, but the tab called ‘Issues’ at the top next to ‘Code’ is missing. This means I cannot give feedback on the Github site - can you open for this tab?
Until then, I have to use this thread for feedback to your excellent work.

This combination works fine: openhab ver 2.5.1 and your stuff version 2.5.1.202001051139
If you upgrade to the latest stable version of openhab 2.5.2, the log gets spammed with errors as I showed in current thread a few days back.
If I then run openhab 2.5.2 with velux version 2.5.3-SNAPSHOT, I still get the errors.
If I then revert to openhab 2.5.1 with 2.5.3-SNAPSHOT, the errors go away, but suddenly my window starts reporting wrong status.
Therefore, I eventually ended with also rolling the velux binding back to version 2.5.1.202001051139, and then everything is fine again without errors.

Edit: It is working fine with openhab version 2.5.3 with included Velux binding

Did you try 2.5.1202001051139 with OH 2.5.3?

As I’m also seeing strange logs with Velux Binding 2.5.3-SNAPSHOT-PR7098+7102-20200305

Andrea

No, I have not tried that combination.

where I can find 2.5.1202001051139 ?

I will try with OH 2.5.3

Hello,
I am using this binding successfully.m Thanks a lot for the great work! Unfortunately, the batteries of my solar rollershutters have started to die and after replacing them it seems that I have to register the rollershutter anew. What is the recommended procedure to do this? I would really like to avoid adding and configuring all my Velux devices again. Is that possible?
Many thanks and best wishes,
Jonas

So I finally tried openhab version 2.5.3 with no Velux add-ons file. That is simply running the current latest stable version out of the box. And it seems to work perfectly with no errors in the log and correct status of Velux components.

Hello everyone. Thanks for supporting the community, hope you guys can help me as well. After migrating from a raspberry pi to linux-dockered openhab things are back set up except for velux. I am using OH 2.5.3 and 2.5.3 prepacked addon of velux as well as org.openhab.binding.velux-2.5.3-SNAPSHOT-PR7098+7102-20200305.jar. Either of them let me control the shutters althoug things are up and green. Any ideas? Thanks in advance A

LOG file(s) excerpt.


2020-03-26 08:36:08.339 [hingStatusInfoChangedEvent] - 'velux:klf200:home' changed from UNKNOWN to ONLINE

2020-03-26 08:36:08.340 [hingStatusInfoChangedEvent] - 'velux:rollershutter:home:RollerShutterBedRoom' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE

2020-03-26 08:36:08.340 [hingStatusInfoChangedEvent] - 'velux:rollershutter:home:RollerShutterKidsRoom' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE

2020-03-26 08:36:08.440 [vent.ItemStateChangedEvent] - Current_DateTime changed from 2020-03-26T08:35:08.441+0100 to 2020-03-26T08:36:08.441+0100

2020-03-26 08:36:08.440 [vent.ItemStateChangedEvent] - CurrentDateTime changed from 2020-03-26T08:35:08.441+0100 to 2020-03-26T08:36:08.441+0100

==> /log/openhab.log <==

2020-03-26 08:36:13.921 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:klf200:home tried checking if channel status is linked although the handler was already disposed.

2020-03-26 08:36:13.921 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:klf200:home tried checking if channel reload is linked although the handler was already disposed.

2020-03-26 08:36:13.921 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:klf200:home tried checking if channel downtime is linked although the handler was already disposed.

2020-03-26 08:36:13.921 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:klf200:home tried checking if channel doDetection is linked although the handler was already disposed.

2020-03-26 08:36:13.922 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:rollershutter:home:RollerShutterKidsRoom tried checking if channel position is linked although the handler was already disposed.

2020-03-26 08:36:13.922 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:rollershutter:home:RollerShutterKidsRoom tried checking if channel limitMinimum is linked although the handler was already disposed.

2020-03-26 08:36:13.922 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:rollershutter:home:RollerShutterKidsRoom tried checking if channel limitMaximum is linked although the handler was already disposed.

2020-03-26 08:36:13.922 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:rollershutter:home:RollerShutterBedRoom tried checking if channel position is linked although the handler was already disposed.

2020-03-26 08:36:13.922 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:rollershutter:home:RollerShutterBedRoom tried checking if channel limitMinimum is linked although the handler was already disposed.

2020-03-26 08:36:13.922 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler VeluxBridgeHandler of thing velux:rollershutter:home:RollerShutterBedRoom tried checking if channel limitMaximum is linked although the handler was already disposed.

When I upgraded from openHAB 2.5.0 to openHAB 2.5.3 the velux binding stopped working. PaperUI showed two versions of the binding (2.5.3 & 1.14.0), Karaf console showed only 2.5.3. It was not possible to install the 2.5.3 version using PaperUI. Once I tried to do that, the 1.14.0 version would get installed (at least according to PaperUI). However, I could not configure the bridge, because PaperUI gave me a “5xx Conflict” error. (Or similar - I do not remember exactly. But it was clear that there was some sort of collision.)

I tried many things including:

  • Back to my 2.5.0 setup, disabling the binding, removing velux.things and all other traces of the binding (except items), updating to 2.5.3.
  • Stopping 2.5.3, clearing all caches, starting 2.5.3

Nothing seemed to remove the outdated duplicate of the binding. I then did a file system search for “velux” and “1.14.0”. The following helped:

  • Stopped openHAB
  • Removed the section referencing the 1.14.0 velux binding from openhab-addons-2.5.3-features.xml
  • Started openHAB
  • Now only the 2.5.3 version of the binding was visible in PaperUI
  • Installed it
  • Added the bridge & configured it
  • Binding was working again

EDIT: The shutters also needed to be added as things via PaperUI auto-discovery. I then had to change the item definitions from a “velux=” to a “channel=” notation.

Maybe this helps anyone reading this.

A huge thumbs up for the 2.5.3 version of the binding! I noticed that it is a lot snappier and that shutters now no longer move sequentially but in parallel. Great stuff! :+1:

2 Likes

I can confirm that PaperUI only installs the 1.14 version.

@jewesta how did you add the bridge? the binding doesn’t accept my textual configs anymore - thanks!

1 Like

Hi @csi_oh,

not 100% sure, but I believe I did this:

  • In PaperUI navigated to Configuration > Things
  • Clicked the circular blue “+” button
  • A list of bindings appeared
  • Chose “Velux Binding”
  • Chose “Add Manually” under “Thing not listed?”
  • Chose “Velux KLF200”

And then went from there (IP address, etc.). I believe my three roller shutters were auto discovered after I had created the bridge thing. Bearing in mind that it might be a good idea to restart the KLF200 right before adding it since it might not accept logins after some time of inactivity… but don’t we all know that… :wink: :roll_eyes:

HTH!

Jens

I also noticed that, after the update to OH2.5.3 [complete new installation, in fact]) when I installed/deinstalled the 2.5.3 version of the binding in PaperUI that somehow the circle for the 1.14 was rotating. However, for me the 2.5.3 version appears to be installed according to PaperUI, but I am not sure.

The proposed editing of the xml file, however, does not seem to be a proper procedure for installing a binding in a release version. Is there a better procedure as the workaround for the apparent bug? Maybe manual installation of the most recent 2.5.3 jar file into the addons directory? I have not tested this yet, but this would sound more sensible to me, compared to messing with the xml file.

I have not progressed much further than that since with my old configuration the bridge seems to be recognized, but not much more. I am also still on FW 1.1.0.45, so I am a bit hesitant to upgrade since a downgrade is not possible. In particular, I am hesitant because I do not want to re-initialize all my rollershutters which I had to do in the past already once. Does anyone have an idea about how to do the FW update properly, avoiding the re-initialization of the devices already known to the bridge?

I am also missing an example textual configuration in the readme for the binding including examples for the *.things and the *.items files

Just some detail about my message before: Because I don’t use the binding yet and to reduce the log entries (io(): raised an error during connection setup: Remote host closed connection during handshake. and Starting velux bridge connection.), I just deinstalled it. Before, the 2.5.3 binding was shown to be installed in PaperUI (and also the binding showed as “velux” and not as “velux1” in /var/lib/openhab2/config/org/openhab/addons.config). So I clicked on “UNINSTALL” next to the 2.5.3 binding in PaperUI. This led to the “something’s being done” circle to start next to the “Velux Binding binding-velux - 1.14.0” entry which was not installed before, not the one next to the " Velux Binding binding-velux - 2.5.3" entry as I would expect.

Btw, the messages about the connection problems did not stop, despite PaperUI, the addons.config file, and the Karaf console all stopping to show any hint of the velux binding. I had to restart the OpenHAB service to stop the messages from coming.

Anyway, I would much appreciate (a) some hints on how to use the 2.x binding in OH 2.5.3 including some example for the *.things and *.items textual configuration (not PaperUI configuration) and (b) some advice on how to upgrade the firmware on the KLF to 2.0.0.71 without having to reinitialize all connected devices such as my shutters.

So far the binding seems to be working for me… some of the time. I’m wondering if it’s because of my VELUX cabling/transformer (KUX110) setup or something in the KLF200 binding code (running 2.5.4-SNAPSHOT Build #80 ):

2020-04-02 16:22:53.663 [WARN ] [nal.transport.MiIoAsyncCommunication] - Error while polling/sending message
java.lang.ArrayIndexOutOfBoundsException: null
        at org.openhab.binding.miio.internal.MiIoCrypto.iv(MiIoCrypto.java:52) ~[bundleFile:?]
        at org.openhab.binding.miio.internal.MiIoCrypto.encrypt(MiIoCrypto.java:74) ~[bundleFile:?]
        at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication.sendCommand(MiIoAsyncCommunication.java:250) ~[bundleFile:?]
        at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication.sendMiIoSendCommand(MiIoAsyncCommunication.java:166) ~[bundleFile:?]
        at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication$MessageSenderThread.run(MiIoAsyncCommunication.java:225) [bundleFile:?]

From VELUX I’ve heard two answers:

  • one KLF-200 per house and one KUX-110 per window
  • one KLF-200 per house and one KUX-110 per thing you want to simultaneously control (e.g. a room with two windows would need one KUX-110 for inside blackout blinds and another for outside sun blinds)

Currently I have my 8 windows setup according to the second answer. How do others have theirs setup? Would this explain the errors in my logs?

Does the KLF200 send a radio signal to the window or to the KUX110 that then sends something over the 24v cable? Could one simply use a beefy 3rd-party 24v transformer? Sorry this is a bit of a VELUX question and less of an OpenHAB question. But comes about since I’ve not been able to reliably get the blinds opening and closing.

Thanks for you answer, that helped!

Good health guys!

1 Like

I‘ve been where you are approx. two years ago, so I feel with you. :wink: I‘ve also been on the phone with Velux back then because the obvious thought is that one KUX110 should be able to control two (or more) devices that would be expected to work in sync anyway, thereby saving money.

The short answer is: This is not possible. Every device needs its own KUX110. The KUX not only supplies the 24V but the control signal is modulated on top of the supply current. What happens is that the KUX wakes the device by supplying current. They then communicate and do a handshake via a proprietary protocol. Both need to be coupled initially. After that the KUX cannot be simply moved to another Velux device. They now form a unit and must be reset so each can be paired with another.

Yes, the KLF communicates with the KUX units via radio.

I have never seen the log messages you posted. My gut feeling is that they are not related to this particular issue. But this is just speculation.

I just remembered that I should add that (AFAIK!) it is possible to use a „dumb“ power off/on setup, controlling up/down movement by inverting polarity of the supply current (or not). As far as I know this is only possible if the device (e.g. roller shutter) comes straight from the factory. Once it has been coupled with a KUX there is no going back. Also, if one goes with the „dumb“ solution, one is on one‘s own in terms of controlling the device. So no integration with the KLF at all.

@jewesta - thanks for the feedback and nice to know it’s not just me struggling with multiple interpretations of how VELUX is supposed to work and that . I did find this informative post that mirrors your “24v and a signal on top” comment: https://smarthome.exposed/controlling-velux-windows/ The post also mentions a way to kick the devices back to “legacy” 24v polarity switching mode.

What is interesting " If two or more SML shutters are connected to one power supply, they immediately stop." This is probably why I’m getting wierd control problems in the openhab module - sometimes works, sometimes doesnt. I’ll rewire the windows up to one window per KUX.

Oh VELUX and your proprietary control protocols. Nice windows though.

:+1: Great. Glad I could be of help. :slight_smile:

One other reason why this would not work in practice is that there might be something obstructing one of the paired shutters. E.g. if we forget to close one of our roof windows the shutter senses the resistance and stops. The other shutter(s) in the group would probably just continue to whatever target position is set. I cannot see how any one KUX would resolve such a conflict.

Before I went with the KLF/KUX combination I had a manual setup with HomeMatic switches. It worked surprisingly well in practice but the implementation was very awkward (timers, etc.) and was prone to problems in exceptional situations like the one I described above.

This is biggest strength of the KLF/KUX combination: It is very reliable. At least from my experience. Once set up properly there usually are no problems. (Power outages & openHAB restarts aside, of course.) If a shutter is forced to stop the KUX (and consequently the KLF & openHAB) still know its exact position. So you’re always dealing with absolute values.

Btw.: I’m using the latest firmware for the KLF. “Latest” meaning September 2018. The one with the cumbersome “Wifi only web UI.” I have not defined any scenes in the KLF. Some tutorials make it seem as if this is necessary or wildly superior. That’s why I’m mentioning it. I just paired / registered all the devices with the KLF and the openHab binding discovers them as individual devices. I like it this way because I always try to keep the peripherals as “dumb” as possible and do all configuration / programming / grouping in openHAB.

1 Like

Sorry for bumping this up.
I had to exchange the battery of one of my solar rollershutters and now it is not recognized anymore. Is there a way to efficiently add a single new device or do I have to add the new device to my KLR 200 remote and copy that to the KLF 200 bridge. In case of the latter, can I somehow keep the old Thing IDs of my windows and rollershutters?
Many thanks in advance,
Jonas