Getting hot around the collar about TMP36GZ

The idea of a better-instrumented home I find very interesting - more data could mean better choices for heating and so on, right? So what more interesting than some ESP8266 thermometers that log temperature over a period of time!

Easy - buy some TMP36GZ 3.3V temperature sensing chips, connect them to the A0 pin on ESP8266s, read the voltage, turn it into a regularly published MQTT message - job's a good 'un!

And here we are - red circle around TMP36, connected to GND and Vcc, with centre pin connected to A0 on the NodeMCU dev board. I've stolen some code to read the A0 pin, connect to my wireless network, and send MQTT packets with the temperature in Celsius to the world. Super.

NodeRED setup and debug output

I've set up some NodeRED nodes to process the incoming data:

• Temperature Collection Node is an MQTT input, subscribed to topic "temperature/office"
• Add Timestamp is a simple JS function to add the current timestamp to the data, so I can log it; saves having an RTC in the ESP :-)
• /home/pi/officetemp.log is a File output node that writes the data to a file for future analysis
• msg.payload is a Debug node that just writes the msg.payload to the NodeRED console - you can see the output on the right, showing both MQTT node and Function node outputs

And it works! Hurray. 

Except... I noticed a comment in the code I originally stole, which was careful to turn the wireless off whilst taking measurements, to the effect that if the wireless part of the chip was operating during a measurement, it caused the reference voltage or whatever on the ADC on the A0 port to fluctuate, causing wildly fluctuating measurements. Hmm. And certainly, I was getting fluctuating readings, by as much as 2 degrees or more!! Even if taken in quick succession. Bummer. 

And then the stupid code started to crash with no real obvious cause, except I've found that dicking about unduly with WiFi etc. can do this. Dull. So switched code to an example that left the wireless on, which didn't fail. After running this all night the values were still fluctuating, although there was a discernible trend. I didn't keep these measurements and the graphs I drew to investigate this - I tried using rolling averages to see if it improved it, but the occasion low value spikes and so on meant that even that wasn't enough.

I then tried using a 50kΩ pot set to a value that approximated the temperature value. That was rock steady, whatever I did with the wireless. Hmm... That makes a nonsense of the stressy posts about wireless and so on that I'd read lots of. One guy did point out that the TMP36 is actually not going to be incredibly repeatable in its readings anyway as its specification for good devices is ±2%, which since the ADC is reading ~226 i.e. about ±4, represents more than ±1 degree Celsius i.e. a range of 2 degrees anyway!

Now what?? Grrr. Then I came across this blog - excellent! The author suggests that the ADC input presents a variable loading across the TMP36 output, so it will be more stable if you put a reasonable sized resistor across the Vout and GND e.g. 47kΩ. So I tried this... And it seems much more stable, even using the "wireless always on" code. Here's some graphs - I've tried rolling averages of 10 and 20 samples to see how they work too. This is with samples every 5 seconds.

Revised TMP36 deployment results and rolling average plots

I think I'll go with this, for the moment.