Skip to content

Travel Time Calibration

Jason Rhubottom edited this page Aug 3, 2026 · 1 revision

Travel Time Calibration

Adaptive Cover Pro can measure how long each of your covers takes to travel from fully closed to fully open, and use that to report where a cover is while it is moving. Dashboard cards can then animate the movement instead of jumping straight to the end position.

Not the same thing as Position Calibration. That one maps calculated % onto the % your cover needs. This one measures seconds. They live side by side under the same Calibration menu and are otherwise unrelated β€” you can use either, both, or neither.

Why you'd want it

Most covers report their position rarely, or not at all:

  • A Zigbee roller that publishes current_position once a second gives a card four or five frames for a twenty-second move β€” visibly steppy.
  • A Somfy RTS blind reports no position at all. Between "closed" and "open" a card has nothing to draw, so the cover appears to teleport.

Neither is a bug, and neither can be fixed by polling harder β€” the information simply isn't on the wire. Knowing the travel time lets the integration model the move instead: given where the cover started, where it was told to go, and how long that takes, everything in between follows.

Nothing about where your covers go changes. This affects only how movement is drawn.

Running a calibration

Options β†’ Calibration β†’ Travel Time β†’ Measure now.

The run sweeps each cover in turn:

  1. Drive it fully closed (untimed β€” this just establishes a known starting point).
  2. Time the traverse to fully open.
  3. Time the traverse back to fully closed.
  4. Average the two, then put the cover back where it was before the run started.

Expect it to take a few minutes. The page shows the current state and which cover is being measured; back out and re-enter to refresh it.

⚠️ Your covers will move on their own for the duration, end stop to end stop. Pick a moment when that isn't disruptive β€” not while someone is asleep behind the blind, and not during the hour you actually want shading.

While a run is going, nothing else can command the covers β€” not sun tracking, not a weather-safety retract. The control_status sensor reads calibrating for the whole time so it's clear why nothing is responding, and Cancel on the same page stops the run and sends the covers home. A run also stops itself after an hour regardless.

Covers that can't be measured

Some covers report their state as assumed β€” one-way radio, typically Somfy RTS, where Home Assistant sends a command and has no way to hear back. Those report "open" the instant they're told to open, so there is nothing to time: a measurement would capture the round trip of a service call, not the cover.

The integration detects these and skips them rather than recording a fake number. They're listed on the Travel Time page with a ⚠️, and the configuration summary warns about any that still have no travel time set.

For those, use Enter times manually. A stopwatch and one full close is plenty β€” the figure only affects how movement is drawn, never where the cover is sent, so being a couple of seconds out costs nothing. Set a cover to 0 to clear its time.

This is worth doing precisely because those are the covers with the most to gain: they have no position reading at all, so the modelled one is the only thing a card can show.

Two-rail day/night shades

Day/night shades running the two rail entities model are supported. The two rails share one track and can't pass each other, so before each rail is swept the other is parked out of the way, and both are returned to their original positions afterwards. You don't have to do anything special β€” but note that a full run moves both rails through their entire range several times, so it takes correspondingly longer.

What gets measured

Per cover:

Value Meaning
Full travel Average of the two directions β€” the headline figure.
Open / close Each direction separately. Many covers close faster than they open, since gravity helps; keeping the two apart means a ramp drawn in either direction is right.
Start delay How long the motor sits still after accepting a command before it actually begins moving. Some actuators pause several seconds. Held separately so an animation doesn't start early and finish late.

A hand-entered time records the headline figure only.

Results are stored per cover and survive restarts. They're not re-measured automatically β€” if you replace a motor or the fabric starts dragging, run it again. Clear all times on the same page resets everything.

Where the data shows up

sensor.{device}_cover_position gains three attributes, all present only when there's something to report:

Attribute When Contents
travel_plans While a cover is moving Per cover: where it started, where it's going, when it was told, the start delay, and how long the move should take.
estimated_positions While a cover is moving The same model, sampled as a plain number per cover.
travel_time_calibration Whenever any time is stored The stored table β€” full travel, per-direction, start delay, when it was measured, and whether it was measured or typed in.

There's also a sensor.{device}_travel_calibration diagnostic sensor showing the state of the last (or current) run, plus per-cover results including anything skipped and why. See Diagnostic Sensors.

Making cards animate

The proxy cover, if you have it enabled, animates automatically. While a source cover is mid-move and its travel time is known, the proxy publishes the modelled position β€” and because the proxy is an ordinary Home Assistant cover entity, any cover card pointed at it will animate. This is the simplest route, and it needs no card that knows anything about Adaptive Cover Pro.

The companion card reads the raw attributes directly. Support for them is tracked in card issue #266 and isn't in a released card version yet.

Bear in mind what the estimate is: a model, not a reading. A cover that jams halfway will still be drawn as arriving. That's the deliberate trade β€” it beats a frozen or absent value, and it self-corrects as soon as the move ends and the real position takes over.

Troubleshooting

Symptom Cause
A cover is listed "⚠️ not measurable" Home Assistant reports its state as assumed. Enter a time manually.
A cover was skipped as unobservable after the run tried it It reports no position and never publishes an opening/closing state, so there was no way to see it move. Enter a time manually.
A cover timed out It never reached the end stop within the per-move budget. Check it isn't obstructed, and that it's actually reachable.
A result was discarded as implausible The measured traverse was under a second or over five minutes. Usually a device that echoes its target back before acting. Enter a time manually.
Nothing responds and control_status reads calibrating A run is in progress. Wait, or press Cancel on the Travel Time page.
The run stopped early It hit the one-hour budget. Very slow covers, or a lot of them, may not fit β€” calibrate in smaller batches, or enter times manually.

🏠 Home Β· ✨ Features Β· πŸ“° What's New

Buy Me A Coffee

πŸš€ Getting Started

🧠 Core Concepts

πŸ“ Cover Types

βš™οΈ Configuration

πŸ”Œ Entities & Services

πŸ› οΈ Operations

πŸ”§ Advanced Use Cases

🎨 Dashboard

πŸ§ͺ Testing & Simulation

πŸ“š Reference

πŸ‘©β€πŸ’» For Developers

Clone this wiki locally