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 
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.jarSounds 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…
I installed the new binding, still the messages
[core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-velux1'
appear. Is there any configuration file I could look for this binding which seems to install itself all the time?
EDIT:
The file
/var/lib/openhab2/config/org/openhab/addons.config
contains a reference to “binding=velux1,(and my other addons)”.
Just try to navigate to https://github.com/gs4711/org.openhab.binding.velux
Then click onto the appropriate jar-file named org.openhab.binding.velux-1.14.0.201907010000.jar and download it by selecting the Download button. At that point the web browser should ask you for a location where the file should be stored.
BTW the file is sized 505.055 bytes (493 KB).
Ok. Now I’m totally confused. This raises some more questions:
(a) How did you install the openHAB2? (Via a packaging tool?) What’s your operating system?
(b) How did you install the additional binding?
sorry for the inconvenience - it might be that there is something broken within the packaging environment and I’d like to chase it
No problem, you’re helping me, not the other way round ;-).
OpenHAB 2.5.0M1 on Raspian.
I put the jar into /usr/share/openhab2/addons/. Tried it with both download versions, as I said above - the 50kb and the 500kb version. I don’t know if the obviously truncated 50kb version did something to my installation?!?!
In addition I tried to define a velux bridge thing several times with HABmin, PaperUI and text file, but deleted all those attempts.
Oh, the new version broke something.
2019-07-02 20:40:13.868 [WARN ] [g.velux.things.VeluxExistingProducts] - update() failed as actuator (with index 1) is not registered.
Rollershutters do no longer react to openHAB.
The bridge item “products” still shows all my rollershutters?!
Downgrade to the previous version fixes the problem.
A week ago I did the same with Raspbian (GNU/Linux 10, 4.19.50-v7l+ #895 SMP) but using the stable version (openhab2 / 2.4.0-1). In the past I had several times some configurations being kept somewhere and the only way to get rid of them was to eliminate the complete OH2.
Will remove the OH2 stable and give the milestone release a try… still wondering where the velux1 is coming from???
BTW did you need to activate the compat1x layer like described in the README ?
Interesting fact! Reviewing my pilot installation the file contains:
package="standard" service.pid="org.openhab.addons" ui="basic,paper,habpanel,homebuilder"
Some of the UIs might have added this line. At least this explains the occurence of the openhab-binding-velux1 failure.
Removal of the velux1 entry in this file removes the installation error and the binding still works (the older version, the new one doesn’t work for me, see above).
During my early attempts to get the binding running I indeed did activate this layer. However, the log messages of the binding did not really change afterwards - it was the removal of the velux bridge thing which did the trick. So I doubt if the compat1x layer was really needed - as it seems not to hurt, I leave it activated.
Thanks for the hint, I will give it a try.
Any way I can help here?
Do you mean the request sent from my browser or by the binding?
@gs4711 Couldn’t you add a null check at the start of the io() method so a null request won’t be sent?
No and yes: This would be an avoidance of the results - not fixing the originating issue.
Just found the area of this bug… has been introduced during OH1/OH2 compatibility coding. Will try to fix it today (seems to be a minor change).
Thank you very much for your work. I’m looking forward to the changes!