Skip to main content
The Open/Close control sits in the left column of a dock’s detail view, under the status card and diagnostics panel.

​
Opening the door

Live control works from both the desktop and mobile dashboards. Either way, opening a dock asks you to confirm first: a sheet states the consequence — the lid is about to move — and asks you to confirm no personnel or aircraft are near the pad before it sends the command. Tapping outside the sheet does not dismiss it; only the explicit Cancel button does, because this is a physical action, not a passive confirmation. If a dock is one you cycle constantly, you can turn the confirmation off for it. Open that dock’s settings with the gear, and check Skip confirmation — the box sits under the colour swatches, above the map. The Open/Close button then acts on the first press. Uncheck it to bring the sheet back; the setting takes effect immediately, either way. Three things it does not do, worth knowing before you rely on it:
  • It does not travel. The preference is stored in your own browser and applies to that one dock. A teammate opening the same dock still gets the sheet, you get it again on another computer, and you get it on your phone — which is the surface used standing at the pad, and where the confirmation is worth the most.
  • It does not unlock anything. A dock that is holding a stop or is already moving refuses the press exactly as before, and so does one you are not entitled to command. Skipping the sheet skips the sheet, nothing else. A dock that has gone quiet is not locked, though: its status reads Offline with when it was last heard from, but the button still sends, and the command fails or goes unanswered on its own.
  • It is not a permission. Because it changes nothing about the dock and nothing anyone else sees, anyone who can operate the dock can set it — including someone in another organization the dock is shared with, who can command it but cannot edit its settings.
While a command runs, the status names its direction — Opening… or Closing… — and the button disables on every device, not just the one that pressed it. A command another device started is attributed: Another device is opening… (or closing…), and a stroke driven on the lever at the dock reads Someone is opening manually…. If the direction isn’t known yet, the status says Another device is actuating… and the button reads Dock busy…, rather than guessing which way a physical door is moving. Every stroke lands in that dock’s Recent Activity feed: who ran it, which way, and how long it took.

​
Reading a dock’s status honestly

There is no position sensor on the door. Every position you see is an inference from the last recorded stroke, never a direct observation. A fresh claim reads plainly — Open or Closed. One that has aged past a week reads muted, with its age (Closed · 12d ago), rather than implying more certainty than it has. And when the last stroke established no position at all — it was obstructed, it timed out, someone stopped it at the dock, or it never reported back — the claim is simply absent. The status line then carries the state word instead — Command failed, Stopped (or Stopped at the dock while the stop is still held), Lost track of the door — and shows a dash only for a connected, idle dock that has no claim at all. The dashboard says less rather than guessing, and it never falls back to the previous position: reporting “closed” for a door that’s actually standing half open would be worse than admitting we don’t know. While the door is moving the claim drops off too — a door mid-travel is in neither position. A restart does not erase the claim — the last recorded position stays beside the status, because history is still history — but the dock’s own travel model is gone, so the detail view says so above the control: “Position lost after a restart. Open briefly with the lever, then close.” and offers only Close dock, the one stroke that drives to its switch from anywhere and re-anchors the model. One deliberate stroke to a known end re-establishes the position, and the notice clears. Until then the control still works — this is a notice, not a lock.

​
The pad camera

Camera-equipped docks get a camera button in the detail view’s toolbar. The stream starts connecting the moment you open the detail, so toggling the camera on is usually instant, and the picture holds back until a clean frame has decoded rather than showing you decoder smear. The stream is deliberately bounded:
  • One viewer per dock. Within your own organization, the newest viewer wins: if a teammate takes the stream — or you open it on another device — your view closes and a toast says exactly what happened. Someone outside your organization is simply refused.
  • One live stream per organization, across the whole fleet. Starting a second stream ends the first, with the same toast.
  • Five minutes at a time. A continuously watched stream stops after five minutes and the camera toggle flips off; toggle it back on to keep watching. This is what actually releases the camera on the hardware side, so a forgotten tab can’t hold it forever.

​
The diagnostics panel

Beside the status card sit two readings, both real on a provisioned dock:
  • Temp is the ambient temperature at the landing platform, from the dock’s own air sensors.
  • Lifetime Cycles counts every stroke this dock’s actuator has driven.
A dash instead of a temperature means one of two different things, and the status light tells you which. A dash with a normal light means no air sensors are fitted to this dock. A dash with an amber light and “Air sensor fault” means sensors are fitted and their readings disagree, or both failed — two claims with no way to know which is wrong is not a reading, so the dashboard shows neither rather than picking one. A sensor fault says nothing about the door, which stays commandable throughout. On a phone the diagnostics panel is the status plus a Temp tile that always reads a dash; the live temperature and the cycle count are desktop-only.