What should a rain-station API preserve during an outage?
Preserve the original measurement time, station identity and a stable record identifier. Define durable local storage, acknowledged delivery and retries so the platform can distinguish delayed measurements from new measurements and avoid counting a retry twice.
Engineering plan
Keep rainfall records through an outage
Constraint
The receiving platform needed the original measurement time, station identity and records after a connection interruption.
Decision
Define storage, record identity, acknowledgement and recovery tests alongside the platform interface.
Working output
A data-delivery contract and an outage/recovery test scope.
Stage & next checkPlanned checks; no passed test or accepted deployment is claimed.
Measurement time and arrival time answer different questions
A reading collected before a network outage may arrive much later. Keep measured_at and received_at as distinct fields, with a stated timezone and clock-sync policy. A graph based only on arrival time can move rainfall into the wrong interval.
Treat a retry as the same record
The planning scope used a stable record identifier and specified how the server acknowledges accepted records. The proposed authentication covered the exact transmitted payload. The implementation must agree record format and retry behaviour with the receiving platform, rather than assuming an HTTP connection is sufficient.
Turn recovery promises into test cases
The project separated mains/Wi-Fi and solar/cellular configurations and described a paid engineering phase with its own deliverables. Offline storage and recovery were verification requirements, not assumed device features.
- Interrupt the network, then restore it and compare collected and received records.
- Restart the unit while records are waiting to upload.
- Exercise timeouts and server error responses.
- Check duplicate retries, chronological ordering and storage-full behaviour.
- Document the maximum supported outage for the final sampling rate and configuration.
Evidence & context
Anonymized rain-station firmware and platform-integration scope, August 2026. The source defines proposed work and tests; it does not prove completed testing or delivery.
The basis above distinguishes editorial guidance from anonymized project records. Final equipment capabilities and delivery commitments require configuration-specific confirmation.
Common questions
Does local storage always mean automatic backfill?
No. Confirm whether the selected firmware keeps unsent records, retries them and removes them only after a valid acknowledgement.
Can a station connect to our existing platform?
We can review your receiving interface and agree the device, data mapping and integration work. Compatibility must be checked for the final configuration.
