O.K., thanks! It was the PW. I used the Wifi, but it is the high secure one: velux123
Maybe, I just updated the FW today??
Anyway, I will go on now and try to figure out how to control the windows (as they don’t show up yet)
Thanks again for the help and the binding,
Ingo
If the bridge is stated as online, you’ll able to activate the discover button within paperUI which leads to many Things within the Inbox. Rgds, Guenther
Thanks, and yes I saw that. I try to find the syntax for the .things file. The thread is rather long allready…
Hi Guenther,
Since today I am using your 2.5 binding with openhab 2.4. Everything runs very smooth with one exception (in version1.x not better): A status update of the position is send several minutes after reaching the position. Is this normal?
Thank you for your hard work!
Really cool! The Window opens via Openhab. Thanks for your work Guenther!
Thanks for your message. Thinking about the House Monitoring Service: Did you see any failures during the activation phase? Normally there should be a line like
[TRACE] [ing.velux.handler.VeluxBridgeHandler] - bridgeParamsUpdated(): HSM activated.
or, in opposite, an error like…
[WARN] [ing.velux.handler.VeluxBridgeHandler] - Activation of House-Status-Monitoring failed (might lead to a lack of status updates).
With the changed refresh time to 10 seconds, the binding will look for an update coming via the HSM messages about changes within the actuator environment.
Will have to take a look onto it, what could be the reason…
Hopefully it can be closed as well 
I have no errors or warnings during execution.
Sorry, Joachim, @Saua, for coming back to two of your traces, again. Having reread the following …
is was wondering about your firmware version. The response GW_ACTIVATION_LOG_UPDATED_NTF is never ever being sent by any of the gateways I have been in contact with. Did you use other software which might has set some internal parameters?
Reading the API specification, there it is stated that
This notify is send every time a new error is written in the log.
Do you have any problems with your actuators?
Thanks in advance, Guenther
Sorry for my ignorance. I know this topic has been discussed but I am not sure how to deal with it: is there a way to invert the commands for windows (UP vs DOWN). Current behavior is to open windows with the DOWN command, which is different to all my rules.
Thanks!
Hello Jonas,
just set the configuration parameter inverted to the value true.
In fact, your mentioned issue is dedicated to Somfy products as they currently provide an unknown device type identifier. In opposite to this, the Velux devices, of course, announce themselves as Windows which is recognized by the binding (an excuse for Somfy: it’s an Velux gateway 
).
I only have Velux windows and rollershutters and the parameter is already set to “inverted”.
I changed it to “false” and now the windows are behaving as desired.
Thanks!
Really? Then, I’d like to ask you for sharing the type identification which is printed during startup phase with loglevel INFO: the binding 
is based on the type definition from November 2018 as provided by Velux.
Sure, I will post those once I am home tonight.
I really haven’t investigated this issue but sometimes it takes about 10 s from sending the command until the window starts moving. Are there any known issues causing this (the TRACE log is really long…)?
Hi @gs4711,
I have to correct me. It’s one windows which don’t give a direct feedback of the position. I have tested an other one without problems.
But with normal logging I do not have any errors or warnings.
I have an other question:
With the 2.5 binding version is there still the support for the silent mode on scenes?
I have configured and tested two scenes (in klf configuered with silent mode) but the execution is in normal mode. I would appreciate to have this feature because I use the rollershutters in the morning to wake up by sun light.
Thank you for your help and hard work on that famous binding!!!
Pls. feel free to send the huge log file via PM (with a small note at which time the stop-and-go behaviour has been recognized).
Not yet completely supported. There is a discussion whether it should be a bridge-wide setting or an actuator-specific setting… what’s your opinion on it?
Actuator-specific means I can chose it for every rollershutter seperatly with a switch? Silent mode ON or OFF and than valid for every action, not only for scenes?
Both ways could be possible according to the API:
Sounds like a great feature!