Alpaca transport

Alpaca is the cross-platform, HTTP/JSON evolution of ASCOM. Drivers are HTTP services; you talk to them with GET/PUT calls. Works on Windows, Linux, macOS, anywhere — the Alpaca server can even be running on a different machine on your network from the one running Starship.

Enabling Alpaca

Alpaca is off by default. Turn it on in Settings → Equipment: tick Alpaca transport enabled. Until you do, the Alpaca slots stay dormant and nothing polls the network.

Per-role

Same model as ASCOM: each equipment role connects independently. Starship exposes an Alpaca slot for every role:

• Mount (Alpaca telescope)
• Camera (Alpaca camera)
• Guide camera (Alpaca camera)
• Rotator (Alpaca rotator)
• Focuser (Alpaca focuser)
• Filter wheel (Alpaca filterwheel)
• Observatory — roll-off roof or dome (Alpaca dome)
• Power — relay board / smart PDU (Alpaca switch)
• Flat device — flat panel / flip-flat (Alpaca covercalibrator)

You can mix transports freely: run the mount over ASCOM and the camera over Alpaca, or any other combination. Each role picks its own transport.

Setup flow

Every role has a Transport selector in its Settings block with three choices: ASCOM (Windows COM), Alpaca (HTTP/JSON), and None. Pick Alpaca, then fill in:

1. Host (IP or hostname) — the Alpaca server's LAN address, e.g. 192.168.1.50 or localhost.
2. Port — the server's HTTP port. The Alpaca default is 11111 (some servers use 32323).
3. Device number — usually 0; the index of this device on that server when it exposes more than one of the same type.
4. Auto-connect on service start — tick this to have Starship connect the device automatically every time it launches.

Save your settings. To bring the devices online, use Connect all on the console (or rely on auto-connect). Connect all connects every role that has a host set, across both ASCOM and Alpaca, and also brings up guiding. Once connected, each role reports live status and properties just like an ASCOM device.

Finding what's on a server

If you know a server's host and port but not what it's serving, the Discover action queries that server's Alpaca management API and lists every device it exposes — name, device type, and device number — so you can copy the right device number into the role's settings. Discovery talks HTTP to the address you give it; it does not scan or broadcast across the network, so you always point it at a specific host:port.

Hand-editing the config

You can also set everything directly in config.toml. Turn the transport on with [alpaca] enabled = true, then add a block per role:

[alpaca]
enabled = true
poll_interval_s = 5.0

[alpaca.camera]
host = "192.168.1.50"
port = 11111
device_number = 0
auto_connect = true

poll_interval_s controls how often Starship refreshes each connected device's readings.

How it works

Alpaca is just HTTP. To read the mount's RA: GET http://host:port/api/v1/telescope/0/rightascension. To slew: PUT http://host:port/api/v1/telescope/0/slewtocoordinates with form-encoded RA and Dec. Starship handles all of this for you — the endpoints above are just what's happening under the hood.

Every device is polled on a background thread while connected, so temperature, position, shutter state, filter, switches and the rest stay current in the console and dashboard without you refreshing anything. If a device drops off the network, its slot flips to disconnected and reports the error rather than showing stale numbers.

Starship's Alpaca client is pure-stdlib Python — no requests, no httpx, no alpyca. It uses urllib. That means the Alpaca transport has no external dependencies, which matters for the open-core philosophy. Properties a given device doesn't implement (a filter wheel with no focus offsets, a camera with no cooler) are quietly skipped rather than treated as errors, so a minimal driver still connects cleanly.

When to prefer ASCOM

When the only driver available is COM-based, you don't have a choice — use ASCOM. ZWO ASI cameras work via either, but native ASI SDK access is faster than ASCOM. QHY cameras: direct SDK > Alpaca > ASCOM in performance terms. The right choice depends on the camera. Alpaca's advantage is reach — it's the way to drive gear on another machine, on Linux/macOS, or over the network.

Authentication

Alpaca supports HTTP Basic Auth. Starship doesn't currently configure credentials — drivers running on the same trusted LAN are assumed safe. For remote Alpaca (e.g. driving the observatory from outside the LAN), put a reverse proxy with auth in front.