I'm making an IoT pizza warning robot - Part 1

Our engineering team at Convious has an unofficial tradition - if you somehow manage to break production, Friday pizzas are on you. It's usually foretold by a busy #monitoring Slack channel and people asking whether it smells like 🍕.

One day I had an idea:

artis [11:44]
I have an idea for some swag
we use NLP to parse Slack conversations and look for phrases that ask if something has been fixed. whenever something like that pops up, a piece of rubber pizza is flopped around by a motor
it’s a warning

That's how PizzaBot was born. And I'm going to make it. My colleague Saulius offered to buy me pizza for a week if I make PizzaBot, ship it to our Vilnius engineering HQ, and it works upon arrival.

Disclaimer: I'm not an electrical engineer, but a hobbyist. My knowledge about programming hardware comes from online tutorials and a lot of tinkering around.

TL;DR: There are pictures at the end of this post.

But why?

I've been tinkering with electronics ever since I remember myself as a kid. There's something fascinating about making a piece of silicon, embedded in resin, work to your bidding. My dad taught me a lot about electronics, starting off with a simple circuit that consisted of a transistor, a capacitor, two resistors, an LED and a battery. It made the LED blink, yay!

I like it when code transforms into something that reacts in real life, whether it's an LED blinking, or it's PizzaBot, menacingly informing you about tasty pizza on Friday.

The decision

Having done hardware side projects before, I know that hindsight is 20/20. Before committing to anything, I decided to quickly weight out all my available options to assess how and if I can do it.

I decided to rank all available options based on the following factors: cost, sustainability and amount of e-waste produced.

Option 1: ESP8266 talking to Slack RTM API

I'll admit it - I didn't know the exact specs of an ESP8266 until I started writing this article, but I was reasonably sure that it would be capable of doing it. A quick search on the internet told me that an ESP8266 runs at 80 MHz and has a full TCP/IP stack. Apollo 11's guidance computer ran at a whooping 2.048 MHz, I was pretty confident that 80 MHz should be enough to receive a stream of simple messages.

Pros:

• simplicity - a single device responsible for all communication, parsing data and triggering the pizza flopping mechanism;
• less parts to fail - an ESP8266 paired with a motor shield means there are less parts that can fail;
• probably possible to use a single power supply for both the motor(s) and the controller itself;
• small e-waste footprint, as I had a bunch of ESP8266 laying around doing nothing; if all were to fail, the controller could be re-flashed. Everything could be reused even if PizzaBot stopped working for whatever reason;
• it's a challenge! I believe you don't need more sophisticated hardware to pull this off;
• reasonably priced - I got 5x WEMOS ESP8266 based chips off AliExpress for around $1.50 a piece;

Cons:

• ESP8266 might not be able to handle Slack RTM API;
• WiFi SSID and password have to be baked into the firmware;
• API access tokens need to be baked into the firmware;
• Slack RTM API might change and then the device would be bricked;
• A custom power supply would be needed to provide power to both the motor(s) and controller;
• No NLP or even advanced message parsing, as the device would try to match strings like "bug" and "fix" as triggers.

Option 2: ESP8266 using the cloud

This approach felt very lucrative. ESP8266 talking to a free online MQTT broker and an Amazon Lambda based API endpoint that uses Slack event API, instead of RTP. I like the appeal of ESP8266 doing one thing and one thing only, which is listening to a magic MQTT message and engaging motors if it's received. All the heavy lifting of determining whether a message is worthy of mentioning pizza would be left to the cloud. Besides, leveraging the cloud would make it so much easier... or would it? Therefore I decided to lay out all the cons and pros once more:

Pros:

• more flexibility and easier development;
• gives access to NLP API's to make the device smarter;
• makes fixing bugs a lot easier;
• makes testing a lot easier;
• I can use a high level programming language for most parts;
• API or authentication token changes don't affect the end device anymore;

Cons:

• WiFI SSID and password still baked in;
• MQTT broker settings have to be baked in;
• vendor lock-in with an MQTT broker;
• MQTT broker might go offline or become paid, I'm only investigating options without recurring subscription costs;
• Amazon Lambda vendor lock-in;
• way more wasteful. Even at no cost an MQTT broker means it's running on a server somewhere, adding to climate change, CO2 footprint and e-waste being produced. Same goes for any other third party solution that gets involved in building this project;
• ESP8266 remains at the same cost, but additional costs may incur later if third parties abandon their free tiers;

Option 3: Use a RaspberryPi

Most tempting option for a lazy programmer like me. I can't deny that the thought of using a Pi didn't pop up right after. Then I received a Slack message:

saulius [14:49]
Hey re. the robot, I can send you a raspberrypi if you need, have one lying around doing nothing

Speak of the devil... Using a Raspberry Pi would have many advantages over previous solutions and here's why:

• RaspberryPi is very powerful and can process Slack RTM API with ease;
• I can use a high-level programming language like Python or JavaScript for everything. And I ❤️ Python!
• WiFi SSID, password and any other tokens can be stored in a text file on /boot directory thus allowing easy maintenance of the device;
• Full power of Linux with superb third-party library support;
• I could ssh into the device and change/fix things when needed;
• Eventually I could make the device do more or better;

Cons of using a Raspberry Pi:

• overkill! You don't need 1GHz, single-core CPU and 512MB RAM (Pi Zero W specs) to invoke a motor from a simple, string based trigger;
• (way) more expensive; Having pizza delivered to your house for a whole week sounds tempting, but cost control is a good process to have in place; Pi Zero's are hard to source in Latvia at the time of writing. A bare-bones Pi Zero W costs €11,79 + €3,35 shipping. I would also need an SD card, a power supply and a mini-HDMI to HDMI adapter in addition to motor(s), motor driver and any miscellaneous components I'd have to buy;
• Too easy? Is it okay to say that?

The conclusion

After carefully weighing out all the possible options, I decided to try out a vanilla ESP8266 approach as I had those handy already. I could always buy the best gear, but that takes away the excitement of hacking. So I grabbed my trusty soldering iron and putting it to work:

Now when I'm done with soldering, I can move on to the next part of this build, which is connecting to Slack RTP API from an ESP8266.

My tech stack used for this project so far:

• WEMOS ESP8266-based board called the D1 mini;
• WEMOS OLED shield;
• Platform.io for VSCode as an IDE;
• MacBook Pro running OS X;

I will try to make use of Slack RTP API in my next post, stay tuned until then!