Skip to content

Local GUI tour

SkyNode's local GUI is the day-to-day interface for the on-site operator. It runs as a Tauri window on the SkyNode host, against the same Python backend that the hub talks to over the network — so anything you see in the GUI is exactly what the hub sees, and any manual operation you do here is reflected on the hub.

The Angular GUI ships today; a React port lives at apps/sky-node-desktop/gui-react/ and is in active development. This page describes what's there in the shipping Angular UI.


Page structure

Top-level pages live under apps/sky-node-desktop/gui/src/app/pages/:

Page Purpose
sign-in/ OAuth start — sign in as the user that owns or has update rights on the bound telescope/observatory
auth-callback/ OAuth redirect handler (skynode://auth/callback)
startup/ First-run / cold-start wizard — pair the install, pick the node binding, pull the hardware graph
node-selection/ Pick the specific telescope or observatory the install binds to (used during initial pairing and when re-binding)
dashboard/ The home screen — status, controls, telemetry, current tasks
configuration/ Edit SkyNodeConfig — devices, drivers, hub endpoints, MQTT
recovery/ Crash-recovery flow when the backend can't come up cleanly
sign-out/ Sign out, optionally also unbinding the install

Dashboard

The dashboard is where the operator spends most of their time. It's a tabbed surface (pages/dashboard/):

Tab / panel What it shows What you can do
dashboard-overview Top-level health card grid: bound telescope, control authority, lease state, hub connection, last sync, active devices, key constraints Read-only summary; click through to specifics
dashboard-assets Per-device snapshots — mount position, camera temperature and exposure state, dome shutter and rotation, focuser position, filter wheel slot, weather readings Read-only live state; click to drill into a device
dashboard-controls Manual controls hub — only enabled when the telescope is in manual mode or an active manual control lease is held Jump to the per-device control panel
dashboard-controls-mount Mount control — RA/Dec slew, alt/az slew, park, home, stop, set offset Direct mount commands; safety checks still apply
dashboard-controls-imager Camera control — start exposure, abort, set cooling setpoint, read temperature Direct camera commands; respects current filter / focuser state
dashboard-controls-enclosure Enclosure control — open/close shutter, rotate, home Direct enclosure commands; not all enclosure drivers support all operations
dashboard-constraints All operational constraints, their current status snapshots, last evaluation time Toggle dismissed/active; trigger a re-evaluation
dashboard-weather Weather sensor readings — cloud cover, wind, temperature, humidity, rain — and any sensor-bound constraints Read-only
dashboard-tasks Current and queued observation tasks for the bound telescope View task detail; cancel a task (with appropriate permissions)
dashboard-telemetry Historical graphs — temperature, position, exposure progress — from local snapshots Zoom, pan

The header bar carries the current controlAuthority indicator, the hub connection status, and a quick-toggle for requesting a manual control lease.

The dashboard also surfaces shutdown interlock dialogs when an interlock fires — a modal explaining what tripped, what shutdown actions are being performed, and (where applicable) what to do to clear it.


Configuration page

The configuration page (pages/configuration/) is where you edit SkyNodeConfig from the GUI rather than the JSON. The component is large — every section of the config (hub endpoints, device-by-device driver bindings, MQTT, lifecycle actions) is editable through dedicated forms.

Notable surfaces:

  • Hub settings — auth server, API/gateway URLs, OAuth client parameters. Editing these typically requires re-pairing.
  • Node binding — change the bound telescope / observatory. Triggers a re-pairing flow.
  • Device editor — one form per device in the hardware graph. Pick the driver, supply driver-specific parameters (TCP host, COM port, ASCOM ProgID, …), test the connection. Per-device-type field components live under components/ (e.g., mount-settings, camera-settings, filter-wheel-settings, weather-sensor-settings).
  • Driver-config form — generated from a driver descriptor so each driver can declare its own params without bespoke UI.
  • Local broker (MQTT) settings — enable, host/port, TLS, channels.
  • Lifecycle actions — startup and shutdown checkboxes.

A status bar at the bottom of the configuration page shows the config's dirty state and what will change on save.


Driver / device dialogs

When you add a new device or change a driver, a sequence of dialogs walks you through:

  • device-model-search-dialog — search a catalog of known device models (often the easiest way to populate a new device).
  • device-model-dialog — pick or create the device model record on the hub.
  • device-editor-dialog — bind a driver and its parameters to the device.

These all live under apps/sky-node-desktop/gui/src/app/components/.


Log viewer and status bar

A persistent status bar at the bottom of the window summarizes:

  • The current task and its execution phase, if one is running.
  • Any hub or driver error since startup.
  • Sync progress when the hardware graph is being refreshed.

A log viewer component (components/log-viewer/) lets you tail the backend log without leaving the GUI — useful for operators who don't want to find the log file on disk.


React port — what's coming

The React port at gui-react/ targets the same surface area as the Angular GUI. While it's in development:

  • Use the Angular GUI for production operations.
  • Use the React GUI as a preview only; some flows may still be incomplete.

Once the React port reaches parity it will replace the Angular GUI on the live install path. This page will get updated then.