Skip to content

Enclosure

The enclosure protects the telescope and (for automated installs) opens, closes, and rotates in coordination with observations. Skynet treats enclosures as devices controlled either at the telescope level (one enclosure per scope) or at the observatory level (one enclosure shared by multiple scopes — handled by an observatory node — see SkyNode → Overview).

Config shape

{
  "device_type": "enclosure",
  "driver": "ascom" | "simulator",
  "managed_by": "this_node",
  "allow_control": true,
  "driver_configs": {
    "ascom":     { /* see below */ },
    "simulator": { /* see below */ }
  }
}

The two enclosure-specific top-level fields:

Field Meaning
managed_by Which node, if any, opens this enclosure's driver. "this_node" — this install owns the cable and connects directly. "another_node" (the default) — a sibling telescope node or a dedicated observatory node drives it; this install only consumes the state it publishes. "no_node" — nothing drives it anywhere; SkyNode skips it entirely and never treats its silence as a fault. In the app this is the Managed by selector on the enclosure settings card.
allow_control If true, SkyNode actively commands the enclosure (rotate, open/close shutter) as part of the observation lifecycle. Requires the enclosure to be managed by this node. Set to false to monitor without controlling.

Upgrading? Older configs used a boolean connect_locally. It is migrated automatically on first load: true becomes managed_by: "this_node", false becomes "another_node". Do not write connect_locally in new configs.

Together they express:

  • One install controls a dedicated enclosure — managed_by: "this_node", allow_control: true.
  • One install monitors a shared enclosure driven by an observatory node — managed_by: "another_node" (allow_control is ignored without a local connection).
  • One install connects to the enclosure but only to read state — managed_by: "this_node", allow_control: false.

Drivers

ascom — production

For any ASCOM-conformant dome / roll-off-roof driver on Windows.

"ascom": {
  "prog_id": "ASCOM.ScopeDomeUSB.Dome"
}
Key Meaning
prog_id ASCOM ProgID of the dome driver. Examples: ASCOM.ScopeDomeUSB.Dome, ASCOM.AAGCloudWatcher.RollOff, ASCOM.Simulator.Dome

Notes:

  • The ASCOM dome driver's slaving and rotation settings live in the driver app, not in SkyNode. SkyNode sends rotation commands through the standard ASCOM dome interface.
  • Make sure the dome's home and park positions are correct in the driver app before SkyNode tries to use them — shutdown actions (close, park) depend on them.

simulator — testing only

Paper enclosure. Open/close and rotation commands return success immediately.

"simulator": {}

Troubleshooting

  • "Enclosure won't open." Driver-app issue first: check rain sensor input, manual lockout, weather interlocks at the ASCOM-driver level. SkyNode respects whatever the driver reports.
  • "Dome doesn't rotate to follow the mount." Dome-slaving is typically configured in the ASCOM driver app. SkyNode emits rotation commands when the enclosure controller decides the dome should move; if those commands aren't reaching the dome, check the ASCOM driver app's slave settings.
  • "Two installs are fighting for the enclosure." Set managed_by: "another_node" on the install that shouldn't be in control. Only one install may claim a given enclosure at a time — SkyNode refuses to start if more than one enclosure config on a node claims this_node.
  • "Enclosure didn't close on shutdown." Verify the controller_lifecycle.shutdownActions.closeEnclosure flag in SkyNodeConfig is true. Also confirm the dome driver isn't in a state where it refuses to close (mount not parked, dome not at home position).