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.
- Measure
Station, interval and original time
- Store + replay
Stable record ID and persistent queue
- Receive
Acknowledge, deduplicate and save
Rainfall data example
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.
Configuration documents
A record format, acknowledgement method and test plan for lost connections and restarts.
Check before orderingTest network loss, queued records and restart with the final firmware.
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
Define a stable record identifier and how the server acknowledges accepted records. Agree authentication for 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
Compare mains/Wi-Fi and solar/cellular configurations separately. For each configuration, state where records are kept and how delivery resumes. Include any required firmware or platform work and its recovery checks in the proposal.
- 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.
Define the rainfall interval as well as the timestamp
A payload may contain a tip count, an interval total or an accumulated counter. Name which one is sent and how the receiving platform converts it. Keep units and reset behaviour in the interface document. If an accumulated counter resets after service, the platform needs a rule for that change instead of treating it as negative rainfall. For interval totals, agree the interval boundary and timezone.
Check the exported file after the outage test
A dashboard can display a plausible graph while an export has duplicate rows or different time labels. Compare an exported interval with the station record, including delayed samples. Record how uncertain or missing measurements are represented. Check a service reset as well as a network outage so the operator can distinguish a measurement change from a transport delay.
| Field | Use in the receiving system |
|---|---|
| Measurement time | Place the value in its observation interval |
| Arrival time | Measure delivery delay and connection health |
| Record identifier | Recognize a retry of the same observation |
| Station identifier | Keep locations and replacements distinguishable |
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.
