IoT Trashcan Monitor: A Golioth Reference Design

Internet of Things (IoT) devices are successful when they cut down on work. This almost always results in monetary savings for the companies or groups deploying the IoT solution. Since I am a fan of industrial uses of IoT over other (consumer) use cases, I often say that the value of IoT devices is not in making money, but in saving money. It’s easy to draw a straight line from the struggles of putting devices into the world, to saving money on things like maintenance, downtime, loss of property, fuel costs, and more.

Our first Reference Design (more on what those are later) is an internet connected trash can. This allows a municipality or organization like the US National Parks to save money on sending around trash trucks to empty bins. Given the additional features of this Reference Design, they could also set alerts when there is a situation that needs more immediate attention.

The IoT Trashcan Monitor

First off, why an IoT Trashcan Monitor? That question is easy: we had multiple people asking us about this type of solution, so we decided to build it! Aside from that, I think this solution is representative of a wider class of IoT device designs: simple sensors connected back to the network, sending data once or twice a day. The fact that we used cellular connectivity also untethers it from local networks like Wi-Fi requires. This is an entire category of IoT, needing to do occasional readings from far afield. I could easily take the design you’ll see here and either:

• Reuse the sensor for a different distance measuring purpose or
• Swap out the sensor

In both cases, I would be taking the scaffolding of this Reference Design, but then turning it into an entirely different product. We include a range-finder sensor used to detect the height of trash in a bin. That can be reused for things like liquid level sensing, human detection, proximity alarms, and more. Switching out the main range-finder sensor for something like a PIR sensor allows very similar firmware and cloud software to be deployed as an entirely new application.

Let’s take a look at what’s involved in this Reference Design

Hardware

For most Reference Designs we do, we’re favoring off-the-shelf hardware for ease of implementation. However, most of the modules that we use are simple breakout boards that aren’t much more than a sensor or two, some power handling, and interconnects like cabling. The idea is that someone could take this setup and choose which sensors they want to put onto their custom hardware design that will go out in the field.

The full parts list is on our Golioth Projects page, but the key components involved are the Nordic Semiconductor nRF9160 and the ST VL53L0X. The former was chosen because it is one of our best supported parts on Golioth, in addition to being a Cellular + GPS solution (required if we’re in the middle of a national park). The latter was chosen to target a range application, but also because the driver for this particular sensor was already in Zephyr. This sped up the development time considerably.

Firmware

Because the design is using off-the-shelf hardware, the majority of effort on this project went into the firmware. Built on top of the Golioth Zephyr SDK, most of the work involved setting up timers and work queues to kick off work on different triggers; once triggered, all of the sensors were read, processed, and then finally sent back to the Golioth cloud. Like all Golioth Reference Designs, this includes Over-The-Air firmware updates from Day 1. Most IoT designs think of this as an afterthought, but we want people using these designs to be certain they can update devices as soon as they are deployed.

This design also takes advantage of the new Golioth Settings Service. In this Reference Design, we’re using it to calibrate trashcan levels based on the detected height of garbage. Like all fleets using the settings service, these settings can be applied at the project level (all devices), at the Blueprint level (usually separated out by hardware revisions or similar), or on an individual level. In the screenshot below, you can see that I’m using the “SENSOR_READING_LOOP_S” to change the reporting frequency for only the shown device, because I wanted it to report every 10 seconds. I have the default set to 600 seconds (10 minute interval, also still pretty low!), because this information isn’t super time sensitive.

Cloud Software / Dashboard

Finally on the Cloud side of things, there is the Golioth aspect. Since the Reference Design is using the Golioth SDK in Zephyr, everything is taken care of by default Golioth features on the Cloud:

• Capturing the time-series based data on LightDB Stream
• Handling the Settings service described above
• Tracking latest device state, including device health
• Managing OTA rollout, when a new image is available
• Giving a convenient REST API to access all of the device data from other Cloud applications

For visualizing this data, we created a Grafana dashboard that talks to the Golioth REST API on a regular interval. While we could have also used WebSockets to get live updates, we don’t expect a trashcan to need to update more than a couple of times per day.

Let’s take a step back and talk a bit more about Reference Designs in a broader sense.

What is a Reference Design?

Our first concept for a Reference Design was called a “Business In a Box”. Someone utilizing a Golioth Reference Design would be well on their way towards a fully formed IoT-based business. This benefits two parties:

• People who have a business problem similar to what we’re showcasing
• Engineers who want to see an example of an end-to-end IoT solution

Reference Designs are still relatively early in the Product Lifecycle. They are the equivalent of having an in-house design team build out a v1 prototype to validate an idea and see data streaming back from the field. Someone utilizing a Reference Design likely would want to take the data package to a Development Shop and have them harden the design for the constraints of the real-world application. In the case of the IoT trashcan monitor, they would want to:

• Customize the hardware for manufacturing and form factor
• Make sure the hardware could stand up to the elements (waterproof)
• Get the necessary certifications (PTCRB, FCC part 15B, etc)
• Work with a manufacturing partner to start building to scale
• Review the firmware solution for long term maintenance
• Create a custom app or web portal to view data (or develop one using low code visualization tools)
• Add any other required features on the hardware, firmware, and cloud side

Golioth helps along the way and has design and manufacturing partners we are happy to help introduce you to.

More Reference Designs

We are busy building out more reference material for you to take and customize for your business needs. We recently launched an Industries section of the Golioth website, which lays out some of the other areas we are targeting and Reference Designs we are building. If any of them interest you, click the “Schedule Demo” button for the one that best matches your needs. You can also drop a note on our Forum or on our Discord if you have ideas of other IoT prototypes you need help with or would like to see us build.