The window-covering config has keys totalDurationOpen and totalDurationClose, and accepts hex codes for open, close, and stop, allowing for percentage-open control, based on linear time interpolation.
This is great, except that I find with my curtains, there is a small delay after sending the open/close command before the motor actually starts moving, and this introduces error for percentage-open controls. When setting to the same percentage-open value, the physical result depends on whether it started fully open or fully closed.
To fix this, how about adding another key, say, motorLagTime, to compensate for this delay?
Starting at the fully-closed (0%) position, setting the curtain to 50% would send the open hex code, wait 6000 / 2 + 400 = 3400ms, and then send the stop hex code. It would be the same 3400ms in the opposite direction, from fully-open (100%) to 50%. The waiting time is asymmetrical, but because of the motor delay, the curtain ends up physically at the same position.
The window-covering config has keys
totalDurationOpenandtotalDurationClose, and accepts hex codes for open, close, and stop, allowing for percentage-open control, based on linear time interpolation.This is great, except that I find with my curtains, there is a small delay after sending the open/close command before the motor actually starts moving, and this introduces error for percentage-open controls. When setting to the same percentage-open value, the physical result depends on whether it started fully open or fully closed.
To fix this, how about adding another key, say,
motorLagTime, to compensate for this delay?For example: with the following config:
Starting at the fully-closed (0%) position, setting the curtain to 50% would send the open hex code, wait 6000 / 2 + 400 = 3400ms, and then send the stop hex code. It would be the same 3400ms in the opposite direction, from fully-open (100%) to 50%. The waiting time is asymmetrical, but because of the motor delay, the curtain ends up physically at the same position.