Skip to content

SkyNode

SkyNode is the agent that runs at your observatory and bridges your local hardware to the Skynet hub. One SkyNode install corresponds to one record in Skynet's SkyNodeInstallation table, which in turn binds to either a single telescope or a whole observatory.

SkyNode handles four things on your behalf:

  1. Local hardware — connects to your mount, cameras, filter wheels, focuser, enclosure, weather sensors, and so on through pluggable drivers (ASCOM, MaxIm DL, vendor-native, simulator).
  2. Task execution — pulls observation tasks from the hub when the telescope's controlAuthority is remote, runs them through a per-observation-type executor (optical imaging, optical imaging calibration, radio mapping, radio tracking), and reports results back.
  3. Telemetry — publishes device snapshots, constraint snapshots, manual-control-lease changes, telescope logs, and instrument state to the hub continuously, and (optionally) re-publishes them to a local MQTT broker for in-house monitoring tools.
  4. Manual operation — exposes a local GUI for the operator to directly control devices when running locally, with or without an active manual control lease.

The source lives under apps/sky-node-desktop/ — a Tauri shell wrapping a Python backend (backend/sky_node/) and an Angular GUI (gui/). A React port of the GUI (gui-react/) is in progress.

Telescope node vs. observatory node

A SkyNode install is configured as one or the other through its node_type field in SkyNodeConfig:

  • Telescope node (node_type: telescope) — bound to a specific telescope, with telescope_id and observatory_id both set. Monitors and controls everything attached to that telescope: mount, cameras, OTAs, filter wheels, focusers, instrument rotators, receivers, radio backends, and (optionally) the enclosure and weather sensors.
  • Observatory node (node_type: observatory) — bound to an observatory only, with no telescope_id. Focuses on observatory- level devices: weather sensors and enclosure (when the enclosure serves multiple telescopes).

The split exists because not all observatory devices belong to a single telescope. A dome that protects two telescopes, or a weather sensor that gates the whole site, should be owned by an observatory node — otherwise both telescope nodes would race to control it.

If your observatory has only one telescope under its own enclosure, running a single telescope node with the enclosure attached is fine.

Control authority and manual control leases

Two flags decide whether SkyNode is taking tasks from the hub or yielding to a local operator:

  • controlAuthority lives on the telescope record. It's either remote (the default — SkyNode runs scheduled tasks) or manual (automated scheduling is paused; the operator is in charge).
  • ManualControlLease is a time-bound override: even when controlAuthority is remote, an active lease pauses automated task execution. When the lease expires or is released, automated execution resumes immediately.

The two are intentionally different tools:

  • Use controlAuthority: manual when the telescope is going off the network for a longer period — engineering, maintenance, manual observing nights, prolonged weather closures.
  • Use a manual control lease for short, ad-hoc takeovers — a few minutes to slew somewhere by hand, a brief manual focus tweak, a reset of a stuck device. The lease has an explicit expiry so forgetting to release it doesn't strand the telescope.

Either can be triggered from the SkyNode local GUI or from the website. Whether ordinary observers can request a lease, and what the approval/revoke flow looks like for the owner, is something the Operations page covers in more detail.

How SkyNode talks to the hub and your network

SkyNode connects to two hub endpoints:

  • Public API (api_server in HubConfig, default http://127.0.0.1:5001) — REST endpoints for task fetch, snapshot publish, file upload, etc.
  • Gateway API (gateway_api_server, default http://127.0.0.1:5002) — the sky-node-gateway service, used for the bidirectional command/stream surface.

Authentication is OAuth — see Installation for the pairing flow.

Optionally, SkyNode runs its own MQTT publisher that mirrors device and constraint snapshots to a local broker. Enable it via local_broker.enabled = true in SkyNodeConfig when you want internal observatory tools (status displays, monitoring dashboards) to subscribe directly without going through the hub.

Where to go next

  • Installation — install the desktop app, pair it with the hub.
  • Configuration — full walkthrough of SkyNodeConfig.
  • Driver interfaces — how SkyNode integrates with mount, enclosure, receiver, and radio-backend hardware; what the driver interface looks like.
  • Operations — running observations locally, manual command executor, lease workflow.
  • Local GUI tour — what the dashboard and configuration pages expose.
  • Troubleshooting — sync monitor, recovery, common failure modes.