-
Notifications
You must be signed in to change notification settings - Fork 22
Command Queue
Availability: not in v2026.8.0. This ships in the next monthly stable release.
A command queue makes covers take turns transmitting. Covers that name the same queue never send a command at the same moment, which stops one-way radio backends from losing frames to collisions.
You need this if, and only if, your covers share a radio that has no acknowledgement: Somfy RTS, RFXtrx, and similar 433/868 MHz one-way protocols. On Zigbee, Z-Wave, KNX, WiFi, or anything else that acknowledges a command, leave it alone. Covers with no queue set behave exactly as they did before this feature existed.
RTS motors never confirm receipt. Two frames keyed at the same instant collide, and both are simply lost. The motor does not retry and Home Assistant never learns anything went wrong: the cover just does not move.
This bites hardest on installs where each cover is its own Adaptive Cover Pro entry. Sun geometry is shared, so covers on the same facade compute the same trigger time and fire together. A 16-cover install across four facades will routinely have several covers deciding to move at 12:30, and several more at 16:30, purely because the sun reached the same angle for all of them.
A reasonable assumption, and a wrong one. The stagger delay in Cover Groups only spaces commands that the group itself dispatches: a scene activation, a group position call, a lock release. It sits inside the group's fan-out path.
Each member's own sun-tracking pipeline never touches that path. A member calculates and fires on its own schedule, with no knowledge of what any other entry is doing. So grouping by facade fixes collisions within a group's scene actions and does nothing for everyday automatic tracking. Two different groups, or two ungrouped covers, can still key the radio in the same instant.
The two mechanisms are independent and can be used together. Stagger orders a group's own fan-out; the queue arbitrates between entries whatever triggered them.
Step 1 is the whole feature. Open each cover's options, go to β±οΈ Movement & Schedule, and type a name into Command queue. Use the same name on every cover that shares a transmitter.
Matching ignores case and extra spaces, so Facade South, facade south, and Facade South are the same queue. The name you typed is what you see in the UI; the folding happens only when matching.
That is enough. A named queue serializes immediately, at a 5 second gap, with no further setup. The field is also part of the Automation sync category, so Copy Settings to Other Covers will push one queue name to every cover you select in a single step. On a 16-cover install that is the difference between one action and sixteen.
Leave the field blank for no queue. That is the default.
To use anything other than 5 seconds, create the queue as an entry. From the integration's Add menu, choose Create command queue, give it the same name your covers use, and set Gap between commands (0 to 60 seconds).
Creating the entry is optional and always has been. It exists so you can tune the gap and see who joined. A queue name that matches no entry still works.
Changing the gap takes effect on each cover's next command. No reload, no restart.
Queue names are unique: a second entry with the same name is refused, because the name is the identity covers link by. Deleting a queue entry does not touch any cover's settings; the queue reverts to the 5 second default and keeps working.
5 seconds is a reasonable starting point for RTS. If you still see missed commands, raise it. The practical ceiling is not the 60 second maximum but your reconciliation budget: a queue with N covers needs roughly N Γ gap seconds to work through a full round, and covers that do not get a turn within a cycle wait for the next one.
A queue entry's options include π¦ Queue Overview, a read-only list of every cover currently naming that queue. Use it to catch the failure this feature is most likely to produce: a typo that silently puts one cover on a queue of its own. If a cover is missing from the list, its name does not match.
The queue sits between "Adaptive Cover Pro decided to move this cover" and "the command is actually sent". It changes when a command leaves, never what position was chosen. Every part of the decision pipeline runs first and is unaffected.
Three behaviours are worth knowing:
Safety jumps the line but still takes its spacing. A weather override, a priority-100 Custom Position slot, or an explicit user command goes ahead of routine sun tracking that is already waiting. It does not skip the gap. A storm retraction firing across sixteen covers at once is the single most collision-prone moment there is, so that is exactly when spacing matters most. Safety must not wait behind tracking; it must still be spaced.
A newer decision replaces an older waiting one. Only one command per cover can be waiting at a time. If the sun moves while a cover is queued, the newer target replaces the queued one rather than stacking behind it, and the older one is recorded as skipped with the reason superseded_in_queue. Without this, a busy queue would eventually transmit targets that were twenty seconds stale.
No command waits forever. Each command has a 30 second wait budget. If the queue is still busy when that runs out, the command transmits anyway. Spacing is best-effort under heavy load, not a hard guarantee, and a jammed queue can never leave a cover stuck.
- It does not retry a lost frame. Nothing in RTS can tell you a frame was lost. The queue reduces collisions; it does not detect them. For covers that stop short of their target, see Position Verification.
- It does not serialize commands from outside Adaptive Cover Pro. Another automation, a physical remote, or the HA cover card writing directly to
cover.*bypasses the queue entirely. - It does not group covers for any other purpose. Queue membership is not a roster, has no scenes, and grants no bulk control. That is Cover Groups.
- It does not replace My Position or any other RTS-specific setting. Those solve a different problem, and most RTS installs want both.
Each cover's diagnostics carry the queue outcome for its last command: which queue it used, how long it waited, how many covers were ahead of it, and whether it went immediately, waited its turn, or transmitted on an expired budget. A run of budget_expired outcomes means the queue is oversubscribed and the gap is too high for the number of covers on it.
The queue entry's own diagnostics report the resolved gap, whether that gap came from an entry or the default, and how many covers are attached.
See Debug & Diagnostics.
- Hardware Compatibility for the full list of RTS-specific settings
- My Position Support (Somfy RTS) for reaching a third position on open/close-only motors
- Cover Groups for orchestration, scenes, and the group stagger
- Automation for the page the queue field lives on
- How It Decides for the pipeline that runs before the queue is consulted
π Home Β· β¨ Features Β· π° What's New
π Getting Started
- Installation
- Migrating from Custom Repository
- Migrating from Adaptive Cover
- First-Time Setup
- Building Profile β start here if you have multiple covers
- Cover Groups
- Copy Settings to Other Covers
- Cover Types
π§ Core Concepts
π Cover Types
- Vertical
- Horizontal
- Oscillating Awning
- Roof / Skylight Window
- Tilt
- Louvered Roof
- Sliding Curtain
- Day/Night Shade
- Dual Panel
- Venetian (Dual-Axis)
βοΈ Configuration
- Sun Tracking
- Position
- Position Matching
- Travel Time Calibration
- Glare Zones
- Automation
- Command Queue
- Custom Position
- Force Override
- Weather Safety
- Climate
- Templated Thresholds
- Template Self-References
- Blindspot
- Summary Screen
- Debug & Diagnostics
π Entities & Services
- Entities
- Proxy Cover Entity
- Position Verification
- My Position Support (Somfy RTS)
- Runtime Configuration Services
π οΈ Operations
- Known Limitations
- Hardware Compatibility
- Troubleshooting
- Troubleshooting Findings
- Diagnostic Sensors
- Tips and Tricks
π§ Advanced Use Cases
- Overview
- Dynamic Temperature Thresholds
- Dynamic Tracking Window
- Bedroom Sleep Mode
- Handling Variable Cloud Cover
- Indoor Lux Sensor Behind the Cover
- Venetian Tilt-Only on Overcast Days
- Forecast-Based Shading
- Custom Position When Sun in FOV
- Suppress Closing While a Door Is Open
- Keep a Blind Clear of the Sill
π¨ Dashboard
- Dashboard Cards
- Panel Card
- Tile Card
- Sky Compass Card
- Decision Strip Card
- Solar Chart Card
- History Card
π§ͺ Testing & Simulation
π Reference
π©βπ» For Developers