the make is Velux and they do not move with the window frame, their rails are still on the roof. It’s standard Velux rollershutter for the model I have, which is Velux Integra.
I would have expected this clashing conflict be managed at firmware, within the IO home controller, but it’s not the case.
What I’m hoping is to be able to introduce some safeties using openHAB rules and your binding, but I’d need an “abort” command or something like that.
any ideas?
Hmm. That is odd. Mine look like this..
See also the installation video below (from time mark ca. 2:30 onwards..)
But obviously notwithstanding the above, you could indeed write two rules in OH..
- if window position commanded to > 7% (vent) then shutter position => 0%
- if shutter position commanded to > 0% then window position => 0%
Hi,
is it included in the 3.1.0 Stable?
If not? where can I find the jar file? 
Yes it is.
1 Like
my bad…
was at 3.0.1-SNAPSHOT and either was blind or it did not shown up at the about Page.
It now seems to work better
1 Like
@AndrewFG : I sent a detailed description and suggestion to Velux through other channels. Velux has now confirmed to me that this has been given to their product development team to look at.
I suggested one of these 3 options to Velux:
- Change to 10 simultaneous sessions
- Keep 2 sessions default, but add client configuration option to increase this
- Remove maximum sessions completely
Also, I asked them to review if the 15 minute session kill feature in the description is actually working.
And a restart of OH 3.1. service unfortunately still seems to not release the session in KLF200, because it cannot login again after the restart. A power recycle of KLF200 is needed.
1 Like
Congratulations. Well done.
Indeed, I saw that too. (In my case it works on one of my two KLFs but not on the other). I had it working well (for both) in 3.0.x but obviously something changed again in the core shutdown code (probably the threading) in 3.1.x. Honestly I am getting rather tired of chasing this issue around in circles, so please don’t expect a fix from me quickly.
I do understand your frustration and me and other people are also feeling the pain. I hope that Velux can fix the root cause based on your very precise analysis of the behaviour of KLF200.
Unfortunatelly, I couldn’t agree more. For more than two years, I was struggling with the same obstacles (resulting in a bunch of debugging/logging code within this binding): The same issues came up even with minor upgrades since OpenHAB1.2 … it is not a problem of Velux but a fundamental OH issue: Undocumented changes in the framework which modifies the calling behaviour, the handling of parallel threads a.s.o.
But that’s only my 0,2$
1 Like
Worth to note: The binding runs well and stable on the OH2 for longer than six months! Congratulations!
1 Like
Hi,
the binding works since I migrated to 3.x perfect, I can also do upgrades of the OH and the KLF reconnects without a problem.
Br Leo
1 Like
Thanks for the support @gs4711.
The issue is that Java has two ways to close a thread – namely a) a soft close, where the thread is signalled to terminate, and then the framework waits until the thread actually completes, or b) a hard close, where the framework forcibly removes the thread from memory.
In OH when you disable a binding in Main UI (while OH continues to run), then the Velux binding shutdown thread is closed softly. But when you shut down the OH service from the console, it seems to first try a soft close of the binding thread, but if the thread does not terminate within a certain time, it seems to revert to a hard close. (I am actually not sure if this behaviour is part of OH or of the underlying Java SDK??)
Anyway the work around is to shut down OH in two steps – 1) within Main UI disable the binding, and then 2) from the console stop the OH service.
1 Like
Same for me!
1 Like
Thanks for the tip. However, it did not work for me. I ended doing a power recycle as the only option.
I understand that you do are tired of this, but I have one question: Can I somehow ask the binding to gracefully terminate the connection? - restAPI, Karaf console or other methods.
I am now also considering to establish a relay to be able to power recycle KLF200 device.
That is very surprising. In the step 1) above, I was not very precise when I said “disable the binding”; actually I mean “disable the KLF hub Thing” (and wait a few seconds)..
Well actually that is the purpose of all the code changes that I made 
.. but if you are asking if it is possible to access the hub via a second connection and tell it to close the first connection, the answer is no. Firstly because we know that it won’t accept a second connection, and secondly because that would not be a security friendly thing to do.
I also did that, but it failed. I just tried again, and this time it worked fine When OH has restarted, the KLF hub Thing is still disabled, and I simply enabled it again in the main UI.
I am not interested in a second connection to close. I was more searching for a bullet proof termination, which is needed, if I am physically not at home to do a power recycle. But your workaround seem to work fine, so I will use this going forward.
1 Like
@gs4711 I did some logging, and found out the following..
-
From the time that the user issues a console command to stop the openHAB service, the OH framework takes a variable time of between 0 and 8 seconds before the Velux binding
dispose()method is called. -
From the time that Velux
dispose()method is called, the actual Velux binding code takes a fairly stable time of 3.5 seconds for it to physically shut down the KLF comms.
I guess that our problem is the variable 0 to 8 seconds delay in step 1. above: – If the delay gets too long then the OH framework will already be trying to tear down its underlying TCP socket system (hard close) before the poor Velux dispose() method has had a chance to finish its (soft close).
Obviously the OH framework calls dispose() on all its Things, UI, and other services, in no particular time sequence. Sometimes Velux dispose() gets called early in the sequence and everything is good; but sometimes Thing/service dispose() methods are called before Velux dispose(), and then there can be problems for us.
Particularly problematic are those Things which (against the openHAB coding rules) are blocking for a long time in their dispose() method. e.g. the ZWave binding dispose() blocks for more 5 seconds; the framework gives a warning after 5 seconds, but it probably blocks longer than that, so it is likely to be guilty of a large proportion, if not all, of the ‘problem period’ of 8 seconds..
Therefore, ironically, it may be that the final fix to the Velux shutdown problem, may be to fix those other bindings which are guilty of breaking the openHAB coding rules in their dispose() methods. => Please discuss..
1 Like
@EjvindHald do you have the Zwave binding on your system? If so, the below mentioned change in that binding may fix your issues. Please let me know.
Hi
No, I am not using the Zwave binding. But based on your analysis I tried to disable all bindings except Velux before doing a restart. Then I enabled them one by one to try to identify a problem binding. However, restart worked with all bindings enabled.
Therefore, it seems not to be consistent.
I am using these bindings: ihc, rfxcom, mqtt, resol, modbus, deconz, hue and velux.
I also have mqtt, modbus and hue on my system; and I don’t see them causing any issues.