What We Show Our Biggest Clients: A Full Golioth Cloud Demo

As a longtime Golioth user, I have to remind myself that for the majority of the world’s population, our capabilities are brand new–despite being around since 2020. What’s more, our core capabilities are so stable and useful for my projects, I forget just how novel they are for a lot of IoT device creators. We offer simple cloud services for constrained devices that very few others can match.

So today I’m going to show all of the common pieces of the Golioth Console that I use in my daily projects and the demo that we often show to our biggest clients. I’ll be showcasing with a ‘mini-fleet’ of 4 Thingy91 devices configured in a North/South/East/West configuration. These are mounted to a board in order to show devices operating near each other, but operating independently.

For all of the capabilities shown here, you can follow along! You’ll need a Thingy91 or Thingy91X and the binaries available from this repository.

What we showed

I really love the organization of how we built the Thingy91 firmware because each function from Golioth is broken out into a .c/.h file, such as app_rpc.c. This makes it very easy for me to understand where to go when I want to add something like a new Remote Procedure Call to a project. This corresponds to many of the features that we showed in the video and described below. One exception is Over-the-Air (OTA) updates, since it is so fundamental and seamless…well it just works! Let’s look at the other services discussed in this video (and links to more info on Golioth about them)

• Settings – This was the first thing shown, specifically the same setting being changed across all devices in this “mini-fleet”. It’s always edifying to see them all change at the same time. The settings service can push a range of data types (boolean, int, float, string) down to your devices. We showed it on both the fleet (project) level and also the device level, but we could also have created a Blueprint and only delivered the setting to devices with that specific Blueprint attached.
• Credentials & device status – This is ‘table-stakes’ for device management, showing when the device was first created and when it last connected to the Cloud. That can be critical for tracking and troubleshooting devices in the field. Also useful is the usage data that we show on each device page, to see what is being sent to and from each device. The credentials are directly accessible via the device page as well, which gives you the pre-shared key (PSK) required to allow your device to validate onto the cloud. Check out our provisioning post/video to see how we did the same with certificates.
• LightDB State – Our 2-sided database allows the device and cloud to communicate critical information about the latest known state of a device. We put an ad-hoc ‘digital twin’ design pattern in the project firmware to show how you can request a change on the device and only act upon that data once it has been received by the device and reported back to the cloud (ie. the ‘source of truth’ is the device).
• Stream (and LightDB Stream) – Our stream service is how timeseries data is sent from your device up to the cloud. Once the data arrives at the Golioth cloud, you can use Pipelines to determine if that data is sent into our internal timeseries database (LightDB Stream) or sent to an external 3rd party service (like AWS, Azure, or database services like Mongo DB). Or don’t worry about choosing and send your data to multiple destinations.
• Remote Procedure Calls – RPCs are the multitool of cloud-to-device communication, simply because you are writing the code that is being triggered from the cloud. Send a simple activation command or send down additional variables and receive data back to the cloud (like in the get_network_info command shown in the video).
• OTA / Cohorts – The best part of Golioth’s Over-The-Air (OTA) capability is that it just works. In the example in the video, the OTA is integrated into main.c with a simple library call and initialization; everything else is taken care of by the SDK. You can see this in a standalone example in the Golioth Firmware SDK’s fw_update example. The Cloud is where all of the management layers exist to create cohorts, initiate deployments, and view the event logs.

Bonus: Viewing data via the REST API

After finishing the first recording, I realized I should have shown a visualization of the data. This isn’t built into the Golioth Console, but does talk to the Golioth REST API. We have a Grafana instance querying the REST API and putting that data onto charts for easy viewing of each unit’s current status.