Weather sensor

Weather sensors feed the operational constraint evaluator with sky, wind, temperature, humidity, and (where the sensor supports it) cloud-cover readings. Constraints reference these readings to decide whether observations are eligible to run.

Like enclosures, weather sensors can be bound at the telescope level or at the observatory level — a single sensor that covers the whole site should be bound to an observatory node so multiple telescope nodes don't fight to read it.

Config shape

{
  "device_type": "weather_sensor",
  "driver": "<one of the supported drivers>",
  "connect_locally": true,
  "driver_configs": {
    "<driver-id>": { /* driver-specific */ }
  }
}

Flag	Meaning
connect_locally	If true, this SkyNode install reads directly from the sensor (typically the install that owns the sensor). If false, SkyNode consumes the sensor's readings via the hub (the install that owns the sensor publishes them).

Drivers

All weather sensor drivers are experimental today — they work on specific hardware they've been tested with, but none is a mainline production target. Talk to the Skynet team before relying on one in production. ASCOM is not currently used for weather sensors; each driver targets the sensor's native protocol or file format.

A common parameter across most drivers:

Key	Meaning
max_stale_seconds	Maximum age in seconds before a reading is treated as stale (and the constraint evaluator should ignore it). Defaults vary; raise for sensors that publish infrequently

aag_cloudwatcher — experimental

For Lunatico AAG CloudWatcher sensors.

"aag_cloudwatcher": { "max_stale_seconds": 3 }

aurora_eurotech — experimental

For Eurotech Aurora weather stations.

boltwood_i — experimental

For first-generation Boltwood Cloud Sensors.

boltwood_ii — experimental

For second-generation Boltwood Cloud Sensors (Clarity II).

"boltwood_ii": {
  "prog_id": "ClarityII.CloudSensorII",
  "use_pywin32": true,
  "max_stale_seconds": 3
}

Key	Meaning
prog_id	COM ProgID for the Boltwood II sensor — defaults to ClarityII.CloudSensorII (Diffraction Limited Clarity II software)
use_pywin32	Whether to use pywin32 for COM access (vs. an alternate COM layer)

cumulus — experimental

For weather stations exposed through Sandaysoft Cumulus.

davis_weatherlink — experimental

For Davis Instruments stations exposed through WeatherLink.

"davis_weatherlink": {
  "base_url": "http://localhost:8080/",
  "timeout_s": 10.0,
  "max_stale_seconds": 600
}

Key	Meaning
base_url	URL of the WeatherLink API endpoint
timeout_s	HTTP request timeout in seconds
max_stale_seconds	Stale-reading threshold; WeatherLink updates slowly, so the default of 600 is generous

simulator — testing only

Paper weather sensor. Reports configurable static readings.

"simulator": {}

old_csharp_drivers — legacy

Holdover from a previous Skynet generation. Not used in new installs; documented only so people don't accidentally pick it.

Troubleshooting

• "Constraint says 'unknown' or 'stale' even though the sensor is alive." max_stale_seconds is too tight for the sensor's update cadence. Check the sensor's logs to find its typical reading interval and set max_stale_seconds a few intervals above that.
• "Sensor is up but readings are wrong." Calibration is a hardware-side concern. Verify with the vendor's own diagnostics tool first.
• "COM-based sensor (Boltwood II) won't initialize." Same pattern as ASCOM drivers — check the ProgID with PowerShell, confirm the bitness matches the SkyNode build, and run the vendor's own software to verify the COM proxy is alive.
• "Two installs report different readings." The sensor is bound to multiple installs with connect_locally: true. Only the install that owns the sensor should connect locally; everything else should consume the published reading.