MicroPython Temperature Sensor

I’ve shown an example of the “Hello World” in IoT, a blinking light, in this post. Blinking lights are great and make for a nice visual experience, but what if we want to do something with an IoT device, such as a NodeMCU ESP8266 that goes beyond the visual? Let’s take our NodeMCU and add a temperature sensor. Then, with MicroPython, we’ll get our readings.

Needed Equipment

To get started on this project you’ll need the following equipment:

I have found this kit of basic electronic components to be pretty good for starting one’s IoT device journey. It doesn’t include things like the TMP36 temperature sensor, but it has a wide variety of other pieces that are ultimately useful.

TMP36 Specs

Since this project will be using the TMP36, let’s discuss it briefly.

TMP36 Temperature Sensor

This temperature sensor is a low voltage sensor, requiring 2.7 V to 5.5 VDC input. It returns a Celsius temperature reading from the Vout pin in an operating range of -40°C to +125°C. It is reasonably accurate, especially for hobby/demo situations with a ±2°C accuracy. You can download the specs for the TMP36 here.

Temperature Sensor Project

Hardware Configuration

Make sure the NodeMCU is disconnected from USB when making connections.

Temperature Sensor schematic

  1. To add the TMP36 sensor to the NodeMCU we need to make sure that it is properly oriented. The flat side of the temperature sensor should be facing the bottom of the board.
  2. Connect the rightmost lead, in position a8 to the negative rail on the board.
  3. The negative rail then is connected to the GND pin (pin a29)on the NodeMCU.
  4. Connect the leftmost lead (a10) of the TMP36 to the positive rail.
  5. Connect the 3v3 pin (a30) on the NodeMCU to the positive rail.
  6. Finally, connect a jumper wire from the center lead (c9) to the A0 pin on the NodecMCU (j16).

Temperature Sensor bread board

The A0 pin on the NodeMCU is the analog-to-digital conversion (ADC) pin.


With the hardware side of things built, let’s see what we can do in MicroPython to get a temperature! Fortunately, MicroPython’s machine library makes this pretty simple for us.

I’ll be working in the console REPL.  The code should work the same, however, if you are working in the WebREPL environment.

Our first step is to handle our imports

from machine import ADC

That brings in our necessary ADC connections, and we can assign a variable to pin 0 for that

adc = ADC(0)

We can print out the value from the TMP36 now with adc.read() which returns the Celsius temperature, well almost. The value it returns is ten times the temperature. Let’s write a function that will handle that conversion for us.

def temp(value):
    return value/10

While we’re at it, let’s write a function to convert to Fahrenheit as well.

def fahrenheit(celsius):
    return (celsius * (9/5)) + 32

With those in place, we can get, and display our readings.

reading = adc.read()

celsius_temp = temp(reading)

fahrenheit_temp = fahrenheit(celsius_temp)

print("TMP36 reading {}\nDegrees Celsius {}\nDegrees Fahrenheit {}".format(reading, celsius_temp, fahrenheit_temp))

After executing our print statement we should get back our readings. MicroPython certainly has made things easy for us with the ADC methods.

Temperature Sensor REPL

For your convenience I have included the code is available as a Gist on GitHub as well.

Wrap Up

In this post, I have shown how to get temperature readings from an analog temperature sensor, such as the TMP36. In just a few lines of MicroPython code, we are able to get quite a bit of functionality. This is one of the many great things about MicroPython, the direct access to hardware is generally pretty easy.

I think the next step in exploring MicroPython and the NodeMCU will be to take these temperature readings and see if we can connect them to a service such as Losant and generate some visualizations of our temperatures.

Follow me on Twitter @kenwalger to get the latest updates on my postings on MicroPython and IoT and let me know what you are building with MicroPython.


Overview of the MQTT Protocol

There are several different ways one can utilize to connect an Internet of Things (IoT) device to a network. I have previously discussed some of the setup for a NodeMCU development board to connect to a WiFi network. In an IoT environment full blown network protocols such as HTTP can be a bit heavy. A popular, lighter weight, solution I’d like to discuss the basics of is MQTT.


While MQTT used to stand for MQ Telemetry Transport, it is now classified as not being an acronym. So what is it? What does it do? Well, it is a messaging protocol using TCP of TCP/IP fame to provide publish/subscribe services. It was, and is, designed for small, constrained devices and makes design decisions based on those constraints. Concepts which are important in the IoT world, such as memory, bandwidth, latency, power consumption, and network reliability. Let’s focus in on one of the main MQTT concepts, the publish/subscribe pattern.

MQTT Publish/Subscribe Pattern

In a publish/subscribe pattern a client publishes information and another client can subscribe to the information it wants. In many cases there is a broker between the clients who facilitates and/or filters the information. This allows for a loose coupling between entities.

The decoupling can occur in a few different ways, space, time, and synchronization.

  • Space – the subscriber doesn’t need to know who the publisher is, for example by IP address, and vice-versa
  • Time – the two clients don’t have to be running at the same time
  • Synchronization – Publishing and receiving doesn’t halt operations

Through the filtering done on the broker not all subscribers have to get the same messages. The broker can filter on subject, content, or type of message. A client, therefore could subscribe to only messages about temperate data. Or only messages with content about centrifuge machines. Or, perhaps, we only want to receive information about specific types of errors.

Thinking about an IoT situation with, for example, a NodeMCU device with some environmental sensors connected to it such as a TMP36 temperature sensor and a moisture sensor we could be publishing that data. Some clients that are connected to our broker may be interested in that, others may not. They would subscribe to the information they wanted.

MQTT Publish-Subscribe Model


Once connected to the broker the publishing client simply sends its data to the broker. Once there, the broker relays the appropriate data onto the clients who have subscribed for that data. Again, those subscriptions can be filtered. All of this data transferring is done in a light weight fashion designed for small, resource limited devices.

Message Packet

The message packet shown in the above diagram is just an example. Along with the message, or payload, a real packet would include additional information such as a packet ID, topic name, quality of service (QoS) level. Also included in the packet would be flags so the broker knows how long to retain the message and if the message is a duplicate.

Wrap Up

This is just the tip of the iceberg for MQTT, there are several other features of interest as well. Features such as Retained Messages, Quality of Service, Last Will and Testament, Persistent Sessions, and SYS Topics. It should also come as no surprise given the importance of security in today’s world, that MQTT has security features as well.

Follow me on Twitter @kenwalger to get the latest updates on my postings on IoT topics. If you enjoyed this article, or have questions, leave comments below.