Well only a few days after putting my latest version up, the system was tested in a very real way.
A large winter thunderstorm moved through New Jersey on Wednesday night. One bolt of lightning made my wife and I jump out of our seats with a noise inside our home.
It was so scary that I looked around the house to make sure nothing was on fire.
Later that evening, I noticed that my WIFI was down. A quick troubleshoot had me rebooting the cable modem as it was blinking all light in synch. The next morning it was the same and basically, most of the day was spent either on the telephone with tech support or driving to get a replacement cable modem.
It got fried. Best I can tell it was the Ethernet ports in the Modem.
Anyway, once I got that back online, I was then able to plug in my wireless router and low and behold, it was not obtaining an IP address. So I’m assuming it got damaged as well (being attached to the same ports that got hosed).
So I checked the Internet of Things gradient temperature project to see how it was responding. I was worried on two fronts. one was losing internet connectivity and the other was the surge put the Arduino or my logging computer into a non functional state.
The whole system kept working without a hiccup. Before the Wifi situation was fixed, it had logged over 1,000 readings to the SQLite database and was gracefully failing on attempting to replicate them to the web based database.
Here’s a screenshot of my local SQLite database table containing the non-replicated data.
Real world test # 1 passed. Connectivity outage did not take my application out.
The replication is designed to do 9 updates every 10 minutes. I left a safety boundary around the time that reading are taken and written to the SQLite database due to file locking concerns. (I did not look into how SQLite handles locking if at all). Put another way, it updates 1.5 hours of readings every 10 minutes.
The data is about 1.5 days stale and should be up to date in about 4 hours.