Skip to content

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>",
  "managed_by": "this_node",
  "driver_configs": {
    "<driver-id>": { /* driver-specific */ }
  }
}
Field Meaning
managed_by Which node, if any, reads this sensor. "this_node" — this install owns the sensor and reads it directly. "another_node" (the default) — the owning install publishes readings and this one consumes them via the hub. "no_node" — the sensor is gone or unused; SkyNode skips it and never reports it as a fault. In the app this is the Managed by selector on the weather-sensor settings card. Older configs' boolean connect_locally is migrated automatically (true"this_node", false"another_node").

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.

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 managed_by: "this_node". Only the install that owns the sensor should claim it; everything else should be "another_node" and consume the published reading.