I posted yet another version of the JAR file under the same link (below), which hopefully fixes both the ‘ghost 21’ and ‘subsequent command interrupts prior command’ issues.
many thanks for the testing; and apologies that it is taking so long…
No problem. Glad someone looks into it.
And, I suppose vice-versa might apply to. Did you test that?
I suppose you mean with vice-versa, pushing te UP triangle, and see if it gets interrupted. No not tried yet.
I will test the new jar, within an hour.
No. 
You showed that setting the vane position, will (have) interrupt(ed) the prior shutter position command.
So I suppose that setting the shutter position will (have) interrupt(ed) the prior vane position command. ??
At first I thought you meant that but you realise you can’t be that quick to interrupt the vanePosition change bij pushing up or down? vanePostion changes take max 1 second. So impossible to check/interrupt.
Here the new logs
trace7b.txt (728.3 KB)
trace7a.txt (814.6 KB)
21:29 vanePosition to 80; got two reacting quickly following up each other but slats moved to 80. After few seconds sadly slider returned to 21.
21:30:40 I clicked on vanePosition 21; slats turned to 21 and slider staued at 21.
21:30:30 vanePosition to 80; slider returned to 21
21:31:30 (not 100% certain about time) vanePosition to 80; slider returned to 21
21:34 vanePosition to 0; no reaction
21:34:30 again vanePosition to 0; no reaction
21:35 vanePosition to 100; no reaction
The I saw the bridge was offline. Restarting bridge; no change.
UI says " HANDLER_MISSING_ERROR"
The handler missing error probably means that OH was in process of loading the new JAR. So that probably means your test was done while the old JAR was still loaded.
Ah, that would make sense. I did not know this would take langor than starting OH.
Tomorrow I will try it again with the, hopefully improved and loaded😉, jar.
Normally I disable the Velux Bridge Thing from the UI, wait about 30 seconds, drop the new JAR in the Addons folder, wait another 30 seconds, and then re-enable the Bridge Thing. That seems to make the transition quite smooth…
Ok. Next time I follow that precedure.
New logs after restart OH:
First I waited to see if the UI would update to the current position and vanPosition but it did not (sadly).
Then:
8:56 vanePosition to 60; after some time UI slider went to 21.
8:58 vanePosition to 40; after some time UI slider went to 66.
8:59:20 vanePosition to 100; after some time UI slider went to 21.
8:60 vanePosition to 0; after some time UI slider went to 66
9:01 vanePosition to 66; after some time UI slider went to 21.
trace8a.txt (1007.3 KB)
trace8b.txt (226.1 KB)
This is really weird…
At first I thought that the 21% number (0x2A49) was either some kind of artefact inside the binding code, or an old value previously received (ghost in the machine). But really must now conclude that the shutter is indeed actually physically sending this number. In fact, the binding sends the command 60% = 30720 = 0x7800 and the shutter responds with 0x2A49 = 10825 = 21% !!
I have to conclude that this is either 1) a bug in the KLF 200 firmware or 2) a bug in your specific shutter. => @GeVaSta you said earlier that you have two types of shutter with different motors, so I wonder if you can confirm the same 21% error with that other shutter? (This would at least tells us whether to refer the bug report to Velux or Somfy).
Now, you reported that the vanePosition did seem to be reported correctly when you ran your test with HA. And I reported that HA uses a different KLF API command for polling the state, compared to the command used by OH. As I mentioned earlier, I think it might be quite difficult for the OH binding to change over entirely to the HA polling scheme. And even possibly difficult to implement both schemes in parallel. But, nevertheless, I am now going to create a highly experimental build of the binding, that does indeed use both polling schemes in parallel. So we can tests it and see a) if anything else explodes, and b) if the HA polling scheme returns a vane position different than 21%. At least this might help clarify some way forward…
Your response is clear.
I have some questions and remarks.
Why is the vanePosition not reported automatically when I start OH?
Now I only get values back after I have send a commadn from the UI.
The Somfy Tahoma/Connexoon binding I use now, gets the position and vanePosition fine out of the Somfy motors. Also without first sending something. This means the motor reports the right values.
Is it an option to make a setting (Toggle) in the binding to select the preferred polling method. The old-scheme or the new 300 scheme. This could then also be used for a migrationpath for existing users to use a “better” or at least more informative, way of polling.
Both methods simultaneously is, I think, not a good idea.
Could you program something simple to find out, if the problem is in the polling command?
One more question. Why is the vanePosition, equal to the normal position (MP) not always returned at every node-query? Do you need a special kind of query/polling method, to read the FP3, or at least to get the FP3 filled with real data?
In fact the KLF IS reporting/updating the current vanePosition immediately! But the value that it is reporting is 0xF7FF (Unknown); it seems that the only values we get from the KLF are 0xF7FF (Unknown) or 0x2A49 (21%)…
Not necessarily. It just means that they report the right values when talking to another type of bridge.
I am working on that. But it is not simple…
Maybe. But it depends on the “simple” test above…
Who knows?
For your information. However I am willing to test everything, the thing is, after tomorrow I am out of my home for about 2 months. In this time I am not able to test jar’s. After returning I am willing to continue of course. It’s also very much in my own interest.
No stress. I will carry on working on this. @GeVaSta please let me know when you are ready to test again.
Today I can still test if you have something you like to be tested.
Sorry but it’s not ready yet 
No problem. Take your time. i’ll report back in two months.
@GeVaSta I think I found out which part of the Velux API was causing the problem. And so I have developed TWO new JARS to address it.
- The first has fixes that are still based around the existing API calls.
- The second has fixes that based around implementing the new API calls for ‘vanePosition’.
In both cases, the fixes are quite extensive, so I will test them both on my own system for some time (while you are away). But obviously I do not have any shutters with vanes, so I would like you to test it properly on your system too, when you are back.
EDIT: the JARs can be downloaded under the same link as before…
Ah, that sounds very good and promising.
As soon as I am back, I will continue testing. Thank you so far.