Skip to content

Wiring devices in SkyNode

This subsection walks through how to bind each device kind to a SkyNode install — what JSON-config block to write, which drivers are available, and what the driver-specific parameters mean.

The model that ties this all together is in Configuration → device_configs. For driver maturity and the support tiers (production vs. experimental), see Driver interfaces.

The canonical reference here is the JSON config block — that's what gets persisted on disk and what the local GUI reads/writes. The GUI exposes equivalent forms for each driver, but the JSON shape is what doesn't move when the UI changes.

Per-device pages

  • Mount — ascom, gbtwenty.py, simulator.
  • Camera — ascom, maxim, simulator.
  • Filter wheel — ascom, maxim, simulator.
  • Focuser — ascom, simulator.
  • Enclosure — ascom, simulator.
  • Weather sensor — aag_cloudwatcher, aurora_eurotech, boltwood_i, boltwood_ii, cumulus, davis_weatherlink, simulator.

ota and instrument_rotator only have simulator implementations today; concrete drivers will get wiring pages when they arrive. receiver and radio_backend are interface-only placeholders.

Wiring page conventions

Every page below has the same structure:

  1. What this device is for — one-paragraph framing for someone wiring it up for the first time.
  2. Config shape — the canonical JSON block, with field annotations.
  3. Drivers — one subsection per driver, with the driver_configs keys and what they mean.
  4. Simulator — a config-only "paper" driver for testing.
  5. Troubleshooting — common failure modes specific to that device kind.

If you're trying to bring a device online for the first time, work through the corresponding page top-to-bottom. The simulator is always a useful safety net — a simulator config will run cleanly without hardware so you can verify the rest of your install before plugging real devices in.