Yet another Webtherm

It is understood the web is full of instructions how to build Online-Thermometers with microcontrollers. Anyway ...


How it was done

You could install a web server on an Arduino that responds to http-requests by sending the required data.
We decided to implement an ftp client and uploading the data in certain intervals. A commercial web server is more reliable than a microcontroller released in the wilderness. Also it can respond to multiple requests easily.

To get the measurements an SMT160-30 was used. You don't need a big library to read the duty cycles and calculate the temperature.

As temperatures don't change very fast you don't need to read the sensor(s) more than twice or four times an hour. Still over the time, you get a lot of data. When you store them in the EEPROM memory you soon run out of space. So you have to rewrite the cells from the start. As you know the number of rewrites to a single cell is limited. The manufacturer only specifies 100,000 rewrites.

So the amount of samples shown in a plot is limitetd by the size of the EEPROM.

For the ftp upload some code was adapted published by SurferTim in 2012. The data to upload are stored on the SD card temporarily . Also the configuration data of the system and its environment are stored on the SD card. So the program can run on different controllers without modification just by editing the config files on the SD cards.

Details of the implementation


The system has to overcome a power cut when all data in SRAM are deleted. So there won't be an index telling you which EEPROM cell has to be written to next. Saving this index in the EEPROM would mean it had to be rewritten after each measurement. But this should not be done.

The problem was solved in the following way: For storage we defined ths data structure
Variant with 2 sensors:
NTP-time stamp (seconds since 1900)
Sensor 1
Sensor 2
Byte 3 (MSB) Byte 2 Byte 1 Byte 0 (LSB) HIGH LOW HIGH LOW

As the size of the EEPROM is 4096 bytes (ATmega1280 respectively 2560) we can store 4096 / 8 = 512 samples.

So samples of about a week can be stored in the EEPROM before they get overwritten. The life expectancy of the EEPROM will be some 2,000 years.

The memory in the EEPROM has to be organized as a circular buffer. Otherwise, we had to copy all the data clockwise. This not only takes a lot of time but also reduces the life time of the EEPROM memory significantly.

So, before the new sample can be stored, the highest time stamp has to be found. The next location (modulo total number of locations) is the one where to store the new data. To produce the plot we also need to know where is the beginning of the series.


To ease the task of the Arduino we select Scalable Vector Graphics (SVG) graphics format. Performing the display in the browser will be the job of the SVG plugin. We only implement the minimum requirements of the standard. But doing this we exceed the limit given by the Arduino UNO. So, at least you need an ATmega1280 (which you hardly will get any more) or an ATmega2560.

Time stamp

The protocol NTP gives the time as a 32 bit integer value (actually, it is a 64 bit floating point value but the fractional part is the fractions of the current second). This time stamp will be stored with the samples.

The problem:

Final remark

When running the device for a while it turned out that in rare cases the program came to a stop at different locations: As you have no means to overcome such situations you just have to restart the controller hoping for the better.

When we tried with the Arduino hardware watchdog library (#include <avr/wdt.h>) we found that its limitation to a maximum of 8 seconds is not enough. So we had to implement one of our own using Timer2 of the controller.

We even managed to find a way how to determine the cause of a new start. Normally, variables are reset to zero on power-on unless you declare them with
        long errorState __attribute__ ((section (".noinit")));
So by setting this variable to a certain value before entering the watchdog zone you can find the cause of the unexpected program halt on restart.

If the cause was an unsuccessful access to the ftp server it is recommended not to try again immediately as ftp servers accept only a limited number of users at the same time. So you better wait for some time.

Even after all that fixes, one of our devices stopped running after a while. So we replaced the Ethernet shield - without success; at the end we decided to replace the ATmega2560-board. That must have been the cause although it was an original Arduino board.

What could be done better:
In order to adopt the ftp code published by SurferTim, all the svg-commands had to be written to an SD card before uploading. To avoid that detour you could write directly to the ftp server, but it would need major changes to the ftp code.

And this is how it could look like ...

Sources: all sources in one zip file

The file config.txt has to be stored on the micro SD card. You better use a USB to micro SD card adapter to do this.
Make sure the entries in this file match you local network properties and the ftp server you are using. You should not give your modified version of config.txt to anybody else as it contains sensitive data.

contact: nji(at)