Graham White: My Notes

In my previous post where I was showing off my IoT Christmas Trees, I described the project and what the trees are intended to do. This post features the inside track information about how I put the project together. So the first post is supposed to be non-technical if you will and this post details the info more of interest to those interested in the technical make-up of the project. Since this is effectively a recipe for how to create one of my IoT Christmas Trees, we'll start with the list of things needed.

Ingredients

For the Tree

Bits you need to make one tree:

Wood
Paint
Arduino ESP32
Micro USB Cable
Veroboard
LED String
Buttons

Server and Connection Requirements

These are Internet connected of course so needed here are:

An MQTT Broker
An HTTP Server
WiFi with Internet Connection
Another WiFi capable device

Other Useful Bits

Probably staple provisions of any maker's tool box:

Glue Gun
Soldering Iron and Solder
Heat Shrink Tubing
Wire (22AWG Solid Core)

Putting it all together

The wooden bits

You need enough wood in whatever design you prefer. I made a point of making each of my trees in a different style. It caused more work that way of course but there's something nice about each tree being unique. My designs are all between about 25cm and 40cm tall without much thought put into why. However, this sort of size seems to work well with the light string I chose. Given the light string is 5 metres long and I used half a string for each tree I needed to hang 2.5m of string around each tree (containing 25 lights per tree). Therefore, you need to size the wooden structure appropriately for the length of string or number of lights you intend to hang.

Painting

I decided to use spray paint to try and achieve a really smooth and high quality finish. I selected Montana paints as they provided all the types of paint I wanted to use (primer, metallic top coat, glitter and varnish). I went with 4 of their colours, Aztec Gold, Avocado Green, Titanium, Red; and glitter effects in Silver and Dusty Gold. Everything came from Graff City.

A couple of coats of primer were needed followed by a couple of coats of metallic. The glitter paint goes on as a varnish layer with particles of coloured glitter in it and they recommend a top coat of varnish is used to seal the glitter coat and prevent and loose glitter falling off. The result is a really nice layered effect where the fairly reflective metallic coating is set off against a subtle glitter effect and everything is finished off with the sheen of varnish.

Electronics

The main driver of the project, electronically, is an ESP32 board. The board I chose is a knock off of the Lolin D32 simply because it has everything I needed (including having the pins not soldered) and much cheaper than locally available boards in the UK. While the board was cheaper, I did discover some of the drawbacks in as much as it doesn't have built-in pull up resistors on its GPIO pins and as such I had a lot more soldering to do to work in a 10kΩ resistor into a little veroboard circuit to wire in the buttons I chose.

The string of LED lights looks very cool with some quite presentable wiring between the lights when compared to an LED strip. They're completely WS2812/NeoPixel compatible so they're easy to programme and there's some nifty libraries out there already available. They are, however, fairly hellish to solder since the wires are coated with some very thin plastic insulation which is either difficult to remove or otherwise burn through with your solder.

Finally, the whole thing is powered via Micro USB so I ordered a pile 3m long USB-A to Micro-USB cables so the trees can be sited a reasonable distance from a power socket and I didn't have to worry about batteries or charging although battery powering these units would definitely be possible.

Firmware

The firmware is a fairly standard Arduino implementation for the main loop and using WifiManager to configure the ESP32 WiFi to connect to an SSID. It wont come as any surprise to find the messaging component I'm using is based on MQTT and so I'm using Nick's pubsubclient library on the client side.

One of the more interesting things I've done with the firmware is to attempt to make it as remotely configurable as possible without the need to rely on over-the-air updates for the firmware. To this end, I'm using the inih library and the firmware downloads its configuration as an ini formatted file from a remote location that allows me to configure as much as possible, currently: mqtt hostname:port, username, password, SSL settings, publish and subscribe topics, device name; and then configurations for the lights for things like which colours to cycle around, how long the "Merry Christmas" setting is maintained before reverting to the previous setting. The ini file format also allows an easy "global" configuration to apply across each tree while also allowing a per-tree customisation. Should the WiFi connection not be available or the configuration file not be available then the tree reverts to a sensible set of defaults.

Once running, WiFi connected, MQTT connected and the configuration has been downloaded and applied there's some basic login there to cycle between the different light configurations when the left button on the tree is pressed. This is all done locally on each tree. The right button, when pressed, sends a (configurable) message to the other trees that tells them what to do. So it would be possible for each tree to have its own specific "Merry Christmas" pattern so you could, for example, work out who had sent you the message by the pattern/colour of the light flashes on the receiving tree.

I have also built in a simple command protocol to further take advantage of the MQTT connectivity. This allows me to send a "ping" to each tree to see which are currently alive, connected and working properly. The second command I have is a "reload" command that will cause the tree to download and re-apply the configuration from its remote location, noting of course that the configuration could have changed and so I can cause a tree to remotely update its configuration. Finally, there is a "reconnect" command that will cause the tree to disconnect and connect to its configured MQTT broker. This is useful in the rare circumstance where the IP address of the broker may have changed in which case I can update the configuration, have the tree read a new configuration, then have the tree disconnect from the current broker and connect to a new broker.

MQTT Broker

The MQTT broker is provided courtesy of my still relatively new Pi4 home server and the rather excellent Mosquitto MQTT broker. Since I'm running this all myself and not using a cloud based MQTT service I've screwed it all down as far as I can from a security perspective but there's nothing like running your own services to make you feel vulnerable!

My latest maker project has been running for a good chunk of the year and has been a really cool thing to do to keep me occupied during lockdown since I'm not really one to binge watch box sets. I've been making Internet connected Christmas trees as gifts for close family. They're designed to be ambient ornamental decorative pieces with a funky twist of interactivity. The video I produced probably explains them best...

As you can see from the video, each tree is deliberately different. I thought it would be more interesting to have a completely different wooden design for each. My dad did the woodwork which saved me quite a lot of time and allowed me to concentrate on writing the software and doing the electronics not to mention building and painting each tree. There's a good few hours work in each of these things.

Operation of the trees is pretty simple with the most complicated bit, like with most of these things, being the initial set up to get them onto your WiFi network. For that, and to explain the basics of how they work along with a bit of troubleshooting information, I wrote a little user manual to go with them. After all, it will be our closest family members that receive one of these and so I can always help out remotely (and potentially fix any issues that arise). The left button on each tree cycles round a set of pre-defined colour schemes. However, these can be changed on a per tree basis should someone want a different colour or configuration. Similarly, the trees can be operated remotely but I've yet to write a decent interface to do so. The right button on each tree is where the fun is, causing all the other trees to change light pattern for some period of time. Again, this is all configurable per tree but by default they all cause the same green and red frenzied light pattern which should be very noticeable in the corner of your room should it occur.

Finally, big thanks to James Sutton and his original iotree project was in no small amount an inspiration for my work here. Although, the implementations are different both physically and in software there's still a huge amount of overlap. James was also responsible for running an IoT hackathon at work (we're colleagues) introducing a lot of the technology I would need in order to perform this build. Thanks again, James!

I've also written more details on the technical implementation. But, I'll sign this post off with a closer look at each tree in pictures...