Motion time

Calibration of motion steps

1. HTTP UP/DOWN request sent; wait for successful reply (i.e., http_success_codes) = HTTP request delay (measured)
2. Wait for device to send the signal to blinds, and movement begins = response_lag_ms
3. Total motion time = (current_position - target_position) / 100 * motion_time
4. Send stop request (if needed) = Total motion time - HTTP request delay - response_lag_ms
5. Wait for blinds to reach the target position = Total motion time

• The HTTP request delay is in the logs, i.e., Move request sent (484 ms) indicates the HTTP request took 484 ms.

• Using response_lag_ms also helps ensure that if a move event is interrupted early, the position of the blinds will still be correct.

• Because the HTTP request delay in Step 1 can vary significantly (e.g., in the event of a failed request, it could be a few seconds), it is not included in the equation for Step 4. This is also shown in the Example below.

• The optional stop request needs to be sent before the blinds will actually reach the target position. This is because there is a delay (i.e., Steps 1 and 2) before a request is sent, received, and the corresponding signal sent.

Therefore, to calibrate your blinds, you will need to set response_lag_ms. This can be a second or more in some cases. The simplest way to do this is to determine the time from initiating an open/close event via HomeKit to the time you can see/hear movement, and subtract the HTTP request delay (from the logs). This is only relevant when trigger_stop_at_boundaries is required, or, a value of 1-99 is used for the blinds (not just fully open or closed).

Example scenario

motion_time = 10000, response_lag_ms = 750

• 0.00 Open command sent
• 0.25 HTTP request successful (Move request sent (250 ms))
• 1.00 Blinds moving...
• 10.25 Stop request sent
• 10.50 (est.) HTTP request successful
• 11.00 (Blinds should have stopped moving here, but HTTP request delay was ignored as mentioned above)
• 11.25 Stop command received by blinds, blinds stopped moving

Motion time graph

motion_time_graph has a higher priority over motion_time. This means, that if these are both explicitly provided in the configuration file, the value set in motion_time will be ignored. A linear rate of change will be assumed between positions and pos = 0 and pos = 100 are required at a minimum. Per HomeKit, a position of 0 = closed, 100 = open.

    "motion_time_graph": {
        "up": [
            { "pos": 0, "seconds": 0 },
            { "pos": 1, "seconds": 9.25 },
            { "pos": 10, "seconds": 11.09 },
            { "pos": 99, "seconds": 24.72 },
            { "pos": 100, "seconds": 24.87 }
        ],
        "down": [
            { "pos": 100, "seconds": 0 },
            { "pos": 50, "seconds": 6.8 },
            { "pos": 1, "seconds": 15.35 },
            { "pos": 0, "seconds": 23.72 }
        ]
    },