[velux] New OpenHAB2 binding - feedback welcome!

Hi Guenther,

testing now:

258 │ Active   │  80 │ 1.14.0.201903161709    │ openHAB Velux Binding

Log:

2019-03-16 20:04:54.178 [INFO ] [inding.velux.internal.VeluxActivator] - velux binding has been started.
2019-03-16 20:04:54.431 [INFO ] [.binding.velux.internal.VeluxBinding] - Active items are: [V_FIRMWARE, V_STATUS].
2019-03-16 20:06:22.565 [WARN ] [g.velux.things.VeluxExistingProducts] - update() failed as actuator (with index 0) is not registered.
2019-03-16 20:06:23.619 [WARN ] [g.velux.things.VeluxExistingProducts] - update() failed as actuator (with index 1) is not registered.
2019-03-16 20:06:24.692 [WARN ] [g.velux.things.VeluxExistingProducts] - update() failed as actuator (with index 2) is not registered.
2019-03-16 20:06:25.747 [WARN ] [g.velux.things.VeluxExistingProducts] - update() failed as actuator (with index 4) is not registered.

At this point, again, I don’t think it’s something with your binding, but an issue with the KLF200 instead. Could you tell me briefly how you “registered” your Velux rollershutters? Did you use some hard-wiring or just “scanning” for products during setup procedure?

Many thanks (+ schönen Abend!),
Chris

You should see a log message from the binding (at log level INFO) which looks something like this:

[INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Found velux actuators:
	Product "ShutterBathSecondFloor" / ROLLER_SHUTTER (bridgeIndex=0,serial=****,position=0000)
	Product "ShutterAtticL" / ROLLER_SHUTTER (bridgeIndex=2,serial=****,position=0000)
	Product "ShutterAtticR" / ROLLER_SHUTTER (bridgeIndex=1,serial=****,position=0000)

The product names in the log appear as defined in the KLF200 and have nothing to do with openHAB items (just to clarify). You then take the serial numbers (which look a bit like MAC addresses) and define your items:

Group Velux
String VeluxKLF200Firmware "Firmware [%s]" (Velux) {velux="thing=bridge;channel=firmware"}
String VeluxKLF200Status "Status [%s]" (Velux) {velux="thing=bridge;channel=status"}

Rollershutter KLF200ShutterBathSecondFloor "Rollladen im Bad [%d]" (Velux) { velux="thing=actuator;channel=serial#****" }
Rollershutter KLF200ShutterAtticL "Rollladen auf dem Spitzboden links [%d]" (Velux) { velux="thing=actuator;channel=serial#****" }
Rollershutter KLF200ShutterAtticR "Rollladen auf dem Spitzboden rechts [%d]" (Velux) { velux="thing=actuator;channel=serial#****" }

I would then restart the binding and I’m guessing that it will work. So in essence the binding will log the serial numbers and without those you cannot continue. The message you are seeing means the binding is getting updates (which is great, obviously :wink:) but cannot find a related item.

Hello Chris,

any io-homecontrol device has to registered i.e. by being learned from the remote control. Please take a look into the Velux manual, page 11 .

Cheers, und erholsamen Abend, Guenther

Hello,
I want to upgrade my KLF200 to firmeware version 2, but I have one question. Where can I find the serial numbers of my Velux rollershutters for the channel configuration? In firmeware Versionen 1 I can not find any serial number.

Thanks!

Short question, as I’ve received my gateway just right now.

I have 5 velux, and 5 remote control. Do you think it’s better to learn a velux from each remote control (of course with different name), or better to register all velux in a single remote control, then learn from that?

thanks
Andrea

Hi Guenther,

It has bin a while that i wrote you.

I am still running the velux binding 1.13.0 and openhab 2.4

Is your new binding ready for use on openhab 2.4 ?

How should i install this binding and are there changes needed on my config files ?

I hope to hear from you.

Regards, John bakker

Hi John,

sorry for not having seen this still open question: the v1.14 version of the binding supports the openHAB2 together with the compatibility layer.

For stability I suggest to wait for the final merge of the PR5833 which is currently in review: This patch adds another section to the README (How to run it under openHAB2?), too. Of course, the resulting file org.openhab.binding.velux-1.14.0.201903162123.jar is located at github.

@ariela,

my preferred way to is learn from the simple remote controls. By that you’ll have a fallback control method for your convenience stored somewhere in the cabinet, if the openHAB or the KLF200 fails for whatever reason.
Best regards, Guenther

1 Like

Hi Guenther @gs4711 ,

Can you help me with my question to the serial numbers of the rollershutters for the channel configuration? I have no idea where can I find them.
Any hints?

Thank you for your effort!

Hi Johannes @ johannesbonn,

the serial number will be printed during startup of the binding for convenience. Of course, only those devices which are registered within the KLF200 are shown.
Alternatively the serial number are part of the window/roller shutter label.

Regards, Guenther

Hallo @gs4711,

Ok, Thank you, got it. I can start the rollershutter to drive up or down as rollershutter item on the sitemap (arrows up and down), but it is not possible to stop the shutter with the x-button. I thought with the new firmware a stop command should be also possible during driving the shutter.

Update:
I found the following in the log:

Item 'VeluxSchlafzimmer_Hof' received command STOP

2019-03-24 20:09:16.539 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item VeluxSchlafzimmer_Hof (type ACTUATOR_SERIAL) failed.

What does it mean? Any idea…?

Have a nice evening

Johannes

P.S.
My items:


Rollershutter VeluxSchlafzimmer_Hof    "Velux Hof [%d]"      (gVelux, gSchlafzimmer)    { velux="thing=actuator;channel=serial#56:32:14:5A:XX:XX:13:XX" }

Rollershutter VeluxSchlafzimmer_Strasse     "Velux Straße [%d]"      (gVelux, gSchlafzimmer)      { velux="thing=actuator;channel=serial#56:32:14:5A:XX:XX:13:XX" }

Hi Guenther,
binding works now, I can drive my rollershutters now to 0% and 100% - thanks to your binding! Many, many thanks for that.

Just a quick question; I can only move my rollershutters one-by-one and not simultaneously, but I guess that’s due to limitations of the KLF200?

BR,
Chris

Chris @csi_oh,
it is not a real limitation of the KLF200 but the binding in its current state. There are several way to achieve multiple activations:

  1. Define a scene of desired end positions (works now),

  2. Define a KLF200 internal grouping (not yet supported by the binding),

  3. Parallel activation of different actions on different io-homecontrol device (binding adaptions pending).

For a quick solution, I’d suggest to follow the way (1).

Best regards, Guenther

@johannesbonn,

interesting message. Did not see this one up to now. Will try to evaluate in which case this message appears,

BR Guenther

Ok, made a few tests and this log entry also appears when I send the command UP or DOWN to change the direction during a run. Is it generally possible to stop the shutter anytime or change the direction during a run?

Thank you for your effort and this nice binding!

Yes, this will be the second next extension to support STOP on any active commands. First of all the full openHAB2 (esp. for PaperUI) is planned to be finalized.

1 Like

Hi Guenther, .
can you show me how to questonairy the status of the Klf200 in the rules file ?
I want to send a message when the klf200 is not online anymore
something like , request item status and if online then send msg.
i will do the send by telegram and that is already working ,
i only dont know how to get the status from the klf200
here is my items file

// Velux Bridge channels

String	V_FIRMWARE	"Firmware [%s]"				 	{ velux="thing=bridge;channel=firmware" }
String	V_STATUS	"Status [%s]"				 	{ velux="thing=bridge;channel=status" }
String	V_CHECK		"Velux Config Check [%s]"		{ velux="thing=bridge;channel=check" }

// Velux IO-homecontrol devices

// Rollershutter V_Keuken	"Keuken [%d]"					        { velux="thing=actuator;channel=serial#00:00:00:00:00:00:00" }
Rollershutter 	GF_Keuken_Shutter     "Keuken [%d]"					{ velux="thing=actuator;channel=serial#00:00:00:00:00:00:00" }                
Rollershutter   F2_Badkamer_Shutter   "Badkamer [%d]"			    { velux="thing=actuator;channel=serial#53:2A:5D:5A:12:10:1A" }				 
Rollershutter   F2_Slaapkamer_Shutter "Slaapkamer [%d]"				{ velux="thing=actuator;channel=serial#53:2A:5D:5A:12:10:3A" }
Rollershutter 	F3_Zolder_Shutter     "Zolder [%d]"					{ velux="thing=actuator;channel=serial#53:2A:5D:5A:12:10:3B" }
//
// end-of-items/velux.items

Hello John,

if you try to use your V_CHECK item, you will be notified about any changes of the bridge status, but not in case of failure in communication. Interpreting the mentioned intentions something like timestamp of last successfull communication would be helpful?

What do you think about this approach?

Hi Guenther,
in the API documentation i saw this phrase,
“Gateway state
The user can get the state of the gateway, during an ongoing operation, using
GW_GET_STATE_REQ/CFM command set.
This command set can also be as a kind of ping method.”

That is why i thought i could use it.

Hi John,

the documentation is completely correct - but if your gateway is in Nirvana, the binding won’t update its state…