WebSockets are the real-time data pipe for your next IoT project

The new WebSockets feature on Golioth allows users to stream data out to external services, such as visualization platforms and web apps. This includes showing “real-time” data from sources on embedded devices, such as sensors. Let’s look at how these are different than previous offerings.

What is a WebSocket?

A WebSocket is a persistent connection that runs over TCP connections between two entities, normally a browser and a server. Thought about in the abstract, it is a datapipe that allows bidirectional information. Golioth is using these to push and pull data between the Golioth Cloud and another endpoint, such as a browser or visualization tool.

How is this different?

As a hardware engineer, I find myself falling into the familiar trap of, “it’s all just moving data around!”. But that, of course, is wrong. Once your data moves from your device up to the Golioth cloud, you normally want it to go somewhere or to do something. Readers familiar with our other service offerings will remember that we have a REST API. If you want to pull data using the REST API, you need to request that next chunk of data. An external application like an Android app would need to ask for an update from the API on a regular basis, perhaps every second. This pull action is akin to “polling” in a microcontroller. Hardware and firmware designers will know the downsides to this method, especially in terms of processing overhead. But it happens all over the web and there are lots of reasons to use the REST API. In fact, this is how we update the Golioth Console when users are viewing LightDB data:

With WebSockets, you are not polling; you are being pushed data as it appears on the platform. That is, “from the perspective of the web application showcasing the data”, it’s a push, instead of a pull. The WebSocket connection must remain open in order to receive this data, but if it is, any new data will flow to the web application on the other side. Combining a WebSocket with LightDB Stream (Golioth’s time-series database) allows you to potentially stream data from a device up to the Golioth cloud and then out to a charting service like Grafana. In this way, it’s a conduit for sensor data in “real-time” (overhead will cause some delay between the action and the charting of the event).

Let’s imagine environmental sensors connected to an nRF9160 development board like the CircuitDojo nRF9160 feather. In fact, there is a demo from Jared Wolff (creator of the nRF91 Feather), showcasing the environmental add-on board called the “Air Quality Wing”. That demo implements this using the REST API. Now instead of Grafana constantly pinging the REST API for the next data point, we’ll be able to update that demo to have data streaming directly to Grafana as a change happens. We’ll have demos showcasing this functionality in the near future.

Get started today

Our team released new documentation about WebSockets alongside the new functionality. We love to hear from users putting features to good use, so be sure to stop by Golioth Office Hours on our Discord server to show off what you have built.

/by
,

Organizing thousands of connected devices

Scaling makes things more difficult

As your deployments grow, things start to get messy.

At 100, or maybe even just below 1000 devices…you can do it however you’d like. You might have a spreadsheet listing the location of devices and all of the relevant information about them. But even then, it is a full-time job to manage devices. What’s more, as new people come in to take action on particular devices, they need to slice and dice the data about where the device is located, its status, the capabilities that the device has.  According to Satistia in 2021, there are more than 13.8 billion active IoT devices. It’s estimated that the number of active IoT devices will surpass 30 billion by the end of 2025.

A good organizational system will reduce mistakes

Planning and organizing will help you get your work done accurately while avoiding costly mistakes. Managing this huge number of devices requires a good organizational system. Golioth provides a simple solution to manage devices: tags.

Tags provide a flexible, flat hierarchical structure in which you can group multiple devices. We are going to explore the usefulness of tagging in the Golioth platform.

Why use tags?

A tag is a simple text, generally, one to three words, that provides details about a device. The tag is assigned to a unique device on the Golioth network. Later, when searching, it is a simple click or search term in order to locate similar devices with the same tag.

You can easily separate your devices with any criteria you choose. For example, a separation between development devices and production devices. This can be useful when you want to change configurations for a specific set of devices. By using tags, you can group these devices and push the needed configuration using something like the OTA DFU on the nRF91.

You can also group different devices depending on your deployments or regions. Maybe you’re building an asset tracker application and you want to separate your devices that are on the east coast of the US vs the west coast. Or maybe you want to only update devices that are in a particular time zone. Or even separate when you push an update based on timezone, preferring to push firmware when no one is actively using the device. With tags, it’s possible to target firmware update deployment where and when you want it.

Flat structure

Right now, Golioth tags are a flat structure. You can assign multiple tags to a device without the concept of hierarchy. Even with this flat structure, it’s possible to do some powerful things like we just described. For example, using tags with LightDB allows us to pull or send data to specifically tagged devices. If you want to toggle an LED on a group of devices, you can send the new state to that group by sending the command to the associated tag, as shown in the video below. This is practical for test purposes. You can manipulate a device’s tags graphically on the console, or you can use the Golioth Command Lines Interface (CLI) to remove, add, or modify certain tags. The CLI in particular can be really useful as you start to have a deployment that’s much bigger (hundreds, thousands, millions).

When you’re ready to retrieve data from groups of devices, you can also query data and even do aggregations using tags. For example, if you want to see the average temperature of devices located on the 3rd floor in a factory, you could filter the logs for “factory”, “3rd floor”, “temperature” and then aggregate the data. Extending this idea, pulling data from tagged devices in a region could even lead to a sort of ad-hoc mapping.

Watch the demo

 

/0 Comments/by
, ,

Device Firmware Update (DFU) with Golioth

“I’m sorry boss, I am working as fast as I can here. I reprogrammed about 36 out of the total 50 units, but this is slow going. I only have one programming cable and I need to disassemble the deployed units so I can get to the header on the boards first.”

A bad firmware image on your deployed IoT devices can mean ruined weekends, upset customers, and lost time. Many businesses pursue a network based firmware update so that they can push new versions to their devices. In fact, this is a critical part of the firmware development process, often a very early one. Developing or implementing a bootloader allows engineers to ship new control software to their devices. A straw poll on Twitter showed that some engineers spend a significant amount of time putting this tooling in place.

While the “barely any time” group seems large, it also includes those who aren’t doing a custom bootloader, nor a bootloader that is networked:

In the past, networked firmware updates took a significant amount of planning and coordination between hardware, firmware, software, and web teams. Golioth has collapsed this down to a simple process.

Update all the devices in your fleet with the click of a button

Golioth Device Firmware Update (DFU) is possible because the Golioth SDK is built on top of the Zephyr Project. Part of that implementation includes MCUboot, an open source bootloader. Using open source software up and down the stack, Golioth enables quick, secure deployment of firmware packages to IoT devices throughout the world. The Golioth Console enables easy management of firmware releases, including multi-part binary bundles, enabling updates for devices as diverse as smart speakers, digital signage, machine learning enabled sensor systems, multiple processor embedded devices, and more.

In the video linked below, Lead Engineer Alvaro Viebrantz demonstrates with Chris Gammell how to update the firmware of an nRF52 based device over Ethernet. The video includes code snippets in Zephyr and walking through the build process using the command line tool West. Once the firmware image is built, Alvaro showcases how to push the image to the Golioth cloud, package it for delivery, and then deploying to Golioth enabled devices.

No more fussing with programming cables out in the field, Golioth allows engineers to update their devices with new features, requested fixes, and efficiency improvements. Try it out today!

About Golioth

Golioth is a cloud company dedicated to making it easier to prototype, deploy, and manage IoT systems. Learn more by joining the Golioth Beta program and reading through Golioth Documentation.

/by