>> TEMPERATURE MONITOR - DEALING WITH A FROZEN ARDUINO
Well; that didn't take long - all of a sudden temperature data stopped
arriving from the Arduino.
After working flawlessly for over two days; something happened such that my
last recording was received at 09:03am earlier this morning - basically, the
Arduino just froze up and did nothing. After a quick reboot the data started
streaming over again (at 10:44am) so it was time to put some fail safes into
the sketch to deal with unexpected lockups and weird crashes.
I have written about watchdog timers
in the past that would allow a device to go into a nice sleep mode to
maximize power but now it is time to use them as they were designed. To kick
the micro-controller in the backside if the code doesn't check in periodically.
The issue could have also been a result of the very long delay call
in the sketch - so I also optimized that to work a little better.
The avr/wdt.h header is the only one we need here - in addition, I
recorded the exact amount of time it takes for a reading/upload to occur to
make sure the communication to the server occurs almost perfectly on the minute.
The time to perform the reading of all four of the DS18B20 and the HTTP POST
request was just under ten seconds.
The above is slotted into our setup function; just a little house
keeping at first and you can see we set the watchdog timer to activate
after eight seconds - there are multiple values you can use, but eight
seconds is sufficient for what we need. The last line is to make sure the
first time we run the loop function it will perform a reading
The changes to the loop function are as above. In order to do
anything; we want to make sure that the requires amount of time passes -
in addition, we are checking if the millis counter overflows;
which is documented to happen after approximately
It is important to update the ts variable after we transmit the
data to the cloud for this to work as well. Otherwise the device sleeps
for half a second and resets the watchdog timer. We also need to find all
places in the sketch where their can take longer than eight seconds delay
or the device will reset.
One such place is when the sketch attempts to connect to the WiFi network -
we need to reset the watchdog timer and also lower the delay to anything under
eight seconds for this to work correctly. A delay of only five seconds
for the network connection was sufficient in the tests I performed.
// reset the watchdog timer
// attempt to connect to Wifi network:
while (status != WL_CONNECTED)
Serial.print("Attempting to connect to WiFi SSID: ");
// Connect to WPA/WPA2 network:
status = WiFi.begin(ssid, pass);
// reset the watchdog timer
// wait 5 seconds for connection:
With this; a new sketch was deployed which hopefully will not freeze up.
A complete updated sketch is available below - time will tell if
these changes are sufficient to keep the system stable. It has been reported
often that the WiFi and Ethernet shields cause lockup's on the fragile
16Mhz micro-controller - the use of watchdog timers has always proven
successful in most of the cases it has happened.
An additional change is required when the client.connect() function
fails; the WiFI environment may need to be reset - the simplest way was to
add the following code in the loop function.
In the existing case; if the function would fail - the watch dog timer
would get reset at the end of the loop and as such would never kick in.
The above should attempt to reconnect to the WiFI network.