Great initiative.

I think one useful feature will be to automatically show on app startup all stations close to user’s position, so the app would be as informative as possible. Also stats on radiation trends and a few lines on exposure limits and their effects, as published in current literature.

Email alerts or push notifications should be configured on the website, and delivered to the mobile apps, for events like: major changes in background radiation levels at some location, preconfigured threshold reached, etc.

The ui should take advantage of modern UI/UX

So if I understand it correctly, this could be packed into the following scenario:
1) By default program the units with a default mac, a default ID and uradmonitor.com as single server
2) When the unit connects, it would download a freshly allocated mac/device ID and a list of alternative servers and store the data in its EEPROM.
3) Periodically, the unit would check if other alternative servers are available (and delete those that are offline).

Would this work? Does it cover everything, enough to make this decentralisation stand?

I believe the logic will require only a minimal code, that can fit in the available flash memory. The only issue is I find multiple transmissions of the same data to multiple servers a bit redundant (not a big issue though).

My pleasure. The “connection-watchdog” is set to 5 minutes.

These are all valid points, Vinz, and we should see how to secure the central server dependancy.

But at least for the IP, things are not that bad:
– the units use DNS to resolve data.uradmonitor.com to latest IP
– if communication fails, the units will automatically reboot, part of a watchdog mechanism, so at least this part is covered.

As you said it is a good time to start thinking about a way “to break the dependency to the central server”, while keeping the solution easy to use (plug and play)