
Starting this month, uRADMonitor automatically notifies sensor owners when their devices need attention. The system covers two situations: sensors that have gone offline, and sensors with aging electrochemical cells that are due for maintenance. Aging warning applies to the uRADMonitor CITY, INDUSTRIAL, SMOGGIE-GAS, SENSIGAS, MODEL A3 and MODEL A4.
Why this matters
The value of uRADMonitor comes from the network itself: thousands of stations reporting real-time environmental data across the globe. Every offline sensor is a gap on the map. Every sensor with expired cells reports data that can no longer be trusted. Until now, detecting these situations depended on each owner checking their dashboard. Most of the time, nobody noticed. A power outage or a changed WiFi password could silently take a station down for months.
The notification system closes this loop automatically.
How it works
The server checks the online status of every device every 30 minutes. When a sensor transitions from online to offline, the owner receives an email with practical reconnection steps. In most cases the fix takes two minutes: a power cycle or a router check.

Separately, the system tracks the age of the electrochemical gas cells (O3, NO2, SO2, CO, etc) in each device. These cells have a designed lifespan of about two years. Past that point, readings drift gradually, and while the sensor keeps reporting, accuracy degrades. When cells pass their service life, the owner is invited to arrange a sensor board replacement.
Designed not to be annoying
Notifications are deliberately conservative:
- An offline alert is sent once per event, when the sensor actually goes down. If a sensor flaps on and off, a minimum of 3 days passes before another alert.
- If you own multiple sensors, events are grouped into a single email listing all affected units, never one email per device.
- Maintenance reminders repeat at most once every 90 days per device.
- Long-offline reminders repeat at most once every 30 days.
If you restart your sensor and it comes back online, no further action is needed and no further emails are sent.
The technical side
For those interested in how an IoT network handles this at scale, three details:
- Edge detection instead of state polling. Offline alerts fire on the transition from online to offline, not on the state itself. A sensor that has been offline for a month does not generate a new alert every scan cycle. This makes alert volume proportional to actual events, not to fleet size.
- Event queue with per-user aggregation. Alerts are not sent directly. Detection writes events into a queue; a separate delivery process groups pending events per owner and composes a single message. Detection and delivery run on independent schedules, which also allows delivery rate limiting to protect email deliverability.
- Per-device cooldown timestamps. Each device carries its own notification timestamps, so the same unit is never re-alerted within its cooldown window, regardless of how many scan cycles observe it. Different notification types (offline vs. maintenance) use separate timestamps and suppress each other where the messages would overlap.
The goal
None of this is about sending more email. It is about keeping the network as close to fully operational as possible, with the least effort from everyone involved. A sensor that comes back online after a two-minute fix is worth far more to the network, and to its owner, than one that sits dark for a year because nobody noticed.

If you received one of these notifications recently, that is the system working as intended. And if your sensor needs more than a restart, just reply to the email. We read every response. And a human operator will get back to you.


codemore code
~~~~