[velux] New OpenHAB2 binding - feedback welcome!

Tags: #<Tag:0x00007fc2021e3ce8> #<Tag:0x00007fc2021e3c20>


the installation should not interfere with the IHC binding. But the bindings are sharing the httpclient library. Please let me know whether this will occur again.

Regards, Guenther

The warning stopped after a few minutes, and the windows operates fine from my rule. So I guess something just had to settle. But I´ll keep an eye on it, specially next time I reboot.
Which library did Velux binding use, before I installed the Apache http client?

i am not a programmer but just a man of 69 years and trying to get openhab working for me, with the prev ios binding all worked for me, but i installed the new binding and have some problems.
i am running the *org.openhab.binding.velux-
but i am getting problems with actuators like below i also uploaded some msg

handleCommandOnChannel(): cannot work on unknown actuator: 53:2A:5D:5A:12:10:3A.

Does anyone know this and how to solve ?
pls read the logfile for more messages and startup of the binding.

actuator-log.log (9.4 KB)

Helllo John, @Johnny-b,
most parts of the logfile looks fine to me. Let’s summarize:

  • you have defined 16 scenes on the KLF, which are well recognized,
  • you have registered four rollershutters on the KLF which are recognized (with one exception):
    ** there is one non-Velux shutter (“Keuken”)? It reports a strange serial-number (00:00:00:00:00:00:00:00),
  • the bridge is in fully operational mode and in good contact with the binding (status GW_S_GWM/GW_SS_IDLE).
    But there is an issue with the relationship of the devices and the appropriate things. Could you please share one of the definition lines for the four different shutters (assuming that you have them manually entered into an items file)?

Regards, Guenther

Hallo @Johnny-b again,
rereading parts of your 1st sentence:

I’m doubting whether I’ve got it right: Did the unchanged setup have worked before?

Hi Guenther,

no your right, i ment to say that it worked with the previos version and i installed the new binding but also started to create more scenes on the klf200 and tried to get them in the in the things, items and sitemap.

And then the messages came about unknown actuators.

And in the posts i saw a message from Kim Anderson who had the same msg but i could not find the solution there.

Regards Johnny

Hi John,
is it possible for you to increase the log level of the binding?
Thx in advance, Guenther

Hi Guenther,
i found the problem, it was my fault !
In the items file there where the last two digits missing in the serialnumber and that is the reason why the actuators where not found.
But thanks for the help anyway !

Hi John, thanks for your feedback.

Hello there! I’m using this binding to talk to my io-homecontrol (somfy) shutters via a KLF200, but the setup seems to be … flaky.

It sometimes works when everything is just fine (mostly after powercycling the KLF200 and then restating openhab), but it often gets stuck in some state where no commands are correctly transmitted.

The one consistent symptom that happens is log lines like this appearing in my log:

2019-08-19 12:41:48.881 [WARN ] [nding.velux.bridge.slip.SCgetProduct] - Gateway response GW_GET_ALL_NODES_INFORMATION_NTF (516) cannot be handled at this point of interaction.

I’ll try to provide more useful reproduction information when I can get it and will also try to find the “beginning” of the error state (which I’ve not yet isolated), but are there any suggestion in the meantime that might help with finding the root cause?

It looks like the problems starts when the KLF200 indicates an ended session during a command:

019-08-20 09:49:34.661 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 52cc370d-1471-4d28-ae93-fd6d4c57a0cd, base URL = http://localhost:8080)
2019-08-20 09:49:36.259 [INFO ] [ab.binding.velux.bridge.slip.SClogin] - velux bridge connection successfully established (login succeeded).
2019-08-20 09:49:38.306 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Found velux scenes:
2019-08-20 09:49:39.554 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Found velux actuators:
        Product "Schlafzimmer" / UNDEFTYPE (bridgeIndex=1,serial=Schlafzimmer,position=C800)
        Product "Kinderzimmer Nord" / UNDEFTYPE (bridgeIndex=6,serial=Kinderzimmer Nord,position=C800)
        Product "Bad" / UNDEFTYPE (bridgeIndex=5,serial=Bad,position=C800)
        Product "Buero" / UNDEFTYPE (bridgeIndex=8,serial=Buero,position=C800)
        Product "Wohnzimmer Fix Sued" / UNDEFTYPE (bridgeIndex=2,serial=Wohnzimmer Fix Sued,position=00EB)
        Product "Wohnzimmer Schiebetür" / UNDEFTYPE (bridgeIndex=4,serial=Wohnzimmer Schiebetür,position=0000)
        Product "Kinderzimmer West" / UNDEFTYPE (bridgeIndex=7,serial=Kinderzimmer West,position=C800)
        Product "Wohnzimmer Fix West" / UNDEFTYPE (bridgeIndex=0,serial=Wohnzimmer Fix West,position=00EB)
        Product "Kueche" / UNDEFTYPE (bridgeIndex=3,serial=Kueche,position=0000)        .
2019-08-20 09:49:40.563 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - velux Bridge is online with 0 scenes and 9 actuators, now.
2019-08-20 09:50:04.283 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Result: check ok. All scenes are used within Items.
2019-08-20 09:52:41.823 [INFO ] [ding.velux.bridge.slip.SCsendCommand] - setResponse(): returned ntfRunStatus: EXECUTION_FAILED.
2019-08-20 09:52:42.832 [WARN ] [ding.velux.bridge.slip.SCgetProducts] - Gateway response GW_SESSION_FINISHED_NTF (772) cannot be handled at this point of interaction.
2019-08-20 09:52:48.805 [WARN ] [.velux.bridge.slip.SCgetDeviceStatus] - Gateway response GW_ACTIVATION_LOG_UPDATED_NTF (1286) cannot be handled at this point of interaction.
2019-08-20 09:52:48.810 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-08-20 09:53:04.819 [WARN ] [.velux.bridge.slip.SCgetDeviceStatus] - Gateway response GW_GET_ALL_NODES_INFORMATION_CFM (515) cannot be handled at this point of interaction.
2019-08-20 09:53:04.823 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.

Log messages like that seem to preface every time the controls end up not working. For example, this one happened shortly after restarting OpenHAB (and the velux binding correctly reporting the shutters from the KLF including their position, indicating that the KLF200 can indeed communicate with the shutters).

Just for the record I found out that at least one of the reasons why controlling the shutters doesn’t work is that they are “priority locked” (presumably by my handheld remote controls, because I’m not aware by any other systems controlling them).

Since this binding sends its commands at the priority level 5 (comfort / automation) the blinds refuse to override the presumably “more important” user setting.

While that is a good default level, it would be ideal if direct user-interacted settings (via the app or web app) were sent as user input (and thus override the priority lock). I don’t know if there is a way to distinguish “user initiated” and “automated” events in OpenHab though …

Also as a side note, it would be nice if the binding printed the details of the refusal at the INFO level, I had to switch to debug to find the “ntfStatusReply=6” value that indicates priority lock


I got this velux binding running on a cubieboard3 by copying the jar file into the add-on directory. Good so far. My intention is to use the openhab installation as connection to my loxone air system to include my two velux roller shutters into the automatic control of loxone.
So now, I got it running by sending the commands to the openhab server. Nevertheless I have some questions about the openhab binding. Maybe I did not dig enough - but I could not find a description of commands available commands that can be used. For example, how can I ask the binding for the shutter position or how can I rename the items. Furthermore, the naming created by automatic recognition are not stored within the /etc/openhab2 directory but some elsewhere, but where?
Can somebody me give some answers?

Hello Johann @woec,

the binding is able to control any io-homecontrol device by setting the target position, in your case by setting the device item value to a number between 0 and 100 for opening and closing the Velux shutters. The discovery process will add items to the OH framework. In parallel any discovered Velux device will be mentioned in the log.
In the same way as you have defined the Loxone items, you can define and use the Velux items.

Regards, Guenther

Hi Joachim @Saua,

the behaviour of your handhelds sound strange (is it an official Velux one?) - but, of course, is still possible to override the priority settings. Normally those priorities are used to avoid real bad actions like opening of a window during recognized rain.

Personally I have experienced a shutter restriction due to a blocking situation (something was in its way) which led to a situation where (after this occurrence) the shutter was not closing up to its normal limits. The original Velux remote controls (as well as the OH binding) with the documented priority levels have not been able to override this introduced limitation (in my case, only a factory reset had eliminated the restriction again).

According to the Velux specifications, any automatic control should use the priority level of five (comfort level 2). Higher priorities like 3 (User level 2), 2 (User level 1 i.e. parents overriding the settings introduced by their childs) or 1 (Environment Protection for situations like the mentioned rain sensor) or 0 (Human Protection i.e. protection against jamming somethings within the shutter motion way) should never be used for automation systems (even if its technically possible).

Regards, Guenther

Hy Guenther, thanks for the feedback.

I’ve since found out that the remote control I use (“Situo 5 IO Variant” or something like this) has a “Manual/Auto” slider where the “Manual” side basically blocks any non-“user” actions. As soon as I switched it to “Auto” (which really means "let others control the devices as well), the controls continue to work. I’ve not investigated if the lock is lifted after a while or active as long as the slider is switched to “auto” …

So I guess you can consider my feature request revoked :wink:

The only slight weirdness/question I have left at the moment is that it seems that commands sent via the OpenHAB UI (Basic UI, for example) are executed sequentially and never in parallel (for example if I want multiple shutters to close, the second one will only start closing once the first one is done).

As far as I can see from the API (which isn’t very far, to be honest) that isn’t required by the API. Is this an intentional/known restriction?

Hi Joachim,

you’re right. The initial approach (supporting both firmware versions and both protocols in parallel) is to limit the parallelism to one: one command after another. If most of the users migrate to OH2, I’d prefer to switch to full parallelism.

Hello Guenther,
thank you for your answer.
You say, the discovery process adds the items to the OH framework - ok, but where can I find the definitions. I would like to assign simpler and shorter names to the items, for example.
Further, I could not find a description of available commands applicable to the roller shutters. Some hints I could find in the openhab logs. Is there no complete list available?
For example, I did not recognize a command for query the shutter position which would be nice to get a feedback for the loxone control.
Do you have any more infos on these questions for me?
Best regards,

Hello Johann,

perhaps this real-life example may help: our Velux window in the bathroom will be automaticly closed after a minute being fully opened:

rule "V_DG_M_W_changed"
	Item V_DG_M_W changed
	val Number windowState = V_DG_M_W.state as DecimalType
	if (windowState == 0) {
			logInfo("rules.V_DG_M_W", "Window-Bath changed to fully open.")
			var int interval = 1
			createTimer(now.plusMinutes(interval)) [|

Within this rules you’ll recognize the reaction upon changes of the device state and the possibility to act accordingly.

Regards, Guenther

Hi Guenther,
Thanks so much for this binding. So far I am using simple Velux remotes switched by relays and controlled by OpenHAB. While it is working it is obviously quite limited (no reading of status, cannot set a target percentage for a rollershutter, etc.).
Now I am really keen to use the KLF200 with this binding but wanted to make sure that it can completely replace my current system before I start tinkering. Is there a list of current issues? Would I first include all my Velux windows and rollershutters via the KLF200 interface and then include them in OpenHAB?
I am running OpenHAB 2.5 M3.
Many thanks in advance,