OpenThread and Particle make it so easy and fun to create an inexpensive coordinated Christmas light show! The traditional Christmas light displays all involve wiring to a central controller. With my design each mesh device is modular, and you only need to provide power. The timing of the light show is coordinated over the mesh network. The installation and take down is so much easier since all you need to do is provide power.
The other main benefit of the mesh network for me is that it extends the network beyond the range of my Wi-Fi network. I built devices in previous years that were all on Wi-Fi. My yard has dead zones and areas where Wi-Fi is out of range. The OpenThread mesh network is very smart and with no single point of failure and spread-spectrum techniques provide resistance to interference.
Particle provides an IoT platform that makes the creation of mesh and other products so much easier. The development is so much more productive when you do not need to develop the plumbing and architecture from scratch. I have been developing IoT solutions for a long time and have built my own platforms from scratch, but now I am more productive than ever focusing on the business logic of the product instead of spending time building the platform. Particle's 3rd generation devices incorporate the OpenThread mesh.
OpenThread was released by Google as an open-source implementation of Thread that Google created for Nest. Google released the networking technology to accelerate the development of products for the connected home to use Thead. (OpenThread website: https://openthread.io/)
My company is leveraging this technology for much more than connected home projects. This technology is also great for manufacturing and other enterprise projects because the installation of the solution is so much simpler than traditional ways of doing it by connecting wires between devices or controllers.
OpenThread is an IPv6-based, low-power, and primary features include: (Taken from OpenThread website: https://openthread.io/guides/thread-primer)
- Simplicity - Simple installation, start up, and operation
- Security - All devices in a Thread network are authenticated and all communications are encrypted
- Reliability - Self-healing mesh networking, with no single point of failure, and spread-spectrum techniques to provide immunity to interference
- Efficiency - Low-power Thread devices can sleep and operate on battery power for years
- Scalability - Thread networks can scale up to hundreds of devices
OpenThread extends the goodness of IPv6 and network/web protocols that developers already know to the mesh network.
I created a mesh network that is easily expandable to add new nodes of light features each year. The network has 2 types of devices:
- Gateway Node - Particle Argon (Wi-Fi + OpenThread)
- Light Feature Nodes - Particle Xenons (OpenThread only)
The gateway node is mainly used to bridge the Internet with the OpenThread mesh network. Particle makes the Argon and the Boron gateway devices. The Argon is built for Wi-Fi, but the Boron is built for cellular. The code that I wrote for the gateway was designed to be simple and to not block the gateway from performing other tasks. I plan on expanding the gateway to be used for my home automation and would not want the logic for the Christmas lights to produce a noticeable delay or prohibit another feature in my home automation.
The gateway code does the following functions:
- Subscribes to mesh messages from the Christmas tree - The Christmas tree publishes a mesh message to announce that it is done with its light pattern. The gateway listens for this message and after receiving it will wait a second and then will publish a message for all light feature devices to start a new pattern.
- Has a handler for a Particle function to update the mode. The Particle function is triggered from the cloud and the local gateway handler then relays the mode message across the mesh. Initially, I only had Particle function handlers on light feature nodes, but the cloud functions would often time out while the device was in a tight loop performing a light display. Having the handler on the gateway provides a quick response to the cloud acknowledging the function was invoked and the mesh ensures the delivery of the message to all the light feature nodes. The mesh has 15 modes of operation. Most of the modes are used to debug issues such as lighting up a single channel for placement of the feature or for finding bulbs that need replaced.
- Sets the Wi-Fi credentials for all the access points that I normally connect to. This includes my house, my phone, and the office. This makes it easy to move the mesh to the office or to demo at a conference with my phone as an access point.
- Heartbeat LED. I almost always add a heartbeat LED for my microcontroller projects. This adds a quick visual indicator that the device is alive and not hung. The Particle prototype devices all have an LED connected to the D7 pin included on the PCB, so I typically use this for the heartbeat LED.
All the light feature nodes are running an identical copy of the code. It would be a code maintenance nightmare to deploy different code or have different versions of the code for each device. Every time I add a new feature or fix a bug then I deploy the update to all the light feature nodes on the network. Particle has built a platform that enables over-the-air, OTA, updates from the Particle cloud through a gateway device to a mesh node. The mesh nodes are intended to be mounted high up in trees, so it is extremely nice and safer to be able to update the firmware at any time and during bad weather from the comfort of my living room or anywhere with an internet connection. Both the version of the OS and the firmware running the business logic on the device can be pushed from the Particle cloud to a device on the OpenThread mesh network! There is an issue with the Particle, Real Time Operating System, RTOS, where sometimes the OTA update to the mesh nodes have trouble caused from the tight loop of code running light pattern features. The easy work around is to first update the mode of the mesh nodes through the Particle function discussed in the gateway section above. I'll update the mode on all light feature nodes to exit the tight loop and turn all the lights on. Once I see that all the lights are on then I will run the OTA update and the firmware updates reliably every time.
All the mesh light feature nodes are running the same code, but each node knows its identity and can run special routines based on its identity. When the code initializes during the setup method, the light feature nodes subscribe to the Particle, particle/device/name, api which returns the friendly device name. The code can then have switches based on the friendly name identity of the device. So far there is only one switch in the code based on the identity of the device. The christmasTree device is special and treated as the leader and sends a message to the gateway to tell it that it is time to send out the synchronization mesh message when the christmasTree is idle on startup or idle after completing a light pattern. The christmasTree will keep sending messages every second incase the gateway is unplugged. Once the gateway acknowledges that the christmasTree is idle then it sends a mesh message on the christmasLights topic. All the light feature nodes subscribe to the christmasLights topic and kick off the light show upon message receipt. All the mesh nodes receive the message at practically the same time and are almost perfectly sequenced. Delays in sequencing as small as 20ms can be noticed so it is awesome that all the devices appear to work in complete unison.
I built the 20-foot tree with some solid-state relays, Christmas lights, and black iron 1/2-inch plumbing pipe. The black iron pipe can be purchased from a hardware store in 10-foot sections so you will also need to join two sections of pipe with a coupler fitting. I hammered 3/4-inch PVC pipe into the ground around 1.5 feet so that I would not need to dig a hole to support the tree each year. The tree has 12 channels of solid-state relays and each channel has strands of 100 green light bulbs that I tie a string to and steak to the ground at each corner. It would be ideal to use pulse width modulation to control the brightness of each channel, but the Particle Xenon doesn't have 12 pwm pins available so I wrote my own pulse logic to control the brightness of each channel in a tight loop. I wrote a bunch of cool patterns to do things like fade channels that rotate around the tree and create cool effects.
I built 2 sets of 6 Christmas balls where each ball is 1 foot in diameter and has 200 Christmas lights. Each set of 6 balls has 1 Particle Xenon and a bank of solid-state relays controlling the brightness of each ball. Half of the balls are made with red lights and the other half are made with green lights. The 2 sets of 6 balls are on separate circuits so that each set of 6 balls could be mounted in different trees or displayed in different areas of the yard.
OpenThread provides an excellent way to synchronize Christmas lights where you do not need to wire all of the lights to a central controller. The resilient mesh network is much more reliable than Wi-Fi. Particle provides a platform that makes using OpenThread and doing IoT much easier and much more fun too! I hope that you enjoyed the article and build some OpenThread Christmas magic lights of your own!