DEV Community: Nick Neisen

Creating an ESP8266 Based Wireless Thermometer

Nick Neisen — Mon, 16 Dec 2019 18:58:51 +0000

I've been taking a look at InluxData's TICK stack and figuring out some ESP8266 chips that I recently purchased. I always like to come up with practical projects to do when I'm learning about some new tech. When my dad came to me asking me to keep an eye on the temperature of his house while he was out of town, I knew exactly what I needed to build. It got even better when he told me his plan.

"I've got an old thermometer that I'll duct tape to the window. That way you can come by a couple times a day and you only have to walk up to the window to see the temperature."

I had better idea in mind.

The Thermometer

Hardware

The obvious part of this project is the thermometer itself. I had the smaller circuit components lying around from a previous project that I reused. If I planned on using this for longer, I would upgrade these components to something like a TMP36 or an environment sensor to get multiple measurements. The actual components I used are listed below.

ESP-01 wireless transceiver
ADS1050 12-bit ADC
10K Ohm resistor
Thermistor

I also highly recommend a programming adapter and breadboard adapter for the ESP-01. They make working with the ESP-01 much more enjoyable. I went a while where I was having to rewire the board every time I switched between programming and running the board. It gets old pretty fast.

Wiring

The schematic shows how each component should be wired. I'll comment on a few of my decisions below.

Thermistor

To read from the thermistor, it will need to be in a voltage divider circuit. My thermistor read ~10k ohms at room temperature so I paired it with a 10k ohm resistor to give me a good range of values.

ADS1015

The ADDR pin makes it convenient to change the device address by wiring it to VCC, GND, TX, or RX. I chose to ground mine since this gives it the default address of 0x48. If I had more than one I2C device then I would want to consider a different address. I didn't use the ALRT pin or three of the ADC inputs and so I left these pins disconnected.

ESP-01

The ESP-01 gave me the most trouble wiring up. It seems that everyone is doing it a little different depending on where you look online. There also seems to be a few different versions of the ESP-01 board.

IO2 always needs to be pulled high to boot correctly. IO0 needs to be pulled high on boot to run the program from flash. If it is pulled low on boot then the board will be put into programming mode. Once the board is running, these pins can be used otherwise, such as the I2C pins used above.

Software

The ESP8266 has become so popular for programming that it is now supported by the Arduino IDE. An additional package will need to be installed but afterwards it is just like working with any Arduino board.

The following code is based on the Arduino example to send a POST from the ESP-01. I modified the code to use the ADS1015 library to read an ADC value and convert it to a temperature. I reused the lookup table from the previous project the thermistor is from. It is not as precise as I would've hoped but since I am reusing old parts I was glad to get it within a reasonable range.

#include <ESP8266HTTPClient.h>
#include <ESP8266WiFi.h>
#include <Wire.h>
#include <Adafruit_ADS1015.h>

Adafruit_ADS1015 ads1015;

#define SDA_PIN 0
#define SCL_PIN 2

#define SSID "ssid"
#define PASSWORD "password"

#define MESSAGE "conditions,location=dads temperature="
#define DESTINATION "http://192.168.1.30:8080/temp"

void setup() {
  Serial.begin(9600);

  WiFi.begin(SSID, PASSWORD);
  while (WiFi.status() != WL_CONNECTED) {
    // Wait for the WiFI connection completion
    delay(500);
    Serial.println("Waiting for connection");
  }
  Serial.println("Connected");

  // GPIO pins must be outputs to use with I2C
  pinMode(SDA_PIN, OUTPUT);
  pinMode(SCL_PIN, OUTPUT);
  ads1015.begin();
  Wire.begin(SDA_PIN, SCL_PIN);
}

void loop() {
  float temp = getTemp();
  String message = MESSAGE + String(temp);

    if (WiFi.status() == WL_CONNECTED) {
      HTTPClient http;

      http.begin(DESTINATION);  //Specify request destination
      http.addHeader("Content-Type", "text/plain"); //Specify content-type header

      int httpCode = http.POST(message); //Send the request
      String payload = http.getString(); //Get the response payload

      Serial.println(httpCode); //Print HTTP return code
      Serial.println(payload);  //Print request response payload

      http.end();
    }
    else {
      Serial.println("Error in WiFi connection");
    }

  delay(1000);
}

float getTemp() {
    // Create a table to quickly look up temp values
    static float tempTable[20][2] = {{11.6,     70},
                                    {11.4,  71},
                                    {11.1,  72},
                                    {10.8,  73},
                                    {10.6,  74},
                                    {10.3,  75},
                                    {10.1,  76},
                                    {9.8, 77},
                                    {9.6, 78},
                                    {9.4, 79},
                                    {9.2, 80},
                                    {8.9, 81},
                                    {8.7, 82},
                                    {8.5, 83},
                                    {8.3, 84},
                                    {8.1, 85},
                                    {7.9, 86},
                                    {7.7, 87},
                                    {7.6, 88},
                                    {7.4, 89}};

    int16_t adc = ads1015.readADC_SingleEnded(0);

    // Find the voltage
    float voltage =  ((1024-adc)*3.3)/1024;

    // Find the resistance of the thermistor
    float Rt = ((voltage * 10000)/3.3)/(1 - (voltage/3.3));

    // Adjust our precision to match the lookup tables
    Rt = (float)((int) Rt/100)/10;

    // Find the associated temp in the table
    int i = 19;
    float currTemp = tempTable[19][1];
    for(; i>=0; --i) {
        // Grab the value as long as Rt is lower then the table's R
        if(tempTable[i][0] <= Rt)
            currTemp = tempTable[i][1];
    }
    return currTemp;
}

Pushing to the Cloud

The next step is a location to store the temperature readings. This is where the TICK comes in t play. I wanted somewhere that I could access from anywhere so I opted for InfluxDB Cloud. I'm planning on setting up an instance of InfluxDB locally but for this project the cloud was more convenient and the free tier was more than enough.

After creating an account with InfluxData, there is a little bit of setup to be able to store data from the device.

Creating a Bucket

The first area to visit is the buckets list. Navigate to Load Data -> Buckets on the left panel. Select the blue + Create Bucket button in the top right and fill in the necessary options. This bucket will hold all of the thermometer data.

Creating a Token

The next page to visit the tokens list. Navigate to Load Data -> Tokens on the left panel. Select the blue + Generate button and Read/Write Token from the dropdown menu. Enter a name for the token and choose your newly created bucket from the listed buckets. After saving the Token, click its name from the descriptions list and copy the token to be used later.

Viewing Data

There are two more areas worth noting at this time. The first of these is the Data Explorer tab. This tab provides a convenient way to view the data being logged by devices. Nothing will exist at the moment since we don't have a middle device logging from the thermometer but it's worth knowing where to look later.

If a view of the data is created that you would like to save, clicking the Save As button in the top right will create a copy of the view on the Dashboards page. The Dashboards page allows you to create a number of convenient graphs that are easy to view without having to search each time you log in.

Gathering the Measurements

The final component to setup is a fog device to receive metrics from the thermometer. I went with a Raspberry Pi W that I had lying around. Having a dedicated metrics device makes it easy to move the whole setup around. I could also set up multiple thermometers and have them all report to one device that pushes to the cloud.

I started with a fresh copy of Raspbian lite with SSH enabled and WiFi configured. The remaining steps involve installing telegraf and configuring it for the use with the thermometer.

Installing Telegraf

The telegraf project has very good documentation for installing telegraf and having is run at boot. These are the commands I ran specifically for the Pi.

Add telegraf to the package manager:

sudo apt-get update && sudo apt-get install apt-transport-https

wget -qO- https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/os-release
test $VERSION_ID = "10" && echo "deb https://repos.influxdata.com/debian buster sta

Install and start telegraf. This will install telegraf as a service that restarts on boot.

sudo apt-get update && sudo apt-get install telegraf
sudo service telegraf start

Configuring Telegraf

The final step is creating a configuration file for telegraf. The default location for the telegraf config file is /etc/telegraf/telegraf.conf. Telegraf can be used to generate a new configuration file with the plugins that we will need for this project.

telegraf --input-filter http_listener_v2 --output-filter influxdb_v2 config > telegraf.conf

This will create the initial template for the config file. There are a few sections that will need to be modified for our setup.

[[inputs.http_listener_v2]]
  service_address = ":8080"
  path = "/temp"
  methods = ["POST", "PUT"]
  data_format = "influx"

This lets telegraf know that it should watch the /temp path on port 8080 for POST or PUT requests. It can expect the data it receives at this location to be using the influx line protocol format.

[[outputs.influxdb_v2]]
  urls = ["https://us-west-2-1.aws.cloud2.influxdata.com"]
  token = "<your token>"
  organization = "<your organization>"
  bucket = "<your bucket>"

The information for the output section will depend on how influx cloud was set up. The organization name is the name used when creating your account on InfluxDB Cloud. This can be found on the landing page of the cloud UI. The token and bucket values that were previously chosen when creating a bucket on InfluxDB Cloud. These can also be found by going to Load Data -> Telegraf and clicking the purple InfluxDB Output Plugin. This will assume the token is set using an $INFLUX_TOKEN environment variable.

That should be the last of the needed configuration for the Raspberry Pi. A reboot will start telegraf running on the Pi with the new configuration settings.

Monitoring the Results

We can now return to the Data Explorer in InfluxDB Cloud and we will now be able to select data from thermometer. We will need to select one type of filter for the data to be displayed. I used the temperature field but it's worth trying different options until the graph represents what you like. Finally, clicking the submit button will update the graph to show the logged metrics.

Conclusion

I now have a much more convenient way of keeping an eye on my dad's house while he is away. Time to compare it with his idea and see which thermometer is more accurate. Something tells me that his window thermometer might be a little on the cold side.

How to write a URL Shortener in Go

Nick Neisen — Sat, 03 Aug 2019 17:43:00 +0000

Exercise 2 of Gophercises was to create a URL shortener. The framework for this code was given and the student needed to fill in the missing pieces. The solution of the main problem is given but no solutions are given for the bonus challenges. This is my solution to the main problem along with the bonus challenges in which a solution was not given.

The main goal of this exercise was to get familiar working with different markup languages in Go. It also introduced working with command line arguments and reading data from a database.

The URL shortener

The first step of the problem was to create a map handler. The map handler needs to check a map for a key with the specified URL and redirect the user to the value stored in that key. If no key is found then the fallback handler should be used instead.

return http.HandlerFunc(func(rw http.ResponseWriter, r *http.Request) {
    if pathsToUrls[r.URL.Path] != "" {
        http.Redirect(rw, r, pathsToUrls[r.URL.Path], http.StatusFound)
    }

    fallback.ServeHTTP(rw, r)
})

The next step was creating a handler for YAML input. This function will parse YAML input and build a map from the results. The map is then passed to the map handler built in the previous step.

var redirects []struct {
    Path string `yaml:"path"`
    URL  string `yaml:"url"`
}

err := yaml.Unmarshal([]byte(yml), &redirects)
if err != nil {
    return nil, err
}

paths := make(map[string]string)
for _, path := range redirects {
    paths[path.Path] = path.URL
}

return MapHandler(paths, fallback), nil

Bonus #1: Read the YAML from a file

The given code creates an example YAML string inside the program. This bonus challenge was to instead read the YAML from a file. The file path would be passed in through the command line and have a default value.

The first step was to read the file path from the command line. This is done using the Golang flag package. The flag package makes it very easy to setup command line arguments.

yamlPath := flag.String("YAML", "paths.yaml", "A YAML file")
flag.Parse()

Here the library is setup so it knows it will be receiving a String argument via the command line. That argument will be referred to as “YAML” with a default value of “paths.yaml” and a description of “A YAML file”. The value of this argument will be stored in yamlPath variable. The flag.Parse() function is then called which will process the command line arguments and store them in the associated variables.

One of the great things about using the flag library is that with this one line the program will now have an automatically generated help menu. Passing the --help flag into your program will print a menu for someone trying to figure out the available flags.

Usage of /tmp/go-build244514782/b001/exe/main:
  -YAML string
        A YAML file containing redirects (default "paths.yaml")

The file path now needs to be passed to the YAML handler and have it open and read from the file. There are a few different options available when it comes to reading input from a file.

reader, err := os.Open(*yamlPath)
if err != nil {
    panic(err)
}

err = yaml.NewDecoder(reader).Decode(&redirects)
if err != nil {
    return nil, err
}

Creating an io.reader allows this reader to be passed to the YAML library. This allows the YAML library to manage the buffering of reading from the file. This is then passed to a new YAML decoder which decodes the file into our redirects variable.

Other options include reading the entire file into memory or reading in the file one line at a time. Reading the entire file into memory would increase the memory usage of the program, especially if there are a large number of paths. Reading in the file one line at a time prevents this issue. Luckily, this is similar to how a decoder is buffering the file without having to manually manage the file’s location pointer.

That’s it for handling the YAML input being stored in a file.

Bonus #2: Build a JSON Handler

The next bonus question was very similar to the main challenge but slightly different. This time data will be passed in using JSON instead of the original YAML.

reader, err := os.Open(*jsonPath)
if err != nil {
    panic(err)
}

err = json.NewDecoder(reader).Decode(&redirects)
if err != nil {
    return nil, err
}

Not much changes here other than using the JSON library instead of the YAML library. These libraries are setup to use the same interface so switching between the two is very convenient.

Bonus 3: Build a database Handler

The final bonus challenge was to store paths in a database and access them from the program. BoltDB is recommended in the exercise but I chose to use MongoDB instead. MongoDB is a name I had heard of in production systems and I already had it set up on my system. Installing and setting up MongoDb instructions can be found on the official site.

var db *mongo.Client

collection := db.Database("test").Collection("Paths")
cur, err := collection.Find(context.TODO(), bson.M{})
if err != nil {
    log.Panic(err)
}

db is used as a global variable which has package scope. This assumes db has been initialized in another function. The code first gets access to the “Paths” collection on the “test” database. A search is then ran on that collection using an empty interface. The empty interface causes all rows to be retrieved from the collection. If there were values in the interface, then the results would be filtered by those values. Context.TODO() is an empty context that is used when a context is not available.

Converting the other Handler’s data into a map was pretty straightforward. This process is a little more involved when working with a database.

paths := make(map[string]string)

for cur.Next(context.TODO()) {
    var redirect Redirect
    err := cur.Decode(&redirect)
    if err != nil {
        log.Panic(err)
    }

    paths[redirect.Path] = redirect.URL
}

Collection.Find() in the previous code returned a cursor to the row in the collection. This cursor can now be used to iterator over the rows in the collection and add their value to a map. A struct is created on each iteration to be added to the map. The path is then used as a key in the map with the URL as the value. The map can then be passed into the MapHandler that was first created.

Wrapping up

This Gophercise was a great way to get used to working with different data storage formats. The bonus challenges help to slowly introduce additional libraries that are nice to know about and have some experience working with.