Tag Archive for: Device Management

Golioth Blueprints help your Cloud understand your IoT hardware devices

Building IoT systems is always a push and pull to find the balance between designs that are very rigid in their definition (hard to change later) and overly generalized (less useful for everyday development). Golioth Blueprints are a new concept which apply structure to the relationship between the Cloud and the Device. Blueprints enable more useful features throughout the life of an IoT deployment. In this post we’re going to talk about what a Blueprint is, and how it is used throughout Golioth to enhance capabilities for our users.

Flexibility is a blessing and curse

Golioth works on a wide range of hardware. That’s the blessing. We think it’s really important to meet hardware and firmware teams where they are. If a client requirement or a sourcing issue pushes you into a particular chipset + communication method, we want to support you. That’s why we have multiple SDKs, each of which can pull in a wide range of parts.

But when you “can do anything”, that means nothing is standardized. Data coming in from a temperature sensor is treated the same as data coming in from a motor controller. Firmware updates being deployed to a device in the field running on a Cortex-M7 can also be pushed to a device running on a Cortex-M0 (hardware tip: these are very different). So the curse is that the exercise of separating and protecting all of that data is left up to you. Your Cloud team might only want a piece of data or a variable, but the implications of a mistake in your data design could be severe for your very real hardware deployment.

As you’ll see below, Blueprints will help bridge the communication between the embedded team and the Cloud team. They add information that would normally be hidden somewhere, maybe in a hardware datasheet or an engineering team specification document. Like real blueprints, Golioth Blueprints help to map out how things should be built.

Why are Blueprints needed?

To put an even finer point on the topic of Blueprints, let’s discuss a real-world example. Imagine an environmental monitoring product that has the following in its Rev A version of hardware:

  • nRF9160 cellular SIP from Nordic Semiconductor (running dual Cortex-M33 processors)
  • BMP280 temperature/environmental sensor
  • 4 MB external SPI flash
  • Other supporting components

Due to sourcing issues, you can no longer get any of these parts. Yep, it’s that bad out there. Your Rev B (because you need to ship something to your customers) now has:

  • An nRF52840 processor (single core Cortex-M4)
  • A BG95 cellular modem
  • BMP680 environmental sensor
  • 8 MB of external SPI flash

In the Golioth NCS SDK, the coding differences are minimal, despite pretty extreme changes in the hardware. However, thanks to how Zephyr RTOS is set up, it will be a set of configuration files instead of completely rewriting the codebase.

This is standard fare during the chip shortage, which we wrote about last week. Some companies are taking extreme steps like this in order to continue shipping their products, basically supporting two divergent product lines that can achieve the same goals. The key point is that the software team/end customer/consumer of the data via your company’s app probably doesn’t care how the data gets from the physical world to the digital world, they just want the variables they’re looking at (ie. temperature) to be accurate.

Now that we have pretty different Rev A and Rev B boards, how do we keep everything straight when we’re maintaining these products?

Enter the Golioth Blueprint

Golioth Blueprint management menu on the Golioth Console

The Golioth Blueprint is a description of all of the relevant things on target devices. As the Blueprint continues to mature in the coming months and years, we will evolve the types of data stored in the Blueprint. For now, we lean on board definitions that are in Zephyr. For the above screenshot, you can see that we are using the Sparkfun Thing Plus nRF9160 (based on the CircuitDojo nRF9160 Feather), which is indexed on the Zephyr website and in the Zephyr/NCS codebase.

From the meta data provided by Zephyr, we can pull in things like the target chipset, memory amount, how it’s mapped, peripherals that are available, and even external sensors that are on board (an accelerometer). If you have your own board definition upstream in Zephyr, you would also see that in the Golioth Blueprint list. We are working on other ways to pull in formatted metadata around customized boards that might need to stay private. If you’re interested in that, please email us.

If you don’t have a Blueprint, say because you’re using our ESP-IDF SDK instead of Zephyr, or a completely different platform, that’s OK too. You can assign a placeholder Blueprint name to help delineate between your different hardware builds. Generally, you are not required to use a Blueprint when you are on the Golioth Console, but there are many benefits to doing so. Let’s look at some.

Over-the-Air Firmware Update

Golioth users can assign a Blueprint to their firmware updates:

Doing so means that the Firmware Release will only target a specific subset of devices. If we go back to the example above, this could be critical when the target devices have completely different processors on board; firmware built for an nRF9160 will not work on an nRF52840! Attaching a Blueprint, even without attaching additional meta information (from Zephyr board files) still allows you to track which devices are receiving updates. Memory structure information will be used for future releases, being able to target different artifacts to different segments of memory.

Settings

Our recently released Settings service uses Blueprints to deliver different settings to different devices. As a reminder, settings can apply on the following levels:

  • Project
  • Blueprint
  • Individual device

To use our example from above, you might want to have different setting when different sensors attached to your device. You could set something like “UPDATE RATE” for the project to be every 30 seconds, but maybe you want to have the Rev A boards report in twice as often because you want to average the readings on the Cloud.

If you click into a Device Management page (looking at a specific device), you will see how the settings are being applied by Project, Blueprint, or on that specific device.

Future plans for structured data

We are currently very flexible on the sensor data you are sending back over LightDB State and LightDB Stream. In the future, we hope to be able to extract sensor data from your Blueprint to have our Cloud intuitively understand the types of data that is received from your fleet. Users will benefit from being able to chart data and export to other platforms knowing that a reading is a temperature or another fixed type of reading.

Using Blueprints effectively for your next project

Golioth Blueprints are an enhancement that allows our users to keep track of the hardware they are communicating with in the field. As users’ fleets and number of SKUs grow, this will be a critical aspect to any device management platform.

Try out Golioth Blueprints today on the Golioth Console. If you need any help or would like to discuss the idea more, we have a forum, a Discord, and we can be reached at [email protected].

/by
,

Thread network device management using Golioth

Golioth is a flexible device management solution that allows you to manage devices that have IP addresses. This includes devices connecting over Ethernet, cellular, and Wi-Fi. Today we’re showcasing a demo of a Thread-based device. Utilizing the Golioth Console and API endpoints, it’s possible to manage a wide array of devices provisioned on the internet through a Thread Border Router. This enables even more low-power devices to reliably push data back to the internet for processing on the cloud.

In this post and the associated video, we show a demo of how developers can try out using Golioth to manage Thread based devices.

What is Thread?

Thread is a network protocol for low power IoT devices. It uses 6LoWPAN for mesh communications, in our case on 2.4GHz. In the examples above, we showcase Thread using OpenThread on an nRF52840 from Nordic Semiconductor. Multiple hardware vendors have Thread-based solutions, using Zephyr or other firmware solutions. Vit Prajzler shows how he is using the OpenThread documentation to build different types of devices that form a Thread mesh network, including a Radio Co-Processor (RCP) and a Full Thread Device (FTD).

Set up a Border Router

A Border Router is an element on a Thread Mesh network that allows the entire network to communicate with the broader internet. Each individual device (Node) has an IPv6 address, which allows Golioth to manage specific devices on a mesh.

While it’s possible to buy a few off-the-shelf Border Routers, we showcase building one using commonly available components. Vit is using a Linux computer (a Raspberry Pi), along with an nRF52840 dongle configured as an RCP to route network traffic from the mesh to the rest of the internet. In the case of his Thread network, Vit needs to include a translation layer (called NAT64) to talk from his IPv4-based router to the IPv6-based Thread network. In the future, when Vit gets an IPv6 address assigned to his home network from his ISP, no conversion will be required.

OpenThread software on a Linux device like a Raspberry Pi also has a web interface for managing connected devices. This is a useful way to visualize your network and the location of the Border Router within that network.

Using the Golioth interface in the Zephyr SDK

Once your Border Router has been set up, you can use the Golioth Zephyr SDK to compile an image for your device using OpenThread. In the video above, Vit is compiling for an nRF52840 (dongle). Once this device is loaded with Zephyr-based firmware and added to the mesh network–in this example, connecting directly to the Border Router–the device acts like any other IP connected device. It has an IPv6 address and can ping the address of the Border Router. It can also connect to various Golioth endpoints.

Vit demonstrates button presses and boot commands being logged in Zephyr, which then display over the UART. However, Zephyr logs are also tied to the Golioth logging end point (from the Thread network connection), so they can be viewed on the Golioth web console. As Vit presses a button on the Zephyr based device, the log message almost instantaneously shows up on the cloud.

Extending the examples

Towards the end of the video, Chris and Vit discuss how (Open)Thread-based devices built with Zephyr work very similarly to any other IP-based devices connecting to Golioth. This means that the other features that Golioth provides–such as control using LightDB State, or easy time series data tracking using LightDB Stream–is already in there. And yes, that means Firmware Updates as well. We’ll be showcasing these more in future videos.

We’re excited to bring Golioth and internet connectivity to even more devices, including the kind of teeny tiny low power ones that Thread enables. Please stop by the Golioth Discord or the Golioth Forums to ask questions and discuss the next device you’re working on!

Interested in Thread in a commercial application? Contact us at

 

/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