[velux] New OpenHAB2 binding - feedback welcome!

[quote=“Nosepull, post:225, topic:32926”]

One additional question:

Did the message

2019-06-29 19:50:04.807 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-velux1

disappear now?

Thanks Guenther for the answer!

I’m providing you with full logs so you can maybe understand the error.

openhab.log (162.5 KB)

When I try to access the link http://10.3.0.26:80/api/v1/auth I get ERR_EMPTY_RESPONSE

it’s in the same LAN

Hi @antares2001,

Regarding the password behaviour: There seems to be different approaches depending on the hardware revision: some users sent a feedback that the default password works, other (as you) that only the wifi password is valid. I’m not sure how to deal with it.

The Somfy issue is critical to me as I’d like to integrate any io-homecontrol devices. Therefore, I’ve prepared a special jar-revision with in depth logging about the klf-internal datastructures (avoiding product type UNDEFTYPE) and - probably with the help of Velux engineers - we’ll come to a conclusion.

Thanks for your patience and support. Regards, Guenther

@gs4711
Another question:
Can I view the state my rollershutters are at currently? Like 100% or 0% for open/closed. Because on my Sitemap I can’t see any and I’m not sure that’s because of the errors in the Logs.

Hello @gs4711,

thanks for your reply. I’ll have a look to post more logs eventually when I get back to the system. I’m currently very time pressed, so I can’t do it immediately.

I figured I might be able to stick with Control Somfy io or Velux windows with KLF 200 and HTTP binding for the moment, until the issue with Somfy is solved in the binding.

Thanks, @antares2001. Does this software tool report other serial numbers?

Hello @lukqw,

no and yes. With the firmware v1 you will only have the possibility to use the (predefined) scenes w/o any status responses. After upgrading the KLF to firmware version v2, any fine-granular control of the actuators is possible. Additionally OH will get feedback from the io-homecontrol devices about their status: Even manual control by the remote controls will be recognized and reported back to the OH UI.

Greetings, Guenther

Alright thank you for your response @gs4711!

Did you have time yet to check out my logs over at post #234 ?

@gs4711 - looks like I can just use the names I set up in the KLF 200. I don’t see any serial numbers, just device IDs 0, 1, 2, …

That project is just a kind of http-wrapper to talk to pyvlx (installable via pip) which does all the magic talking to the KLF. Yet, it made the setup very convenient for me by just using the http="…" in item definition to control my devices. Reports also back device status changes @lukqw asks for.

Yep. Trying to check the reason for the empty request - it’s a little bit tricky as I haven’t got any v1 KLF in access to verify the handshake…
The request should contain {"action":"getDeviceStatus","params":{}} as body part.

@gs4711 did you have time to look at the above? I have simular problems, specially when operating more than once device at the same time, (I have 8 Velux windows).
I know you mentioned that during the summe, you´ll have a change for the state report timing… But does this involve the problems with handling more than one device at the same time?

Hi @Kim_Andersen,
the issue with parallel activation is still open. This will be addresses as soon as the activation problems with OH2 and paperUi are fixed: There seems to be a bug within the compat1x layer as the complete configuration handover from GUI to binding is stuck in the middle.

Nevertheless the point mentioned by @nosepull

[…] updated until a few minutes after […]

is fixed with the v1.14-release (PR integrated at the 16th of June): The state reporting is now done asynchronously via the KLF HouseMonitoringService within seconds after actuator changes.

Hi @Nosepull,

do you have a clue (any pointers appreciated) where the name openhab-binding-velux1 is originated? AFAIK this keyword is nowhere included in the available binding code (so far released!).

Great!!
Will the 1.14 .jar be available?

Sorry, forgot to mention … org.openhab.binding.velux-1.14.0.201907010000.jar on GitHub. But, be aware, the problem with configuration by OH2 PaperUI is not solved - textual configuration works fine.

This release runs stable for more than two months on a pi3b with OH1 dealing with all kind of automations like shutting down the shutters after an increasing level of sun intensity, opening the windows when the outside temperature is lower than the room temperature a.s.o.

I us textual configuration only :slight_smile:
Will test it in one of the upcoming days. I´m running OH 2.5 M1.

Hi Johannes (@johannesbonn),

within the README on the github page you’ll find a link to the official Velux documentation: according to this document (dated to 2th of Nov. 2018) the current KLF firmware does only support velocity settings (i.e. silent mode) on scenes.

What is the intention of your question?

Regards, Guenther

Hi @gs4711,

I use my rollershutters in the morning to get woken up by the sun, but the noise with normal speed is very loud and we wake up by that.
I thought about to activate it for this reason.

Whow, quite some activity here since my post. Probably I should first try with the new release.

One thing I noticed already with previous versions: If I download the file from github, the file size vastly differs if I use “save link as” or click the link. Both jar’s seem to work, however?!?!?!

-rw-r--r--  1 user users  80157 Jul  2 20:05 org.openhab.binding.velux-1.14.0.201907010000 (1).jar
-rw-r--r--  1 user users 505055 Jul  2 20:03  org.openhab.binding.velux-1.14.0.201907010000.jar

Sounds reasonable. What about defining one scene with opened shutters - this could be activated with a velocity setting of silent?

Currently the binding is using a default velocity parameter - but it could be worth to modify it towards a parameter (default / fast / silent). IMHO noone is really using the scenes after the upgrading to firmware v2 as the flexibility of setting a fine-granular level was the most requested feature.

Pls. let me know what you’re thinking about it…