As I said just now, please see if the latest OH JAR does actually behave different. It may be that it actually does work now.
I am not an expert on Github. Can you point me to right jar please.
This is not the right one I think.
That is the correct JAR. If I rebuild new versions, I will make sure that they will still always be available on that same link.
Right, got it.
I installed the jar.
What I did:
Blinds fully up (start position of test).
In OH UI slider to 80. The blinds went down and then went to the selected slat-position. Looks good. but did not have to go down first. The second strange thing was the slider in the UI went after about one minute back to position 21. Slats did not change.
Then I slide to 40. Slat rotates ok.
Then I went with the manual remote to slat-position 58. I did not get a confirmation back in the UI.
Perhaps the logs clarify my story.
I also attach an older console-log where I saw after a Slat-change request in the UI, after about one minute an I/O error coming. This was the moment I think the UI jumps back to position 21.
TraceConsole1.txt (3.9 KB)
Trace4.txt (1012.4 KB)
One other thing. From the normal up-stop-down buttons only the up and down buttons work. Stop did not give a reaction.
Thank you for your HA log. It points out one difference between OH and HA as follows. For reading the device statusâŠ
- OH uses the {200, 201, 210, 211} command set
- HA uses the {305, 306, 307} command set
Whereas, for writing the device status, both OH and HA use the same {301, 302, 303} command set.
Logically, it should not make any difference whether the {200, 201, 210, 211} or the {305, 306, 307} command sets are used. The telegrams both include the same data for the Functional Parameters 1 thru 4, which are the ones that we need. (And if they would NOT return the same FPx data, I think that would indicate a major bug in the KLF firmware).
So @GeVaSta I would definitely like you to check again if my latest JAR (based on the {200, 201, 210, 211} command set) is working or not. And (only) if it is not working then I think we have a major problem as followsâŠ
- That means there is a major bug in the KLF 200 firmware.
- We would have to implement the {305, 306, 307} command set in parallel with the {200, 201, 210, 211} command set.
Note: I would not dare to âsimplyâ switch from {200, 201, 210, 211} to {305, 306, 307} because that risks to break the long established existing functionality of the OH binding. But I also I think that running two polling mechanisms in parallel would risk to create its own problems. So if we do have to go down that path, I think it requires a lot of work. (@gs4711 do you have any thoughts on this?)
So @GeVaSta I have my fingers crossed, that my latest JAR does actually work for youâŠ
Commands used by OH to read device status
0x0200 GW_GET_NODE_INFORMATION_REQ
0x0201 GW_GET_NODE_INFORMATION_CFM
0x0210 GW_GET_NODE_INFORMATION_NTF
nb: OH also consumes house status notifications..
0x0211 GW_NODE_STATE_POSITION_CHANGED_NTF
Commands used by HA to read device status
0x0305 GW_STATUS_REQUEST_REQ
0x0306 GW_STATUS_REQUEST_CFM
0x0307 GW_STATUS_REQUEST_NTF
nb: HA seems **NOT** to consume house status notifications
Oops. It looks like my prior message crossed with yours. I think we are making some progress. But I have a number of questions belowâŠ
Did you move the position or the vanePosition slider in the UI?
Can you please clarify what you mean by this?
Good news!
If you wait some time (60 minutes say) does it eventually update?
If you do the same in HA (manual remote control), does HA update the slat-position?
That would be correct. I implemented vanePosition as a Dimmer channel rather than a RollerShutter channel.
^
Some observations from your log:
In your post above that you slid to 80% and then to 40% so it is confusing to which command the log applies. => Can you please separate the commands that you send by a couple of minutes so that the entries in the log are easier to keep track of?
Anyway, the vanePosition value is in Functional Parameter 3. We can see the FP3 command that was sent (search for âreqFunctionalParameter3â), and the the feedback values that were received (search for ântfFunctionalParameter3â). For example as followsâŠ
- Command: âgetRequestDataAsArrayOfBytes(): reqFunctionalParameter3=40960â (i.e. this is 80%)
- Feedback: âsetResponse(): ntfFunctionalParameter3=10825â (i.e. this is 21%)
There are potentially two things behind the differencesâŠ
- Maybe a position mapping inversion issue: 80% <=> 20% ??
- Maybe a rotary range issue: 40% of 90 degrees <=> 20% of 180 degrees ??
I would need more readings (slowly please) in order to figure out what is happeningâŠ
But I have a number of questions belowâŠ
Did you move the position or the vanePosition slider in the UI?
I moved the vanePosition slider
Can you please clarify what you mean by this?
I would expect only a slat-position change, also only tilting the slat, but the blinds first moves down fully. Also when the blind is half-up
Good news! Yes, expected behaviour
If you wait some time (60 minutes say) does it eventually update? I suppose you meant 60 seconds. No, no update in OH
If you do the same in HA (manual remote control), does HA update the slat-position?
Yes, it updates but sometimes it takes till about 30 seconds
That would be correct. I implemented vanePosition as a Dimmer channel rather than a RollerShutter channel.
[/quote]
I mean the âoldâ position control. (Up triangle, rectangular, down triangle). Normally pressing the middle button (rectangular) the movement should stop. After stopping, a second press should move the blind to the so called Somfy MyPosition. A programmable position and slat-position.
Is the next step for me, producing more distinguishable logs or have you already some info to finetune something?
Curious as I am. Whatâs the reason you can retrieve the vanePosition now and not when we started this case?
Yes please. Let us try 0% / 42% and 100% for a startâŠ
The problem was/is that it does not (yet) update the position if the command came from the manual remote. And the prior JAR was unable to send commands from itself.
Tomorrow I will start producing te logs
1 Like
We can do this two ways: a) (current behaviour) if you send a slat position command while the shutter is open then two commands are issued, the first closes the shutter and the second moves the slat, or b) I can change it so that only one command is sent to (nominally) move the slats, but in that case the slats will obviously actually not move. Which do you prefer?
No I did actually mean 60 minutes. In my experience some devices only very seldom inform the hub if they have been operated locally.
If the stop button does not work then that is probably a bug. It works fine for me. This is by no means related to what we are working on here. So I suggest to handle that later as a separate issue. Also the double press functionality of your remote is not part of the KLF functionality, and probably cannot therefore be replicated in OH.
I think the io read timeout error may be unrelated. Or perhaps because you were asking the hub to do too many things at the same time. So again I suggest to postpone this until later. And if it persists we can address it as a separate issue.
Actually we need two command to have it ideally. Now I use the Somfy Tahoma solution (Cloudbased) and I have two command for the slats.
1 âsetâ; slats tilt only
2 âset and closureâ; this is the behaviour you have now.
The first is the most important and necessary. When the blind is half down, you must be able to only tilt the slats.
The set and closure command I issue when the sun starts to shine. The blinds move down and set the slat in the desired position.
During the day, when the sunheight changes, the slats only tilt. Also when I manually have moved the blinds up a little, the tilt changes dependant of the sunheight.
When here is only one command âsetâ possible, and you can issue two command after each other, it would perhaps be possible to first send the âdownâ command and right after that, the âsetâ command. This only works when the second command executes only when the first command has finished. This way it worked before In the Tahoma solution (before âset and closureâ).
^
Are you saying that your shutters can be tilted when partially open? This is more sophisticated than the tilt-on-closed operation of a typical Venetian blind. If so, then I can easily decouple the two channels.
Yes Andrew, sure they can be tilted in every position (up-down). When half open, half of the slats are stacked at the bottom-âbeamââ but tilt like the other slats. Even when fully up, they can be tilted but of course, this is of no use.
Here is a picture of the Hobbykamer-blinds in not fully down state.
Here is a new Trace log of OH3 with the latest JAR.
What I did (times are not at the second accurate):
12:18 vanePosition to 100; went down an positioned slats in 100; fully closed
12:20 vanePosition to 43; slat positioned ok
12:22 vanePosition to 0; slat positioned ok; fully open
12:24 vanePosition to 80; slat positioned ok
12:26 vanePosition to 10; slat positioned ok
12:28 vanePosition to 60; slat positioned ok
12:30 end of trace
After setting the vanPosition, the vanPosition-slider changed to 21 after a few seconds till about one minute. Only at position 100, the slider went to about 66. Later when I tried it again to switch from 0 to 100, the slider went also to 21.
trace5.txt (690.7 KB)
trace5a.txt (690.2 KB)
trace5b.txt (702.6 KB)
^
Many thanks for the logs. The 21% (hex 2A49) is still quite a mystery. I am thinkingâŠ
Ok. I found the ghost in the machine. There is a new JAR file on the same link as before.
@GeVaSta please let me know if the latest JAR is now working.
I installed the new JAR. Slatposition change does only change slatposition; OK.
However the 21-ghost is still alive.
What I did. I restarted OH and logged from the start.
At about:
16:29 I manually with my hardware-remote, lowered the blinds to 17%; no change in UI for vanePosition; Up-Down position got updated ok in UI.
Now all changes using the OH UI.
16:32 vanePosition to 80; vanePosition changed OK. After some seconds vanPosition-slider changed to 21
16:33 vanePosition to 40; vanePosition changed OK. After some seconds vanPosition-slider changed to 21
16:34 vanePosition to 100; vanePosition changed OK. After some seconds vanPosition-slider changed to 98!
16:35 vanePosition to 0; vanePosition changed OK. After some seconds vanPosition-slider changed to 21
16:36 UP-DownPosition using UI down-triangle; blinds went down. Afterwards I changed the vanePosition to 80; Down movement got interupted by vanePosition change. This means (I think) I canât issue both command after each other in the hope the blinds will move down first and thenset the vanPosition.
trace6c.txt (825.8 KB)
trace6b.txt (869.5 KB)
trace6a.txt (1001.5 KB)
@GeVaSta many thanks for the testing; and apologies that it is taking so longâŠ
Hmmpf. I will try some moreâŠ
DittoâŠ
And, I suppose vice-versa might apply to. Did you test that?