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.
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.
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_secondsis too tight for the sensor's update cadence. Check the sensor's logs to find its typical reading interval and setmax_stale_secondsa 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.