The following is a project write-up from a recent hackathon that took place with the Silicon Labs MCU and Micrium Application Engineering teams. The members of this team were Mark Mulrooney, Michael Dean, Alan Sy and Joe Stine.
The goal of this project was to create an IoT enabled Party Button that would allow a user to press a button and trigger a number of party lights all to turn on at the same time. This was accomplished using a combination of Silicon Labs EFM32GG11 Starter Kits, Silicon Labs EFR32MG12 Starter Kits, Silicon Labs Smart Outlets, Silicon Labs Si8751-KIT Isolators, Dream Cheeky Big Red Button and a lot of party lights/disco balls. Using this hardware, a signal was send from the Big Red Button to an MQTT broker which then propagated to out to Giant Gecko kits that listening for a signal. Some of the GG11s had the isolator connected directly to the board and would toggle their specific party light and other GG11s were connected over serial to a Mighty Gecko kit. The Mighty Gecko would send a ZCL on/off message over Zigbee to other Mighty Geckos or the Silicon Labs Smart Outlet to control the other party lights.
Since our team typically works on the EFM32 platform or with software other than Micrium OS, our main goals of this project were to become familiar with the EFR32 chips/tools and to use Micrium OS to add internet connectivity to a LAN IoT ecosystem such as a Zigbee network. As we found out, the project did prove to be a good exercise in both the EFR32 and Micrium OS.
The project can be divided up into three main sections: MQTT, Zigbee and Isolation. An advantage of this was since the project was somewhat complicated and involved a lot of moving parts, it allowed our team members to work on different parts of the project without holding up another part of the team. The following sections describe the different parts of the project and how they operated.
The IoT Party Button project used MQTT as the communication protocol between the Big Red Button and the GG11 nodes. MQTT is a lightweight publish-subscribe IoT protocol that sits on-top of TCP. For our project we used the Mosquitto broker as our MQTT broker for all of the clients to connect to. The Mosquitto broker was hosted on an AWS EC2 instance and implemented a simple username/password for some basic security. In a real-world application you would ideally use TLS in conjunction with MQTT to encrypt your connection to an MQTT broker.
The project used MQTT for control of the trigger for a few reasons. The biggest reason was flexibility. Initially, during the planning of the project we discussed the possibility of plugging the Big Red Button into a Giant Gecko. This would have allowed us to use the Micrium OS USB stack to detect the button press and Micrium OS Net’s MQTT client to publish the button push to the MQTT broker. Since we only had a few days to complete this project we were unsure if there would be enough time to complete this portion, so we set that part aside.
For testing purposes, we created a simple button simulator in Node.JS that could run on anyone’s computer and publish a message to the MQTT topic for a button press. Since we did not have enough time to complete the USB portion on a GG11, we ended up using a Node.JS script to listen for a button press while the button was plugged into one of our computers. When the Node.JS script detected the button press it sent an MQTT message to the trigger topic.
Another advantage of using MQTT for control of the trigger is it opened up the ability to have the trigger sent from a number of places. We use Slack as a communication tool in the office, but we also have a helper bot that you can send commands to. It is possible that we could have had the bot send the same MQTT command to the MQTT broker to trigger the IoT party.
All of the GG11s that were subscribed to the MQTT topic for the button trigger used Micrium OS and the Micrium OS Network MQTT client. Once the Micrium OS portion was set up, the subscribed nodes had one of two functions: either trigger an isolator connected to it or send a serial command to a Mighty Gecko to trigger it’s local network via Zigbee. For simplicity’s sake, we used the same application on all of the GG11s. This allowed us to program them all up without the need for individual code changes.
The Giant Gecko kit only has Ethernet, we found it was not practical to use Giant Gecko’s for every node in our project. Instead, it was easier to use one Giant Gecko that had an Ethernet connection and use a Mighty Gecko to send the command out wirelessly to all nodes in its network. It also allowed us to use some of the Silicon Labs Smart Outlets as nodes in our project.
Zigbee networks typically have three different types of nodes in them: Coordinator, Router and End Device. In our project, the coordinator was connected to the Giant Gecko via serial to receive the on or off command and would then relay that command out to all of the nodes in the network. The coordinator was configured using AppBuilder in Simplicity Studio. AppBuilder allows you to specify what packages should be included and generates the necessary code. Since the Giant Gecko was connected to the Mighty Gecko over serial, we enabled the command line as a simple way for the Giant Gecko to send commands to the Mighty Gecko.
We took advantage of the Zigbee Cluster Library in this project to simplify the format of the on or off message being sent to the nodes. Also, the Silicon Labs Smart Outlets by default use the ZCL on/off library so we did not have to do any configuration on the outlets. Once the command line and ZCL on/off library was enabled in AppBuilder, it was able to put our project together and we were able to flash our coordinator.
The rest of the nodes in our project were configured either as a router or end devices. Similar to the coordinator we used AppBuilder to generate a project that listens for ZCL on/off messages, but in this case, we did not need the command line. We did however have to add code to the ZCL on/off hooks to toggle a GPIO which would in-turn, toggle the power switcher which was connected to our party lights.
To be energy friendly, we decided our system should control the power of the disco light. Our MCU board is running off DC power, but the disco light is powered by AC from a standard wall outlet. So we needed to control AC power from a DC system. To be safe, we should isolate the AC power from the DC power and use a high power MOSFET to turn on and off the AC power to the disco light. Fortunately, Silicon Labs makes an evaluation kit that does just this.
The Si8751-KIT contains an evaluation board that takes care of isolating two power systems and allows for a digital input on the low voltage, DC side to control the MOSFET on the high power, AC side. Set up was as simple as configuring a few jumpers on the board, connecting the low power side to the VDD, GND, and a GPIO of the MCU, and then connecting the high-power side to the AC outlet and the disco light.
We also had another disco light that operated from 12V DC, and fortunately, the SI8751-KIT also has high voltage DC isolation capabilities. So, we used a second Si8751-KIT to isolate the 12V DC from our low voltage DC system on the wireless MCU.
This project required a fine balance between several different protocols all within the same network. This meant there were a lot of moving parts to deal with so sometimes it was difficult to determine where a problem may be occurring. Over the course of the week our debugging skills became a little more fine-tuned but we definitely had some hiccups at first.
By far our biggest challenge was working with Zigbee. This was mainly because none of us were familiar with the tools or the development kits. The Zigbee tools, as we found out, have a bit of a learning curve and a few tricks to them. We also got unlucky when the first example project we chose to try didn’t work because of a software problem in a newly released SDK. After determining the issue was with the project we moved on to a known working example, Dynamic Multi-Protocol. Once we started working with that project we quickly realized that we were using an example that had a lot of extra overhead we did not need and was confusing us.
After our failed experiments with some sample projects we decided to start from scratch and build up our own project in the App Builder. After jumping through a few hoops we were able to get a project configured the way we wanted. We found that starting small and building off that was a much better approach than trying to use a complicated example and trim off the excess features. We also found that complicated projects like Zigbee can have a steep learning curve and we underestimated the amount of time it would take to complete the Zigbee portion. Luckily, we were able to complete the Micrium OS portion on the Giant Gecko rather quickly which gave us extra time to focus on Zigbee.
Due to some issues with our Zigbee configuration, our project was not complete at the end of the hackathon week. Our final presentation had the ability to send a message from the Big Red Button to the MQTT broker and down to the EFM32GG11 boards, the ability to send a serial command from the EFM32GG11 to the EFR32MG12 and the ability to switch the isolators from either the EFM32GG11 or EFR32MG12. The one gap in the project was sending the ZCL on/off message correct to all of the nodes in our network. An obvious next step for this project would be to rectify the issues in our Zigbee network configuration.
Beyond getting the Zigbee network configured correctly, we had a few other improvements that could be implemented. First, the Big Red Button could be connected a EFM32GG11 running Micrium OS USB Host to read the button state and send it via MQTT using Micrium OS Network. The second improvement we talked about was actually hooking up a Slack chat bot to have a command to trigger the party instead of using the Big Red Button.
While we were not able to get the project working as intended, it proved to be a very valuable exercise to explore the EFR32MG12 and a fun way to do it.