The architecture for this project is ... roundabout. I already had a Raspberry Pi running an MQTT broker when I started out to put together the sensor and ESP8266 Feather. It made sense to me to just use my existing MQTT infrastructure to capture the data. And here is where I made my mistake: I used the topic "/sensors" and inserted the data "<sensorname> <value>" into the queue. This is great if you just want to run
and watch the data stream by. It does, however, cause trouble later, as we'll see.
The sensor is wired to a voltage divider, which then sends the signal to the ESP8266's analog pin (A0). That pin can accept only about one volt, but the Vcc to the sensor is 3.3v. Thus, we need the voltage divider to protect the A0 pin.
I wrote a quick Lua program that used the MQTT module to connect to my local MQTT broker and insert the sensor reading, with a one second delay. So at this point, I had data in my MQTT queue that looked like light_001 416
This morning, I wanted to take those data and feed them into Adafruit.IO and graph the data output. There are a number of ways I could get a graph of the data, including reading it out of MQTT with R and generating a publication-quality plot. I didn't need that, though, and it's much more interesting to use Adafruit.IO - it's kind of like UNIX; the right tool for the job is already in the toolbox.
For reasons I'll get into in a bit, I wrote a Python program that runs on a Raspberry Pi, reads the data out of my local MQTT queue, and connects to Adafruit.IO and publishes the data into the Adafruit.IO feed. This Python program cold run on the MQTT broker but I have it running on a separate RPi. It's neither here nor there. It really can be done either way.
And that's it! The information flow is: sensor->Feather ESP8266->MQTT (local)->Python->Adafruit.IO