Compensate Drive latency

[DaniEll-AT]

I am currently using the test-branch of this great custom component.

My hardware is:

• Sonoff 4CH
• Somfy J4 WT

The tilt-time of my blinds is ~1200ms (measured by me). The problem i got is, small changes in tilt do not work.
According to the Somfy J4 WT Data Sheet:

Continuous orders of at least 200 ms must be sent to the drive to ensure proper execution.

My guess is, a setting like "actuator-activation-time" would help in such cases.
So i could configure:

actuator-activation-time: 200ms
tilt_duration: 1000ms

The time to change the tilt should then be calculated like this:
actuator-activation-time + (tilt_duration * tilt-difference)

What do you think? Have you seen such cases before?

[pawelma]

Hey. Yes, I saw that one for my drive, but I wasn't able to find anything useful in Sonesse motor specs. Although, when doing measurements it looked like it was not very deterministic, but it might be that tests I run were not accurate enough to show how it's behaving (methodology was doing repeated OPENs/Closes by Xms multiple times writing the distance travelled and then repeating for increased number of seconds).

Looking at the proposal solution, it looks like it should work, but this is not just a tilt. Position also would be affected if for example, tilt is already 'CLOSED' and movement of blinds is set to CLOSING. In the mentioned case the formula should still work, but it's no longer, a tilt but actuator activation. I think that it deserves the own 'method'.

[DaniEll-AT]

I am not sure how to interpret the Somfy Data Sheet. My drive behaves like you described it: Sometimes it moves after ~150ms, sometimes not. Because it is not very deterministic, the time based calculation will always be off with these small changes in tilt/position. Maybe this is not fixable.

As a workaround, a setting like minimum-movement-time could be possible. When the user commands a change in tilt/position that is below the minimum-movement-time the cover is moved for the minimum-movement-time. As a result, the users command is overachieved, but that is IMHO better than no physical/real world/observable reaction to the users command.

[pawelma]

It depends on the usecase and motor someone have :) And I think overachievement is bad from UI perspective, but it is better than your example when no change has been done. Would incrementing by 1% (which is ~100ms in your setup) 100 times cause no movement at all, or maybe the difference happens when fully Open/Closed or after a while or after change of the direction (if latter is it immediate change of direction or after let's say 1 second)?

[DaniEll-AT]

You are right, "it depends".

For my hardware, actuator activation would make the whole calculation more accurate.
My tests just showed, that 10 x 250ms are not the same movement as 1 x 2500ms, they are rather the movement of 1 x 500ms.
Without feedback from the cover/real world, we can only try to model the real world at best efford.

I will have a look, if i can come up with a PR for actuator-activation-time.

[DaniEll-AT]

I implemented and tested #11 with my setup. The "actuator_activation_duration" of "200ms" makes the whole setup more accurate.
Please have a look at the PR. I have at least one open question there and would be happy about reviews 👍