It starts with a development board

All of our getting started guides are built on top of development kits / boards from our hardware partners.

1. Having a standard set of tests that the Golioth firmware team regularly tests (see our posts on hardware-in-the-loop for more details)
2. Providing a standalone example of that feature working without any distraction For these purposes, development boards work great. Users have a proven, tested set of samples that can run on supported hardware like our

Continuously-Verified Boards (CVB).

Doing more to show more

As we enter another trade show season, capturing engineers’ attention is on my mind. Nestled in a booth among other compelling demos, it can be hard to stand out. There are many things to see at a trade show, and IoT demos don’t benefit from things like cameras, large screens, or the impressive scale of something like an industrial robot. And as tough as standing out at a trade show can be, it might be even more difficult on the internet. How do we showcase complex and abstract topics to a crowd that will click away after a split second? If you want to build a compelling demo (as we often want to do), you need to add other elements to development boards. If I am trying to show the layers and layers of cloud, firmware, and hardware all to showcase how I blink an LED from the internet…that demo falls flat. Don’t get me wrong, I have done this and sometimes all we have is an LED. If you do happen to snag the attention of an engineer who has struggled with the stacks of software required to build an IoT system, the LED will suffice. But they are the exception not the rule. Users eventually want to see all capabilities of Golioth in a coherent demo. This is the origin of our Reference Design Template and more generally our Reference Designs. In order to showcase each of those capabilities in a compelling way, we also wanted to increase the variety of inputs and outputs. The “Follow Along Hardware” version of the Reference Designs took an abstracted interface like the Arduino (Uno) Shield interface on something like the nRF9160-DK and added a breakout to accept MikroBus Click Headers and extend the capabilities of the development board. The flexible nature of Zephyr allowed us to create overlay files and interact with a variety of sensors (inputs) and output devices. But what about when we want to do even more than that? How do we better emulate the setup of our customers?

Approximating production grade hardware

In 2022, we started building some of these designs into full featured Reference Designs that look like customer use cases. Application-specific demos are also concrete; recording a video or talking to a potential customer at a trade shows is easier when a use case is front and center. For example, “Would you like to see this Air Quality Monitor sending back complex data over cellular to Golioth and the wider internet?” Around this same time, we started designing and building pluggable hardware of our own. We wanted the ability to swap out sensors, but in a more realistic form factor. There are still some tradeoffs in order to make it easy to swap out sensors, namely that we built the form factor to include modular headers like the MikroBus Click header and the Sparkfun QWIIC / Adafruit Stemma 4 pin i2c interface.

Additional challenges arise for custom hardware

Customers have specific needs around form factor, power envelope, and supporting components. The Aludel Elixir was the same. The next challenges are in the firmware space, bending firmware ecosystems like Zephyr to work with custom hardware and implement new features. A hardware device maker needs pull in the Golioth Firmware SDK, but also tap into the various subsystems of Zephyr and write custom elements like device drivers that conform to Zephyr standards. We did the same on the Elixir, and have continuously published about what we have learned in Zephyr as a result. When we emulate the production process, we also run into hardware and firmware challenges that many of our customers run into. Things like provisioning devices off the “manufacturing line” (simulated in our case, since we either manufacture ourselves or do very small runs of units) or measuring current consumption of different aspects of the a device that regularly transmits data or optimizing firmware versioning to work with Golioth Over-The-Air firmware updates. Each time we build our own custom hardware, we step into the shoes of our customers building custom hardware. Each time we learn something new about the process of building efficient IoT devices on top of our platform. Smaller and smaller We introduced Golioth Connectivity and Bluetooth support back in August of last year. That also surfaced new challenges around the physical constraints of Bluetooth connected devices. While there is no requirement that a Bluetooth device be small, the new capabilities of Pouch and the Golioth Bluetooth Gateway reference implementation means we can build devices that are smaller than others we have created before.

Dogfooding at each stage of the design

Last month we shared one of our “hack day” projects extending the capabilities of

an ePaper display as a meme delivery device…but really this was an exercise in “dogfooding” our own IoT platform. Each time we port an off the shelf piece of hardware like we used for the MePaper we feel the pain points that IoT developers face from the firmware on up. Building custom hardware takes on even more of the process and is an exercise in empathy for our customers and stress testing our systems. We will continue trying out different designs and look forward to building open source solutions that could be the starting point for new products in the IoT market.

Input Events in Zephyr

The input event system has been around for the last few version of Zephyr, but starting with the next release it will be the default system for the

samples/basic/button application, replacing the more esoteric system of setting up callbacks. For me this is a welcome change as it makes a lot more sense:

#include 

static void button_input_cb(struct input_event *evt, void *user_data)
{
    if (evt->sync == 0) {
        return;
    }

    printk("Button %d %s at %" PRIu32 "\n",
           evt->code,
           evt->value ? "pressed" : "released",
           k_cycle_get_32());
}

INPUT_CALLBACK_DEFINE(NULL, button_input_cb, NULL);

a key code (evt->code) to test which keypress triggered the callback. The evt->value will be 1 for “pressed” and `` for “released”. In your devicetree, ensure that each button has a input code associated with it:

#include 

/ {
	buttons {
		compatible = "gpio-keys";

		button0: button_0 {
			gpios = <&gpio0 11 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 0";
			zephyr,code = ;
		};
	};
};

input-longpress and input-double-tap.

Detect Long and Short Button Presses

Long and short button presses are the most fully-featured pseudo input device implementation that I’ve found in Zephyr. This feature will be automatically selected in Kconfig by adding a node to your devicetree:

/{
    longpress {
        compatible = "zephyr,input-longpress";
        input-codes = , ;
        short-codes = , ;
        long-codes = , ;
        long-delay-ms = <1000>;
    };
};

• compatible: enables the input-longpress binding.
• input-codes: list of input codes (the keys you plan to press) to listen for.
• short-codes: the input event code to send when the button is pressed, but not held.
• long-codes: the input event code to send when the button is held.
• long-delay-ms: how long a button must be held before it is considered a longpress. In your C code, we need to get the pseudo device from the devicetree, which we use as a filter when registering the callback.

#include 

static const struct device *const longpress_dev = DEVICE_DT_GET(DT_PATH(longpress));

static void longpress_cb(struct input_event *evt, void *user_data)
{
    if (evt->sync == 0) {
        return;
    }

    int button_number = -1;

    if (0 != evt->value) {
        switch (evt->code) {
            case INPUT_KEY_A:
            case INPUT_KEY_X:
                button_number = 1;
                break;
            case INPUT_KEY_B:
            case INPUT_KEY_Y:
                button_number = 2;
                break;
            default:
                return;
        }

        switch (evt->code) {
            case INPUT_KEY_A:
            case INPUT_KEY_B:
                printk("Short press: button %i\n", button_number);
                break;
            case INPUT_KEY_X:
            case INPUT_KEY_Y:
                printk("Long press:  button %i\n", button_number);
                break;
            default:
                return;
        }
    }
}

INPUT_CALLBACK_DEFINE(longpress_dev, longpress_cb, NULL);

longpress path to get the instance from the devicetree. At the bottom of the example we register the callback, passing longpress_dev as the first argument so that only input events from this device will cause the longpress_cb callback function to run. The callback function itself really just filters for the desired button actions. First, it checks to see if the sync flag is set; some input events use this sync flag to indicate a stable state. From there, we use a conditional on evt->value to filter out the button release events. There are two nested switch statement, the first translates the  event to a button number (this nRF52840dk board labels the buttons starting with 1 for key0 and 2 for key1) and the second prints a message for short or long presses. The input-longpress binding uses the short-press parameter (which is optional) to remap the button presses. This way you will either get the new short keycode or the long keycode. The actual button code event (INPUT_KEY_0 or INPUT_KEY_1 in our example) will still occur but we have filtered them out from this callback.

Detect Double Tap Button Presses

The input-double-tap binding is a newer addition and not quite as useful as the longpress binding but still worth mentioning here. It is also a pseudo-device that you enable by adding a node in devicetree.

/{
    double_tap: double_tap {
        compatible = "zephyr,input-double-tap";
        input-codes = , ;
        double-tap-codes = , ;
        double-tap-delay-ms = <300>;
    };
};

• compatible: enable the input-double-tap binding
• input-codes: list of input codes (the keys you plan to press) to listen for
• double-tap-codes: the input event code to send when the button is quickly pressed twice
• double-tap-delay-ms: maximum amount of time between presses to be considered a double-tap This issue with this binding is that it lacks the

short-press member that was present in the longpress binding. Because of this, there is no way to separate the double-tap event from two key input events. Nonetheless, let’s implement callbacks for this binding:

#include 

static const struct device *const double_tap_dev = DEVICE_DT_GET(DT_NODELABEL(double_tap));

static void double_tap_cb(struct input_event *evt, void *user_data)
{
    if (evt->sync == 0) {
        return;
    }

    int button_number = -1;

    if (evt->value) {
        switch (evt->code) {
            case INPUT_KEY_C:
                button_number = 3;
                break;
            case INPUT_KEY_D:
                button_number = 4;
                break;
            default:
                return;
        }

        printk("Double tap: button %i\n", button_number);
    }

}

INPUT_CALLBACK_DEFINE(double_tap_dev, double_tap_cb, NULL);

double_tap_cb callback is registered using the double_tap_dev pseudo-device as a filter. This makes it quite easy to detect two quick button presses. However, there is no detection for single button presses on those key. We could use the general input event callback show at the top of this post, but the downside is that we will receive two key events each time a double-tap event happens. Implementing single-tap support on this binding is a great place to contribute some code improvements to the Zephyr project. We’ll see if I can find some time in the near future to work on this.

Start Using the Zephyr Input Subsystem

he input subsystem is a great way to offload some of the input monitoring for your projects. Here I’ve specifically detailed its use for button inputs, but

the input subsystem is a great place to start for any of your GPIO input handling needs. Expect to see these implemented in reference designs and examples coming from Golioth soon.

What is Wi-Fi HaLow?

Before we talk about how to get your first Wi-Fi HaLow project off the ground, we thought we should define some terms and talk about the technology a bit.

Wi-Fi HaLow is the first Wi-Fi standard purpose-built for the Internet of Things (IoT) and is a foundational technology for IoT 2.0. Operating in the sub-GHz spectrum (850–950 MHz), Wi-Fi HaLow delivers what traditional Wi-Fi cannot: long-range, meaningful throughput, low-power, and scalable connectivity, without sacrificing the openness, security, or familiarity of Wi-Fi. Wi-Fi HaLow offers a unique combination of capabilities and advantages that other wireless technologies can’t match. This includes

Morse Micro is leading the global adoption of Wi-Fi HaLow with purpose-built silicon and reference solutions that redefine what Wi-Fi can do in large, complex environments. With the mass production of the MM8108 back in September 2025, Morse Micro is unlocking a new generation of long-range, low-power IoT devices.

Introducing the MM8108-EKH05

The MM8108-EKH05 is a fully integrated Wi-Fi HaLow development platform designed for a wide range of IoT applications. It features the Morse Micro MM8108-MF15457 module, alongside an STM32U585 low-power microcontroller, a BlueNRG-M2 Bluetooth® SoC, a rich set of on-board sensor options, and expansion headers to enable users to add their own circuits quickly. The MM8108-EKH05 is the ideal hardware platform to get started building Wi-Fi HaLow-enabled IoT devices or gateways. Morse Micro provides a Zephyr West manifest repository, enabling rapid bring-up of Wi-Fi HaLow on Zephyr compatible targets. This includes the devicetree configuration for the MM8108-EKH05 board, but also definitions for Morse Micro shields, the Morse Micro Wi-Fi HaLow drivers for Zephyr, and a small number of sample applications to get users started with Wi-Fi HaLow on Zephyr.

Preparing the MM8108-EKH05 for Golioth

Adding Wi-Fi HaLow support to a Zephyr-based Golioth project is simple. The manifest repository mentioned above doubles as a west module, which can be added to your west manifest to extend your Golioth west workspace. If you start from the

Golioth Firmware SDK as a base project, you can target the variety of Golioth examples to talk to the Cloud. Add the following to your west.yml, under projects

- name: morsemicro
  path: modules/lib/morsemicro
  revision: main
  url: https://github.com/MorseMicro/mm-iot-zephyr

west update
west blobs fetch morsemicro

west build -p -b mm8108_ekh05 examples/zephyr/hello
west flash

wifi cred add -k 1 -s your_ssid -p your_wifi_password
settings set golioth/psk-id your-golioth-psk-id
settings set golioth/psk your-golioth-psk
kernel reboot

the Golioth stream example, you can start sending data right away through Pipelines to a variety of end points. Or try an Over-The-Air firmware update, done at high throughput using a sub-gig based modem. Walls are no match for this technology stack!

And just like that…

If you are instead adding Wi-Fi HaLow to a board which isn’t the MM8108-EKH05,  then you’ll need to modify your board’s devicetree to include a node for the Morse Micro HaLow Wi-Fi interface. The MM8108 is a module talking to the STM32 on the Morse Micro development board, so it could also move onto your custom hardware as a peripheral for any other Zephyr enabled processor. You can add it as a child node to the SPI master you’re attaching to. See

the devicetree implementation for the MM8108-EKH05 board in the Morse Micro Zephyr library for an example on how this node would look.

most specific dictum, but the sentiment is “be more productive”. And for all the thought pieces on how useful AI coding tools are or are not, the reality is they are improving enough that you can spin up ideas quickly. We continue to try out the process during our own hackathons. So now you have the core of an idea, a new feature or capability for your customers. For a long time, that meant field engineers plugging a cable into the back of every product and manually updating each device, dealing with the variety of firmware versions that are out there. Connectivity improved some of the “how do I know what’s going on” problems, but not the the “reliable infrastructure to connect with devices” problems. Golioth does that, day in and day out.

Relying on sturdy infrastructure

Golioth has always been focused on delivering secure, reliable infrastructure to IoT device teams, and that continues into 2026. We spent last year improving resilience of our own internal infrastructure and hardening the already-rock-solid base we had in years past. We made changes to our security capabilities, introducing more ways to provision and deploy certificates and manage certificate infrastructure. Importantly, our engineering team also focused on the ease of use aspect of doing so, in order to make it less hassle to hardware and firmware teams that might not be used to X.509 certificate infrastructure. These improvements are ongoing, including a greater focus on large scale PKI providers.

Our Management API is the control panel for you or your generative interface in order to orchestrate actions for your fleet; our Console is a practical starting place if you want a standard interface, as well. You can introduce new firmware images directly through the REST API, place devices into test cohorts (critical for those one-off test runs), and deploy and monitor devices as they go through the update process. If your new device feature is generating a new type of data, you can route it efficiently using our ever-improving Pipelines. New destination examples arise as new services arise, including the bevy of AI processing tools out in the world. Pipelines have continued to take an important role on internal tooling as well, introducing destinations for LightDB State and Logs, as well.

The abundance of choice (of connectivity)

If your next rapid deployment is a device (instead of only a feature for an existing device), Golioth continues to introduce new connectivity options for building out a product. 2025 was the year we officially introduced Bluetooth connectivity to the platform. More generally, this introduced a new distinction between “directly connected” and “indirectly connected” devices. The former normally are devices that have an IP address assigned (think cellular, Wi-Fi, Ethernet, and Thread devices) and the latter are those that require a gateway…but also covers just about every other type of connectivity. We continue to look at transport options for “indirectly connected” devices like CAN, serial, LoRa, and more. Bluetooth has been a particularly interesting target for new devices, simply because of the range of chipsets and vendors providing solutions. We continue to build upon and fawn over the Zephyr Project, since it enables compatibility across so many solutions. It also is a common RTOS for Bluetooth projects, having its own Bluetooth stack and vendors that build against it. Golioth continues to refine the capabilities for indirectly connected devices, including our Pouch protocol and the associated SDK. On the cloud side, our APIs are evolving to serve devices that are offline-first, such as Bluetooth devices that only check-in when there is user activity. The examples we build around these application spaces will enable users looking to spin up generative tooling around a Bluetooth application quick, efficient, and easy to deploy.

How It Works

The aws-kinesis data destination is similar to the aws-sqs destination for Amazon Simple Queue Service (SQS). However, besides allowing you take advantage of the unique capabilities of Kinesis Data Streams, the aws-kinesis data destination will pass along the exact data delivered to it regardless of format. This gives you more control on the data that ends up in your data stream, but also means that you’ll need to use a transformer like inject-metadata if you want device ID, project ID, and other metadata included in each message. The device ID is also used as the data stream partition key. Like other AWS destination, the aws-kinesis data destination accepts access_key, access_secret, and region parameters. It also accepts a stream_arn parameter formatted as an Amazon Resource Name (ARN).

filter:
  path: "*"
steps:
  - name: step0
    destination:
      type: aws-kinesis
      version: v1
      parameters:
        stream_arn: arn:aws:kinesis:us-east-1:123456789:stream/pipelines
        access_key: $AWS_ACCESS_KEY
        access_secret: $AWS_ACCESS_SECRET
        region: us-east-1

Click here to use this pipeline in your Golioth project! For more details on the aws-kinesis data destination, go to the documentation.

What’s Next

Amazon Kinesis is especially well-suited for high volume data and applications in which there are multiple consumers of the streamed data. It also offers a wide range of integrations with other AWS services, making it a foundational component for customers already leveraging AWS. Reach out to us on the forum if you have any questions on the aws-kinesis data destination or are using an alternative service that does not currently have a native integration in Golioth Pipelines!

• A Node.js project written in TypeScript
• Fully typed API bindings generated from Golioth’s OpenAPI spec
• API authentication handled cleanly with a .env file
• A small example that talks to the Golioth Management API

Why OpenAPI + TypeScript?

Golioth Management API is published as an

OpenAPI definition. This means we can automatically generate:

• Strongly typed request and response objects
• Autocomplete in your editor
• Compile-time errors instead of runtime surprises For backend developers, this removes a lot of guesswork and makes refactoring much safer.

1. Create a new Node.js + TypeScript project

Before we start, you’ll need:

• Node.js 18+ installed
• Basic familiarity with TypeScript
• A Golioth account and an API key Start by creating a new project directory and initializing it:

mkdir golioth-demo
cd golioth-demo
npm init -y

npm install dotenv
npm install --save-dev typescript tsx @types/node

npx tsc --init

2. Store your API key context using a .env file

The Golioth API requires an API key to be passed in a header. You should never hardcode a secret key into your code, as it can easily fall into the wrong hands. Instead, you can set up your application to pull the secret from the execution environment, which allows you to keep your API keys stored in your deployment environment, and use different credentials in different environments. API keys can only be used to access APIs for the project they’re attached to. To keep things portable, we’ll put the project and organization IDs in the environment as well, allowing our application to work with any project without having to change the code. A common solution for managing growing execution environments is to add a

.env file in the project root:

GOLIOTH_API_KEY=your-api-key
GOLIOTH_ORG=your-org-id
GOLIOTH_PROJECT=your-project-id

src/index.ts using dotenv:

import 'dotenv/config';

process.env.GOLIOTH_API_KEY

3. Generate TypeScript bindings from the OpenAPI spec

To generate the TypeScript bindings for the Golioth API, we’ll use the

Swagger TypeScript API package. This provides a flexible set of configuration parameters that allows us to fine tune the generated TypeScript code to make the Golioth API integration as simple as possible. First, we’ll need to install the generator:

npm install --save-dev swagger-typescript-api

swagger-typescript-api can be run as a command line tool with npx, it’s easier to set up its configuration by wrapping it up in a little script that runs the code generation. It’ll also allow us to tweak the generated code a bit. Create a scripts directory at the root of your repository, and add the following to a TypeScript file named golioth.ts:

import path from "node:path";
import { generateApi } from "swagger-typescript-api";

const fromEnv = {
    projectId: "GOLIOTH_PROJECT",
    organizationId: "GOLIOTH_ORG",
};
type PName = keyof typeof fromEnv;

generateApi({
    url: "",
    apiClassName: "Golioth",
    output: path.resolve("src/api"),
    fileName: "golioth.ts",

    // split API into modules:
    moduleNameFirstTag: true,
    // Unwrap the json data in the response:
    unwrapResponseData: true,

    // Skip predefined parameters:
    hooks: {
        onCreateRoute(routeData) {
            routeData.request.parameters =
                routeData.request.parameters?.filter(
                    (p) => !fromEnv[(p as { name: PName }).name]
                ) ?? [];
            return routeData;
        },
        onInsertPathParam(paramName) {
            if (paramName in fromEnv) {
                return `process.env.${fromEnv[paramName as PName]}`;
            }
        },
    },
});

fromEnv object will be replaced with their mapped environment variables. We’ll get to why that’s important in a little bit! Finally, add this as a script in your package.json:

// ...
    "scripts": {
        // ...
        "generate:golioth": "tsx scripts/golioth.ts"
    }
}

npm run generate:golioth

golioth.ts file gets added to src/api, containing several thousand lines of type definitions, including a Golioth class, which we’ll use to instantiate our API.

4. Create and configure the Golioth API client

With the generated bindings and API key in place, creating a client is straightforward. We find it’s cleanest to instantiate the Golioth client in a separate file, and export it as a

const. Create a new file called src/golioth.ts:

import { Golioth } from "./api/golioth";

export const golioth = new Golioth({
    baseApiParams: {
        headers: {
            // Pulling the API key from the execution environment:
            "X-Api-Key": process.env.GOLIOTH_API_KEY,
        },
    },
});

• Authentication wired up
• A fully typed API client
• Editor autocomplete for all endpoints

5. Make your first API call

Let’s make a simple request to verify everything works. For example, fetch a list of devices in your project:

import 'dotenv/config';
import { golioth } from "./golioth"

async function listDevices() {
    const devices = await golioth.devices.devicesList();

    devices.list?.forEach(device => {
        console.log(`- ${device.id}: ${device.name}`);
    })
}

listDevices().catch(console.error);

• The method names come directly from the OpenAPI spec
• Response objects are fully typed
• TypeScript helps you discover fields without checking the docs This is also where the hooks in the configuration come in to make life a little easier for us! All Golioth APIs are prefixed with a project ID (and occasionally, an organization ID), and the hooks we added let us skip these parameters in the function call.

Summary

In just a few steps, we:

• Created a TypeScript Node.js project
• Generated strongly typed API bindings from Golioth’s OpenAPI definition
• Secured our API key using environment variables
• Made our first request to the Golioth Management API If you’re building a backend service and want a 

type-safe, low-friction way to integrate with Golioth, we think this is the fastest way to get started. Happy building!

What is Git Bisect?

Git bisect is a command built into git that pinpoints the commit at which a breaking change was introduced. Basically, you tell Git where the last time the code was working is located, where the non-working code is located. Git will then checkout new commits for you to label good or bad. Just run your test, label the commit, and git does the rest. The astute reader will recognize this as a binary search. You take all of the commits and test one in the middle. Depending on whether that test succeeds or fails you eliminate half of the commits before or after and then start the process again on the smaller set.

Difference When Using Git Bisect with Zephyr

Git bisect is nearly a perfect troubleshooting tool for Zephyr. The maintainers of the project are strict about requiring clean and granular commits, in order to improve consistency during the review process. As a result, every commit should build and run. Ideally you’ll have very few cases where you get a false positive while bisecting. However, the manifest system that Zephyr is based upon means you need to take a few extra steps while bisecting. That’s because git will change the Zephyr hash, but it will not run a west update to ensure all the modules match the current hash of Zephyr. Let’s jump in and look at a few approaches that you can use.

Your Project Setup Matters

This article came to mind when I worked on updating which version of Zephyr the Golioth Firmware SDK uses. Our SDK includes Zephyr as a module, which means we have our own west.yml (actually west-zephyr.yml) that includes a hash (revision) to lock Zephyr to a specific version.

manifest:
  projects:
    - name: zephyr
      revision: v4.3.0
      url: https://github.com/zephyrproject-rtos/zephyr
      west-commands: scripts/west-commands.yml
      import: true

  self:
    path: modules/lib/golioth-firmware-sdk

This is a great approach to use with your own projects, as it ensures you always know which version of Zephyr (and its inherited modules) was used for any given commit in your project. But, when using git bisect on the Zephyr tree of this project, you can’t run west update because it will just check out the revision stored in this file. You can take two approaches to overcome this situation:

1. Manually change the number in your manifest file to match each hash selected by git bisect
   • This is prone to user error if you forget to change the hash or make a mistake when updating.
   • It doesn’t require any other changes to your project.
   • This approach is used in the walkthrough below.
2. Change your project to use the west manifest in the Zephyr tree
   • Add any additional configuration for your project into a manifest that you place in Zephyr’s submanifests/ folder. This can be complicated if your project manifest is rather involved.
   • The manual work of changing your project manifest file for each git bisect step is no longer needed. Today we’re going to stick to the manual version. Let’s dive in!

Walkthrough: Git Bisect with Zephyr

For today’s walkthrough, let’s assume you have the v0.21.1 of the Golioth Firmware SDK set up as a manifest repository by following the directions in the README. The west manifest for this project is located in your_workspace_folder/modules/lib/golioth-firmware-sdk/west-zephyr.yml and the Zephyr tree is found in your_workspace_folder/zephyr.

Start the Bisect

We’re going to find where the Twister tests for the SDK broke between Zephyr v4.2.1 and Zephyr v4.3.0 so we open a terminal in the Zephyr tree to conduct the bisect:

$ git bisect start
status: waiting for both good and bad commits

$ git bisect good
status: waiting for bad commit, 1 good commit known

$ git bisect bad v4.3.0
Bisecting: a merge base must be tested
[413b789deb391d3a37d06b463288a5fe765ee57e] release: Zephyr v4.2.0

git bisect start, and you may abort this process at any time by running git bisect reset. We then constrain the bisect process by labeling a good commit with git bisect good (using the hash of currently checked out commit) and a bad commit with git bisect bad v4.3.0 (here we use a tag but you can also use a hash). Now that we’ve labelled both good and bad commits, git picks out the next commit to test. Our case is a special one: git moved to an earlier commit which was just some internal git housekeeping.

Test the Commit, but Update Modules First!

Here’s where the special step for Zephyr comes in. We need to update the Zephyr modules. If you’re bisecting a project that uses the west manifest inside the Zephyr tree ( zephyr/west.yml), you can update modules directly. But I need to manually update the Zephyr hash in my project manifest file.

# Find the hash of this commit
$ git rev-parse HEAD
413b789deb391d3a37d06b463288a5fe765ee57e

# Update ../modules/lib/golioth-firmware-sdk/west-zephyr.yml with the above commit for Zephyr

# Update Zephyr modules
west update

# Test this commit (change this for your use case!!)
$ scripts/twister --platform frdm_rw612 -T ../modules/lib/golioth-firmware-sdk/examples/zephyr/logging --prep-artifacts-for-testing
$ if test -e twister-out/frdm_rw612_rw612/zephyr/sample.golioth.logging/zephyr/zephyr.hex; echo "PASS"; else echo "FAIL"; end
PASS

update the Zephyr revision in the west manifest file for the project. With that updated, we run west update, which will not change the Zephyr tree, but it will/may change what version of modules are checkout out in modules/lib, etc. The test step is going to be different every time you bisect. In my case, I know that Twister tests place the compiled files in a different directory than our CI is expecting. So I’m just using a fish shell one-liner to test if the hex file is where I expect. In this case the first test passed!

Mark the Commit Good or Bad to Continue the Bisect

Based on the results of the test from the previous section, mark the commit as good or bad and Git will continue the bisect process.

$ git bisect good
Bisecting: 3871 revisions left to test after this (roughly 12 steps)
[3a6ae2b01c9babd8be320a6912123de53ebba748] driver: sdhc: add sdmmc for sama7g5

$ git bisect bad
Bisecting: 1933 revisions left to test after this (roughly 11 steps)
[56a527321ed977338d6ca4f0892114f988bf845a] include: drivers: input: enhance Doxygen documentation for CY8CMBR3xxx

Finishing the Bisect

When you get through all the bisect steps, git should tell you which commit is the first one with a breaking change.

$ git bisect good
9219c81b66f48523f0cd3b7b7cac8cf3dadb84b2 is the first bad commit
commit 9219c81b66f48523f0cd3b7b7cac8cf3dadb84b2
Author: Anas Nashif 
Date:   Fri Jul 11 11:36:03 2025 -0400

    twister: make no-detailed-test-id default

    Make this option default and reduce amount of details displayed by
    twister.
    This options has been enabled in CI for a while now with the intention
    of making it default.

    Signed-off-by: Anas Nashif 

 .github/workflows/clang.yaml                    | 2 +-
 .github/workflows/twister.yaml                  | 6 +++---
 .github/workflows/twister_tests_blackbox.yml    | 8 ++++----
 scripts/ci/test_plan.py                         | 4 ++--
 scripts/pylib/twister/twisterlib/environment.py | 4 ++--
 scripts/tests/twister/conftest.py               | 1 +
 6 files changed, 13 insertions(+), 12 deletions(-)

here is the smoking gun! As you can tell from the excellent commit message, one of the Twister default values was changed. By looking at the code changes in this commit, I was able to discover that all of our tests now need to specify the --detailed-test-id flag. All that’s left now is to return our Zephyr repository to normal functionality by resetting the bisect.

$ git bisect reset
Previous HEAD position was b68058787e9 counter: cmsdk_apb_dualtimer: Use clock freq from DT clocks
HEAD is now at 64e98eb5278 release: Zephyr v4.2.1

A Strong Incentive for Disciplined Commits

This is a great argument for using strict discipline in your git repositories. Ensure that no commit breaks the build, that commits are granular, and commit messages are verbose. If you’re successful at this, then git bisect will someday help you pinpoint problems and deliver useful information in the process.

Bonus: Automation Using Git Bisect Run

I asked for feedback from the Golioth engineering team before I started writing this, to see if there were any tips on using bisect. Marcin Niestroj is the one who suggested using the Zephyr submanifests mentioned earlier in this post. Sam Friedman suggested using git bisect run which was also new to me. Certainly if you take the time to write a short script the run command is pretty powerful. I was able to pinpoint the breaking change by running just four commands:

$ git bisect start
$ git bisect good
$ git bisect bad v4.3.0
$ git bisect run bash bisect_test.sh

#!/bin/bash

# Get the hash
this_hash=$(git rev-parse HEAD)

# Write hash to project manifest for Zephyr revision number
sed -i "4s/.*/      revision: ${this_hash}/" ../modules/lib/golioth-firmware-sdk/west-zephyr.yml

# Update the modules
west update

# Build the twister test
scripts/twister --platform frdm_rw612 -T ../modules/lib/golioth-firmware-sdk/examples/zephyr/logging --prep-artifacts-for-testing

# Test to see if build worked
if [[ -f "twister-out/frdm_rw612_rw612/zephyr/sample.golioth.logging/zephyr/zephyr.hex" ]]; then
    exit 0
else
    exit 1
fi

sed command which replaces line 4 of the manifest file. The rest is the same commands we ran manually, with the exception that we exit with an error code instead of echoing out a PASS/FAIL. This is slick if you take the time to set up your test!

The Origins of the MePaper

The MePaper project started in 2022, also around the holidays. While we continue to support our customers with deployed IoT devices 24/7, the working world seems to slow a bit towards the end of the year. We focus on personal development projects and planning as we move towards a new year. But we also continue to hack and try out new things in hardware and firmware. Mike noticed that we had this great platform in the Adafruit MagTag, a development board that is standard-issue for employees at the company. We had previously used it for in-person and remote training for Zephyr, but hey, how about that ePaper screen on the front?? The board features an ESP32-S2 module, a 2.96-inch ePaper display, an accelerometer, a speaker, and four physical buttons. Because the display is ePaper, the image remains visible even when the device is not actively drawing power, making it an ideal “passive” desk accessory. The original version of MePaper was a side project that relied on a Slack bot. While it worked, the process of sending a meme was difficult. Users had to manually edit images in software like GIMP to ensure they were the correct size, rotated 90 degrees, and converted to a 1-bit black-and-white format. These files were then hosted on Google Drive and distributed via a complex set of commands.

Modernizing the Software and Hardware

To make the system more usable for coworkers, the project was rebooted during a company hack day into version 2.0. This involved a significant overhaul of the firmware and the user interface for creating and distributing images. But Dylan and Mike wanted to continue to increase usage of platform features. The firmware was updated from an older version of the Golioth Firmware SDK to a modern release (0.5.0 -> 0.21.0). This required moving to newer peripheral drivers provided by the ESP-IDF framework. One of the primary technical hurdles was memory management. The on-chip SRAM of the ESP32-S2 was not large enough to hold the framebuffer for the images. To solve this, Mike utilized the 2MB of external SPI PSRAM available on the MagTag board/ESP32 module, allowing for smooth image processing and display updates. The re-written hardware drivers control things like the screen (of course), the buttons, the buzzer, the LEDs. The USB interface, including the serial terminal out of the device, is all captured within the ESP32-S2 module. For the image format, the project continues to use the Portable Bit Map (PBM) specification. This is a 1-bit color depth format that maps perfectly to the requirements of the ePaper display’s byte-ordering. By using this format, the firmware can simply download the file, strip the simple header, and pipe the data directly to the screen without needing complex decoding libraries.

Building the Vibe-Coded Web Application

The most visible change in version 2.0 is the introduction of a professional-looking web application. This interface was built using “vibe-coding” techniques, where AI agents and large language models were used to generate the front-end code and back-end image databases. This allowed the team to create a sophisticated meme builder without the overhead of manual traditional coding. Compared to 2023, this is much improved. The new web app eliminates the need for external photo editors. Users can simply upload any image file, and the app provides tools to zoom, reposition, and add custom text to the top or bottom of the meme. Once the user is happy with the preview, they click a button to “beam” the meme to the fleet. The application handles the technical conversion into the PBM format automatically, ensuring the image looks correct on the low-resolution ePaper screen.

Leveraging Global IoT Infrastructure

MePaper 2.0 is more than just a toy; it is a demonstration of how enterprise IoT features can be used for creative applications. The project utilizes several core platform features:

• REST API – The web app uses the Golioth management REST API to upload completed meme files as artifacts from the web backend built for creating/viewing memes
• Device Settings – To avoid the inefficiency of using the full firmware update system for every image, the team uses device settings. This allows them to push specific image versions to the entire fleet or target specific individuals and groups.
• Asset storage – In addition to firmware images that are delivered to the fleet of devices as Over-The-Air firmware updates, the formatted images (in PBM format) are stored as assets on the Golioth platform and then referenced with settings, mentioned above.
• Golioth Pipelines – The four buttons on the MagTag were turned into a gamified voting system. When a user receives a meme, they can press a button to rate it. This sends an integer through a pipeline to a real-time leaderboard on the web gallery, fostering a sense of competition among the “memers” in the company.

Seamless Setup and Security

Security is important at Golioth. But traditionally (and not just at Golioth), the most secure methods didn’t translate to IoT very well due to overhead and processing power. So we put improved Golioth workflows around certificates and some existing Espressif tooling to improve the process. Dylan leaned on esptool-js, which allows communication to the device using Web Serial. The vibe coded front-end interacts directly with the device and prompts the user for all the steps they need to get the device online. First there is an erase cycle for the device’s flash memory. Then an installation initiates using a standard device firmware image and a device certificate that is provisioned for each user. Since it’s a closed system only available to Golioth employees, we provision a device certificate onto the same project and pair it up with the latest firmware at a memory offset (the cert is stored in a LittleFS partition). Once that bundle of device firmware and certificate is installed into the device, the user can directly configure Wi-Fi credentials without ever opening a terminal or a command-line tool. This ensures that the “Internet of Memes” remains secure while remaining easy for non-technical staff to deploy.

Dogfooding Golioth features, even during the holidays

Sometimes the best way to check in on a platform that we have been building for 5 years is to put it to the test; we created a facsimile of a connected product that our customers might build (with some obvious silly vibes mixed in). MePaper 2.0 represents the company’s commitment to “ Demo Culture“. That is, the idea of testing products in real-world scenarios to identify pain points, find creative solutions, and share with coworkers. By turning the MagTag into a dedicated social terminal, the team has created a way to share joy and maintain a cohesive culture in a fully remote environment. It serves as a reminder that even the most advanced IoT infrastructure can be used to build something as simple and human as a shared laugh.

Certificate Rotation We’ve long advocated for the use of certificates and public key infrastructure (PKI) to secure and identify devices. Compared to pre-shared keys (PSKs), the other form of authentication supported by Golioth, PKI provides advantages in scale and security by removing the need to explicitly create and store secrets in Golioth. But PKI comes with additional operational challenges compared to PSKs, which can be especially difficult in an embedded context. Chief among those is the need to periodically rotate certificates on devices in the field. Earlier this week, we

announced support for external PKI providers to make certificate rotation easier than ever. In this release of the Golioth Firmware SDK, we’ve added a new service that allows devices to upload a certificate signing request (CSR) to Golioth, where we’ll forward it on to your PKI provider and then send down the resulting signed certificate back to the device. There’s a new example in the SDK that shows how it all works. In this example, we take an existing key stored in the filesystem and create a CSR in standard x.509 format using mbedTLS, but the SDK is agnostic to how keys and CSRs are created and stored. For example, you could generate a new key-pair in a secure element on the device, exporting only the CSR while the private key remains in secure storage. We’ll have more to share on secure elements in the new year.

Logs Through Pipelines Traditionally, the Golioth Firmware SDK has delivered device logs emitted by customer firmware directly to the

Golioth Logs service. With this release, logs are now delivered to Golioth Pipelines by default, allowing users to transform and route logs to the destination of their choice, including the Golioth Logs service. The interaction with the logging service in the SDK is unchanged – either using the GLTH_LOGx macros or plugging into the platform’s logging subsystem. To preserve logging functionality for existing projects, users will need to either enable CONFIG_GOLIOTH_LOG_LEGACY in the SDK configuration, or add a pipeline to route logs to the destination of their choice, such as this one that sends logs to the Golioth Logs service:

filter:
  path: "/logs"
  content_type: application/cbor
steps:
  - name: step-0
    transformer:
      type: cbor-to-json
      version: v1
    destination:
      type: logs
      version: v1

here.

Firmware Update Reference Golioth OTA makes it easy to send the right artifacts to devices in the field. Once the artifacts get there, the device will need to do

something with them, but what exactly is heavily dependent on the specific application running on that device. The SDK has long included a reference firmware update implementation that looks for updates to a single firmware image, and downloads and applies the update using the platform’s default storage partitions and bootloader. For many users, this is all the functionality they need and they can use this implementation as is. Users with more complex application structures, such as AI models, multiple MCUs or graphical assets, can build their own update mechanism leveraging the Golioth OTA service. To better reflect the reference nature of the firmware update implementation in the SDK, we’ve moved it out of the core SDK and into the samples. This change also allows us to remove abstractions in the reference implementation and instead use platform-specific API calls, making the sample more useful as a instructional tool.

The Old Way Traditionally, the Golioth Firmware SDK has delivered device logs emitted by customer firmware to the

Golioth Logs service. Developers do not need to directly interact with the service API, but rather use C macros, such as GLTH_LOGI, to emit messages at their desired log level. When using a supported RTOS, such as Zephyr, developers can also leverage the SDK’s logging subsystem integration to deliver log messages from libraries and drivers to the Golioth platform. Behind the scenes, the Golioth Firmware SDK structures and encodes the log messages in a format that is compatible with the Golioth Logs service. It then buffers and sends the logs to the /logs endpoint of the Golioth device API. After the logs are delivered to Golioth, customers can query messages at the device and project level, filtering by metadata and time buckets.

The New Way Since introducing Golioth Pipelines in

May 2024, we have seen a wide range of customer product use cases be unlocked by the flexibility of the Golioth platform. The ability to easily send data in any format to any destination means that customers can easily integrate with existing cloud systems, drive down bandwidth costs using compact data encoding schemes, and preserve battery life by batching data payloads and delivering as bulk uploads. While many customers enjoy using Golioth’s internal data destinations, such as LightDB Stream for timeseries data and LightDB State for device status, we have always focused on solving the difficult problem of getting data to the cloud, then letting you use the best tool for the job. In order to bring this same level of freedom to device logs, the latest version of the Golioth Firmware SDK updates the log processing functionality to route messages to Golioth Pipelines. We have introduced a new Golioth Logs data destination, which handles incoming logs on Pipelines. To replicate the previous functionality, customers can create the following Pipeline in their Golioth project to convert the CBOR encoded log messages to JSON then deliver them to the internal logs service. These logs are then viewable on the console or via the management API.

filter:
  path: "/logs"
  content_type: application/cbor
steps:
  - name: step-0
    transformer:
      type: cbor-to-json
      version: v1
    destination:
      type: logs
      version: v1

path used for logs delivery can be changed using CONFIG_GOLIOTH_LOG_PIPELINES_PATH and customers who wish to upgrade to v0.22.0 of the Golioth Firmware SDK while preserving the previous behavior can set CONFIG_GOLIOTH_LOG_LEGACY=y. With device logs flowing through Pipelines, messages can be transformed and routed to any of the existing data destinations, such as InfluxDB, and we’ll be introducing new destinations for more external logging services, as well as standardized vendor-neutral protocols, such as OpenTelemetry’s OTLP, in the coming weeks.

Getting Started To get started, add a Pipeline to your existing Golioth project, or

create a new project on Golioth (a logs Pipeline will be automatically created for you), then check out any of the example applications in the Golioth Firmware SDK. If you are interested in support for a specific logging service, let us know by creating a post on the Golioth Forum.

Why Certificate Rotation Matters

Golioth supports two device authentication methods: Pre-Shared Keys (PSKs) and X.509 certificates. While PSKs can be appropriate for early development and constrained use cases, short-lived certificates are the recommended approach for production deployments. The reason is simple: PSKs are static secrets. If a PSK is ever extracted from a device, leaked from a manufacturing system, or reused across devices, there is no clean way to limit the blast radius without manually replacing credentials, which often requires physical access to devices already in the field. Short-lived certificates dramatically reduce this risk:

• Compromise is time-bounded: Even if a certificate is exposed, it automatically expires.
• No shared secrets: The device’s private key never leaves its secure hardware module.
• Routine rotation becomes normal rather than exceptional.
• Revocation and recovery are built into the model. In other words, certificate rotation shifts security from a “hope it never leaks” posture to a “assume compromise and limit impact” strategy, which is the foundation of modern, large-scale IoT security.

Until now, many teams stuck with PSKs not because they were more secure, but because certificate rotation was operationally hard. With Golioth’s new hosted PKI integration, that trade-off disappears.

What’s New: Hosted PKI Integration

From today, Golioth supports integration with external, hosted PKI providers, allowing Golioth to maintain an automatically updated list of Certificate Authority certificates for your project. The integration also supports issuing device certificates through Golioth’s device API, enabling seamless certificate rotation for your devices in the field. For the initial launch, Golioth integrates with

AWS Private CA, a fully managed certificate authority service from AWS. We have designed the external PKI integration to be extensible, and we plan to add support for other hosted PKI providers in the near future.

How It Works

At a high level, the certificate rotation workflow looks like this:

1. A device running the Golioth Firmware SDK initiates a certificate rotation request.
2. Golioth securely brokers the request to the configured external PKI provider.
3. A new device certificate is issued by the external PKI provider (e.g. AWS Private CA)
4. Golioth sends the new certificate to the device, which can install and start using it without any downtime. All of this happens using Golioth’s existing infrastructure, allowing certificate rotation to happen securely, without the need for glue code, custom services, or bespoke provisioning pipelines.

What’s Next?

While AWS Private CA is the first supported provider, we plan to add support for other hosted PKI providers in the near future. We will also be partnering with silicon vendors to offer secure provisioning services. With Golioth’s unified certificate rotation API, you should be able to choose the PKI provider that fits your organization, without changing your device firmware or security model.

Let us know which PKI providers you would like to integrate with to simplify your certificate management!

Get Started Today

If you’re already using Golioth, you can start experimenting with hosted PKI-backed certificate rotation today using the Golioth Firmware SDK and AWS Private CA.

• Read how to set up your integration in our documentation
• Try our Certificate rotation firmware example Security shouldn’t require extra infrastructure or custom code, and with seamless certificate rotation, we believe building a secure products will be a little easier.

Currently available with Golioth Connectivity / Bluetooth

As of December 2025, we have a fully functional system that security transits Bluetooth packets between low power devices up to the Cloud and back again. This includes our streaming data feature (tied to Golioth Pipelines), the Golioth Settings Service, and Over-The-Air Firmware Updates. This allows our users to create fully featured demos and products, and many are already moving towards productization.

Chip support

Our current implementation is built on top of Zephyr and their popular Bluetooth support throughout the industry. That means we support a wide range of vendors, almost with no customization needed between them. We have shown support for many of the Bluetooth chip vendors in Zephyr

• Espressif
• Nordic
• NXP
• Renesas
• SiLabs
• ST Micro This is not all the device types that

_can _utilize Golioth capabilities, but instead are the ones we have tested and continue to test.

Gateway Reference Implementation

In order for indirectly connected devices to talk back to the cloud, they need to transit through a trusted or semi-trusted gateway. We have built a reference implementation that does just that, supporting different connectivity methods to target price points and application spaces that match our customers’ needs. We offer precompiled binaries for our reference implementation for the following boards

• NXP’s FRDM-RW612 Ethernet/Wifi dev board (~$30)
• Nordic Semiconductor’s Thingy 91:x Cellular platform (~$99)
• Nordic Semiconductor’s nRF9160-DK Cellular dev board (~$129)
• Ezurio’s Sentrius MG100 Cellular product (~$150)

Secure by default

As in any Golioth endeavor, security is a first concern, not something left until the end of the development cycle. End-to-end encryption support is default and neither the gateway nor a bad actor with an SDR can peer in on the packets transiting through to the Cloud. We’ve always required that traffic going to Golioth is encrypted, but the new requirement is that any device using Pouch must also utilize certificates (instead of PSKs). Using certificates ensures that Golioth is never in possession of private key material for the device, and supports provisioning fleets at scale. Certs are easier than ever on our platform, including a new client side tool to generate temporary device certs. We have also been doing education around how certs work. Future education will be around the private key never leaving the device, yet still having accessible sane platforms for manufacturing devices (since that’s the goal for all of us)

Over-The-Air (OTA) firmware update works out of the box

By far one of our most popular features, we made sure firmware update is baked in for our standard BLE_GATT demo in the Pouch repository. You can see it working in this video. For a more in-depth look, you can also see how we utilized the LED display on our demo board to showcase OTA working. The main takeaway is that your Bluetooth updates are already working as soon as you choose to use Golioth Connectivity.

Ready-made examples

In addition to the demos above, we have new Reference Designs that highlight real-world use cases. Our  Digital Signage design shows how you can talk to smaller Bluetooth devices from a gateway and send out live commands to reconfigure devices in the field, especially over a short area. For people looking to use a single Bluetooth device with multiple gateways, we also show how we can roam between gateways, a key feature in asset tracking. In the future we expect to see more demos revolving around asset tracking and mobile app + gateway combinations. Pouch already supports large payload upload/download, so you could reasonably expect to see more AI/ML examples coming down the pipe too.

Pattern matching for your next Bluetooth project

We’ve been thinking about how our customers start up new Bluetooth projects or look to update existing projects. Sure, we want to make sure we serve the broadest Bluetooth market, but we also want to make sure we are covering use cases our customers are encountering on a daily basis. As mentioned above, we are thinking more about the mobile app in relation to Bluetooth and Cloud capable devices. G olioth Connectivity can live alongside other GATT profiles and enables cloud capabilities without another full cycle of development. Basically, “Add cloud management and reporting to your Bluetooth device”. This includes adding OTA to any Bluetooth product, which is unfortunately an afterthought in many product design cycles. If you’re not already discussing compliance with the EU’s new Cyber Resilience Act (CRA), you might want to start. Our platform helps to satisfy many of the requirements for the 2027 due dates. Overall, Golioth cuts down on development requirements for Bluetooth applications. Fewer app developers are required to stand up a prototype, and the communication between app and device is clearer with Golioth Connectivity. Whether you’re a hardware/firmware team looking to do less on the app/cloud side or you’re a cloud team looking to quickly enable Bluetooth applications with remote control and secure updates, we have something for everyone. 

What’s coming in 2026

We already have changes in our internal testing setup and we are validating them in an on-going basis. Here are some of the high level changes you can expect in the new year:

• Performance improvements – A new transport protocol between devices and gateways, resulting in significant increases in transfer speeds without adjusting Bluetooth radio parameters that impact power.
• Better customization – Pouch has a specific way of advertising and syncing, but future improvements will allow choosing which devices to sync, when to sync them, and when to disconnect from them. This will drive better bandwidth utilization for large networks and more efficient operations.
• Gateways everywhere – Pouch protocol and the ability to shuttle packets up to the Cloud already is working on the embedded hardware listed above. This code can also be shrunk down to fit in other form factors than standalone gateways. We’ll show how to put gateway functionality into more devices, for better connectivity of all devices.
• More hardware – As more chip vendors join the Zephyr ecosystem, our hardware choices become more bountiful. We will continue testing for different hardware options and sharing about any required changes to the underlying firmware to make it work with Golioth.
• Improved transport-level security – We already offer/require end-to-end encryption from the device to the cloud. In the new year, we’ll also enable Bluetooth pairing to encrypt and optionally authenticate communication between devices and gateways. Security is a first principle at Golioth. Imagine: these are just the things we’re willing to tell you about! Many more are planned for the new year and are already in early-concept phases. If you have any suggestions, drop them on

the Golioth Forums or let our devrel team know if you need any help getting started today.

Sensor Readings and Concurrency

The generic “sensor reading” term is a bit sloppy. What we’re actually talking about here is a bus with one or more devices connected to it. We want to make sure that there aren’t multiple threads trying to access the bus at the same time. For the purposes of this example, we’re going to set up a custom work queue to take sensor readings for a sensor connected via i2c. With this approach we can create a different instance of work for each device on the bus and the queue will ensure that they are read in the order each request is received. The queue will be the only thing accessing this bus. Zephyr has a built-in work queue enabled by default called the system work queue. This runs on the main system thread. Since we’re using blocking sensor reads when calling the fetch command, it’s a good idea to separate these calls from the main thread so we’ll stand up our own custom work queue.

A Work Queue to Take Sensor Readings

When renewing your license you wait in line at the Department of Motor Vehicles (DMV). The work queue functions in the same way. However, what we’re doing under the hood is creating a new thread whose sole purpose is to service a work item until the queue is empty. We’re creating the DMV itself (the work queue) and the people in line (the work). When creating a thread, we need a stack to handle memory and we need to assign a priority to the thread so the scheduler knows how important our work is. In order to use the queue, we need to have work items that tell the queue which functions to run when processing a queue item.

const struct device *const temp_sensor = DEVICE_DT_GET(DT_ALIAS(ambient_temp0));

#define SENSOR_WORKQ_STACK_SIZE 512
#define SENSOR_WORKQ_PRIO 5
struct k_work_q sensor_workq;
struct k_work sensor_work;

K_THREAD_STACK_DEFINE(sensor_workq_stack, SENSOR_WORKQ_STACK_SIZE);

static void sensor_work_handler(struct k_work *work) {
    int err = 0;

    err = sensor_sample_fetch(temp_sensor);
    if (0 != err) {
        LOG_ERR("Failed to fetch sensor reading: %d", err);
        return;
    }


    struct sensor_value temperature;
    err = sensor_channel_get(temp_sensor, SENSOR_CHAN_AMBIENT_TEMP, &temperature);
    if (0 != err) {
        LOG_ERR("Failed to get sensor value: %d", err);
        return;
    }

    LOG_INF("Temperature reading: %d.%06d", temperature.val1, abs(temperature.val2));
}

void sensor_init(void) {
    k_work_queue_init(&sensor_workq);
    k_work_queue_start(&sensor_workq,
                       sensor_workq_stack,
                       K_THREAD_STACK_SIZEOF(sensor_workq_stack),
                       SENSOR_WORKQ_PRIO,
                       NULL);
    k_work_init(&sensor_work, sensor_work_handler);
}

• Values for the work queue stack size and priority
• A struct for the work queue itself, and a struct for the work we will submit to it
• A macro to allocate the stack memory
• The work handler function that will be called when the work item is processed
• An initialization function to init/start the queue and init the work This is the meat and potatoes of the operation, and most of our job is already done. The

sensor_work_handler() uses a familiar pattern to fetch the sensor value from the hardware, and then read the value out of the sensor_value struct where it was stored. To use the new work queue, we run the initialization function and then we can begin submitting work.

sensor_init();

while (true)
{
    k_work_submit_to_queue(&sensor_workq, &sensor_work);
    k_msleep(5000);
}

k_work_submit() we’re calling k_work_submit_to_queue(). This allows us to specify which work queue the work should be sent to. Note that we declared our work item globally. If it’s already in the queue and we try to submit it again, nothing will happen. If you need to submit the same work multiple times you need to initialize multiple instances, each with their own pointers. There are also specialized approaches for rescheduling and delaying work items. For a guided tour of those topics, check out Chris Gammell’s post on Send-when-idle using Zephyr and Golioth Pouch. When we build and run the code we can see that it outputs temperature readings on a regular cadence.

[01:05:31.971,657]  hello_zephyr: Temperature reading: 24.750000
[01:05:36.971,771]  hello_zephyr: Temperature reading: 24.812500
[01:05:41.971,855]  hello_zephyr: Temperature reading: 24.875000
[01:05:46.971,960]  hello_zephyr: Temperature reading: 24.937500
[01:05:51.972,050]  hello_zephyr: Temperature reading: 24.875000
[01:05:56.972,149]  hello_zephyr: Temperature reading: 24.937500

kernel thread stacks command. Keep reading to see the output of that command.

Adding a Stack Name for Better Logs and Debugging

0x10045870                                  (real size  512):   unused   96     usage  416 /  512 (81 %)
0x1005a0d8 coap_client                      (real size 6144):   unused 4312     usage 1832 / 6144 (29 %)
0x100468c0 net_socket_service               (real size 1200):   unused  728     usage  472 / 1200 (39 %)
0x10046b58 rx_q[0]                          (real size 1792):   unused 1040     usage  752 / 1792 (41 %)
0x10046a68 net_mgmt                         (real size  800):   unused  552     usage  248 /  800 (31 %)
0x10045e40 shell_uart                       (real size 2048):   unused  888     usage 1160 / 2048 (56 %)
0x100470c8 sysworkq                         (real size 1024):   unused  496     usage  528 / 1024 (51 %)
0x10046d48 ENET_RX                          (real size 1600):   unused 1200     usage  400 / 1600 (25 %)
0x10045948 logging                          (real size 1536):   unused  664     usage  872 / 1536 (56 %)
0x10046e80 idle                             (real size  320):   unused  256     usage   64 /  320 (20 %)
0x10046f38 main                             (real size 4096):   unused 3264     usage  832 / 4096 (20 %)
0x100539a8 IRQ 00                           (real size 2048):   unused 1832     usage  216 / 2048 (10 %)

kernel thread stacks output. First, our thread doesn’t name its stack so we have to deduce that the top line without a name is the memory usage for our sensor work queue. The second is that 81% of that stack is used, which makes me feel just a bit claustrophobic. In this example we only have one instance of work that is being submitted to the queue, so our stack usage is not going to grow beyond what is shown after the work has run at least once. If there were other types of work, or if you have work handlers that use a variable amount of stack space, it’s important to do some testing to ensure you have enough head room to avoid an overflow.

void sensor_init(void) {
    k_work_queue_init(&sensor_workq);

    struct k_work_queue_config sensor_workq_stack_config = {.name = "sensor_workq"};
    k_work_queue_start(&sensor_workq,
                       sensor_workq_stack,
                       K_THREAD_STACK_SIZEOF(sensor_workq_stack),
                       SENSOR_WORKQ_PRIO,
                       &sensor_workq_stack_config);
    k_work_init(&sensor_work, sensor_work_handler);
}

k_work_queue_config struct with the name member set. Once recompiled you can view the stacks with our brand new name showing proudly.

0x10045870 sensor_workq                     (real size  512):   unused   96     usage  416 /  512 (81 %)
0x1005a0d8 coap_client                      (real size 6144):   unused 4312     usage 1832 / 6144 (29 %)
0x100468c0 net_socket_service               (real size 1200):   unused  728     usage  472 / 1200 (39 %)
0x10046b58 rx_q[0]                          (real size 1792):   unused 1040     usage  752 / 1792 (41 %)
0x10046a68 net_mgmt                         (real size  800):   unused  552     usage  248 /  800 (31 %)
0x10045e40 shell_uart                       (real size 2048):   unused  888     usage 1160 / 2048 (56 %)
0x100470c8 sysworkq                         (real size 1024):   unused  496     usage  528 / 1024 (51 %)
0x10046d48 ENET_RX                          (real size 1600):   unused 1200     usage  400 / 1600 (25 %)
0x10045948 logging                          (real size 1536):   unused  664     usage  872 / 1536 (56 %)
0x10046e80 idle                             (real size  320):   unused  256     usage   64 /  320 (20 %)
0x10046f38 main                             (real size 4096):   unused 3264     usage  832 / 4096 (20 %)
0x100539a8 IRQ 00                           (real size 2048):   unused 1832     usage  216 / 2048 (10 %)

[00:04:12.155,700]  os: ***** USAGE FAULT *****
[00:04:12.155,717]  os:   Stack overflow (context area not valid)
[00:04:12.155,744]  os: r0/a1:  0x18026768  r1/a2:  0x61000000  r2/a3:  0xaaaaaaaa
[00:04:12.155,750]  os: r3/a4:  0x00000002 r12/ip:  0xaaaaaaaa r14/lr:  0xaaaaaaaa
[00:04:12.155,754]  os:  xpsr:  0xaaaaaa00
[00:04:12.155,781]  os: Faulting instruction address (r15/pc): 0xaaaaaaaa
[00:04:12.155,812]  os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
[00:04:12.155,840]  os: Current thread: 0x10045870 (sensor_workq)
[00:04:12.290,057]  os: Halting system

sensor_workq overflowed. If we hadn’t added the name, unknown would have been shown at the end of the Current thread log output.

Go Beyond Logging

It’s easy to envision a system that:

1. Takes readings on a regular cadence
2. Takes additional readings based on stimulus like motion or a threshold-based trigger
3. Takes additional readings on demand (from a button or network-based request) The work queue is essential for coordinating between different threads (or hardware interrupts) from which these triggers arise. However, simply logging the data is not very useful. There are two very handy approaches to recording those readings that are a natural follow to today’s demonstration. The first is

using Zephyr message queues to cache sensor readings and sending them to the cloud as batch data. The second is using Zephyr’s ZBUS system to publish each reading to other processes listening/observing in the system. Stay tuned for more feature highlights from Zephyr and Golioth applications that put them to work.

Sending data when the device is idle

Most of the demos I have been working on for the past few months are based on the Pouch SDK, which enables Bluetooth-to-Cloud bidirectional data flow via Golioth Connectivity. The BLE-GATT demo in the Pouch SDK repository is my starting point for most of the things I am building. Out of the gate, I get data uplink (sending time series data up to Golioth), settings downlink (configuration data synced to each device), and Over-The-Air firmware updates. I also get to roam between different gateways thanks to how Pouch is architected. I have also been working on waking on movement using the LIS2DH12 accelerometer on the Tikk board. When we wake up the board, I want to take a reading and quickly go back to sleep. That’s relatively straightforward. But when should we send that data up to the cloud? Immediately? On a set schedule? For the asset tracking applications I am targeting, I see a couple of themes:

• Efficient battery operation
• Low number of overall events
• Large time gaps between events (irregular intervals)
• Small data payloads I think it makes the most sense for my battery and for data bandwidth to send data when the devices are no longer moving.

Design patterns for send-when-idle

This situation could be a good use case for an event-driven state machine, which you can build using built-in Zephyr features. The State Machine Framework (SMF) gives you all the tools you need to build a state machine that covers a variety of scenarios. But given how this sample requires relatively few states, a state machine is likely overkill. Instead, I will lean on the idea of “delayable work” (insert joke here about me procrastinating writing this article). These are part of the Workqueue feature of Zephyr that we have written about before. I think about them as “thread-like behavior without all the dedicated memory”. Honestly the setup of a thread is pretty easy in Zephyr, but workqueues make it even easier.

Using k_work_schedule to schedule Bluetooth syncs Pouch initiates a connection to the cloud by advertising to the gateway that there is data available, at which point a connection starts. Normally in our sample,

the device starts out requesting a sync on a delay before going into the main loop. When a Pouch session has ended, we schedule it again for another 20 seconds later:

static void pouch_event_handler(enum pouch_event event, void *ctx)
{
    if (POUCH_EVENT_SESSION_START == event)
    {
        pouch_uplink_entry_write(".s/sensor",
                                 POUCH_CONTENT_TYPE_JSON,
                                 "{\"temp\":22}",
                                 sizeof("{\"temp\":22}") - 1,
                                 K_FOREVER);

        golioth_sync_to_cloud();
    }

    if (POUCH_EVENT_SESSION_END == event)
    {
        service_data.data.flags &= ~POUCH_GATT_ADV_FLAG_SYNC_REQUEST;
        bt_le_adv_update_data(ad, ARRAY_SIZE(ad), NULL, 0);
        k_work_schedule(&sync_request_work, K_SECONDS(20));
    }
}

sync_request_work function is just using the K_WORK_DELAYABLE_DEFINE macro to set up the workqueue type and list the handler. In this case, all it’s doing is setting up advertising for the device (which is, of course, configurable for your specific project).

void sync_request_work_handler(struct k_work *work)
{
    service_data.data.flags |= POUCH_GATT_ADV_FLAG_SYNC_REQUEST;
    bt_le_adv_update_data(ad, ARRAY_SIZE(ad), NULL, 0);
}

K_WORK_DELAYABLE_DEFINE(sync_request_work, sync_request_work_handler);

Waiting for downtime using k_work_reschedule In my case, I want to call that same delayable

sync_request_work function. This time, not on a fixed schedule, but when there is no more data coming in from the accelerometer on my board. If I used k_work_schedule each time the accelerometer fired (in an ISR), it would simply execute however many seconds later I set the design (say 20 seconds like in the sample shown above). But that’s not what I want because I would basically get a single accelerometer reading every 20 seconds, executed in the workqueue. For a large number of events in a small amount of time, I would be waiting forever to get all that data up to the cloud. It would be single readings lined up to be transmitted in 20 second increments into the future. Instead, I want to bundle all the readings. Each time I get a hardware interrupt from the sensor and service the ISR, I instead reset the 20 second timer (or whatever your delay is). I can do this by firing k_work_reschedule instead of k_work_schedule. That “starts the timer over” each time it is called, effectively kicking the proverbial can down the road. It only advertises that data is ready 20 seconds after the last reading. If an accelerometer event happens 21 seconds after the previous reading…no problem! It starts a new 20 second timer and waits for that data to no longer fire.

void lis2dh_int_callback(const struct device *dev, struct gpio_callback *cb, uint32_t pins) {

    wake_event_count++;
    current_time_us = k_uptime_get();
    LOG_DBG("wake = %d, time = %" PRIu64 " ms", wake_event_count, current_time_us);

    k_work_reschedule(&sync_request_work, K_SECONDS(20)); // schedule all events to be sent 10 seconds from now, resets if the event happens again

}

Future work

Already, I can hear the howls about all of the corner cases this presents, such as a hyperactive sensor that is taking tons of readings and never has a chance to synchronize with the cloud and offload its data. The howling is in my head as well! But there are a few things we can do. First, I didn’t even mention how the data is being stored while we wait for a Bluetooth sync to occur. That can take many forms, including a message queue, FIFO, ZBus listener, or just shoving into memory somewhere. That is likely the next blog post in this journey. But wherever we put the data, we need to reliably pull it back out. If I really wanted to stir the pot, I might be so bold to even suggest we offload data to local storage like an SD card (gasp/shock/horror). If we want to set up for a higher data rate scenario, we could also put soft and hard limits on the number of data points that are allowed on the device before we initiate a sync (regardless of motion). Say we get to 100 data points (or some other definable limit) before we actually start advertising. Then the RTOS scheduler would be balancing between handling interrupts from the accelerometer and sending data over Bluetooth. RTOSes are made for such a task! Speaking of definable limits, I also plan to include individual settings that can be configured on each device using Pouch downlink and Golioth Settings service. These can be tweaked on a per project, per Blueprint, or per device basis. But more importantly, the configurability means that I am not trying to tweak the setting on my bench; I can just live update the values for things like:

• Delay after the last datapoint
• Upper limit on the number of datapoints before we advertise to the gateway
• Whether we display activity to the user with LEDs Finally, we will be reconstituting this data cloud-side using

Golioth Pipelines. There are a lot of interesting things we can do to ensure the data looks like any other data coming from a Golioth device. Did we pique your interest? Are you ready to start taking data and send it at a convenient time? Head over to our forum to ask more about Bluetooth and share your next project idea.

Production Versus Testing

Snippets make a lot of sense in a bimodal atmosphere, such as the difference between production and testing. It’s unlikely that your production devices will have logging enabled, and you’ll likely disable the shell as well.

west build -p -b frdm_rw612 examples/zephyr/hello -S shell-logs

-S flag to include a snippet called shell-logs in the build. Let’s look at exactly what makes up this snippet.

Snippet: Common Configuration in a Nice Package

The example above calls a snippet that is made up of this file hierarchy.

snippets
└── shell_log
    ├── shell_log.conf
    └── snippet.yml

snippet.yml file assigns the name of the snippet and adds the shell_log.conf file to the build as an extra config file.

name: shell-log
append:
  EXTRA_CONF_FILE: shell_log.conf

CONFIG_LOG=y
CONFIG_LOG_MAX_LEVEL=4

CONFIG_SHELL=y
CONFIG_SHELL_BACKENDS=y
CONFIG_SHELL_BACKEND_SERIAL=y

using a Zephyr module yaml file to specify where to look for the snippets folder, relative to your project’s root directory.

build:
  settings:
    snippet_root: .

-- -DEXTRA_CONF_FILE=snippets/shell_log/shell_log.conf or by adding the symbols to the prj.conf file. But you can see why including the snippet argument is more convenient and less error-prone While it is not demonstrated in this example, the concept is quite extensible. A Devicetree overlay file may be added alongside, or instead of the Kconfig file by adding EXTRA_DTC_OVERLAY_FILE: your_devicetree.overlay in the snippet file append section. Build flags are another option, and all of the additions presented by the snippet may be gated/conditionally included based on board name and domain (eg: when using sysbuild). In fact, let’s jump into some of the quirks that sysbuild brings and how to deal with them.

Using Snippets with Sysbuild (multi-domain builds)

The same snippet example above can be applied to multi-domain builds like Golioth’s firmware update sample.  The syntax looks very much the same but has some unintended consequences.

west build -p -b frdm_rw612 examples/zephyr/fw_update/ --sysbuild -S shell-log

# mcuboot without shell-log snippet
Memory region         Used Size  Region Size  %age Used
           FLASH:       51996 B       128 KB     39.67%
             RAM:       44096 B       960 KB      4.49%
            SMU1:        510 KB       510 KB    100.00%
            SMU2:        140 KB       140 KB    100.00%
        IDT_LIST:          0 GB        32 KB      0.00%

# mcuboot with shell-log snippet
Memory region         Used Size  Region Size  %age Used
           FLASH:       77608 B       128 KB     59.21%
             RAM:       49424 B       960 KB      5.03%
            SMU1:        510 KB       510 KB    100.00%
            SMU2:        140 KB       140 KB    100.00%
        IDT_LIST:          0 GB        32 KB      0.00%

west build -p -b frdm_rw612 examples/zephyr/fw_update/ --sysbuild -- -Dfw_update_SNIPPET="shell-log"

fw_update, but could also have targeted only the bootloader by using -Dmcuboot_SNIPPET="name-of-your-snippet". During the build, Zephyr will report the conf and overlay files included in the build so you can check for the expected files to confirm the snippet worked.

Parsing /home/mike/golioth-compile/golioth-firmware-sdk/modules/lib/golioth-firmware-sdk/examples/zephyr/fw_update/Kconfig
Loaded configuration '/home/mike/golioth-compile/golioth-firmware-sdk/zephyr/boards/nxp/frdm_rw612/frdm_rw612_defconfig'
Merged configuration '/home/mike/golioth-compile/golioth-firmware-sdk/modules/lib/golioth-firmware-sdk/examples/zephyr/fw_update/prj.conf'
Merged configuration '/home/mike/golioth-compile/golioth-firmware-sdk/modules/lib/golioth-firmware-sdk/examples/zephyr/fw_update/boards/frdm_rw612.conf'
Merged configuration '/home/mike/golioth-compile/golioth-firmware-sdk/modules/lib/golioth-firmware-sdk/snippets/shell_log/shell_log.conf'
Merged configuration '/home/mike/golioth-compile/golioth-firmware-sdk/modules/lib/golioth-firmware-sdk/build/fw_update/zephyr/.config.sysbuild'
Configuration saved to '/home/mike/golioth-compile/golioth-firmware-sdk/modules/lib/golioth-firmware-sdk/build/fw_update/zephyr/.config'
Kconfig header saved to '/home/mike/golioth-compile/golioth-firmware-sdk/modules/lib/golioth-firmware-sdk/build/fw_update/zephyr/include/generated/zephyr/autoconf.h'

Using Multiple Snippets

You may add as many snippets to your snippet directory as you like.

snippets
├── dev_sectag
│   ├── dev_sectag.conf
│   └── snippet.yml
└── shell_log
    ├── shell_log.conf
    └── snippet.yml

west build -p -b frdm_rw612 examples/zephyr/hello -S shell-logs -S dev-sectag

Zephyr even has some snippets built-in. Many of them are tightly coupled to vendor-specific configurations. But some are quite useful, like using -S rtt-console to turn on console output when using Segger RTT. What do you have planned for your own snippets? We’d love to hear about it, post your details in the Golioth forum!

The way things were

Getting started in any new ecosystem can be tough. Vendor tooling like ACH gives users a way to quickly find and try out an application and find all the required dependencies. Pairing the ACH with [NXP’s VS Code plugin][2] can help ease the complexity of the Zephyr toolchain, which can be useful for engineers transitioning to a new ecosystem. My earliest memories of interacting with an IDE includes the confusing setup of an Eclipse environment and then using the built-in tooling to pull down a set of examples that are able to run on target hardware. To its credit, when it worked, this ecosystem approach made it simpler to have all the required libraries and build systems to start with an example; often it would not work or I’d be mired in the setup doldrums for days on end.

How the demo works

[The MCX-W71 is a Bluetooth and 802.15.4 chipset][3] meant for low power applications in industrial and smart home applications normally powered via Matter. For this demo, we are accessing this chip via the FRDM-MCXW71, their development platform. We were immediately interested in this chipset for the integrated Cortex-M33 and variety of other powerful NXP peripherals and the affordable pricetag. The chip is running a slightly modified version of the Pouch BLE GATT demo, which wraps up data in end-to-end encryption and also makes it possible to send data to the Cloud via a Pouch Gateway. The FRDM-MCXW71 in this demo also has a “Weather Click” plugged into it, which is a BME280 sensor on a MikroBus compatible breakout board. The Pouch Gateway for this demo is a precompiled binary that goes onto the FRDM-RW612, a chipset that has Ethernet, Wi-Fi, Bluetooth, and 802.15.4 connectivity options. It’s targeted at Matter Border Router applications, but also works great as a Pouch Gateway (in fact, it’s one of our standard recommended options). The FRDM-MCXW71 wakes up on a thread every second and takes a reading from the BME280 and puts the reading onto the ZBus. Every 20 seconds, the Bluetooth will advertise that it has a reading and once it connects to the gateway, it will grab the latest reading off of ZBus and publish that using Golioth Stream over Pouch. The Pouch is encrypted and sent up to the cloud via the gateway with no application-side hassles.

static void pouch_event_handler(enum pouch_event event, void *ctx)
{
    if (POUCH_EVENT_SESSION_START == event)
    {
        char buf[52];
        get_latest_weather(buf,sizeof(buf));
        LOG_DBG("Returned JSON: %s",buf);
        if (POUCH_EVENT_SESSION_START == event)
        {
            pouch_uplink_entry_write(".s/sensor",
                POUCH_CONTENT_TYPE_JSON,
                buf,
                strlen(buf),
                K_FOREVER);
            )
            golioth_sync_to_cloud();
        }
    }

Hear more about the setup

Golioth joined Bridgette and Kyle from NXP to talk through the demo and how Bluetooth devices can talk to the Cloud on NXP’s podcast, the Edgeverse Tech Cast.

How to Discover the Golioth REST API First and foremost, everything you can do in the

Golioth web console is available to do via the REST API. A great place to start learning is the Management API docs. These include an OpenAPI section where you can interact with the api from your browser. This page will generate and display example curl commands which I used to build the examples in this post. Another useful approach is to use the developer console in your web browser. By loading the network tab of developer tools you can view the REST API calls being made when navigating the web console. Select the XHR tab and perform the action in the console that you want to recreate with your own REST API call. The image above shows the Firefox developer console inspecting the process of creating a new cohort using the web console. The body of the request may be viewed by clicking the Request tab. Let’s dive in and use curl to upload and deploy a new OTA artifact.

Uploading an OTA artifact with Curl Golioth Over-the-Air (OTA) updates are

managed using cohorts, deployments, and packages.

• A cohort is a group of devices
• A deployment is a set of update packages available to a given cohort
• A package is a distinct binary file available in a deployment It may be useful to upload a new package version as part of your CI workflow, or just from your build directory as you develop. Assuming you already have a Package group, upload an artifact (a new version of the package) using this curl command:

curl -X 'POST' \
      'https://api.golioth.io/v1/artifacts' \
      -H 'accept: application/json' \
      -H 'x-api-key: 8huiDpFplrcixyC5UwYpd9nQyPpTGJmW' \
      -H 'Content-Type: application/json' \
      -d '{
  "projectId": "your-project-id",
  "content": "'$(base64 test_artifact.bin)'",
  "version": "3.4.5",
  "package": "main"
}'

content member of the JSON body. We use the Linux base64 command to encode the binary data as… you guessed it… base64 to send via curl. You will need to supply your own projectId, an x-api-key, and the name of your package. All of these maybe found/created in the Golioth web console. After running the command, verify by viewing in the web console.

Creating Deployments with Curl In the previous step we uploaded the OTA binary, but to get it to your device fleet we need to create a deployment. The response to the curl command that uploaded the binary includes a key piece of information you need to retain: the artifact ID.

{
  "data": {
    "id": "691b4cbfbb9860973efc2d0d",
    "version": "3.4.5",
    "package": "main",
    "createdAt": "2025-11-17T16:26:39.167Z",
    "updatedAt": "2025-11-17T16:26:39.167Z",
    "binaryInfo": {
      "digests": {
        "sha256": {
          "digest": "5525d41439400d0f7d066551f8e4668189d80d87d14940f15b18dcc36680b13c",
          "size": 32,
          "type": "sha256"
        }
      },
      "size": 21,
      "type": "default"
    },
    "size": "21"
  }
}

curl -X 'POST' \
  'https://api.golioth.io/v1/organizations/your-org-id/projects/your-project-id/cohorts/my_test_cohort/deployments' \
  -H 'accept: application/json' \
  -H 'x-api-key: 8huiDpFplrcixyC5UwYpd9nQyPpTGJmW' \
  -H 'Content-Type: application/json' \
  -d '{
  "name": "my-fw-update-'$(date +"%Y%m%d%H%M")'",
  "artifactIds": [
    "691b4cbfbb9860973efc2d0d"
  ]
}'

• your-org-id: click the gear icon next to your organization name in the top bar of the web console to locate your Organization ID
• your-project-id: find it by clicking settings in the left sidebar of the web console
• my_test_cohort: the name of your cohort, which you’ll find in the Cohorts entry on the left sidebar of the web console You, of course, need to supply the correct

x-api-key for your project. The JSON payload of this command requires a name for the deployment. You decided the name up, here I’ve included a human-readable timestamp but the web console will also indicate the time at which this deployment was created. In this case I’m deploying a single artifact, but you may specify multiple artifacts for a deployment. We can verify the deployment was sent to our desired cohort by viewing it in the web console.

Bonus: Downloading an OTA artifact using Curl While artifact download is meant for your OTA fleet, you can leverage curl to download any package from a project by using a set of device credentials. First, acquire a PSK-ID/PSK by creating a new device on the Golioth web console (or using an existing one) and clicking on the credentials tab.

With our credentials in hand we can retrieve a binary file using the package name and version number.

curl 'https://gw.golioth.io/.u/c/main@3.4.5' -u 20251117171208-amaranth-watery-landfowl@your-project-id -o my_package.bin

The astute reader may have already noticed that I uploaded a binary file of only 21 bytes. It is worth noting that Golioth treats your artifacts as binary data. While it’s easy to think of OTA as a firmware delivery mechanism, with Golioth deployments you deliver any files you like, such as machine learning models, audio/video assets, and firmware too.

Post Your REST API Questions We’d love to hear how you’re using the Golioth REST API. Whether it’s sharing your success, or asking about how to get unstuck, please post your thoughts

on the Golioth forum!

State of Pico2 W Support in Zephyr

The RP2350 has had support in Zephyr for some time now, but the option of using the Wi-Fi–available thanks to the Infineon chip on the Pico2 W board–is brand new. For now, you’ll need to build on v4.3.0-rc2 to use the Wi-Fi. Also of note is that the last stable release of OpenOCD ( 0.12.0 release January 2023) does not support the RP2350. Since this is the version included in the Zephyr skd-ng, you’ll need to build OpenOCD from source (or find a newer build) in order to flash/debug the Pico2 W. I found that building OpenOCD was pretty straight-forward. Follow the compilation instructions on the README by running the following commands:

./bootstrap
./configure
make
sudo make install

west tool to the binary and the scripts directory. More on that later. While there is a VScode plugin for working with the Pico2 in Zephyr, I have not tried it and am unable to report as to the state of OpenOCD with that approach.

Preparing Golioth for the Pico2 W Build

The latest release of the Golioth Firmware SDK (v0.21.1) supports Zephyr v4.2.1. Find the west.yml file and update the Zephyr version to v4.3.0-rc2, then run an update to pull in the new version:

west update

west blobs fetch hal_infineon

west blobs fetch hal_infineon --allow-regex='img/whd/resources/(firmware/COMPONENT_43439|clm/COMPONENT_43439/COMPONENT_MURATA-1YN)/*'

Building and Running Golioth Hello for the Pico2 W

As with most new things, I want to run hello world as a first test. With much trial and error I boiled the necessary configuration down as follows:

CONFIG_NETWORKING=y
CONFIG_TEST_RANDOM_GENERATOR=y

CONFIG_NET_DHCPV4=y

CONFIG_NET_IPV4=y
CONFIG_NET_IPV6=n

CONFIG_WIFI=y
CONFIG_WIFI_LOG_LEVEL_ERR=y
CONFIG_NET_L2_WIFI_SHELL=y
CONFIG_GOLIOTH_SAMPLE_WIFI=y

/* Partitioning for the RP2350A-M33 board using 4M flash.
 */
#include 

west build -p -b rpi_pico2/rp2350a/m33/w examples/zephyr/hello
west flash

Oh no, it didn’t work!

Can't find target/rp2350.cfg
FATAL ERROR: command exited with status 1: /home/mike/zephyr-sdk-0.17.4/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s /home/mike/golioth-compile/golioth-firmware-sdk/zephyr/boards/raspberrypi/rpi_pico2/support -s /home/mike/zephyr-sdk-0.17.4/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts -f /home/mike/golioth-compile/golioth-firmware-sdk/zephyr/boards/raspberrypi/rpi_pico2/support/openocd.cfg -c 'source [find interface/cmsis-dap.cfg]' -c 'source [find target/rp2350.cfg]' -c 'set_adapter_speed_if_not_set 5000' '-c init' '-c targets' -c 'reset init' -c 'flash write_image erase /home/mike/golioth-compile/golioth-firmware-sdk/modules/lib/golioth-firmware-sdk/build/zephyr/zephyr.hex' -c 'reset run' -c shutdown

west build -p -b rpi_pico2/rp2350a/m33/w examples/zephyr/hello -- -DOPENOCD=/home/mike/golioth-compile/openocd/src/openocd -DOPENOCD_DEFAULT_PATH=/home/mike/golioth-compile/openocd/tcl
west flash

creating some Golioth credentials using the web console, opening up a serial terminal, and provisioning the device:

wifi cred add -k 1 -s your_ssid -p your_wifi_password
settings set golioth/psk-id your-golioth-psk-id
settings set golioth/psk your-golioth-psk
kernel reboot

-k is encryption types, while -s and -p are SSID and PSK. From there, set your Golioth PSK-ID/PSK as normal and reboot the chip.

Sample Output

The entire process of provisioning and connecting to Golioth will look about like this:

[00:00:03.112,000]  fs_nvs: 8 Sectors of 4096 bytes
[00:00:03.112,000]  fs_nvs: alloc wra: 0, fe8
[00:00:03.112,000]  fs_nvs: data wra: 0, 0
*** Booting Zephyr OS build v4.3.0-rc1 ***
*** Golioth Firmware SDK v0.21.1-24-g5d0365be5a81 ***
[00:00:03.113,000]  net_sock_tls: No entropy device on the system, TLS communication is insecure!
[00:00:03.113,000]  golioth_settings_autoload: Initializing settings subsystem
[00:00:03.113,000]  golioth_settings_autoload: Loading settings
[00:00:03.113,000]  hello_zephyr: main: start hello sample
[00:00:03.113,000]  golioth_samples: Bringing up network interface
[00:00:03.113,000]  golioth_samples: Waiting to obtain IP address
[00:00:03.113,000]  golioth_wifi: Connecting to stored WiFi network
uart:~$ wifi cred add -k 1 -s golioth -p your-wifi-password
uart:~$ settings set golioth/psk-id rpi-pico2w@iot_fleet
Setting golioth/psk-id to rpi-pico2w@iot_fleet
Setting golioth/psk-id saved as rpi-pico2w@iot_fleet
uart:~$ settings set golioth/psk 840e6b5b64f23e0f2cd794051642c0aa
Setting golioth/psk to 840e6b5b64f23e0f2cd794051642c0aa
Setting golioth/psk saved as 840e6b5b64f23e0f2cd794051642c0aa
uart:~$ kernel reboot

[3067] WLAN MAC Address : 2C:CF:67:DF:09:D9

[3070] WLAN Firmware    : wl0: Jun  5 2024 06:33:59 version 7.95.88 (cf1d613 CY) FWID 01-7b7cf51a

[3079] WLAN CLM         : API: 12.2 Data: 9.10.39 Compiler: 1.29.4 ClmImport: 1.36.3 Creation: 2024-04-16 21:20:55

[3088] WHD VERSION      : 3.3.3.26653
[3091]  : WIFI5-v3.3.3
[3093]  : GCC 12.2
[3095]  : 2025-04-14 03:18:50 +0000

[00:00:03.112,000]  fs_nvs: 8 Sectors of 4096 bytes
[00:00:03.112,000]  fs_nvs: alloc wra: 0, fa0
[00:00:03.112,000]  fs_nvs: data wra: 0, 13e
*** Booting Zephyr OS build v4.3.0-rc1 ***
*** Golioth Firmware SDK v0.21.1-24-g5d0365be5a81 ***
[00:00:03.113,000]  net_sock_tls: No entropy device on the system, TLS communication is insecure!
[00:00:03.113,000]  golioth_settings_autoload: Initializing settings subsystem
[00:00:03.113,000]  golioth_settings_autoload: Loading settings
[00:00:03.113,000]  hello_zephyr: main: start hello sample
[00:00:03.113,000]  golioth_samples: Bringing up network interface
[00:00:03.113,000]  golioth_samples: Waiting to obtain IP address
[00:00:03.113,000]  golioth_wifi: Connecting to stored WiFi network
Connected
[00:00:06.024,000]  net_wifi_mgmt: Connection requested
[00:00:06.612,000]  net_dhcpv4: Received: 192.168.200.43
[00:00:06.613,000]  golioth_mbox: Mbox created, bufsize: 1320, num_items: 10, item_size: 120
[00:00:06.839,000]  golioth_coap_client_zephyr: Golioth CoAP client connected
[00:00:06.839,000]  hello_zephyr: Sending hello! 0
[00:00:06.839,000]  hello_zephyr: Golioth client connected
[00:00:06.839,000]  golioth_coap_client_zephyr: Entering CoAP I/O loop
[00:00:11.839,000]  hello_zephyr: Sending hello! 1
[00:00:16.839,000]  hello_zephyr: Sending hello! 2
[00:00:21.839,000]  hello_zephyr: Sending hello! 3

Zephyr Gotchas with the Pico2 W

There are a number of gotchas to following along with the post so far. Zephyr supports a number of runners for flashing this board, including the UF2 bootloader. However, I’m using a programmer because I don’t want to push a button (and replug USB) to flash the chip. That’s okay, because Zephyr doesn’t have USB-CDC support for this board either. This means you can’t get logs from the USB port. I’m using the Raspberry Pi Debug Probe because it takes care of a number of these issues: directly program the chip, use the built-in UART to connect to the chip’s console, and I’m using a hack to power the Pico from the debug probe (do so at your own peril). Edit: Thanks to Chris Wilson who pointed out that USB-CDC worked on the Pico and should also work on the Pico2 w. I went back and tried again and was able to get it working on the usb-cdc sample with a bit of devicetree work.

--sysbuild to indicate the build wants a bootloader, you must change the board name itself to use an additional qualifier: rpi_pico2/rp2350a/m33/w/mcuboot. This presents a minor annoyance when I added this to our GitHub CI, but otherwise it’s just a different approach from what I’m accustomed to and still works well.

Take Golioth for a Spin on your Pico2 W!

Official Golioth support for this board is coming soon. We can’t merge to main until Zephyr releases v4.3.0, expected this month. For now, check out my working branch and let us know how things go!

“Okay, now let’s scale it.” Suddenly, the “fun” part of building connected devices gives way to the messy middle: authentication, provisioning, firmware updates, dashboards, logging, alerts, certificates, retries, and reboots. The firmware team focuses on getting data off the device, the cloud team focuses on ingesting and storing it, and the space in between becomes a gray area of responsibility. Integrating those layers takes more coordination than anyone expected, and over time, the team finds itself maintaining infrastructure that doesn’t add new value to the product — it just keeps the lights on. And that’s exactly where Golioth comes in.

The “Messy Middle” Problem

Every connected product, no matter how innovative, hits the same wall: getting reliable, secure data from devices into the cloud, and keeping it there at scale.

Building firmware and product features your users will love, that’s exciting. But building and maintaining the infrastructure that gets data from the edge to the cloud? That’s the messy middle. It’s the layer of plumbing between devices and cloud applications that nobody sets out to build, but every IoT product eventually needs.

This is where most teams start losing time and momentum. What begins as a simple proof of concept gradually expands into a complex ecosystem of systems and dependencies that has to stay online, scale, and evolve. Each addition feels necessary at the time, but together they create an infrastructure that needs as much attention as the product itself. Before long, your team isn’t just building a product — you’re running an entire IoT platform.

Focus on What Actually Matters

When you use Golioth, you don’t have to think about:

• How to securely connect thousands of devices to the cloud
• How to push firmware updates over the air
• How to log, store, and route data to the right systems You just build your product. By leveraging Golioth’s

Device Management, Data Routing, and Application Services, your team can focus on innovation and not infrastructure. You can iterate faster, run real-world tests earlier, and deploy with confidence knowing your foundation is solid. It’s the difference between spending six to twelve months building an IoT backbone versus spending six days integrating one.

The Business Case for Using Golioth

This is often where the conversation with your boss begins or where it gets stuck.

“Why do we need another platform?” “Can’t we just build it ourselves?” The answer is: sure, you can. But should you? Every hour your team spends managing TLS certificates, maintaining cloud infrastructure, or troubleshooting firmware updates is an hour not spent improving your product’s value. Those tasks are operational costs, not competitive advantages. What often gets overlooked in the “build vs. buy” debate is the DevOps burden that comes with building it yourself.  Once you decide to roll your own IoT backend, you’re not just creating infrastructure; you’re committing to owning it. That means servers, monitoring, scaling, uptime, incident response, and ongoing maintenance. Golioth eliminates that DevOps cost and responsibility. We take care of the connectivity layer, device provisioning, scaling, and monitoring, all the operational work that keeps an IoT system running reliably. Your team doesn’t have to worry about uptime, infrastructure tuning, or maintenance; it’s all handled as part of the platform. And as your product matures, you’ll inevitably want to add new features for your customers. That also means new requirements for your infrastructure: new APIs, new scaling needs, and new integrations. If you’ve built your own stack, you’re now maintaining and evolving two products: your core product and the Golioth equivalent platform you’ve built on the side. Golioth turns all of that complexity into a managed service. We handle the operational layer, device connectivity, data ingestion, routing, and cloud integration, so your team can stay focused on your users, your data, and your differentiation.

Engineering Freedom, Not Lock-In

Golioth isn’t just an IoT “cloud” — it’s an IoT data company. Our core mission is to help you move data cleanly, securely, and reliably between the physical world (your devices) and your cloud infrastructure. We provide device management capabilities because they’re essential to making that data journey possible. You can register, provision, monitor, and update devices at scale with just a few lines of code. But that’s only part of the story. The real value is in the data itself, the insights your devices generate, and how you use them to shape your product, your operations, and your customer experience. Golioth is the vessel that carries that data from your devices to wherever it needs to go. Whether it’s streaming telemetry to analytics tools, routing events to webhooks, or archiving logs in cloud storage, we make sure your data arrives intact and ready for use, without locking you into a single ecosystem. You own the data. Always. It’s your differentiator, the reason your product stands out in the market. Our job is to make sure nothing gets in the way of you collecting it, moving it, and using it. Route your data to AWS, GCP, InfluxDB, or anywhere else your architecture requires. Golioth gives you the freedom to evolve your stack as your product grows, to adapt, migrate, and scale, without ever losing control of your most valuable asset: your data. We’re here to accelerate your roadmap, not dictate it.

Wrapping It Up

Convincing your boss isn’t about buzzwords or hype. It’s about showing that engineering time is precious, and that the unsexy, repetitive parts of IoT don’t need to be reinvented for the hundredth time. With Golioth, your team can:

• Reduce development risk by starting from a proven IoT foundation
• Speed up time to market by skipping infrastructure work
• Optimize resources by focusing only on what differentiates your product If your goal is to launch within the next year, Golioth gives you the end-to-end infrastructure to get there — securely, efficiently, and without distraction. Let your engineers focus on what they do best: building great products. Let Golioth handle the rest.

Signed URLs Recap To briefly recap, signed URLs are time-limited credentials that grant access to a remote private resource. While they are typically used on the web when a server issues a signed URL to a client that then uses it to download an asset from a Content Delivery Network (CDN), they can also be useful in the context of embedded devices. For example, devices with multiple microcontollers (MCUs) can store private keys in the secure processing environment (SPE) of one MCU, then issue signed URLs to the other. This is especially useful if one of the processors is not equipped with the same level of security features as the other. The less secure processor is only ever issued a narrowly scoped, ephemeral credential.

Bringing Signed URLs to the ESP32

signy leverages Arm’s Platform Security Architecture (PSA) Crypto API, which offers a consistent interface for common cryptographic operations across embedded hardware and software platforms. This made adding support for ESP-IDF relatively painless, as the vast majority of the functionality in signy involves invoking PSA APIs, such as psa_hash_compute() and psa_sign_hash(). In addition to ensuring that signy only used standardized APIs, we also packaged the library as an ESP-IDF component, meaning that it can now be included in any project by adding the following to the projects’s idf_component.yml.

dependencies:
  signy:
    version: v0.2.0
    git: https://github.com/golioth/signy.git

Leveraging ESP-IDF’s OTA Firmware Update Capabilities The

Golioth Firmware SDK offers support for downloading assets, including firmware images, over-the-air (OTA). It also includes a reference implementation for firmware update, which provides an abstraction layer over the functionality offered by the various supported platforms (see the example of its use with ESP-IDF). However, ESP-IDF also offers its own high-level interface for firmware update in its esp_https_ota component. As the name suggests, it leverages HTTP instead of CoAP, which can be desirable when transferring large amounts of data, especially for products that are communicating over higher bandwidth mediums, such as Wi-Fi or Ethernet. Using esp_https_ota alongside the Golioth Firmware SDK has been possible in the past, but doing so was non-trivial. With signy, performing an OTA update over HTTP is much simpler: sign a URL for the asset, then pass it in the HTTP client configuration.

signy_sign_url(CONFIG_SIGNY_EXAMPLE_BASE_URL,
                     strlen(CONFIG_SIGNY_EXAMPLE_BASE_URL),
                     signed_url,
                     sizeof(signed_url),
                     &signed_url_len);

esp_http_client_config_t config = {
    .url = signed_url,
    .cert_pem = (char *) server_cert_pem_start,
    .event_handler = _http_event_handler,
    .keep_alive_enable = true,
    .buffer_size_tx = 10240,
};

esp_https_ota_config_t ota_config = {
    .http_config = &config,
};

esp_https_ota(&ota_config);

signy repository now includes a full OTA firmware update example with ESP-IDF, which demonstrates how a new firmware image can be downloaded from Golioth, then used to replace the existing firmware on the device.

What’s Next? ESP32 devices are used in many different products and projects. While OTA firmware updates are one use case for signed URLs, we are excited how else they can be leveraged. Let us know how you are using signed URLs on the

Golioth forum!

How roaming between Gateways has traditionally worked

For most models of Bluetooth devices talking through Gateways ³ up to the Cloud, the Gateway is a trusted source. When a Gateway talks to a Bluetooth node, it needs to first determine if/when/how it’s going to connect to a device over the Bluetooth link. Often this is based on the UUID, something in the advertising packet, or a specific GATT profile being transmitted. Next the pairing process must complete so the Gateway (normally Central) and the Node⁴ (normally Peripheral) can communicate. Next, the Gateway needs to determine if that device is allowed to transmit data up to the Cloud. This can be done with a Gateway connection to a Cloud backend that validates a newly connected Node at the application level and determines whether the device is allowed to transmit. If it is allowed, the data starts flowing through the Gateway up to the Cloud. For this example, lets say this is Bluetooth Node 123 talking through Gateway ABC.

If the Node moves to a different location, now what?

First, Node 123 ‘sees’ a new Gateway, we’ll call the new one Gateway XYZ. Once again, the gateway needs to determine if/when/how to connect over Bluetooth to the Node. If this requires that the link is encrypted, once again there would need to be some kind of manual intervention to enable the pairing to happen. If there is no such requirement, then it’s likely the Gateway will validate at the application level, though this might mean that the Bluetooth link and the data contained within is visible to bad actors peeping into Bluetooth traffic with a sniffer. In order to validate Node 123, the new Gateway XYZ either needs to talk to the Cloud or directly to Gateway ABC (much less likely). If the new Gateway XYZ validates the Node then it will be able to ‘Roam’ and pass data through the new Gateway. The gateways themselves can have a variety of methods to block/allow Nodes to pass data, but the infrastructure and security requirements ramp rapidly for this setup if you want to have a seamless handoff between Gateways. For instance, if you want to have asymmetric (cert based) validation of the Nodes, you need to have a root CA on every Gateway for every class of cert that might be presented. This can quickly overwhelm an IT group and require that the Gateway be complicated enough that the device move into the ‘Linux class’ (MPU based), in order to handle the computing and Cloud interaction elements. If you have 1000 Gateways and 20 different root CA certs that are valid at any given time, all 1000 Gateways need to synchronize with the master list of certs so that a Node can talk through any of the 1000 Gateways. Of course, there are tradeoffs that allow an embedded (MCU based) gateway to also act in this manner, but for sufficiently large fleets, the storage capabilities of the MCU may start to limit the number of devices that can be connected.

What about when the Gateway is an app?

The most common use case for Bluetooth devices is directly interacting with a mobile phone app. The idea of ‘roaming’ hardly ever enters the conversation. In this case, the idea of “Node communicating with the Cloud” is often skipped entirely and the App talks directly with a Bluetooth device and takes over all transmission of data up to the Cloud (when/if needed).

How it’s different with Golioth Connectivity and Pouch

Golioth Bluetooth Connectivity is built upon Pouch, our innovation that enables indirectly connected devices to talk to the Cloud and introduces end-to-end encryption of data from a Node to the Cloud. This also includes the associated Cloud-side tooling that makes it seamless to have those packets decrypted and assigned to the proper device record in Golioth. The Node device needs to be running the Pouch SDK; the packets sent from that device transit through Gateways that are also running a portion of the Pouch SDK and the Golioth Firmware SDK. We have precompiled binaries of our reference Gateway implementation on a board like the FRDM-RW612, which makes it very easy to create a group of Nodes and Gateways and see roaming in action. Let’s talk about the same Node 123 (such as the Tikk board) talking through a Gateway ABC (FRDM-RW612). The device advertises that it has uplink data available, the Gateway (central) connects to the Node (peripheral), and the device certificate is presented through the Gateway up to the Cloud. After the device is authenticated onto the Cloud, the certificate is cached (on the Cloud), and the uplink/downlink data is able to flow. If you look at the hex dump of the uplink data on the Gateway, you’ll see…well nonsense! That’s because Node 123 is end-to-end encrypted with the Cloud, not with the Gateway. The Gateway has no way of decrypting the data passing through it. Now Node 123 moves to a different location and it is again advertising that it’s ready for uplink. Gateway XYZ (thingy91x) is also running the Golioth Gateway reference implementation and connects to the Node. Once again the certificate is passed through the gateway up to the Cloud and validated. No allowlist or credential passing down to the Gateway is required because the Cloud is the ultimate arbiter, having the root CA that generated each device certificate. Want to learn more about certificates? Read our post about how certificate based security works or go use our brand new certificate generator on the Console to quickly try out the newly optimized workflow. In the Golioth use case, a mobile phone app can also be a gateway, and one that still enables roaming. If the application is authenticated to talk to Golioth and also has access to the Bluetooth radio, the app can shuttle packets along in the same way that an MCU or MPU class device does. The difference is that the phone will not directly interact with data from the Bluetooth device, instead relying on accessing data from the Cloud or via an alternative channel, such as a separate GATT profile.

Roaming unlocked and simplified

Now that Node 123 can validate between Gateways ABC and XYZ, it’s easy to imagine how this could be expanded to more and more gateways, as happens in an asset tracker scenario. For super high value asset tracker scenarios, it’s conceivable that there are even more gateways to track movement than there are the nodes themselves! Golioth’s Pouch SDK and reference gateway implementations make it easy to spool up a new application that hops between gateways and still sends data up and down to the Cloud, while still taking advantage of the low cost and low power nature of Bluetooth connectivity. Head over to the Golioth forum to ask more questions about how the technology works or to let us know what you’re building next.

Glossary

Let’s make sure we have a good definition of the terms we’re discussing here

We’re not building games at Golioth, but today we are borrowing an idea from the gaming industry: the most optimal way of playing a game should also be the most fun.  Players are always going to pick the shortest path to winning the game, so it’s the game developer’s job to make sure this path also makes the game as fun as possible. Extending this idea to IoT and building more secure products, a corollary would be: The shortest path to shipping products should also be the most secure.

The Problem

Currently, we support two types of credentials on the Golioth Cloud: Pre-Shared Keys (PSKs) and Certificates. When starting a new project on Golioth, one of the first things our users do is add their device in the Golioth Console, and set up some credentials that lets their device authenticate to the cloud. This is really creating a cloud-side representation of the device, which has yet to connect to the platform. PSKs are easy to understand and easy to use, being similar to a username/password. But they’re less secure than certificates: PSKs have to be stored on both the device and in Golioth’s servers ahead of time, which increases the overhead to the manufacturing entity, as well as the number of attack vectors. Certificates only include the public part of the device’s encryption key, and Golioth does not need to know the contents of the device’s key to verify its identity. We want to encourage our users to use certificates for authentication, but unfortunately, generating and signing certificates is pretty cumbersome, especially in the early stages of development. Ideally, developers should be setting up their own Public Key Infrastructure with an external provider, but this can be both intimidating and time consuming. We made a short guide showing how they can sign their own certificates, but that’s still not a production-grade solution. Storing your own private key for a root CA is much less secure than a Public Key Infrastructure provider. But, again, this is done to allows users to bypass the cumbersome PKI setup process during their initial setup. The difficulty again ramps up for users looking to just try out the capabilities of something like Golioth Connectivity: generating and loading self-signed certs is still harder than just copying the PSK onto the device. As a result, a lot of our users end up using PSKs during their development phase. When they’re ready to take their product to production, they often continue using PSKs (why rock the boat, right?). We’ve effectively failed them: The shortest path to shipping their product was with the less secure authentication method, so that’s what they chose.

Introducing The Certificate Generator

What if we could maximize security and convenience? To reduce the threshold for getting started with certificate based authentication, we have added a Certificate Generator to the Golioth Console. The Certificate Generator allows you to generate certificates and private keys for your devices directly in your browser, making it easy to use certificate based authentication throughout your development process. You don’t have to install any command line tools, and you can easily transition to an external Public Key Infrastructure provider later, without changing your firmware. You can find the Certificate Generator from the Certificates page in the console, or at the end of the device creation workflow. Note that you do not have to create the device before generating the certificate. Through Zero Touch Provisioning, you can just set a unique device name in the generator, and the device will get created in Golioth as soon as it authenticates. The Certificate Generator creates a temporary certificate authority that gets used to sign a device certificate you can download, alongside a matching private key. The certificate authority gets registered with Golioth automatically, and the certificate signing key is discarded as soon as it has signed the device certificate. Golioth never stores or even sees any of your generated private keys, so if you lose it, you’ll need to generate a new one. You can run the Certificate Generator as many times as you’d like, and each device certificate you generate will have its own dedicated certificate authority registered with Golioth. You can invalidate the device certificate by removing its certificate authority (sometimes referred to in our docs as a ‘root ca’).

Limitations

The goal of the Certificate Generator is to make it easier to pick the strongest authentication method for your product, but we have to be careful to avoid weakening the security in the process. To ensure that the certificate generator doesn’t get abused, we’ve added some restrictions:

• Generated certificates and their corresponding certificate authorities are only valid for four weeks. Once your certificate expires, you’ll have to generate a new one, or change to a proper Private Key Infrastructure provider.
• As the certificate signing key gets discarded right away, it can only be used to sign a single device certificate.
• Certificate authorities registered by the Certificate Generator get a DEMO tag attached to them. This is visible in the console and management APIs, but it does not affect the certificate authority’s behavior as long as it’s valid. We’re working on some pretty big improvements to the certificate based authentication workflow, which we’ll be able to show you pretty soon. We hope the Certificate Generator makes it easier to start using certificate based authentication from the very first device you connect to Golioth. Let us know what you think on our forums or reach out directly!

Zephyr System Heap Runtime Stats

The good news is that if you are using the Zephyr Shell, you likely already have access to the heap stats by typing kernel heap. This is a useful tool for spot checking your heap usage. If the command is not working for you, make sure you have CONFIG_KERNEL_SHELL selected. Spot checks like this will catch egregious leaks where you keep allocating memory on a regular basis without freeing it. However, I’ve found that programmatically tracking heap usage and reporting on anomalous growth is the most reliable way to catch a subtle leak. If you look deep inside the API reference for Zephyr’s low level heap allocator you’ll be delighted to find sys_heap_runtime_stats_get(). However, it’s not entirely clear how to get the pointer to the system heap that this function requires as a parameter. Luckily, we already know the kernel shell is getting these stats from somewhere so it is just a matter of grepping to find how it’s done. Let’s put together a test app to illustrate.

Memory Leak Test App

Here’s a barebones application that includes a memory leak that is tracked by printing out heap stats during every other loop.

CONFIG_LOG=y
CONFIG_SHELL=y

# Heap size may default to 0 in which case, no heap is allocated
CONFIG_HEAP_MEM_POOL_SIZE=4096

# Use runtime stats
CONFIG_SYS_HEAP_RUNTIME_STATS=y

#include 
LOG_MODULE_REGISTER(memory_leak, LOG_LEVEL_DBG);

#include 
#include 
#include 

struct sys_memory_stats stat;

extern struct sys_heap _system_heap;

int main(void)
{
    uint32_t counter = 0;

    while (true) {
        int *my_int = k_malloc(sizeof(int));

        counter++;
        if (0 == counter % 2)
        {
            continue;
        }

        LOG_INF("Hello %u", counter);
        sys_heap_runtime_stats_get(&_system_heap, &stat);
        LOG_WRN("Heap: Free: %u, Alloc: %u, MaxAlloc: %u", stat.free_bytes,
                stat.allocated_bytes, stat.max_allocated_bytes);

        k_free(my_int);

        k_msleep(2000);
    }
}

• CONFIG_SYS_HEAP_RUNTIME_STATS=y to include the library in the build
• extern struct sys_heap _system_heap to point to the system heap
• sys_heap_runtime_stats_get(&_system_heap, &stat) to poll the heap stat information When we run the program, an integer is dynamically allocated at the beginning of the loop and freed at the end. However, if the counter is even, we continue the loop, which jumps past the

k_free() command causing a memory leak. Here’s the output of this program.

*** Booting Zephyr OS build v4.2.1 ***
[00:21:16.071,588]  memory_leak: Hello 2
[00:21:16.071,600]  memory_leak: Heap: Free: 3992, Alloc: 32, MaxAlloc: 32
[00:21:18.071,775]  memory_leak: Hello 4
[00:21:18.071,785]  memory_leak: Heap: Free: 3976, Alloc: 48, MaxAlloc: 48
[00:21:20.071,868]  memory_leak: Hello 6
[00:21:20.071,876]  memory_leak: Heap: Free: 3960, Alloc: 64, MaxAlloc: 64
[00:21:22.071,966]  memory_leak: Hello 8
[00:21:22.071,974]  memory_leak: Heap: Free: 3944, Alloc: 80, MaxAlloc: 80
[00:21:24.072,063]  memory_leak: Hello 10
[00:21:24.072,069]  memory_leak: Heap: Free: 3928, Alloc: 96, MaxAlloc: 96
[00:21:26.072,163]  memory_leak: Hello 12

Zephyr Heap Listener

Memory stats give you running totals of what is happening with the heap. But it’s also useful to know where and when the allocations are happening. For this we can use Zephyr’s Heap Listener features. Let’s update our application to use listeners instead of stats.

CONFIG_LOG=y
CONFIG_SHELL=y

# Heap size may default to 0 in which case, no heap is allocated
CONFIG_HEAP_MEM_POOL_SIZE=4096

# Use heap listener
CONFIG_SYS_HEAP_LISTENER=y

#include 
LOG_MODULE_REGISTER(memory_leak, LOG_LEVEL_DBG);

#include 
#include 
#include 
#include 

extern struct sys_heap _system_heap;

void on_heap_alloc(uintptr_t heap_id, void *mem, size_t bytes)
{
    LOG_WRN("Allocated: %zu", bytes);
}
HEAP_LISTENER_ALLOC_DEFINE(my_heap_listener_alloc, HEAP_ID_FROM_POINTER(&_system_heap),
               on_heap_alloc);

void on_heap_free(uintptr_t heap_id, void *mem, size_t bytes)
{
    LOG_WRN("Freed: %zu", bytes);
}
HEAP_LISTENER_FREE_DEFINE(my_heap_listener_free, HEAP_ID_FROM_POINTER(&_system_heap), on_heap_free);

int main(void)
{
    uint32_t counter = 0;

    heap_listener_register(&my_heap_listener_alloc);
    heap_listener_register(&my_heap_listener_free);

    while (true) {
        int *my_int = k_malloc(sizeof(int));

        counter++;
        if (0 == counter % 2)
        {
            continue;
        }

        LOG_INF("Hello %u", counter);

        k_free(my_int);

        k_msleep(2000);
    }
}

k_malloc() and k_free() are called. When we look at this output it is pretty obvious that we’re allocating twice as often as we are freeing memory. For our simple application this visual pattern tells the whole story. But in your own test code, these callbacks can be used to keep track of the stats, or monitor for an imbalance between the two functions. There is also a callback available for heap resize events.

Demystifying Heap Operations

It’s easy to be complacent and never give heap usage a second thought. But memory leaks are notoriously difficult to track down in large code bases, so it pays to keep an eye on the heap starting early in your development. Use these built-in Zephyr tools in your testing and set up alerts to catch an issue early, or better yet, to give you peace of mind when those tests turn up green. If you find that your devices in the field already have a leak that are affecting operations, Golioth’s Over the Air firmware update capabilities will make it easy to push a fix and even monitor the resulting logs.

Prerequisites

If you want to give this a try yourself, here’s what you need to have solved before jumping in today:

1. Have a Golioth project set up with a Pipeline to receive your Stream data
2. Understand the concepts behind sending data block-by-block using the golioth_stream_set_blockwise_sync() API call Both of these are covered in How to Use Golioth Blockwise Stream to Upload Large IoT Data Payloads.

Using a Dynamically Allocated Data Wrapper

When using the async blockwise stream API it will be our responsibility for tracking the upload process through each block. To facilitate this, we can create a new struct in our program.

struct block_stream_container {
    struct blockwise_transfer *transfer_ctx;
    uint8_t *data;
    size_t data_len;
    uint32_t block_idx;
    size_t block_size;
    bool is_last;
};

A Helper Function to Send Blocks

We need to call the async API once for each block, so let’s set up a function just for this purpose.

enum golioth_status send_next_block(struct block_stream_container *container)
{
    if (NULL == container)
    {
        LOG_ERR("Container cannot be NULL");
        return GOLIOTH_ERR_NULL;
    }

    uint32_t offset = container->block_idx * container->block_size;

    /* Test to see if this is the final block of data we need to send */
    if (container->data_len <= offset + container->block_size)
    {
        /* Overwrite the block_size with number of bytes in last block */
        container->block_size = container->data_len - offset;
        /* Indicate to the Golioth Firmware SDK that this is the final block */
        container->is_last = true;
    }

    LOG_INF("Sending block %u of %zu bytes.%s",
            container->block_idx,
            container->block_size,
            container->is_last ? " Final block." : "");

    return golioth_stream_blockwise_set_block_async(container->transfer_ctx,
                                                    container->block_idx,
                                                    container->data + offset,
                                                    container->block_size,
                                                    container->is_last,
                                                    on_stream_block_sent,
                                                    container);
}

covered in detail in the previous post. Just remember that we need to calculate the offset for the next block (using that value to read from the correct place in memory). We also need to handle the size and flag when sending the final block. This function submits each block to the Golioth Firmware SDK using the golioth_stream_blockwise_set_block_async() API. Note that everything we need for parameters comes from the container struct. Well, everything except the callback which you could store in the struct if you need different callbacks for some types of blockwise stream. The final argument is the pointer to our struct which will be passed to the callback function. This will be important later!

Beginning the Asyncronous Blockwise Stream

We haven’t yet discussed the async callback function, but let’s first look at initiating the blockwise stream as this is where our memory handling adventure begins.

static void send_blockwise_stream(void)
{
    struct block_stream_container *container = k_malloc(sizeof(struct block_stream_container));
    if (NULL == container)
    {
        LOG_ERR("Failed to allocate container; stream aborted");
        return;
    }

    container->transfer_ctx =
        golioth_stream_blockwise_start(client, "my-test-path", GOLIOTH_CONTENT_TYPE_JSON);
    if (NULL == container->transfer_ctx)
    {
        LOG_ERR("Failed to allocate transfer context; stream aborted.");
        k_free(container);
        return;
    }

    container->data = (uint8_t *)json_data;
    container->data_len = json_data_len;
    container->block_idx = 0;
    container->block_size = CONFIG_GOLIOTH_BLOCKWISE_UPLOAD_MAX_BLOCK_SIZE;
    container->is_last = 0;

    enum golioth_status status = send_next_block(container);
    if (GOLIOTH_OK != status)
    {
        LOG_ERR("Failed to start blockwise stream: %d", status);
        /* Clean up memory before returning */
        golioth_stream_blockwise_finish(container->transfer_ctx);
        k_free(container);
        return;
    }
}

golioth_stream_blockwise_start() which takes the Golioth client pointer, the path to which we’re sending data, and the data type. We will need to remember to call golioth_stream_blockwise_finish() and k_free() the context at the end of the stream operation, lest we create a memory leak. Note that we are calling these as part of the error handling in this function. But we will see them again in the next section of the post. This function sets up everything for the stream operation, starting with a data pointer and length. This assumes the data you wish to send is already in memory and can be directly accessed. But later in the post we’ll discuss other options for accessing block data to send. Worth noting is the use of CONFIG_GOLIOTH_BLOCKWISE_UPLOAD_MAX_BLOCK_SIZE as the starting block size. This symbol is provided by the Golioth Firmware SDK and is the upper limit for sending blocks. With everything configured, the send process begins by calling our send_next_block() function we discussed in the previous section. As long as that returns GOLIOTH_OK, program flow can continue and the asynchronous callbacks will handle the rest. Speaking of, we need to define our callback!

Async Callback

The Golioth Firmware SDK will call a user callback at the end of sending each block. This callback receives the success/failure code from the block, and it’s a great way for us to know when the SDK is ready for the next block. This may look like a lot, but it’s mostly error handling.

static void on_stream_block_sent(struct golioth_client *client,
                                 enum golioth_status status,
                                 const struct golioth_coap_rsp_code *coap_rsp_code,
                                 const char *path,
                                 size_t block_size,
                                 void *arg)
{
    if (NULL == arg)
    {
        LOG_ERR("Expected block_stream_container pointer as arg but got NULL");
        return;
    }
    struct block_stream_container *container = arg;

    if (GOLIOTH_OK != status)
    {
        if (GOLIOTH_ERR_COAP_RESPONSE == status)
        {
            LOG_ERR("Blockwise stream failed with CoAP code %d.%02d",
                    coap_rsp_code->code_class,
                    coap_rsp_code->code_detail);
        }
        else
        {
            LOG_ERR("Blockwise stream failed: %d", status);
        }

        goto end_blockwise_stream;
    }

    if (true == container->is_last)
    {
        LOG_INF("Blockwise stream completed successfully");
        goto end_blockwise_stream;
    }

    /* Last block completed successfully but there are still more to send */

    /* Increment the block number */
    container->block_idx += 1;
    /* Ensure we use the block_size the server wants */
    container->block_size = block_size;

    enum golioth_status err = send_next_block(container);
    if (GOLIOTH_OK != err)
    {
        LOG_ERR("Failed to send next block of blockwise stream: %d", status);
        goto end_blockwise_stream;
    }

    return;

end_blockwise_stream:
    golioth_stream_blockwise_finish(container->transfer_ctx);
    k_free(container);
}

block_stream_container type. From there we check the status code that was returned by the Golioth Firmware SDK. This indicates that the block was successfully sent to the cloud (GOLIOTH_OK) or an error if unsuccessful. Some types of error will return a CoAP error, which explains the complicated logging seen above when an error is received. Next we check to see if the block we just sent is the last block of the transfer. If so, we can just return without further action. Otherwise now’s the time to increment the block index and call our send_next_block() function. Note that we always use the block_size received as a parameter of the callback. In practice this will almost always be the CONFIG_GOLIOTH_BLOCKWISE_UPLOAD_MAX_BLOCK_SIZE value we used when the blockwise stream was started, it is (very unlikely but) possible the server will request a smaller block size and this is how we handle that case. If at any point in this callback we encounter an error, or if we’ve already sent the final block, we need to clean up our memory here. The original calling function already went out of scope, so this will be the last time we have a pointer to that memory. We carefully clean up the transfer_context used by the SDK async blockwise stream APIs, then free the container itself.

Putting It All Together

You can run the example code for yourself. Start with the stream sample from the Golioth Firmware SDK, replacing the main.c file with the one below. Build, flash, and provision the code following the README in the SDK. The one caveat is that we need to make sure Zephyr includes k_malloc(). The default for this sample is 0 so add the following Kconfig symbol to your prj.conf file:

CONFIG_HEAP_MEM_POOL_SIZE=128

/*
 * Copyright (c) 2025 Golioth, Inc.
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include "golioth/golioth_status.h"
#include 
LOG_MODULE_REGISTER(golioth_stream, LOG_LEVEL_DBG);

#include 
#include 
#include 
#include 
#include 
#include 
#include 

static const char json_data[] = "{\"my-quote\":\"1. The Imitation Game\\nI propose to consider the question, ‘Can machines think?’ This should begin with definitions of the meaning of the terms ‘machine’ and ‘think’. The definitions might be framed so as to reflect so far as possible the normal use of the words, but this attitude is dangerous. If the meaning of the words ‘machine’ and ‘think’ are to be found by examining how they are commonly used it is difficult to escape the conclusion that the meaning and the answer to the question, ‘Can machines think?’ is to be sought in a statistical survey such as a Gallup poll. But this is absurd. Instead of attempting such a definition I shall replace the question by another, which is closely related to it and is expressed in relatively unambiguous words.\\nThe new form of the problem can be described in terms of a game which we call the ‘imitation game’. It is played with three people, a man (A), a woman (B), and an interrogator (C) who may be of either sex. The interrogator stays in a room apart from the other two. The object of the game for the interrogator is to determine which of the other two is the man and which is the woman. He knows them by labels X and Y, and at the end of the game he says either ‘X is A and Y is B’ or ‘X is B and Y is A’. The interrogator is allowed to put questions to A and B thus\"}";

static size_t json_data_len = strlen(json_data);

struct golioth_client *client;
static K_SEM_DEFINE(connected, 0, 1);

static void on_client_event(struct golioth_client *client,
                            enum golioth_client_event event,
                            void *arg)
{
    bool is_connected = (event == GOLIOTH_CLIENT_EVENT_CONNECTED);
    if (is_connected)
    {
        k_sem_give(&connected);
    }
    LOG_INF("Golioth client %s", is_connected ? "connected" : "disconnected");
}

struct block_stream_container {
    struct blockwise_transfer *transfer_ctx;
    uint8_t *data;
    size_t data_len;
    uint32_t block_idx;
    size_t block_size;
    bool is_last;
};

/* forward declaration */
enum golioth_status send_next_block(struct block_stream_container *container);

static void on_stream_block_sent(struct golioth_client *client,
                                 enum golioth_status status,
                                 const struct golioth_coap_rsp_code *coap_rsp_code,
                                 const char *path,
                                 size_t block_size,
                                 void *arg)
{
    if (NULL == arg)
    {
        LOG_ERR("Expected block_stream_container pointer as arg but got NULL");
        return;
    }
    struct block_stream_container *container = arg;

    if (GOLIOTH_OK != status)
    {
        if (GOLIOTH_ERR_COAP_RESPONSE == status)
        {
            LOG_ERR("Blockwise stream failed with CoAP code %d.%02d",
                    coap_rsp_code->code_class,
                    coap_rsp_code->code_detail);
        }
        else
        {
            LOG_ERR("Blockwise stream failed: %d", status);
        }

        goto end_blockwise_stream;
    }

    if (true == container->is_last)
    {
        LOG_INF("Blockwise stream completed successfully");
        goto end_blockwise_stream;
    }

    /* Last block completed successfully but there are still more to send */

    /* Increment the block number */
    container->block_idx += 1;
    /* Ensure we use the block_size the server wants */
    container->block_size = block_size;

    enum golioth_status err = send_next_block(container);
    if (GOLIOTH_OK != err)
    {
        LOG_ERR("Failed to send next block of blockwise stream: %d", status);
        goto end_blockwise_stream;
    }

    return;

end_blockwise_stream:
    golioth_stream_blockwise_finish(container->transfer_ctx);
    k_free(container);
}

enum golioth_status send_next_block(struct block_stream_container *container)
{
    if (NULL == container)
    {
        LOG_ERR("Container cannot be NULL");
        return GOLIOTH_ERR_NULL;
    }

    uint32_t offset = container->block_idx * container->block_size;

    /* Test to see if this is the final block of data we need to send */
    if (container->data_len <= offset + container->block_size)
    {
        /* Overwrite the block_size with number of bytes in last block */
        container->block_size = container->data_len - offset;
        /* Indicate to the Golioth Firmware SDK that this is the final block */
        container->is_last = true;
    }

    LOG_INF("Sending block %u of %zu bytes.%s",
            container->block_idx,
            container->block_size,
            container->is_last ? " Final block." : "");

    return golioth_stream_blockwise_set_block_async(container->transfer_ctx,
                                                    container->block_idx,
                                                    container->data + offset,
                                                    container->block_size,
                                                    container->is_last,
                                                    on_stream_block_sent,
                                                    container);
}

static void send_blockwise_stream(void)
{
    struct block_stream_container *container = k_malloc(sizeof(struct block_stream_container));
    if (NULL == container)
    {
        LOG_ERR("Failed to allocate container; stream aborted");
        return;
    }

    container->transfer_ctx =
        golioth_stream_blockwise_start(client, "my-test-path", GOLIOTH_CONTENT_TYPE_JSON);
    if (NULL == container->transfer_ctx)
    {
        LOG_ERR("Failed to allocate transfer context; stream aborted.");
        k_free(container);
        return;
    }

    container->data = (uint8_t *)json_data;
    container->data_len = json_data_len;
    container->block_idx = 0;
    container->block_size = CONFIG_GOLIOTH_BLOCKWISE_UPLOAD_MAX_BLOCK_SIZE;
    container->is_last = 0;

    enum golioth_status status = send_next_block(container);
    if (GOLIOTH_OK != status)
    {
        LOG_ERR("Failed to start blockwise stream: %d", status);
        /* Clean up memory before returning */
        golioth_stream_blockwise_finish(container->transfer_ctx);
        k_free(container);
        return;
    }
}

int main(void)
{
    LOG_DBG("Start Golioth blockwise stream sample");

    net_connect();

    /* Note: In production, credentials should be saved in secure storage. For
     * simplicity, we provide a utility that stores credentials as plaintext
     * settings.
     */
    const struct golioth_client_config *client_config = golioth_sample_credentials_get();

    client = golioth_client_create(client_config);
    golioth_client_register_event_callback(client, on_client_event, NULL);

    k_sem_take(&connected, K_FOREVER);

    /* Give network connection logs a few seconds to clear */
    k_msleep(2000);

    int counter = 0;
    while(counter++ < 5)
    {
        send_blockwise_stream();
        k_msleep(5000);
    }

    return 0;
}

*** Booting Zephyr OS build v4.1.0 ***
*** Golioth Firmware SDK v0.20.0-6-gd6836844668c ***
[01:03:50.293,041]  golioth_settings_autoload: Initializing settings subsystem
[01:03:50.294,606]  fs_nvs: 8 Sectors of 4096 bytes
[01:03:50.294,624]  fs_nvs: alloc wra: 0, f90
[01:03:50.294,631]  fs_nvs: data wra: 0, d9
[01:03:50.294,668]  golioth_settings_autoload: Loading settings
[01:03:50.294,873]  golioth_stream: main: Start Golioth blockwise stream sample
[01:03:50.294,913]  golioth_samples: Starting DHCP to obtain IP address
[01:03:50.294,996]  golioth_samples: Waiting to obtain IP address
[01:03:57.331,030]  net_dhcpv4: Received: 192.168.1.238
[01:03:57.331,490]  golioth_mbox: Mbox created, bufsize: 1320, num_items: 10, item_size: 120
[01:03:57.559,826]  golioth_coap_client_zephyr: Golioth CoAP client connected
[01:03:57.559,937]  golioth_stream: Golioth client connected
[01:03:57.560,077]  golioth_coap_client_zephyr: Entering CoAP I/O loop
[01:03:59.560,104]  golioth_stream: Sending block 0 of 1024 bytes.
[01:03:59.602,783]  golioth_stream: Sending block 1 of 349 bytes. Final block.
[01:03:59.660,987]  golioth_stream: Blockwise stream completed successfully

the Golioth web console.

What if Your Data Isn’t In Memory?

Your data may not be in memory that is directly accessible. This is the case when you have stored readings on a filesystem, or when you’re using another library that handles its own memory but provides chunked access to you. Don’t worry, just update the container struct to store a reference to how this data may be accessed, and add a block buffer when sending the block. (This buffer memory may go out of scope as soon as the Golioth

golioth_stream_blockwise_set_block_async() command returns as the SDK will make a copy of it before the function returns.) While you need to implement this chunk-read function yourself, here’s how our code from above would differ with this approach.

uint8_t block_cache[CONFIG_GOLIOTH_BLOCKWISE_UPLOAD_MAX_BLOCK_SIZE];

enum golioth_status send_next_block(struct block_stream_container *container)
{
    /* unchanged code removed from beginning of function */

    read_chunk_from_memory(container->filesystem_uri, offset, container->block_size, block_cache);

    return golioth_stream_blockwise_set_block_async(container->transfer_ctx,
                                                    container->block_idx,
                                                    block_cache,
                                                    container->block_size,
                                                    container->is_last,
                                                    on_stream_block_sent,
                                                    container);
}

An Excellent Pipe from Device to Cloud

Getting data from your device fleet to the cloud is something Golioth thinks about all the time. As you’ve seen here, we not only make it easy, but we provide flexibility on both the firmware side and on the cloud side with all the data management tools you will need. Take Golioth for a test drive to day and let us know how it goes by posting to the Golioth forum!

Improved OTA Robustness The Golioth Firmware SDK makes use of

CoAP Observations to be notified anytime a new OTA manifest is available. Observations allow the server to push updates to a resource directly to a client, so that the client can conserve bandwidth and power, while receiving updates with low latency. While generally reliable, these notifications, like all traffic on the Internet, are not 100% guaranteed. Packets can be dropped due to spotty Internet connections or congestion on the device itself. Polling can be more robust, as if any individual response is dropped, the server has another chance to send the response the next time the client requests an update. But most of the time there isn’t any new update, and achieving low latency requires many requests, resulting in high bandwidth and power usage. We’ve combined the best of both worlds into a polling-with-short-circuit mechanism that we’re calling subscriptions. Subscriptions still use CoAP observations to get asynchronously notified of new updates with low latency. But it layers polling with a long interval on top. This ensures that in the ‘happy path’, devices are notified of any changes immediately. In the worst case, they are still notified eventually. This results in a small increase in power usage, and the polling is configurable via a new KConfig symbol called CONFIG_GOLIOTH_OTA_MANIFEST_SUBSCRITION_POLL_INTERVAL_S. We’re rolling this out first for OTA manifests, but soon we’ll use this subscription mechanism in place of all observations in the SDK.

More Flexible Wi-Fi

When we first added support for Wi-Fi devices to our samples, there was no standard way to store and retrieve Wi-Fi credentials in Zephyr, so we built our own. It was relatively simple, only allowing open or WPA2-PSK networks, and storing credentials in plaintext in Zephyr’s settings subsystem. Since that time, Zephyr has implemented a robust Wi-Fi Credentials library that outclasses our own. Credentials can be added through the wifi shell for a wide variety of network types, and credentials can be stored in PSA secure storage in addition to the settings subsystem. We’ve moved our samples to use this library, which will result in a more flexible experience for users, while bringing our samples in line with the wider Zephyr ecosystem.

Updated Platform Support

We’ve updated our support for Zephyr and the nRF Connect SDK to the latest versions. That’s v4.2.1 for Zephyr and v3.1.1 for the nRF Connect SDK. While there’s always lots of great additions in each release, this time around we’re particularly excited for the new silicon and boards that are supported in these new releases.

How OTA works with Pouch

[Pouch][2] is the Golioth innovation that enables [Bluetooth devices to talk through standard gateways up to the Cloud][3] and send/receive data like any other device on the cloud. It is end-to-end encrypted and can access nearly all of the same services as cellular, Wi-Fi, or Ethernet devices running the Golioth Firmware SDK. Here’s the order of events, as it works in our reference implementation:

1. Bluetooth device advertises that there is data to send
2. [Gateway][4] initiates connection with Bluetooth device
3. Bluetooth device sends data up to the cloud (uplink)
4. After uplink, available data (downlink) is sent down as a response, including services like OTA or Golioth settings
5. Bluetooth device disconnects and the entire cycle can start anew, depending on the device Note that it doesn’t need to work in that order, since many of the services in Pouch are independent of one another. Furthermore, it’s possible for you to create a completely bespoke version of the Gateway that handles Pouch traffic. But currently, our demos follow the order of events listed above. In my setup, I am using

[the pre-compiled binary that is built for the NXP FRDM-RW612][5]. Once I program that in and add Golioth credentials to the Gateway, I basically don’t need to think about it again. The Gateway logs the connections that are happening, but cannot see any of the traffic transiting through, since only the Cloud has keys paired with the Bluetooth device.

Visualizing OTA updates

We have been working on a demo using the Tikk board as an asset tracker, albeit a very LED-flashy one. Part of this work was developing a wake-on-movement behavior using the accelerometer (more about that in future posts). We pulled that work and the ability to control the LED matrix on the front of [the open source Tikk board][7]. So we put that all together and what do we get? A Bluetooth device that prompts you to shake it to get an update to the OTA firmware!

Modifications

This took the standard files you see in BLE GATT demo and added some new functionality. First in the ota_manifest_receive function, we add in some LED messaging to report the received firmware version and also clear out any previous indication of status, in case an OTA restarts.

static void ota_manifest_receive(const struct golioth_ota_manifest_component *components,
                                 size_t num_components)
{

    char buf[32];
    for (int i = 0; i < num_components; i++)
    {
        fw_size = components[i].size;
        LOG_DBG("Target: %s@%s, %d bytes",
                components[i].name,
                components[i].target,
               fw_size);
        LOG_HEXDUMP_DBG(components[i].target_hash,
                        GOLIOTH_OTA_COMPONENT_HASH_BIN_LEN,
                        "Target hash:");
        if (0 != strcmp(components[i].current, components[i].target))
        {
            golioth_ota_mark_for_download(components[i].name);
        }
        snprintk(buf,sizeof(buf),"FW ver %s ready", components[i].target);
    }
    led_message(buf);
    led_message("Shake to start");

    clear_led_progress_bar();
}

ota_main_receive we see how the blocks of data are received from the cloud 1K at a time. Much like the blockwise_upload that sends data in the other direction, the total image size is split up into chunks and then tracked block by block. Since we know the current block and we know the total size, we can do some math on the progress and apply that to the 105 LEDs on the front of the Tikk board.

static void ota_main_receive(const void *data, size_t offset, size_t len, bool is_last)
{
    LOG_DBG("Received %d bytes at offset %d", len, offset);

    int err = 0;
    if (count==0)
    {
        led_message("Starting FW update");
        count++;
    }
    if (0 == offset)
    {
        err = flash_img_init(&flash_context);
        if (err)
        {
            LOG_ERR("Failed to init flash write");
            return;
        }
        clear_led_progress_bar();
    }

    check_progress((uint32_t)offset);

    err = flash_img_buffered_write(&flash_context, data, len, is_last);
    if (err)
    {
        LOG_ERR("Failed to write to flash: %d", err);
        return;
    }

    if (is_last)
    {
        err = boot_request_upgrade(BOOT_UPGRADE_PERMANENT);
        if (err)
        {
            LOG_ERR("Failed to request upgrade");
            return;
        }

        LOG_INF("Rebooting to apply upgrade");

#if IS_ENABLED(CONFIG_LOG)
        while (log_process())
        {
        }
#endif
        led_message("Rebooting");
        k_sleep(K_SECONDS(3));

        sys_reboot(SYS_REBOOT_WARM);
    }
}

Try it out yourself

While the Tikk board itself is not available, you can try out OTA on your own Bluetooth devices right now. Grab one of the supported Gateway dev boards, upload the binary, program one of the supported Bluetooth nodes with a sample, and kick off an OTA within your cohort. You’ll see the device pulling down blocks and rebooting, ready to face the world with a shiny new version of firmware. [1]: https://golioth.io/connectivity [2]: https://github.com/golioth/pouch [3]: https://blog.golioth.io/bluetooth-open-beta/ [4]: https://github.com/golioth/bluetooth-gateway [5]: https://github.com/golioth/bluetooth-gateway/releases/tag/v0.1.0 [6]: https://github.com/golioth/pouch/tree/main/examples/ble_gatt [7]: https://blog.golioth.io/open-sourcing-the-tikk-demo-board/

Streams and Pipelines, Oh My

When we refer to Stream we’re talking about a cloud service that receives data from devices in an IoT fleet. Sensor readings are a prime example: these are data packets sampled at different points in time that get pushed to the cloud. Golioth uses a concept called Pipelines to transform and route this data. You must have a pipeline set up on the Golioth cloud that indicates what you want to happen with your data. For today, we’re going to use a Pipeline that listens on all paths for JSON-formatted data and routes it to Golioth’s own LightDB stream destination. But you can just as easily send CBOR or raw binary data and route it to GCP, Azure, AWS, your own server using webhooks, or a number of other available destinations. To follow along with this guide, Make sure you have the Legacy LightDB Stream JSON pipeline example enabled on your Golioth project. If you don’t you can click this link to automatically add it.

Firmware Concepts for Blockwise Stream

Microcontrollers have RAM limitations that make it difficult to hold the entire data set in memory in order to stream it over your network connection. This is where the “blockwise” part comes in. Golioth uses the CoAP protocol for securely transferring data to and from the cloud. The protocol has a payload limit of 1024 bytes per packet. The Golioth Firmware SDK implements an API that accepts 1024-byte blocks of data from your application, sending each to the cloud until the entire payload has been transferred. Your application needs to supply the data to the SDK using the following concepts:

• block index: the number of the current block in the overall transfer, beginning with 0.
• block size: the maximum size of a block (configurable with a default of 1024).
• data offset: the offset from the beginning of your data set from which to read the next block of memory. Your callback needs to calculate this by multiply the block index by the block size.
• buffer length: the length of the data (in bytes) supplied by your callback. This will be the same as the block size, except when sending the last block which may be smaller.
• last block: a boolean value your callback sets to indicate all data has been sent Let’s apply these concepts in a practical firmware example.

Blockwise Stream Firmware Example

We want an example that’s easy to set up and easy to see when the data has arrived on the cloud. For this reason we’ll use some hardcoded JSON data. It’s human-readable, and we’ll send it to Golioth’s internal LightDB destination because you can view received data directly on your project page.

/* Sample text source: Mind Volume LIX, Issue 236 https://academic.oup.com/mind/article-abstract/LIX/236/433/986238 */

static const char json_data[] = "{\"my-quote\":\"1. The Imitation Game\\nI propose to consider the question, ‘Can machines think?’ This should begin with definitions of the meaning of the terms ‘machine’ and ‘think’. The definitions might be framed so as to reflect so far as possible the normal use of the words, but this attitude is dangerous. If the meaning of the words ‘machine’ and ‘think’ are to be found by examining how they are commonly used it is difficult to escape the conclusion that the meaning and the answer to the question, ‘Can machines think?’ is to be sought in a statistical survey such as a Gallup poll. But this is absurd. Instead of attempting such a definition I shall replace the question by another, which is closely related to it and is expressed in relatively unambiguous words.\\nThe new form of the problem can be described in terms of a game which we call the ‘imitation game’. It is played with three people, a man (A), a woman (B), and an interrogator (C) who may be of either sex. The interrogator stays in a room apart from the other two. The object of the game for the interrogator is to determine which of the other two is the man and which is the woman. He knows them by labels X and Y, and at the end of the game he says either ‘X is A and Y is B’ or ‘X is B and Y is A’. The interrogator is allowed to put questions to A and B thus\"}";

static size_t json_data_len = strlen(json_data);

Blockwise Async Callback and User Arguments

We will call a synchronous API but the firmware SDK uses an asynchronous callback to get each block of data from your application. This means that the API call will block your application program flow until all data has been sent. This makes it really easy to keep the data in scope, but we need to make both the data pointer and the data length available in the async block read callback. You can do this with global variables but instead let’s pass a pointer as the callback argument. When the callback runs, it can cast the arg pointer to the correct type and access the data within.

struct block_stream_container {
    uint8_t *data;
    size_t data_len;
};

enum golioth_status stream_read_block(uint32_t block_idx,
                                      uint8_t *block_buffer,
                                      size_t *block_size,
                                      bool *is_last,
                                      void *arg)
{
    if (NULL == arg)
    {
        LOG_ERR("Expected block_stream_container pointer as arg but got NULL");
        return GOLIOTH_ERR_NULL;
    }
    struct block_stream_container *container = arg;

    uint32_t offset = block_idx * *block_size;

    /* Test to see if this is the final block of data we need to send */
    if (container->data_len <= offset + *block_size)
    {
        /* Overwrite the block_size that was passed in with number of bytes in last block */
        *block_size = container->data_len - offset;
        /* Indicate to the Golioth Firmware SDK that this is the final block */
        *is_last = true;
    }

    /* Copy our data into the supplied buffer */
    memcpy(block_buffer, container->data + offset, *block_size);

    LOG_INF("Sending block %u of %zu bytes.%s",
            block_idx,
            *block_size,
            *is_last ? " Final block." : "");

    return GOLIOTH_OK;
}

arg is not NULL it is cast to the block_stream_container we defined as part of the application. Now we can begin calculating the information we need to access the data. The Golioth Firmware API supplied the parameters we need to target the next block of data. First, we can use block_idx and block_size to calculate the offset from the start of the data. This offset is where we begin reading after the start of the data set we are trying to upload. Next, we need to know if there is enough data remaining to send a full block. Since the SDK has told us it wants block_size bytes of data, we first check to see if there’s more than that amount remaining (if so, this is not the last block). When we get to the end of the transfer, we will have a smaller block size (or exactly the block size and no more). In this case we need to set the is_last flag, and set the block_size to the actual amount of data for this final block. With our calculations finished, we need to copy the data into the block_buffer supplied by the SDK. Return GOLIOTH_OK to show the data has been copied and is ready to upload. If there is a problem and you want to cancel the upload, return any other error code.

Initiating a Blockwise Stream

We’ve already done all the hard work in our callback. Initiating the transfer is rather simple.

static void send_blockwise_stream(void)
{
    struct block_stream_container container;

    container.data = (uint8_t *)json_data;
    container.data_len = json_data_len;

    enum golioth_status status = golioth_stream_set_blockwise_sync(client,
                                                                   "my-test-path",
                                                                   GOLIOTH_CONTENT_TYPE_JSON,
                                                                   stream_read_block,
                                                                   &container);
    if (GOLIOTH_OK != status)
    {
        LOG_ERR("Failed to send blockwise stream: %d", status);
        return;
    }

    LOG_INF("Blockwise data successfully sent.");
}

Putting it all together

You can run the example code for yourself. Start with the stream sample from the Golioth Firmware SDK, replacing the main.c file with the one below. Build, flash, and provision the code following the README in the SDK.

/*
 * Copyright (c) 2025 Golioth, Inc.
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include 
LOG_MODULE_REGISTER(golioth_stream, LOG_LEVEL_DBG);

#include 
#include 
#include 
#include 
#include 
#include 
#include 

static const char json_data[] = "{\"my-quote\":\"1. The Imitation Game\\nI propose to consider the question, ‘Can machines think?’ This should begin with definitions of the meaning of the terms ‘machine’ and ‘think’. The definitions might be framed so as to reflect so far as possible the normal use of the words, but this attitude is dangerous. If the meaning of the words ‘machine’ and ‘think’ are to be found by examining how they are commonly used it is difficult to escape the conclusion that the meaning and the answer to the question, ‘Can machines think?’ is to be sought in a statistical survey such as a Gallup poll. But this is absurd. Instead of attempting such a definition I shall replace the question by another, which is closely related to it and is expressed in relatively unambiguous words.\\nThe new form of the problem can be described in terms of a game which we call the ‘imitation game’. It is played with three people, a man (A), a woman (B), and an interrogator (C) who may be of either sex. The interrogator stays in a room apart from the other two. The object of the game for the interrogator is to determine which of the other two is the man and which is the woman. He knows them by labels X and Y, and at the end of the game he says either ‘X is A and Y is B’ or ‘X is B and Y is A’. The interrogator is allowed to put questions to A and B thus\"}";

static size_t json_data_len = strlen(json_data);

struct golioth_client *client;
static K_SEM_DEFINE(connected, 0, 1);

static void on_client_event(struct golioth_client *client,
                            enum golioth_client_event event,
                            void *arg)
{
    bool is_connected = (event == GOLIOTH_CLIENT_EVENT_CONNECTED);
    if (is_connected)
    {
        k_sem_give(&connected);
    }
    LOG_INF("Golioth client %s", is_connected ? "connected" : "disconnected");
}

struct block_stream_container {
    uint8_t *data;
    size_t data_len;
};

enum golioth_status stream_read_block(uint32_t block_idx,
                                      uint8_t *block_buffer,
                                      size_t *block_size,
                                      bool *is_last,
                                      void *arg)
{
    if (NULL == arg)
    {
        LOG_ERR("Expected block_stream_container pointer as arg but got NULL");
        return GOLIOTH_ERR_NULL;
    }
    struct block_stream_container *container = arg;

    uint32_t offset = block_idx * *block_size;

    /* Test to see if this is the final block of data we need to send */
    if (container->data_len <= offset + *block_size)
    {
        /* Overwrite the block_size that was passed in with number of bytes in last block */
        *block_size = container->data_len - offset;
        /* Indicate to the Golioth Firmware SDK that this is the final block */
        *is_last = true;
    }

    /* Copy our data into the supplied buffer */
    memcpy(block_buffer, container->data + offset, *block_size);

    LOG_INF("Sending block %u of %zu bytes.%s",
            block_idx,
            *block_size,
            *is_last ? " Final block." : "");

    return GOLIOTH_OK;
}

static void send_blockwise_stream(void)
{
    struct block_stream_container container;

    container.data = (uint8_t *)json_data;
    container.data_len = json_data_len;

    enum golioth_status status = golioth_stream_set_blockwise_sync(client,
                                                                   "my-test-path",
                                                                   GOLIOTH_CONTENT_TYPE_JSON,
                                                                   stream_read_block,
                                                                   &container);
    if (GOLIOTH_OK != status)
    {
        LOG_ERR("Failed to send blockwise stream: %d", status);
        return;
    }

    LOG_INF("Blockwise data successfully sent.");
}

int main(void)
{
    LOG_DBG("Start Golioth blockwise stream sample");

    net_connect();

    /* Note: In production, credentials should be saved in secure storage. For
     * simplicity, we provide a utility that stores credentials as plaintext
     * settings.
     */
    const struct golioth_client_config *client_config = golioth_sample_credentials_get();

    client = golioth_client_create(client_config);
    golioth_client_register_event_callback(client, on_client_event, NULL);

    k_sem_take(&connected, K_FOREVER);

    /* Give network connection logs a few seconds to clear */
    k_msleep(2000);

    send_blockwise_stream();

    return 0;
}

*** Booting Zephyr OS build v4.1.0 ***
*** Golioth Firmware SDK v0.20.0 ***
[00:45:26.985,074]  golioth_settings_autoload: Initializing settings subsystem
[00:45:26.986,658]  fs_nvs: 8 Sectors of 4096 bytes
[00:45:26.986,675]  fs_nvs: alloc wra: 0, fa0
[00:45:26.986,679]  fs_nvs: data wra: 0, b6
[00:45:26.986,715]  golioth_settings_autoload: Loading settings
[00:45:26.986,912]  golioth_stream: main: Start Golioth blockwise stream sample
[00:45:26.986,929]  golioth_samples: Starting DHCP to obtain IP address
[00:45:26.987,001]  golioth_samples: Waiting to obtain IP address
[00:45:35.004,339]  net_dhcpv4: Received: 192.168.1.170
[00:45:35.004,816]  golioth_mbox: Mbox created, bufsize: 1320, num_items: 10, item_size: 120
[00:45:35.269,926]  golioth_coap_client_zephyr: Golioth CoAP client connected
[00:45:35.270,055]  golioth_stream: Golioth client connected
[00:45:35.270,191]  golioth_coap_client_zephyr: Entering CoAP I/O loop
[00:45:37.270,335]  golioth_stream: Sending block 0 of 1024 bytes.
[00:45:37.322,012]  golioth_stream: Sending block 1 of 349 bytes. Final block.
[00:45:37.407,104]  golioth_stream: Blockwise data successfully sent.

Going Deeper with Blockwise Stream Blockwise stream is a tool you should be using because it unlocks the ability to cache data locally into larger batches for upload at a convenient time. For instance, devices operating on battery power may opt to only upload data above a certain charge, and ambulatory devices may only have a network connection occasionally. Golioth’s data routing can separate readings

using the batch destination and use the extract-timestamp transform to parse timestamps embedded in the data for accurate accounting of each reading. While the example above is adequate for understanding how these block uploads work, in most cases you will not want to block program flow while uploading data. In an upcoming post we’ll cover using the asynchronous API, dynamic memory handling, and reading data from storage when using the blockwise stream feature.

What this means today: Bluetooth + Connectivity

One of the immediate wins from this partnership is the enhanced support for Bluetooth connectivity via ST hardware under our Golioth Connectivity offering. Here’s how Golioth enhances Bluetooth devices:

• One platform, every protocol. You use the same APIs, dashboards, monitoring, OTA, device settings, data streaming regardless of whether your device is Bluetooth, cellular, Wi-Fi, or anything else.
• Secure provisioning & built-in encryption. Critical for low-power or battery-constrained devices using Bluetooth, we’ve baked in security from the start. Zero Touch Provisioning (ZTP) makes Golioth and easy decision on the production line.
• OTA over BLE. Firmware and software updates over Bluetooth LE, keeping devices up to date, complying with new regulations like the Cyber Resilience Act (CRA), and reducing field maintenance.
• Gateway‑based architecture for Bluetooth. Constrained Bluetooth devices use a gateway to relay to the cloud to access the same services as directly connected devices. This can be a microcontroller-based gateway, a Linux based gateway, or a mobile phone app acting as a gateway.
• Unified dashboard. Manage all your devices from one place: Bluetooth, cellular, Wi-Fi, Thread, Ethernet. Same tooling. Same dashboard view. Less context switching. We already have demos showing ST’s hardware connecting

Bluetooth IoT devices via the STM32WB5MM-DK, using Bluetooth. This gives you a head start in building low‑power wireless devices on ST chips, with cloud connectivity handled via Golioth.

AI, ST Hardware & What’s Coming

On top of connectivity and Bluetooth, we’re pushing forward with Golioth AI Orchestration — enabling you to deploy, manage, and update edge‑AI workloads across fleets. A great example: the STM32N6 series, featured in the OpenMV N6 cameras — python‑programmable, low‑power AI cameras. Together with Golioth, devices like these can stream ML inferences, receive model updates, and be managed securely from the cloud.

What to Expect Next

From here, we’ll be focusing on:

• Deeper integration with ST’s development tools (e.g. SDKs, tools, references.)
• Continued enhancements to Golioth Connectivity for Bluetooth—faster onboarding, more gateway options, tighter security.
• Extending AI Orchestration support (models, pipelines) for ST’s edge‑AI capable chips. We’re really excited about this

partnership. Together with ST, and with robust Bluetooth + AI orchestration support, we want to make building connected, smart, and reliable devices easier than ever. We can’t wait to see what you build.

About the GTI-RW612 and NXP RW612 Chipset

We are big fans of NXP parts, including the tri-band radio on the RW612. We have precompiled Bluetooth gateway binaries for the FRDM-RW612, which is an affordable dev board from NXP and a super easy way to get started with Golioth Connectivity. You can route Pouch-based Bluetooth packets back to the cloud using either Ethernet or Wi-Fi. This chip is targeted at the Thread / Matter ecosystem as a Border Gateway all-in-one chip, and it hits the mark. Each of the radios have a dedicated memory space and there is an additional Ethernet interface to enable wired backhaul. The main application processor is built with a core of a Cortex M33, but running at a whopping 260 MHz! There is also a PowerQuad coprocessor, but honestly we haven’t scratched the surface at utilizing all of the capabilities on this chip yet. Globalscale took this part and created their own in-house module, the GTI-RW612B. Though the name is a bit confusing (similar to the name of the gateway that employs that module), the idea is clear: this is a module that enables precertified access to a capable chipset. The GTI-RW612 is the gateway itself, targeted at the Matter market as a border router. The unit comes with prebuilt firmware that is not source-available. It is based on MCUxpresso (another NXP specific firmware ecosystem), if you’re hoping to fire up the unit and start routing Matter traffic. Instead, we reprogrammed it using Zephyr and started digging into the peripherals to enable this as a Bluetooth gateway. Note that Golioth works great as a Thread enablement platform as well, so we could also use this as a Thread Border Router connected to Golioth…but that’s probably a blog post for another day.

Microcontroller Based Gateways

We have covered a different microcontroller based gateway in the past, the Sentrius MG100 from Ezurio. That has a Bluetooth main controller (nRF52840) and an attached cellular modem (Sierra Wireless HL7800). The enclosure is water resistant and works with Cat-M1 and NB-IOT, so it’s a good option for industrial use cases. The GTI Why use a microcontroller vs a larger Linux based gateway? One reason is that the gateway itself is a device on the Golioth platform, or as we call it, a “managed device”. The primary benefit is that you can utilize our OTA firmware update service for the gateway, in addition to the nodes that are connecting over Bluetooth through that gateway. But it is also easy to add features to the gateway, such as time-series data and logging. We did that with our internal platform called the Aludel Elixir, adding solar panel measurement. To bring the point home and contrast it with Thread, a Border Router is often invisible to the Golioth platform, as it is routing packets like a Wi-Fi router might (a benefit in the days before Pouch).

Getting the gateway working

The gateway showed up from the manufacturer effectively without firmware; or at least without firmware that we could use in our scenario. Instead, Mike had to bring up the board using our bluetooth-gateway repository, which is built on top of Zephyr. We do have the FRDM-RW612 supported in that repository, but there were a few key differences.

• The module had a different flash part than the FRDM-RW612, but it did match the in-tree board called rd_rw612_bga/rw612/ethernet
• The bootloader required adding a button and LED assignment
• The LCD needed to be defined in the overlay file
• LVGL needed to be added as a library in the manifest And most importantly, we needed to add a splash screen with the Golioth Logo:

Since the device is not meant to be opened by the end user, Mike enabled MCUboot so that new firmware can be loaded over the USB port using smpmgr. The factory would need to program the initial bootloader but then future firmware updates could be done over USB or more likely via Golioth’s OTA firmware update service.

Application Spaces

This device is a great fit in an office or light industrial use case. Personally I love an Ethernet connection to not need to set up the WiFi connection, but both are equally capable. This could be a great fit for simple asset tracking using Bluetooth, which we will be highlighting on the blog soon. This works for locations like:

• Hospitals
• Factory floors
• Warehouse spaces
• Offices We have other gateways we are looking at enabling on Golioth Connectivity, but we want to hear about what you need for your next Bluetooth application. Let us know on the forum or send an email to

devrel@golioth.io. We can’t wait to see what you build!

Signed URLs Background

Signed URLs are typically used on the web to grant time-limited access to private resources. The most common use is with Content Delivery Networks (CDNs), where a client may request a large private media asset from an origin server that is geographically far away, then be redirected to a closer CDN server with a signed URL to speed up the download of the asset. In order to avoid complex authentication and authorization logic across a large, geographically distributed CDN, the origin server can determine whether the client can access the asset, then generate a signed URL that the CDN server is able to verify as issued by the origin. When the client uses the signed URL, the CDN server verifies the signature in the URL, and ensures that the URL is not being used outside of any time restrictions included in URL parameters.

Bringing Signed URLs to Embedded Devices

While device signed URLs use a similar technique to traditional signed URLs, the device, which would usually be thought of as a client, is acting more like an origin server. But if the device is the origin server, then who is the client? To be more precise, a component on a device is acting like an origin server, and the client may be another component on the same device, or an external system that is communicating with the device. One motivating use case for this functionality is embedded devices with multiple communication interfaces. For example, many devices that connect to the Golioth platform leverage both cellular and Wi-Fi, with a separate microcontroller (MCU) managing each. Most modern MCUs support the ability to leverage a secure processing environment (SPE) for private key storage and cryptographic operations. The network stack running on the MCU is typically able to interact with the SPE in order to securely connect to an external server using (D)TLS or some other secure transport. However, the device manufacturer is responsible for generating private keys in the SPE and issuing certificates from their PKI during initial provisioning. If there are multiple components that need credentials to communicate over the network, the provisioning process and ongoing credential management becomes more complex. Furthermore, it may be the case that one component lacks sophisticated security features that are present on the other. With device signed URLs, a single component on a device can be provisioned with credentials, and can use its private key to issue time-limited signed URLs that may be distributed to other components over local communication interfaces (e.g. UART, SPI, etc.). Doing so grants the less secure component narrowly scoped access to a resource without transmitting any long-lived credentials.

Making Device Signed URLs Easy with signy

Generating signed URLs on embedded devices can be complex, which is why we have also built signy. signy takes care of crafting signed URLs in the format supported by Golioth, and makes use of the Arm Platform Security Architecture (PSA) Crypto API for all signing operations. This ensures that private keys can be stored and accessed securely, and that any cryptographic acceleration support on underlying hardware can be leveraged.

int err = signy_init(priv_key, device_crt_der, device_crt_der_len);
if (err != 0)
{
    LOG_ERR("Failed to initialize signy: %d", err);
    return -1;
}

err = signy_sign_url(CONFIG_BASE_URL,
                     strlen(CONFIG_BASE_URL),
                     signed_url,
                     sizeof(signed_url),
                     &signed_url_len);
if (err != 0)
{
    LOG_ERR("Failed to sign URL: %d", err);
    return -1;
}

signy repository is also a Zephyr module, meaning that it can easily be pulled into existing Zephyr applications with minimal configuration.

Looking Forward

We are excited about the new use cases that device signed URLs enable. Outside of the multi-MCU scenario described in this post, device signed URLs can also be leveraged to allow other devices without Golioth credentials, such as a smartphone connected to a Bluetooth Low Energy peripheral using Golioth Managed Connectivity, to download assets. Stay tuned for future posts, and let us know how you are using device signed URLs on the forum!

Digging into issues with drivers

I don’t know about you, but as a hardware engineer, I always assume the problem with code is… me. So my first instinct isn’t necessarily to start digging under the hood of Zephyr so much as “let’s figure out what I configured wrong”. This results in lots of tweaking of configurations like devicetree and kconfig symbols. Sometimes it happens that I need to check if those configurations are even taking effect though. This happened recently with configuring the behavior of an accelerometer we have on a lot of our development boards. I wanted to set up “wake on movement” and I have been struggling. I will get into the details of that in a future post once things are working better using many of the techniques I describe below. My co-worker Mike sat down with me and helped me do some of this debugging, and was the inspiration for this article. Mike has written about using GDB on the bootloader before (a more difficult task) but I realized we didn’t have an article about GDB on the application side of Zephyr. That’s likely because GDB is “obvious” to many engineers, but as this series of articles shows, “Zephyr for Hardware Engineers” is meant to empower folks who don’t dig under the hood of code that often.

GDB over other options?

My expectations around debugging are built from my early experiences with Eclipse-based tools offered from vendors:

• Pre-configured from the vendor, often set up for Windows
• Lots of buttons to click, but one with a bug and a play button
• Double click next to the line I want to break on, start the debugger, wait for the view to change to ‘debug view’, and hope for the best Transitioning from that to a more command-line driven development flow, it kind of makes sense that I would stick to printk debugging: where do I click? There are a growing number of vendor-specific options for building on different vendor ecosystems with Zephyr and getting pre-configured VS code setups to work with those boards. It’s still Zephyr and it’s a good option, but I wanted to use this learning opportunity to dig in.

Getting started with west and GDB

We’re unabashed fans of the west meta tool that Zephyr provides because it pulls together so many individual tools like the build system and Python scripts that manage tooling like autocompletion and SDK installation. The key command we’ll use here is west attach. After you build and flash the board (as we show how to do in our training pages), you are ready to connect the debugger. Why not use west debug? Well, that’s fine too, but requires more setup. And to be honest, when I see all my smartest firmware coworkers using attach…I take the hint. As an actual explanation: debug reflashes the ELF each time, which can overwrite flash areas you didn’t intend (e.g. bootloader), whereas west attach is non-destructive. Instead, you can run attach and hook up GDB whenever you’d like. If you want to run from the reset vector, you can use a command like monitor reset from within GDB (note the (gdb) callouts to see where you’re executing commands from within GDB vs on the normal command line. That command resets the remote GDB server–which thanks to west, we’re not really thinking about here, but is part of the equation. I should state my hardware setup, since variations could require different commands. I am building/testing for the Tikk board, which is plugged into an nRF52840 on a ProMicro-compatible form factor. I am connected to that board using a JLink PLUS Compact for programming and debugging, which should mirror other JLink setups. If you’re using a different debugger, look up Zephyr’s concepts of ‘runners’, which can/will be part of your build process and will allow you to customize for whichever board you might be building against. It’s possible (and preferable!) that these are already set up for many of the boards that are in-tree for Zephyr. So to recap:

west build -p -b promicro_nrf52840 tikk_fleet/app
west flash
west attach
(gdb) monitor reset

Commands within GDB

This is where I almost always get confused about what to do next. So I am writing this article for future-Chris as well. I will encase any shortcut with [ ] because main keywords are shortened for convenience/speed:

[b]reak sensor_read   # Function name to break on (ie. "sensor_read")
[b]reak main.c:34     # Call out a line ("34") of a file ("main.c") to break on
[c]ontinue            # Continue the program until next breakpoint 
[n]ext                # step over
[s]tep                # step into
[f]inish              # run until current function returns
[p]rint          # display latest variable, but also can print out complex data structures
[i]nfo [b]reakpoints  # list all breakpoints
[d]elete 1            # delete breakpoint #1 (shown in command above)
[b]ack[t]race         # see all calls that got you to where you currently are
[i]nfo threads        # see all threads (useful since this is an RTOS)
[w]atch          # break when a variable's value changes
x/32bx 0x20020000     # prints out 32 bytes in hex format from that address
clear                 # remove the breakpoint you just stopped on

[n]ext and [s]tep, it’s also possible to repeat the action by continuing to hit the enter key, especially useful as you’re stepping through a program. Oh man, there are so many more. This is a deep rabbit hole and there are literal books on the subject. The above will get you started. Almost any command has a help menu that’s accessible from within the (gdb) command line, so take advantage of that as well.

Getting more context with TUI

This one really unlocked more useful info for me. If I’m in a terminal window for my project and I type in west attach, it’ll do that. But where am I in the code? What are some of the available symbols. It’s almost like entering a video game level without a map. Well if you want a map, hit ctrl + x and then a, you will be shown the current location in a program From here you can scroll up and down in that file. If you don’t want to have focus on the code window, you can repeat the ctrl + x, a command to close the window or ctrl + x, o to change ‘focus’ back to the (gdb) terminal prompt. Other ways to enable TUI include:

layout src           # show source window (same as ctrl + x, a)
layout asm           # show assembly window
layout split         # source + assembly split
layout regs          # registers window
focus src            # focus on the source window (same as ctrl + x, o)

Other navigation

ctrl + c interrupts the target, which is especially useful if your interface gets locked up. ctrl + d from the (gdb) command line will gracefully exit help from the (gdb) command line will introduce you to myriad other commands, as will other resources about GDB online. This is just the tip of the iceberg for fellow hardware engineers.

So how did you solve your problem?

The resolution to the problem with the accelerometer is ongoing from a code perspective. I still am not completely certain why configuration isn’t passing down over the i2c bus to the LIS2DH. However, I was able to trigger the expected behavior by directly modifying registers on the i2c device using the i2c shell, another favorite troubleshooting tool around these parts. I could directly manipulate the values I needed to turn on the interrupt mode that I wanted. With the shell interface to i2c and the ability to halt on code and dig into the problem, I’m certain I’ll be able to troubleshoot the root cause. As always with electronics, having the right tool for the job makes things much easier. I’m grateful to have expert co-workers that also help guide me along the path, and hope this article does the same for you. If you get stuck please let us know over on the Golioth forum.

Why not just make it part of the firmware?

Why are we even doing this, can’t these files just be built into the firmware? The problem with hardcoding data like this is that you need to update the whole firmware image to change them. Take the case of machine learning models. These models are commonly trained on specialized hardware, and only once the model has been refined is it presented to the constrained device (your microcontroller-based product). If a more performant model is available later on, you want to be able to update just the model. Firmware updates consume bandwidth (which for cellular has a cost) and battery budget. Golioth specializes in OTA updates of not just firmware, but assets like ML models. So you can send the new model as an OTA asset which gets written to the filesystem. Separating this data into a filesystem makes a lot of sense. You can update the firmware without sending the machine learning model with it. The device is also capable of updating what’s on the filesystem without touching the firmware its currently running. So let’s take care of the chicken and egg issue by flashing a populated filesystem as devices roll off the line.

Running the Zephyr LFS Sample

Zephy has a built-in support for LFS, the “little fail-safe filesystem designed for microcontrollers”. The RTOS reserves a partition for the filesystem, and at first run it will format the partition if unable to a read valid filesystem configuration. We can build the Zephyr LFS sample to see the formatting happen, and the sample will also populate some files in the filesystem afterward. I’m building for the NXP frdm_rw612 board. By default, this sample will build a filesystem that is ~57MB, so I’m going to use a devicetree overlay file to create a more manageable ~24k filesystem.

/delete-node/ &storage_partition;

/ {
    fstab {
        compatible = "zephyr,fstab";
        lfs1: lfs1 {
            compatible = "zephyr,fstab,littlefs";
            mount-point = "/lfs1";
            partition = <&lfs1_part>;
            automount;
            read-size = <16>;
            prog-size = <16>;
            cache-size = <64>;
            lookahead-size = <32>;
            block-cycles = <512>;
        };
    };
};

&w25q512jvfiq {
    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        lfs1_part: partition@623000 {
            label = "storage";
            reg = <0x623000 0x6000>;
        };
    };
};

west build -p -b frdm_rw612
west flash

I: littlefs partition at /lfs1
I: LittleFS version 2.10, disk version 2.1
I: FS at w25q512jvfiq@0:0x623000 is 6 0x1000-byte blocks with 512 cycle
I: partition sizes: rd 16 ; pr 16 ; ca 64 ; la 32
E: WEST_TOPDIR/modules/fs/littlefs/lfs.c:1389: Corrupted dir pair at {0x0, 0x1}
W: can't mount (LFS -84); formatting
I: /lfs1 mounted
I: Automount /lfs1 succeeded
*** Booting Zephyr OS build v4.1.0 ***
Sample program to r/w files on littlefs
Area 0 at 0x623000 on w25q512jvfiq@0 for 24576 bytes
/lfs1 automounted
/lfs1: bsize = 16 ; frsize = 4096 ; blocks = 6 ; bfree = 4

Listing dir /lfs1 ...
/lfs1/boot_count read count:0 (bytes: 0)
/lfs1/boot_count write new boot count 1: [wr:1]
I: Test file: /lfs1/pattern.bin not found, create one!
------ FILE: /lfs1/pattern.bin ------
01 55 55 55 55 55 55 55 02 55 55 55 55 55 55 55
03 55 55 55 55 55 55 55 04 55 55 55 55 55 55 55

--- snip ---

43 55 55 55 55 55 55 55 44 55 55 55 55 55 55 55
45 55 aa
I: /lfs unmounted
/lfs unmount: 0

Reading and Analyzing an LFS Partition

Now that we have a filesystem on the device, let’s read it from flash and analyze the contents. I’m using a J-Link to read the memory. For this particular chip, flash is locate at an offset of 0x8000000. Combine this with the partition address (0x623000) and size (0x6000) from our devicetree overlay file and we can read the LFS partition to a file.

JLinkExe -Device RW612 -if SWD -Speed 4000
connect
SaveBin lfs.bin 0x8623000 0x6000

littlefs-python that we can use to view the files on the filesystem. Let’s install it and list the files. If you go back and look at the output of the sample program you’ll notice the filesystem is reported 6 blocks of size 0x1000 (4096 bytes) which we use when viewing the binary.

pip install littlefs-python
littlefs-python list lfs.bin --block-size 4096

/boot_count
/pattern.bin

littlefs-python extract --block-size 4096 lfs.bin output/

Creating an LFS Binary

Now for the main event. Let’s create our own filesystem binary and write it to the device. I’m going to start by setting up the desired filesystem on my computer. I’m going to do this with empty files but of course any files may be used here.

mkdir my-new-fs
touch my-new-fs/hello-there.txt
mkdir my-new-fs/models
touch my-new-fs/models/yolo.bin

my-new-fs/
├── hello-there.txt
└── models
    └── yolo.bin

littlefs-python create my-new-fs/ lfs-new.bin --block-size 4096 --block-count 6

littlefs-python list lfs-new.bin --block-size 4096

/models
/hello-there.txt
/models/yolo.bin

JLinkExe -Device RW612 -if SWD -Speed 4000
connect
LoadBin lfs-new.bin 0x8623000
reset

Using Zephyr’s Filesystem Shell

We can recompile and reflash our firmware to enable the shell. Remember, the filesystem is on its own partition, so this will not overwrite our data. One change is required in the sample code. At the end of the application, the filesystem is unmounted. We want to leave it mounted so we can list the files. Before rebuilding, comment out these two lines at the end of main.c:

/*rc = fs_unmount(mountpoint);*/
/*LOG_PRINTK("%s unmount: %d\n", mountpoint->mnt_point, rc);*/

west build -p -b frdm_rw612 -- -DCONFIG_SHELL=y -DCONFIG_FILE_SYSTEM_SHELL=y
west flash

uart:~$ fs ls
lfs1/
uart:~$ fs ls lfs1
boot_count
hello-there.txt
models/
pattern.bin
uart:~$ fs ls lfs1/models
yolo.bin

What will you use it for?

These are some nice filesystem tricks that may come in handy during a manufacturing run. While we’ve used Zephyr’s SMP subsystem to read from and write to the filesystem, that requires the SMP to be built into your application. A programmer is already present on the production line, so writing a filesystem at the same time as the firmware makes sense. If it’s the same filesystem for every device, the binary may be bundled along with the firmware. But there are use cases where each device would have different data. Such is the case where certificate authentication is used. Your PKI should have the device itself generate a key, and the certificate signing request (CSR) may be written to the filesystem then read/signed and the resulting public cert written back onto the device. Whatever your use case, we’d love to hear about why you need to read/write the filesystem. Let us know by posting to the Golioth forum!

What’s in the code

The tikk-fleet project that enables this digital signage demo is based on our Pouch BLE GATT example program. It extends the capabilities by listening for different settings and then acts on those settings using a IS31FL3731 driver for Zephyr. This basically turns settings on the Golioth Cloud into scrolling text or arrows on the device. For the scrolling text, we explained what that looks like on the last post, so check that out. For the arrows being shown in this demo, there is a setting handler that looks for one of 4  integer values coming from the cloud. This is used to trigger the directions of the arrows on the IS31FL3731 driver, which ultimately is a set of frames that are stored and replayed to get different motion in the arrows.

static int led_arrow_cb(int new_value)
{
    if (_arrow_dir == new_value)
    {
        return 0;
    }

    _arrow_dir = new_value;

    switch (_arrow_dir)
    {
        case 0:
            scroll_arrows(led_dev, false, false);
            break;
        case 1:
            scroll_arrows(led_dev, true, false);
            break;
        case 2:
            scroll_arrows(led_dev, false, true);
            break;
        case 3:
            scroll_arrows(led_dev, true, true);
            break;

        default:
            LOG_WRN("Unsupported scroll settings: %i", new_value);
            break;
    }

    return 0;
}

GOLIOTH_SETTINGS_HANDLER(ARROW, led_arrow_cb);

Commissioning fleets with certificates

As you’ll see over the coming weeks and months on the Golioth blog, we’re thinking about producing devices for production grade fleets. You may have also noticed that one requirement that is different for Golioth Connectivity (and our new Bluetooth support) is that indirectly connected devices can only validate onto the Golioth platform using certificates. This is different than directly connected devices, which can still prototype using Pre-Shared Keys (PSKs) before going to production with certificates. For a device like the Tikk, we were able to take the various steps in our Public Key Infrastructure documentation and turn it into a Python script to quickly generate device keys from the Certificate Authority. This is still using a locally generated Root CA–and we highly recommend using a PKI provider to hold your keys–but it lessened the load on generating and pushing the certs onto the Tikk device. Here’s what the Python script looks like:

#!/usr/bin/env python3
import argparse
import csv
import subprocess
import sys
from pathlib import Path
import shutil
import datetime

def check_tool(name: str):
    if shutil.which(name) is None:
        sys.exit(f"ERROR: Required tool '{name}' not found on PATH.")

def run(cmd, cwd=None, dry_run=False):
    print(">>", " ".join(cmd))
    if dry_run:
        return 0
    try:
        res = subprocess.run(cmd, cwd=cwd, check=True, capture_output=True, text=True)
        if res.stdout.strip():
            print(res.stdout.strip())
        if res.stderr.strip():
            print(res.stderr.strip())
        return res.returncode
    except subprocess.CalledProcessError as e:
        print(e.stdout or "", end="")
        print(e.stderr or "", end="")
        sys.exit(f"Command failed with exit code {e.returncode}: {' '.join(cmd)}")

def make_subject(project_slug: str, cert_id: str) -> str:
    return f"/O={project_slug}/CN={cert_id}"

def prompt_yes_no(prompt: str, default_no=True) -> bool:
    ans = input(prompt).strip().lower()
    if ans in ("y", "yes"):
        return True
    if ans in ("n", "no"):
        return False
    return not default_no  # empty -> default to no

def prompt_int_with_default(prompt: str, default_val: int) -> int:
    while True:
        s = input(f"{prompt} [default {default_val}]: ").strip()
        if s == "":
            return default_val
        try:
            v = int(s)
            if v <= 0:
                print("Please enter a positive integer.")
                continue
            return v
        except ValueError:
            print("Please enter a valid integer.")

def ensure_ca_exists(dry_run: bool):
    ca_crt = Path("ca.crt.pem")
    ca_key = Path("ca.key.pem")
    if ca_crt.exists() and ca_key.exists():
        return

    print("No local CA found (ca.key.pem, ca.crt.pem).")
    if not prompt_yes_no("Would you like to generate a new Root CA now? [y/N]: "):
        sys.exit("ERROR: Root CA is required. Provide ca.key.pem and ca.crt.pem or allow generation.")

    days = prompt_int_with_default("Enter validity period in days for Root CA", 365)
    print(f"Generating Root CA with validity: {days} days")

    # Generate CA key
    run(["openssl", "ecparam", "-name", "prime256v1", "-genkey", "-noout", "-out", "ca.key.pem"], dry_run=dry_run)

    # Self-signed CA certificate
    run([
        "openssl", "req", "-x509", "-new", "-nodes",
        "-key", "ca.key.pem",
        "-sha256", "-subj", "/CN=Root CA",
        "-days", str(days), "-out", "ca.crt.pem"
    ], dry_run=dry_run)

    expiry_date = datetime.datetime.now() + datetime.timedelta(days=days)
    print(f"Root CA created with validity: {days} days")
    print(f"Root CA will expire on: {expiry_date.strftime('%Y-%m-%d')}")

def provision_one(project_slug: str, cert_id: str, serial_port: str, days: int, mtu: int, outdir: Path, dry_run: bool):
    device_dir = outdir / cert_id
    device_dir.mkdir(parents=True, exist_ok=True)

    # Compute expiry and filenames
    expiry_date = datetime.datetime.now() + datetime.timedelta(days=days)

    # Filenames (include cert_id and expiry date: CERTID_YYYY-MM-DD)
    base_name = f"{cert_id}_{expiry_date.strftime('%Y-%m-%d')}"
    key_pem = device_dir / f"{base_name}.key.pem"
    csr_pem = device_dir / f"{base_name}.csr.pem"
    crt_pem = device_dir / f"{base_name}.crt.pem"
    key_der = device_dir / f"{base_name}.key.der"
    crt_der = device_dir / f"{base_name}.crt.der"

    ca_crt = Path("ca.crt.pem")
    ca_key = Path("ca.key.pem")
    if not ca_crt.exists() or not ca_key.exists():
        sys.exit("ERROR: ca.crt.pem and/or ca.key.pem not found in current directory.")

    print(f"\n=== Provisioning {cert_id} on {serial_port} ===")
    print(f"Output dir: {device_dir}")
    print(f"Certificate validity: {days} days")
    print(f"Certificate will expire on: {expiry_date.strftime('%Y-%m-%d')}")

    # 1) EC private key
    if not key_pem.exists():
        run(["openssl", "ecparam", "-name", "prime256v1", "-genkey", "-noout", "-out", str(key_pem)], dry_run=dry_run)
    else:
        print(f"Skip key (exists): {key_pem}")

    # 2) CSR
    subj = make_subject(project_slug, cert_id)
    run(["openssl", "req", "-new", "-key", str(key_pem), "-subj", subj, "-out", str(csr_pem)], dry_run=dry_run)

    # 3) Sign certificate
    run([
        "openssl", "x509", "-req",
        "-in", str(csr_pem),
        "-CA", str(ca_crt),
        "-CAkey", str(ca_key),
        "-CAcreateserial",
        "-out", str(crt_pem),
        "-days", str(days),
        "-sha256"
    ], dry_run=dry_run)

    # 4) Export DER
    run(["openssl", "ec", "-in", str(key_pem), "-outform", "DER", "-out", str(key_der)], dry_run=dry_run)
    run(["openssl", "x509", "-in", str(crt_pem), "-outform", "DER", "-out", str(crt_der)], dry_run=dry_run)

    # 5) Upload via smpmgr
    run(["smpmgr", "--port", serial_port, "--mtu", str(mtu), "file", "upload", str(key_der), "/lfs1/credentials/key.der"], dry_run=dry_run)
    run(["smpmgr", "--port", serial_port, "--mtu", str(mtu), "file", "upload", str(crt_der), "/lfs1/credentials/crt.der"], dry_run=dry_run)

    print(f"Done: {cert_id} ✔")

def parse_csv(csv_path: Path):
    items = []
    with csv_path.open(newline="") as f:
        reader = csv.DictReader(f)
        required = {"cert_id", "serial_port"}
        if not required.issubset(reader.fieldnames or {}):
            sys.exit(f"ERROR: CSV must have headers: {', '.join(sorted(required))}")
        for row in reader:
            cert_id = row["cert_id"].strip()
            serial_port = row["serial_port"].strip()
            if not cert_id or not serial_port:
                print(f"WARNING: Skipping row with missing cert_id or serial_port: {row}")
                continue
            items.append((cert_id, serial_port))
    return items

def main():
    ap = argparse.ArgumentParser(
        description=(
            "Provision devices with OpenSSL + smpmgr uploads.\n\n"
            "Files are written under ./provisioned// using names like\n"
            "_YYYY-MM-DD.key.pem / .csr.pem / .crt.pem / .key.der / .crt.der\n\n"
            "If run with only --project-slug, the script will check/generate a Root CA and then exit with examples."
        )
    )
    ap.add_argument("--project-slug", required=True, help="Organization (O=) field for the certificate subject.")
    ap.add_argument("--cert-id", help="Device certificate ID (CN=) for single-device mode.")
    ap.add_argument("--serial-port", help="Serial port for single-device mode (e.g. /dev/ttyACM0, COM5).")
    ap.add_argument("--csv", type=Path, help="CSV with headers: cert_id,serial_port for batch mode.")
    ap.add_argument("--days", type=int, default=365, help="Certificate validity in days (default: 365).")
    ap.add_argument("--mtu", type=int, default=128, help="smpmgr MTU (default: 128).")
    ap.add_argument("--outdir", type=Path, default=Path("provisioned"), help="Base output directory (default: ./provisioned).")
    ap.add_argument("--dry-run", action="store_true", help="Print commands without executing.")
    args = ap.parse_args()

    check_tool("openssl")
    check_tool("smpmgr")

    # Ensure local Root CA exists or offer to generate one
    ensure_ca_exists(args.dry_run)

    # If no devices/CSV provided, cleanly exit after CA prep with next-step examples
    if not args.csv and (not args.cert_id or not args.serial_port):
        print("\nRoot CA is present and ready.")
        print("CA files: ca.key.pem, ca.crt.pem")
        print("\nNext, provision devices in one of two ways:\n")
        print("Single device:")
        print(f"  python3 provision_devices.py \\\n    --project-slug {args.project_slug} \\\n    --cert-id DEVICE123 \\\n    --serial-port /dev/ttyACM0")
        print("\nBatch (CSV with headers cert_id,serial_port):")
        print(f"  python3 provision_devices.py \\\n    --project-slug {args.project_slug} \\\n    --csv devices.csv")
        sys.exit(0)

    items = []
    if args.csv:
        items.extend(parse_csv(args.csv))
    if args.cert_id and args.serial_port:
        items.append((args.cert_id, args.serial_port))

    timestamp = datetime.datetime.now().strftime("%Y-%m-%d_%H-%M-%S")
    print(f"Starting provisioning at {timestamp}")
    print(f"Project slug: {args.project_slug}")
    print(f"Devices: {len(items)}")
    args.outdir.mkdir(parents=True, exist_ok=True)

    for cert_id, serial_port in items:
        provision_one(args.project_slug, cert_id, serial_port, args.days, args.mtu, args.outdir, args.dry_run)

    print("\nAll done. 🎉")

if __name__ == "__main__":
    main()

How this could be modified

While there aren’t a ton of direct commercial use cases for a 25×15 mm LED sign, the idea is the same throughout the industry. Many devices could take our Settings service and apply it to portions of their fleet. As Golioth Connectivity continues to expand, we’ll be looking at other transport mechanisms to get the same encrypted data over other channels to devices (think CAN, LoRa, or even serial). One important distinction is that each device is directly communicating back through the cloud through a gateway. Effectively the Bluetooth device using Pouch is an internet connected device…just using an additional hop. This is different than the behavior that might be expected for updating a range of signs in a small area all at once. We have shown a BLE Mesh demo in the past that achieves that goal, but has many other challenges, including not actually being enabled by Golioth Connectivity (that demo far preceded our announcement). If we wanted similar behavior on this setup, we could instead implement a schedule, upon which all signs would change. But that requires additional features that deliver time to each device. If you’re interested in time-based updates, please reach out! We’ll continue to have demos using the Tikk board and Golioth Connectivity. If you have a use case you’d like us to take on, please drop a note on our forum!

Apply settings to all or one

The Golioth Settings service delivers fleet control from the cloud down to devices. For example, let’s consider Bluetooth (BLE) devices that sleep most of the time but occasionally wakes up to upload sensor data via a gateway. The amount of time spent in the sleep state can be added as a setting that applies to the entire fleet, but the same setting may also be tweaked on a device-by-device basis. If you know your entire fleet is going to be collecting more sensor data than usual, you can make one change and all devices will update their sleep pattern the next time they check in. In the same way, the setting for a single device may be adjusted separately from the fleet-wide setting. Since this is built into the Golioth platform, its really easy to add it to your Bluetooth firmware. Let’s see what is involved in adding a new setting.

Prerequisite: Run the sample application

If you don’t already have a Bluetooth fleet on Golioth, follow the Getting Started guide in the Bluetooth Gateway repository and add a leaf-node by following the example app in the Pouch repository. This will get you up and streaming simulated sensor data to the cloud in no time. Golioth is free for individuals making it frictionless to take it for a test-drive. You will need to get hardware that matches the recommended boards for the lowest-friction experience. The sample Pouch application already supports the Settings service to switch an LED on or off remotely. From the cloud, this is just a few clicks to add a boolean setting called LED. The device-side code that supports this setting couldn’t be easier. It’s made up of a function that will run as a callback, and a macro to register that callback.

static int led_setting_cb(bool new_value)
{
    LOG_INF("Received LED setting: %d", (int) new_value);

    if (DT_HAS_ALIAS(led0))
    {
        gpio_pin_set_dt(&led, new_value ? 1 : 0);
    }

    return 0;
}

GOLIOTH_SETTINGS_HANDLER(LED, led_setting_cb);

the callback function prototypes specified in the Pouch library. In this case we know the callback is for a Setting of boolean type because that’s the type for the parameter passed into this function. The last line is important because it registers this callback. The parameters used in that registration are the settings name that will trigger the callback (LED) and the function to run when that setting is received. The code inside the actual function is up to you. In this example, the new setting is logged. Next the function checks to see if there is an LED enabled in the devicetree, toggling it when found. I suppose I said there are only two important parts, but the return code is also important. Whether successful or not, the return code will be reported back to the cloud, indicating that the device successfully (or unsuccessfully) received the settings update. Lets try adding our own setting to the fleet.

Adding a setting to send text to the Bluetooth fleet

If your Bluetooth IoT devices have a user interface, like a screen, you may want to send messages to them. Lets add a setting that sends a string to the fleet. First, add the setting in the Golioth web console. The screenshot above shows a setting called MESSAGE added as a String type. The value is the string that should initially be sent to the fleet. The value may be changed at any time (although the key and data type are immutable because they need to match what is built into the firmware). Adding this setting to the firmware is nearly the same as we saw in the previous section, requiring a callback function that is then registered for this setting.

#include 

#define MESSAGE_MAX_LEN 64
char _stored_msg[MESSAGE_MAX_LEN + 1];

static int settings_message_cb(const char *new_value, size_t len)
{
    if (MESSAGE_MAX_LEN < len)
    {
        LOG_ERR("Received message is too long: %zu > %u", len, MESSAGE_MAX_LEN);
        return -1;
    }

    if (0 == memcmp(_stored_msg, new_value, len))
    {
        return 0;
    }

    LOG_DBG("New MESSAGE setting: %.*s", len, new_value);
    snprintk(_stored_msg, MESSAGE_MAX_LEN, "%.*s", len, new_value);
    scroll_message(led_dev, _stored_msg, 50);

    return 0;
}

GOLIOTH_SETTINGS_HANDLER(MESSAGE, settings_message_cb);

Data Up, Settings and OTA Update Down

Golioth Connectivity enables a new generation of Bluetooth devices that can send any data they like to the cloud. At the same time, you can control your fleet using the Settings service, and update the leaf nodes using the OTA service. We’re happy to welcome the world of Bluetooth devices properly to the Internet, and its ready for you to start using right now!

Join the livestream at 2 pm ET / 11 am PT on August 29th

Step 1 – Cloud control

This step is exceedingly easy, and you’ve surely already completed it: get yourself a Golioth account. This takes care of the cloud side of the equation: no setting up databases or creating IAM profiles and hoping you don’t give the wrong people the right access.

Step 2 – App / Gateway control

Another easy step! This one replaces the need to learn how to design an app. Instead, you can download a binary that goes onto one of these 3 development boards:

• NXP FRDM-RW612
• Nordic Thingy: 91X
• Nordic nRF9160-DK Follow the instructions on the repository to

download the pre-compiled binary, create a device on your Golioth console, and assign credentials to the gateway. Bingo, you have a bluetooth-to-cloud gateway.

Step 3 – Bluetooth node control

This is the bulk of the activity we’ll be focusing on during the livestream tomorrow, since the Bluetooth nodes in your fleet contain the smarts (firmware) and the credentials to talk through the gateway up to the cloud. First, you need to look at our Pouch repository, which has a ble_gatt example. This is the basis for sending up a packet that has been encrypted with the cloud but is still allowed to traverse the gateway. Unstated in the directions is how to create a Zephyr workspace. If you are working from a fresh environment, it might look like this: Install the Python virtual environment (recommended)

cd ~
mkdir pouch-test
cd pouch-test
python -m venv .venv
source .venv/bin/activate
pip install wheel west ecdsa

Use west to initialize and Install

west init -m git@github.com:golioth/pouch.git .
west update --narrow -o=--depth=1
west zephyr-export
pip install -r zephyr/scripts/requirements.txt
pip install -r pouch/requirements.txt

you would build against the board you’re looking to try out. The pouch repository was extensively tested against nrf52840dk/nrf52840:

west build -p -b nrf52840dk/nrf52840 pouch/examples/ble_gatt
west flash

Check out the new Bluetooth section on our forum to try chips from different vendors and see what you might need to do differently (and ask questions about each, as needed).

Step 3a – Using certificates

One of the biggest differences everyday Golioth users might notice is that Bluetooth nodes must use certificates in order to connect to the cloud (through a gateway). This is explained in our introduction video for Golioth Connectivity and we’ll continue to publish about the role of security in our new paradigm of indirectly connected devices. The example application we just built has a “Little Filesystem” (littlefs or lfs) included with it. That allows us to push certificates onto the device using some standard SMP tooling. You will first need to generate your own certificates using openssl; follow the Public Key Infrastructure (PKI) docs page to do so.

Step 4 – Put it all together

Once your gateway is booted up and your Bluetooth node connects through the gateway to the cloud, you will see both devices on your console. If you create a node with a brand new Certificate ID, that node will be created on your project account the first time it connects (allowing zero-touch provisioning). Add a new device setting LED as a boolean, and that will be passed down over the gateway to the node and will toggle the LED. The node will also publish a simulated temperature every 20 seconds (the pre-defined advertising interval). We’ll show all of this in action in the Livestream on the 29th.

See it in action right now

Yesterday we posted a video of a Bluetooth device talking using Pouch through a standard gateway up to the Cloud to complete an Over-The-Air firmware update. This is a preview of Golioth Connectivity in action. Want to learn how to do it yourself? Sign up for the livestream on August 29th at 2 pm ET / 11 am PT…or watch it on demand!

We’re excited to announce that Bluetooth support is now available in Open Beta for all Golioth users. With this release, Golioth now brings full device management and data routing to Bluetooth-based devices, even those without direct internet access. Developers can now stream telemetry, perform OTA firmware updates, manage settings, and log events using the same Golioth services they already use for devices with a direct internet access. Previously available in private access, Bluetooth support is now open to all users as a part of a broader initiative we call Golioth Connectivity. This enables a flexible and unified approach to connecting devices to the cloud, whether directly via Wi-Fi, Ethernet, or Cellular, or indirectly through a local gateway. As part of this release, Bluetooth Low Energy (BLE) devices can now connect to the Golioth platform securely through a gateway. These BLE devices, which often lack native internet connectivity, are now able to stream data, receive firmware updates, and be fully managed through the Golioth Console. To power this experience, developers use Pouch, an open source SDK for building firmware that communicates over protocols like BLE without a direct internet connection. Pouch provides an efficient, encrypted, and authenticated communication layer between BLE devices and the cloud, enabling seamless integration with Golioth services. While this open beta focuses on BLE, Pouch is designed to be extensible and will soon support additional protocols such as LoRa, CAN & Modbus. This paves the way for broader support of gateway-based communication strategies across diverse IoT deployments. With these capabilities, Golioth extends full cloud control to BLE devices, streamlining deployment and operations for devices that typically lack direct cloud integration. Developers can now manage, update, and monitor BLE-based device fleets with the same ease and infrastructure used for other connected hardware. This also extends all of Golioth’s AI capabilities to unlock new Edge and Physical AI use cases.

Gateways

To help developers get started quickly, Golioth provides reference implementations that use popular development boards configured as BLE gateways. These reference gateways include both pre-compiled binaries and fully open source firmware, available on GitHub.

• NXP FRDM-RW612
• Nordic Semiconductor Thingy:91 X
• Nordic Semiconductor nRF9160DK These boards offer a fast path for evaluating BLE gateway functionality and provide a foundation for building custom gateway implementations. In addition to reference hardware, Golioth is partnering with leading providers to offer off-the-shelf BLE gateways that are pre-validated to work with Golioth Connectivity, including

Ezurio, Arduino, Globalscale Technologies, Minew & Device Solutions. These ready-made options give teams the flexibility to align their gateway choice with their product architecture and deployment needs. At the same time, they allow developers to focus on building their Bluetooth-based product rather than reinventing the wheel by creating gateway infrastructure from scratch. Our users can build upon the Reference Implementation in the bluetooth_gateway repository and create their own production-grade gateway. Golioth’s in-house prototyping platform the Aludel Elixir will be a showcase of how to do that on custom hardware.

Building a Bluetooth device

We have shown over the past few month a range of different development kits working as  nodes with our Bluetooth support (then called Bluetooth-to-Cloud). This includes hardware from Espressif, Nordic Semiconductor, NXP, Renesas, Silicon Labs & STMicroelectronics. Each of those links are forum posts that will track any required changes to get various development boards working, and offer a place to discuss issues getting hardware booted up on Golioth. We have ongoing reference hardware and implementations that will grace the pages of this blog, such as the recently announced Tikk add-on board.

Pricing

During the open beta, users can add unlimited BLE devices at no extra cost. This is a great time to test BLE deployments and explore Golioth Connectivity without device-based fees. Standard platform and service usage fees still apply. See the pricing page for details. Once Golioth Connectivity reaches General Availability, pricing will apply to BLE devices that use an advanced feature of Bluetooth Connectivity that allows devices to seamlessly utilize multiple gateways for better coverage. We call this feature “roaming.” After GA, the rate for devices that roam is $0.50 per device, with volume discounts available for larger deployments.

Get started today

If you’re ready to explore Bluetooth support with Golioth Connectivity, there are several ways to dive in:

• Review the Golioth Connectivity documentation for detailed technical guides and integration patterns
• Try out our reference gateway firmware to quickly stand up a BLE gateway integration
• Choose from a supported board to begin prototyping
• Browse the docs
• Explore one of the sample projects As you get started with managing BLE devices during our open beta, we’d love to hear from you. Your feedback is critical as we refine the experience and work toward general availability. Join the conversation and share your questions, comments, or suggestions in the

Golioth Forum. Your input directly helps shape the future of Golioth Connectivity.

Start from low cost ecosystems

There have been standardized form factors since before Arduino popped on the scene with the Uno header in 2007. In that time, electronics costs have dropped through the floor. We continue to relish in these ad hoc standards, adopting things like the MikroBus Click header standard on our Aludel Elixir board (also open source) and utilizing Uno-to-Click converters to make those same designs even more accessible with our “Follow Along Hardware”, which uses a range of development kits and Zephyr’s flexible pin assignments to adopt hardware to a range of vendor hardware. For this design, I wanted to go smaller. Not quite as small as on the AirTag clone (Orleon), but smaller than an Uno or Click header would allow. Instead, I was clued into a ProMicro clone that includes the nRF52840 chip, one of the many that works with Zephyr and Golioth’s Bluetooth-to-Cloud. Surprisingly, the board can be shipped to a house in the US from a factory in China with tariffs included (somehow) for $3. OK, you need to buy two, but that’s fine with me, I bought a lot more than that. Why this low price point? They’re targeting the keyboard builders of the world, many of whom adopted the ProMicro form factor (rumor has it that some keyboard enthusiasts roam the virtual halls of Golioth, as well!). This board has USB, the chip and RF front end/passives, battery charging, power regulation/control, status LEDs, and 26 breakout pins in a 2×13 pattern. That’s enough for just about anything I might want to do with tiny boards, though the board maker did leave a lot of pins unused on the nRF52840 (I hate to see unused pins, there are just so many on that part!) What this board didn’t have? Much of anything interesting to alert a user that things were happening inside the Bluetooth part. So let’s build a demo board to attach to it.

How many LEDs?

Sure, blinking an LED from the cloud is cool and impressive when transiting the various systems we transit. But what if we blinked a _lot _of LEDs? And put them all in order. Perusing the available chips from LCSC (more on that later), I found a familiar chipset: the IS31FL3731. It’s a 9×16 LED matrix display with an optional audio input that can match the pulse of input audio. It’s targeted at EQ displays for stereos, but also makes a fun way to display text, graphics, and whatever else you can dream up…but maintaining that “Times Square in the 80s” kind of look. This board has 105 LEDs in a 7×15 matrix, basically the most I could fit onboard with 0402 LEDs in the available space. The 7 pixels high is a crucial number to fit a minimalist 7×5 pixel font size. The I2C driver allows control of individual LEDs and has framebuffers to allow animations without regular interaction with the driver chip; you set up the frames and away you go. Easier said than done, but Mike Szczys made short work of the driver in Zephyr and plans to upstream it at some point as well.

An exercise in low(er) cost

In the face of US tariffs, getting any custom electronics made right now can be tricky. The supply chain is inexorably tied to other countries, especially China, even if we decided to do domestic production. I couldn’t find what I needed on US marketplaces at the price point I wanted, so instead I decided to lean into lower cost parts (LCSC) and assembly (JLC) and then pay the tariffs. As such, the parts on this board were largely informed by what I could get on that marketplace and what fit onto the somewhat limited size of the board. Here are the features/part names:

• 105 LEDs in 0402 format, individually addressable in a 7×15 matrix with the IS31FL3731
• Two H-Bridge chips (L9110S) for driving a single stepper or two dc motors
• 3 axis accelerometer (LIS2DH12)
• Temperature sensor (TMP102)
• QWIIC / Stemma header to expand breakout boards*
• User button
• Reset button
• A voltage divider that monitors battery voltage

• Additional GPIOs I can solder to (5 digital, one analog)
• LiPo battery charger on board
• Load switch for all peripherals except motor driver
• USB Input to the nRF52840 (get serial terminal using USB-CDC)
• NFC tag emulation (via the nRF52840 and onboard flex connector)

Shield your eyes, demos are on the way

This board will highlight the various Golioth Bluetooth-to-Cloud capabilities by making it blindingly obvious when a configuration change has been sent down to a device. The less outwardly obvious demonstrations like OTA and Cloud side data will follow our normal display format, but are just as intriguing when done over a Bluetooth link without any custom code on the intermediary device. Stay tuned for more demos here or reach out on the forum to let us know what we should build! * As happens with some Rev A boards, the QWIIC header got miswired, so this is currently backwards (but fixable with a cable mod) and will be fixed in Rev B

the Bluetooth-to-Cloud capabilities of Golioth. For this approach, we use a Gateway to bridge between the resource-constrained BLE devices to the cloud. The Bluetooth devices themselves just advertise a characteristic that indicates they are using the Pouch protocol.  This delivers bi-directional access to a huge number of devices that are usually considered to be connectionless.

Using the ESP32 with Zephyr

Today we’re using Zephyr because that’s what’s currently supported in the Golioth Bluetooth fleet examples. However, Pouch is designed to work cross-platform so with a bit of implementation work this is also possible for ESP-IDF. Espressif maintains support for the ESP32 family in Zephyr, so building for this ESP32-S3 is trivial when you already have Zephyr installed on your development computer. I found that all I needed to do was add hal_espressif to my allow-list and run a west command to fetch the binary blobs.

Building Golioth’s Bluetooth-to-Cloud Example To add the ESP32-S3 to my IoT fleet I followed the instructions from

the Golioth Bluetooth-to-Cloud private access repository. The example application uses a west manifest with an allow-list to limit the number of libraries that are cloned during initialization. I updated this file to include the Espressif HAL library.

# Copyright (c) 2025 Golioth, Inc.
# SPDX-License-Identifier: Apache-2.0

manifest:
  version: 0.8

  projects:
    - name: zephyr
      revision: v4.1.0
      url: https://github.com/zephyrproject-rtos/zephyr
      west-commands: scripts/west-commands.yml
      import:
        path-prefix: deps
        name-allowlist:
          - zephyr
          - cmsis
          - hal_expressif
          - hal_nordic
          - mbedtls
          - mcuboot
          - segger
          - tfm-mcuboot
          - trusted-firmware-m
          - zcbor

west update
west blobs fetch hal_espressif

/ {
    leds {
        compatible = "gpio-leds";

        led0: led_0 {
            gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
        };
  };

    aliases {
        led0 = &led0;
    };
};

REPLACEME text with the Device ID from the Golioth console.

west build -p -b esp32s3_devkitc/esp32s3/procpu pouch/examples/ble_gatt -- -DCONFIG_EXAMPLE_DEVICE_ID=\"REPLACEME\"
west flash

follow steps 1 and 2 from the getting started guide. After a few seconds, the device will start advertising and sending data up to the cloud!

Explore both Uplink and Downlink The example code sends simulated sensor data from the device to the cloud. From the Golioth web console, we can use the LightDB Stream tab to view the “sensor” readings received on the cloud.

I didn’t actually connect a hardware sensor up to the device, so we’re only going to receive 22C for every reading as long as this device is powered on. However, as covered in the previous step, I did add an LED to this board.

Golioth Settings service to change the state of this LED from the Cloud. Settings can changed at the Project or Device level. Here I’ve edited the device-specific setting and a few seconds later the LED lights up!

The Internet is for Bluetooth Too! Your fleet of BLE devices can easily gain bi-directional access to the Internet using

Golioth’s Bluetooth-to-Cloud service. Just add a gateway that can be used by all devices within range and you’ve immediately unlocked a world of functionality.

Solar + Cellular + Bluetooth Hardware

This setup is built on top of the Aludel Elixir, our open source hardware cellular platform. It takes advantage of the multiple types of connectivity onboard, including the Nordic Semiconductor nRF9160 cellular modem and the Espressif ESP32-C3. The former is the main processor running Zephyr (more on that below) and the latter is set up as an HCI interface for Bluetooth connections. There are also two Mikrobus Click slots onboard and we have a VCP Click plugged in there. That is an INA260 chip from Texas Instruments, the same that we used on the DC Power Monitor Reference Design to measure incoming DC power.

Firmware required on the Bluetooth gateway

A key enablement for this design is Mike’s recent work with the ESP32-C3 Bluetooth HCI, effectively turning that segment of the hardware into a ‘bluetooth modem’. Other gateways that we create also use HCI, which is a bit of an equalizer in Zephyr. We can change out the chosen HCI and assign the pins to swap over to using this new HCI.

/ {
    chosen {
        zephyr,bt-hci = &bt_hci_uart;
    };
};

&uart1 {
    status = "okay";
    current-speed = <115200>;
    pinctrl-0 = <&esp_uart_default>;
    pinctrl-1 = <&esp_uart_sleep>;
    pinctrl-names = "default", "sleep";

    bt_hci_uart: bt_hci_uart {
        compatible = "zephyr,bt-hci-uart";
        status = "okay";
    };
};

bluetooth-gateway repository, which is a Zephyr based repository that is yet to be released for the general public. Doing so allowed me to add new compatibilities for the Aludel Elixir, much of which mirrors the currently supported nRF9160-DK. The current Bluetooth gateway firmware has an instance of “pouch“–our new enabling capability for data to transit over transports like BLE GATT–and our firmware SDK–which allows the gateway to bounce those packetized pieces of data up to the cloud. The piece that is not in the standard firmware is sending up generic sensor data through from the gateway itself. I can imagine gateways that might have light or temperature sensors could be standard measurements any user would want to send up, but in our case, I want to send up voltage, current, and power coming from the solar panel. First, I need to process the sensor data coming from the INA260. Since that sensor isn’t in-tree in Zephyr, I instead pulled the driver code from our DC Power Monitor reference design. We implemented it differently back when that RD was created, so instead Mike helped me to transition it over to being a Zephyr module. I pulled in app_sensors.c, a file that we normally have in our Reference Designs and one that sits completely separate from all of the Bluetooth stuff. In main.c, when we call the initialization function, I am passing the Golioth client object, so that we have access to all of the normal goodness that the Golioth Firmware SDK enables. In this case, I want to be able to send up asynchronous stream data that will then get routed through Golioth Pipelines to LightDB Stream, our internal timeseries database. So we’re initializing the Stream capabilities, calling the sensor driver to read from the INA260, formatting that data into something human readable, and then passing it to Golioth with the Stream functionalities. This lives in perfect harmony with the Bluetooth capabilities that are processing incoming Pouch packets and shuttling those up to a different destination on the Golioth cloud for processing and decryption.

Sunshine sensor data on the Cloud

Once the solar panel’s readings are sent up to the cloud, I send those through a simple Pipeline to LightDB Stream The data looks like this During editing of this article, my coworker Mike pointed out that I was actually sending up the raw readings, which have a conversion factor as explained in the INA260 datasheet. There was a different function that makes this correction, but I will do that correction using the images above and below: So the readings are actually 5275 * 1.25 mV = 6.594V for the voltage, 128 * 1.25 mA = 160 mA for the current, and 90 * 10 mW = 900 mW for the power. The last one seems to have some non-linearity on the chip output because 6.594V * 0.160 A = 1.05W. Note that the current (“cur”) only goes above zero when the voltage (“vol”) is up above 5.5V (ie. the middle reading 4165 + 1.25 mV = 5.2V is less than the required 5.5V). That’s due to the input cutoff of the high power buck regulator, and why I said a 12V panel would generally operate better.

What else can you put on your gateway?

This demo is a great example of the power of an embedded processing gateway: not only is it easy to add on additional capabilities for sensors connected to the gateway, it also operates at low power envelopes. When the sun isn’t shining, that means we can operate for longer or with smaller on-board batteries. This design isn’t super optimized for low power, but we have done webinars recently about enabling “batteryless” sensors…perhaps we’ll be able to do the same for gateways next? We are still in Private Access for our Bluetooth-to-Cloud capabilities, but joining simply requires a short application. We can’t wait to see what you build!

Using the EFR32BG27 with Zephyr

We grabbed the SiLabs xG27 dev kit for this experiment because it already has support in the Zephyr tree. Although support begins with v4.1.0 of Zephyr, our testing showed that for the device to work correctly with our gateways we needed to upgrade to v4.2.0. This board includes an embedded J-Link adapter so you can flash it using the USB-C port and Zephyr’s west flash command. To access the Bluetooth features of the chip, use west to grab the binary blob.

west blobs fetch hal_silabs

the Zephyr Bluetooth Observer sample is really handy when testing out new chips, so I built and ran that sample to confirm the radio was working as expected. Now it’s time to add this to our IoT fleet!

Building Golioth’s Bluetooth-to-Cloud Example To get the SiLabs EFR32BG27 talking to the cloud I followed the instructions from the

Golioth Bluetooth-to-Cloud connectivity repository. The example application is found in the Pouch non-IP protocol repository that is included as a submodule. I just needed to make a few updates to the pouch/west.yml manifest file in that repo so it will work with SiLabs parts:

1. Use Zephyr v4.2.0
2. Add the SiLabs HAL library to the allowlist
3. Add cmsis_6 to the allowlist

# Copyright (c) 2025 Golioth, Inc.
# SPDX-License-Identifier: Apache-2.0

manifest:
  version: 0.8

  projects:
    - name: zephyr
      revision: v4.2.0
      url: https://github.com/zephyrproject-rtos/zephyr
      west-commands: scripts/west-commands.yml
      import:
        path-prefix: deps
        name-allowlist:
          - zephyr
          - cmsis
          - cmsis_6
          - hal_nordic
          - hal_silabs
          - mbedtls
          - mcuboot
          - segger
          - tfm-mcuboot
          - trusted-firmware-m
          - zcbor

west update after making these changes to pull in the new version and new library. Here’s what that looks like, including the step to download binary blobs.

west update
west blobs fetch hal_silabs

REPLACEME part with the Device ID from the Golioth console.

west build -p -b xg27_dk2602a pouch/examples/ble_gatt -- -DCONFIG_EXAMPLE_DEVICE_ID=\"REPLACEME\"
west flash

following steps 1 and 2 from the getting started guide. If so, your newly flashed SiLabs board will soon be reporting into the cloud!

Go Deeper with the SiLabs xG27

By default the Golioth example sends simulated temperature sensor data. But the xG27 dev board has a Si7210 sensor that includes a temperature reading. It’s far more fun to send actual sensor readings to the cloud so let’s update the sample to read that sensor! First, create an overlay file to enable the sensor node which is already part of the in-tree Zephyr definition.

&i2c0 {
  si7210 {
    status = "okay";
  };
};

CONFIG_I2C=y
CONFIG_I2C_SHELL=y
CONFIG_SENSOR=y
CONFIG_SENSOR_SHELL=y

const struct device *const temperature_dev = DEVICE_DT_GET_ANY(silabs_si7210);
#include 

static void pouch_event_handler(enum pouch_event event, void *ctx)
{
    if (POUCH_EVENT_SESSION_START == event)
    {
        sensor_sample_fetch(temperature_dev);
        struct sensor_value temperature;
        sensor_channel_get(temperature_dev, SENSOR_CHAN_AMBIENT_TEMP, &temperature);

        char sbuf[64];
        snprintk(sbuf, sizeof(sbuf), "{\"temp\":%g}", sensor_value_to_double(&temperature));

        pouch_uplink_entry_write(".s/sensor",
                                 POUCH_CONTENT_TYPE_JSON,
                                 sbuf,
                                 strlen(sbuf),
                                 K_FOREVER);

        golioth_sync_to_cloud();
    }

    if (POUCH_EVENT_SESSION_END == event)
    {
        service_data.data.flags = 0x00;
        k_work_schedule(&sync_request_work, K_SECONDS(CONFIG_EXAMPLE_SYNC_PERIOD_S));
    }
}

Bluetooth to Cloud has never been this easy

The Golioth Bluetooth-to-Cloud service is incredibly easy to integrate with your low-power devices. Add a Gateway to your fleet and you will be streaming your sensor data to the cloud right away.

Gateways and Devices

We previously defined the distinction between devices and gateways in The Taxonomy of Connected Device Networks. Gateways deliver data to Golioth, typically over cellular, Wi-Fi, or Ethernet, on behalf of other devices. This is enabled by pouch, a custom protocol we developed that enables devices that can’t communicate directly with cloud services to deliver data via an intermediary (i.e. gateway). One of the most common use cases is Bluetooth Low Energy (BLE) devices, which can deliver encrypted “pouches” to a gateway, such as a mobile application on a user’s smartphone or an embedded Linux-based single-board computer (SBC), which can then be forwarded along to Golioth over Wi-Fi or cellular. Golioth customers in our Bluetooth-to-Cloud private access program are using this functionality today. Gateways can leverage Golioth Location’s network-based positioning to resolve their location from scanned Wi-Fi access points or nearby cell towers, or, if they are equipped with GNSS capabilities, can obtain their own position and deliver it to Golioth Location for tracking. Because edge devices must be in relatively close proximity to a gateway in order to communicate through it, Golioth Location is able to approximate the location of the device over time based on the gateways that deliver data on its behalf, regardless of how the gateway obtained its own location.

Making Use of Pipelines

The same location transformer that is used for network-based positioning in Pipelines can also be used for gateway-based positioning. If network information is provided in the message payload, it will first attempt to resolve using network-based positioning. If it is unsuccessful, or no network information is provided, the transformer will fallback to gateway-based positioning if the message was delivered via a gateway. If the position of the gateway is known, it will be returned as the position of the device. For example, in the following Pipeline, an empty message sent from a device on the /.s/loc path and delivered via a gateway could be routed to the location transformer. The information about the gateway will be automatically passed from the Pipeline context to the transformer. Because no network information is provided, the transformer will look up the location of the gateway, and if known, will return it such that it can be passed along to the location and lightdb-stream destinations.

filter:
  path: "/loc"
steps:
  - name: resolve-position
    transformer:
      type: location
      version: v1
  - name: store-location
    destination:
      type: location
      version: v1
  - name: stream-location
    destination:
      type: lightdb-stream
      version: v1

location transformer if it does not contain network information. This effectively enables location tracking with zero-byte overhead, just by knowing what gateway a device communicated through.

Getting Started

Gateway-based positioning is available to all users in Pipelines today, but in order to start using gateways you must enroll in the Bluetooth-to-Cloud private access program. After doing so, you’ll be able to start tracking the location of your BLE devices without changing a single line of firmware. If you have any questions or feedback, feel free to reach out to us on the forum!

Zbus overview

Your Zbus experience begins by defining a channel. Each channel has a set message type (a struct), a starting message value, and a list of observers. Optionally each channel may specify a function to validate each message before publishing, and a pointer to user data. In addition to the observers that were set up when the channel was defined, a zbus channel may be read from at any time, making the most recently published message data available. Zbus breaks down “observers” in a few different categories. Listeners receive a callback with data from each new message. Subscribers may choose to receive a notification of new message. The subscriber is responsible for choosing when to read the message after receiving the notification. There is also an option for subscribers to receive a copy of each message via a FIFO. There are several benefits to the zbus system. Chief among them is thread-safe data handling. Each channel stores its own message and arbitrates access to the data so that you never have a situation where data is changed while it is being read my another thread. Another notable benefit is the ability for many consumers to read data from a single producer. If you added more threads or functions that need to access a channel message, the new code can read messages from the zbus subsystem directly without needing to change existing code. The rest of this post will walk through how the Golioth Coldchain Reference Design to uses zbus to:

1. Publish sensor readings on the zbus at 1Hz
2. When recording location data, read the latest sensor value from zbus

Enable the zbus subsystem

As with all Zephyr libraries, use Kconfig to enable zbus by adding the following to your project’s prj.conf file:

CONFIG_ZBUS=y

#include 

Define a zbus channel

Each zbus channel has a defined message type so this definition includes a struct to use as the message. The state of the message must be initialized so I fill my sensor readings with obviously invalid data that may be checked for by the consumers.

struct weather_data {
    struct sensor_value tem;
    struct sensor_value pre;
    struct sensor_value hum;
};

#define ERROR_VAL1 999
#define ERROR_VAL2 999999

ZBUS_CHAN_DEFINE(weather_chan, struct weather_data, NULL, NULL, ZBUS_OBS_DECLARE(),
         ZBUS_MSG_INIT(.tem.val1 = ERROR_VAL1, .tem.val2 = ERROR_VAL2,
                   .pre.val1 = ERROR_VAL1, .pre.val2 = ERROR_VAL2,
                   .hum.val1 = ERROR_VAL1, .hum.val2 = ERROR_VAL2));

weather_chan. The message type for this channel is struct weather_data, an agreed upon format that both the producers and consumers will have access to. I am not using a validator function or user data so both of those params have been set to NULL. In this example I don’t have any observers so I added an empty initializer. The final param is a macro that initializes the channel with my obviously invalid data that indicates a sensor error. This will be replaced as soon as the first message is published.

Publishing a zbus message

Publishing to zbus is a simple one-liner with an error check.

err = zbus_chan_pub(&weather_chan, &reading, K_MSEC(100));
if (err != 0) {
    LOG_ERR("Failed to publish sensor data: %d", err);
    return;
}

&weather_chan which we defined in the previous section. The message itself (&reading) is the address of a weather_data struct containing the sensor readings I want to publish. The zbus subsystem will copy this struct data so its fine to free that memory after calling the publish function. Since zbus arbitrates access to read/write a message, the final param is a timeout value in case another thread is currently accessing this zbus channel.

Reading a zbus message

Reading from zbus is very similar to publishing to it.

struct weather_data w_data;

err = zbus_chan_read(&weather_chan, &w_data, K_MSEC(50));
if (err) {
    LOG_ERR("Cannot access weather data: %d", err);
}

&weather_chan. The address of a struct matching the zbus channel type is given to receive the data from the zbus message. And finally we use a timeout value to account for any concurrent access issues.

Keep going with observers

Today’s post is just a taste of what zbus can deliver. To get a full picture I encourage you to try out the different observer options. You can register callbacks, receive notifications that a new message is available, or receive a copy of each new message in a FIFO buffer, depending on what type of observer you use. For more on this, check out the Zbus Concepts section of the Zephyr docs.

Over the past few months, we’ve been evaluating a variety of BLE gateways, some that pair with Wi-Fi or Ethernet, others that speak cellular, and running them through their paces with Golioth. Our goal was simple: find a reliable, flexible, and developer-friendly solution that we can confidently recommend to customers building BLE-enabled fleets.

Defining a Great BLE Gateway

At Golioth, we think of networks in terms of devices (your sensors and actuators) and gateways (the last hop to the cloud). Gateways can be:

• Managed — fully onboarded in Golioth with OTA updates, logging, settings, and policy control.

• Unmanaged — authenticated to Golioth but only relaying data for endpoints that don’t run our SDK.

A gateway is any device that connects directly to Golioth, typically over cellular, Wi-Fi, or Ethernet, and forwards traffic for local BLE nodes. For the newest Bluetooth-to-Cloud capabilities, that means the gateway needs to be able to forward data wrapped in Pouch, our new innovation in the space of non-IP communication. It’s also possible for Gateways to forward non-Pouch traffic, but we’ll be focusing on the most enhanced version of data transfer (ie. Pouch) for the near future.

The BLE Gateway Landscape

You’ll find plenty of Zephyr-compatible dev boards, Nordic’s nRF9160 DK and the Thingy91:X among them that technically fit the bill. We love these boards for rapid prototyping and POCs: they pair the nRF52840’s BLE prowess with an nRF91 Series LTE-M/NB-IoT modem.

But most teams aren’t in the business of maintaining custom hardware stacks. They want a turnkey gateway that just works. That’s why, even though you can cobble together a solution from dev boards, we don’t recommend it for production.

Our Top Pick: Ezurio Sentrius MG100

After testing, we recommend the Sentrius MG100 from Ezurio for industrial BLE + cellular deployments. Here’s why:

• Zephyr-Ready: First-class support in Golioth’s Zephyr SDK, so you can hit the ground running.

• Proven Hardware: nRF52840 for BLE Central; Sierra HL7800 for LTE-M/NB-IoT.

• Off-the-Shelf Reliability: No soldering irons or custom enclosures, just unbox and deploy.

• Customizable: Optional branding and packaging, so it fits right into your product lineup.

With the MG100 + Golioth, you get a hardened, field-ready gateway that delivers the “set-and-forget” experience you and your customers expect.

Next Up: BLE + Wi-Fi/Ethernet Gateways

A microcontroller-based cellular device in an industrial enclosure doesn’t fit every application space. In our next post, we’ll explore the world of BLE + Wi-Fi/Ethernet gateways, as well as discussing more about the processing needs of particular gateways.

We’re continuing to enhance our BLE gateway tooling, improve reference firmware, and if you are building a connected product, sign up for Golioth’s Bluetooth-to-Cloud Connectivity private access program, or join us in the forum to tell us more about your use case!

What Makes a Great Location Service?

In our blog post launching Golioth Location, we outlined why we found it necessary to build a location service. The points presented primarily focused on why providing an integrated network-based positioning service, rather than forcing users to bring their own, dramatically simplified initial setup and ongoing management. We also detailed why network-based positioning is a good fit for connected devices, especially those that are bandwidth and power constrained. These points hold true today: network-based positioning can extend battery life, alleviate time-to-first-fix (TTFF) delays, and drive down the cost of hardware. However, we also received great feedback from customers in the private access program, ultimately driving us to rethink what an ideal location service could look like. As we have so many times since introducing the product in May of 2024, we found ourselves looking to Golioth Pipelines to provide a flexible and robust foundation for Golioth Location. With the wide variety of use cases for location services, ranging from active asset tracking to infrequent device check-ins for product analytics, it is critical to enable users to configure location resolution and storage to fit their use case. For example, some use cases require that historical device location is persisted, whereas others only need the most recent device location. Some products need devices to be made aware of their location rather than just delivering it to a data store. The most significant difference in use cases is whether using GNSS is an option, and whether it can be used together with network-based positioning. Doing so provides the right trade-off of accuracy and performance, all while offering a consistent interface.

Golioth Location: Then and Now

In the private access iteration of Golioth Location, devices:

• Submitted network information to a dedicated API endpoint
• This information resolved a position (lat, long, accuracy)
• It was returned in the response to the device making the request
• The position would also be stored in Golioth Location, making it possible to visualize a fleet on a map in the Golioth console. If it was necessary to store the device location in a timeseries data store, or route it to any external destination, the device would need to stream the position back to Golioth so that it could subsequently be routed to the desired destination via Pipelines. Besides the obvious unnecessary round-trip this incurred, we also found that many products did not require the device itself to be aware of its location. Returning the position to the device at all was extraneous. For use cases where it did seem necessary for the device know its location, the logic in the device firmware could be offloaded to the cloud. For example, in a

geofence application, the fence could be configured on the cloud, and the device would only need to be notified when its position moved outside of the fence. The other major takeaway from customer feedback was the desire to use network-based positioning as a supplemental solution alongside GNSS. In private access, combining location obtained via GNSS with network-based positioning was messy, and the former would not show up in the Golioth Location map visualization. This was especially frustrating when multiple fleets existed in the same project, with some devices using GNSS and others using network-based positioning. To address these concerns and more, we have removed the device-facing Golioth Location API endpoint, and instead introduced a Pipelines location transformer and location destination. The former is used to translate network information into a position, while the latter stores the most recent location for a device, regardless of how it was obtained. These can be combined with any other Pipeline transformers and destinations. For example, if you need to store the historical location for a device, you can add a step to send positions to LightDB Stream via the lightdb-stream destination. If you need to return data to a device, you can add a step to set the current position in LightDB State via the lightdb-state destination, allowing the device to fetch its own location. You can even combine all of these into a single Pipeline, which addresses a wide range of use cases.

filter:
  path: "*"
  content_type: application/cbor
steps:
  - name: convert-to-json
    transformer:
      type: cbor-to-json
      version: v1
  - name: resolve-position
    transformer:
      type: location
      version: v1
  - name: store-location
    destination:
      type: location
      version: v1
  - name: stream-location
    destination:
      type: lightdb-stream
      version: v1
  - name: set-state
    destination:
      type: lightdb-state
      version: v1

location transformer and instead delivers data directly to the destinations after converting to JSON. This would allow for positions obtained via GNSS to appear in each destination in the same manner as those obtained via network-based positioning.

filter:
  path: "*"
  content_type: application/cbor
steps:
  - name: convert-to-json
    transformer:
      type: cbor-to-json
      version: v1
  - name: store-location
    destination:
      type: location
      version: v1
  - name: stream-location
    destination:
      type: lightdb-stream
      version: v1
  - name: set-state
    destination:
      type: lightdb-state
      version: v1

Golioth Firmware SDK versions to start utilizing these features. Nevertheless, we have introduced new net_info functionality in the most recent version of the SDK to make using network-based positioning simple and straightforward.

info = golioth_net_info_create();

struct golioth_wifi_scan_result golioth_result = {
    .mac = {result->mac[0],
            result->mac[1],
            result->mac[2],
            result->mac[3],
            result->mac[4],
            result->mac[5]},
    .rssi = result->rssi,
};

status = golioth_net_info_wifi_append(info, &golioth_result);
if (status != GOLIOTH_OK)
{
    LOG_ERR("Failed to append Wi-Fi access point");
    return -1;
}

status = golioth_net_info_finish(info);
if (status != GOLIOTH_OK)
{
    if (status == GOLIOTH_ERR_NULL)
    {
        LOG_WRN("No network information data provided");
        return 0;
    }

    LOG_ERR("Failed to encode network information data");
    return -1;
}

err = golioth_stream_set_sync(client,
                              "loc/net",
                              GOLIOTH_CONTENT_TYPE_CBOR,
                              golioth_net_info_get_buf(info),
                              golioth_net_info_get_buf_len(info),
                              SYNC_TIMEOUT_S);
if (err != GOLIOTH_OK)
{
    LOG_ERR("Failed to stream network data: %d", err);
    return -1;
}

Getting Started

Ready to get started? Go the the Location section in the console to activate Golioth Location, then check out the examples in the documentation to start tracking your devices. To learn more about network-based positioning pricing, take a look at the Golioth pricing page. If you have any questions or feedback, reach out to us on the forum!

You Need to Pay Attention.

The CRA Has Teeth!

The Cyber Resilience Act (Regulation (EU) 2024/2847) is a uniform legal framework designed to strengthen the EU’s cybersecurity posture and enhance the internal market by ensuring that hardware and software products are placed on the market with a higher level of security. This legislation has significant enforcement provisions. Manufacturers are paying close attention because non-compliance can lead to administrative fines of up to €15,000,000 or 2.5% of the total worldwide annual turnover for the preceding financial year, whichever is higher. This substantial penalty is a primary driver for its rapid adoption across the industry, similar to how EU regulations historically influenced global markets, such as the widespread adoption of USB-C and GDPR. The CRA addresses critical issues like the low level of cybersecurity in digital products, the prevalence of vulnerabilities, and inconsistent provision of security updates. The regulation officially entered into force in December of last year, starting the clock for compliance. While governments need to establish certain procedures by June 2026, manufacturers must begin adhering to reporting obligations just three months later, by September 11, 2026. The entire regulation will be fully applicable by December 11, 2027. The term “manufacturer” under the CRA encompasses anyone with a commercial interest in a product with “digital” elements, which includes both software and hardware. This broad definition means it’s a catch-all for products not already covered by existing specific industry regulations. The CRA applies primarily to “economic operators” who make products with digital elements available on the market in the course of a commercial activity. Most notably, this includes manufacturers, defined as “any natural or legal person who develops, manufactures, or markets products with digital elements under their name or trademark, whether for payment, monetisation, or free of charge.”

Key Requirements for Manufacturers and How Golioth Can Help

The CRA mandates several crucial obligations for manufacturers to ensure cyber resilience throughout a product’s lifecycle:

• Vulnerability Handling and Support Period – Manufacturers must ensure vulnerabilities are handled effectively for a “support period,” which must be at least five years, or the product’s expected use time if shorter.
• Reporting Obligations – This is where the rubber meets the road, as Kate mentioned (around 0:03:10).
  • Actively exploited vulnerabilities must be notified without undue delay, within 24 hours of awareness to the designated Computer Security Incident Response Team (CSIRT) and ENISA via a single reporting platform. A more detailed vulnerability notification is required within 72 hours, and a final report no later than 14 days after a corrective measure is available.
  • Severe incidents impacting product security also require a 24-hour early warning notification.
  • Manufacturers must also inform impacted users about the vulnerability or incident and any necessary risk mitigation measures.
• Software Bill of Materials (SBOM) – Manufacturers are required to identify and document all components in their products, including by drawing up an SBOM in a commonly used, machine-readable format. This is vital for tracking known vulnerabilities and avoiding unnecessary updates. Kate highlighted how Zephyr’s capability to generate SBOMs with just a few lines of code puts them in a strong position for this requirement (around 0:08:00).
• Secure by Design and Updates – Products must be available with a secure by default configuration. Manufacturers should design products to receive automatic security updates (with an opt-out mechanism) and ensure updates are disseminated without delay and generally free of charge.
• CE Marking – Products with digital elements must bear the CE marking to indicate conformity with the CRA.

How Golioth Assists Your Compliance

At Golioth, we’re keenly aware of these evolving regulations. Our platform’s capabilities are designed to help manufacturers meet many of these demands for their embedded IoT devices:

• Over-the-Air (OTA) Updates – The CRA emphasizes the need for secure and timely distribution of security updates. Golioth’s OTA service is a direct answer to this, enabling manufacturers to quickly deploy security patches and new functionality to their fleet of devices, even thousands of miles away. This is crucial for addressing identified vulnerabilities and ensuring ongoing compliance.
• Device Management and Remote Interaction – Our platform allows you to monitor and interact with your fleet. This helps manufacturers stay aware of their devices’ status and deliver necessary updates effectively.
• Remotely manage and update device configurations – The Golioth Settings service ensures adherence to secure defaults across the entire fleet and have stored backup configurations.
• Detect Anomalies – The CRA’s emphasis on “reporting on possible unauthorised access” [Annex I, Part I, point 2(d); 339, 671] is key here. By analyzing patterns in device logs (e.g., unusual data access, unexpected process starts) and streamed data, manufacturers can identify deviations from normal behavior that may indicate an intrusion attempt or an actively exploited vulnerability.
• Continuous Data Feed – Devices can be configured to stream telemetry data, events, and critical security logs directly to the Golioth cloud. This provides manufacturers with the real-time visibility needed to “know when someone was in the system”. An example of this is a light detection circuit on a board that reports back over the Golioth stream service, for when there is an unauthorized opening of a case.
• Facilitate Rapid Reporting – The CRA’s 24-hour reporting window for actively exploited vulnerabilities and severe incidents [Article 14(2)(a), 14(4)(a); 231, 233, 542, 544] is extremely tight. Centralized and accessible logs via Golioth enable manufacturers to quickly gather the necessary information for early warning notifications and subsequent detailed reports, ensuring compliance with these critical timelines. The EU’s Cyber Resilience Act is a significant step towards ensuring more secure digital products for consumers, moving away from a “throwaway economy” (around 6:50). It’s a call for manufacturers to prioritize cybersecurity throughout the product lifecycle. By leveraging robust platforms like Golioth, built on secure foundations like Zephyr, you can better navigate these regulations and deliver more resilient IoT products. Want to learn more about how Golioth’s Firmware SDK and platform can help your product meet these new cybersecurity challenges? Check out our documentation and examples, schedule a discovery call, or join the discussion on our forum!

Golioth’s Bluetooth-to-Cloud service which leverages a standard gateway device to read data from any Bluetooth hardware capable of using the Generic Attribute Profile (GATT), which is basically all Bluetooth devices. With this setup, the gateway periodically scans for devices with a predetermined characteristic. When these devices connect to the gateway, they use Golioth’s Pouch protocol to package sensor (or any other data) and send it to the cloud. In addition to today’s Renesas device, we’ve already demonstrated this functionality with Nordic, STM, and NXP devices.

Using the DA14695 with Zephyr

While the Bluetooth-to-Cloud service doesn’t require that leaf nodes run Zephyr, we have built the first example applications on Zephyr. The first thing we need to do is get ready to build for the Renesas DA14695. My device shipped with a jumper installed on J2 between pins 2-3. This runs the board in 5V mode, but I found that Zephyr applications like basic/blinky didn’t want to run (as if the clock was not running). This was resolved by moving the jumper to J3 between pins 1-2 which connects the chip to the 3.3V rail. While the board includes Bluetooth support in Zephyr, it requires that you fetch the binary blob and turn on the Bluetooth peripheral in the devicetree. I also found that Bluetooth functionality required Zephyr 4.1.0 or later. First, let’s use west to grab the binary blob.

west blobs fetch hal_renesas

/ {
    chosen {
    zephyr,bt-hci = &bt_hci_da1469x;
  };
};

&bt_hci_da1469x {
  status = "okay";
};

eZFlashCLI{.reference.external} which can be installed using pip.

pip install ezFlashCLI

Zephyr’s observer example. It simply scans for Bluetooth devices and reports their mac address in the serial console.

Building Golioth’s Bluetooth-to-Cloud Example

As shown in the video, there are a couple of tweaks we need to make to get the example code to build for this board:

1. Use Zephyr 4.1.0
2. Add the Renesas HAL libraries Make sure you have already completed steps 1 and 2 for setting up a gateway in the

Getting Started section of the BLE Private Access application. When you get to Step 3, follow the instructions to initialize and update the project. But pause at this point to edit the pouch/west.yml file as follows:

# Copyright (c) 2025 Golioth, Inc.
# SPDX-License-Identifier: Apache-2.0

manifest:
  version: 0.8

  projects:
    - name: zephyr
      revision: v4.1.0
      url: https://github.com/zephyrproject-rtos/zephyr
      west-commands: scripts/west-commands.yml
      import:
        path-prefix: deps
        name-allowlist:
          - zephyr
          - cmsis
          - hal_nordic
          - hal_renesas
          - mbedtls
          - mcuboot
          - segger
          - tfm-mcuboot
          - tinycrypt
          - trusted-firmware-m
          - zcbor

hal_renesas library was added to the name-allowlist. Let’s update for these changes to take effect and also ensure we fetch the binary blob and install the flashing tool as discussed in the previous section.

west update
west blobs fetch hal_renesas
pip install ezFlashCLI

pouch/examples/ble_gatt/boards/da14695_dk_usb.overlay. We’re now ready to build and flash the application.

west build -p -b da14695_dk_usb pouch/examples/ble_gatt -- -DCONFIG_EXAMPLE_DEVICE_ID="REPLACEME"
west flash

REPLACEME placeholder that needs to be replaced with the Golioth DeviceID for this hardware. Without this, the cloud will not recognize this as a valid device when receiving data via the gateway.

Sending Actual Sensor Code

In the video we demonstrate going a step further by connecting a BME280 temperature, pressure, and humidity sensor up to the Renesas DA14695 so that we can send actual sensor data. It is actually quite simple to add data to the upload. Let’s look at the pouch_event_handler() callback. You can see in this function we are packaging up some JSON code to send a (simulated) temperature value. This payload may be replaced with any valid JSON, just be sure to change both the JSON string and the length in the write API call.

static void pouch_event_handler(enum pouch_event event, void *ctx)
{
    if (POUCH_EVENT_SESSION_START == event)
    {
        pouch_uplink_entry_write(".s/sensor",
                                 POUCH_CONTENT_TYPE_JSON,
                                 "{"temp":22}",
                                 sizeof("{"temp":22}") - 1,
                                 K_FOREVER);
        pouch_uplink_close(K_FOREVER);
    }

    if (POUCH_EVENT_SESSION_END == event)
    {
        service_data[ARRAY_SIZE(service_data) - 1] = 0x00;
        k_work_schedule(&sync_request_work, K_SECONDS(SYNC_PERIOD_S));
    }
}

Your Bluetooth Devices On the Cloud, Right Now.

Golioth has already solved the complexity of transferring data from your Bluetooth fleet to the cloud. By installing a gateway device, you can automatically scan and upload that data at a cadence of your choosing. Take it for a spin today and let us know how it goes!

Medical devices in the US and abroad have much more stringent regulatory requirements than consumer or industrial electronics. We will join Marcus Engineering–one of our newest Design Partners–and the MedTech Leading Voice group for an upcoming webinar about medical devices. Surprise! Almost all of them are actually IoT devices. You can sign up for the webinar here, happening 11 am ET (8 am PT) on July 16th

What defines an IoT Device, anyhow?

An “Internet of Things” (“IoT”) device is a squishy term, but in the eyes of regulators, if it runs software or firmware, these are increasingly considered IoT devices. The definitions include language like “[any device with a] direct or indirect connection to a device or network, where ‘Connection’ includes “using physical means, including through electrical, optical or mechanical interfaces, wires or radio waves”. So…all of them? But given the benefit of the doubt, these regulations are meant to ensure security and the ability to update and patch for vulnerabilities.

It’s up to each product designer and product team to understand whether they are subject to any particular requirements, such as FDA regulations in the US. Increasingly, there are additional requirements for connected devices that increase the burden on technical teams that might have previously been focused on building a hardware and firmware solution. These now need to include a cloud aspect as well, at least for the ability to update firmware and software. Here are some high level requirements that need to be met:

• Updatability/Patchability
• Logging/Intrusion Detection
• Authentication
• Access Control
• Integrity

During this webinar we’ll discuss how each requirement impacts a medical device and how users can quickly start to meet those requirements with a solution like Golioth. Some of the newer regulations include the Cyber Resilience Act (CRA) in the EU, the Cyber Trust Mark in the US, and the Product Security and Telecommunications Infrastructure (PSTI) in the UK. We’ll offer real world examples of past devices that went awry and how to make sure your product doesn’t meet the same fate.

So be sure to sign up for this webinar on July 16th, regardless of the type of device you’re building. You’ll learn about regulatory environments and how you can harden your solution for a successful

Golioth continues to enable new boards with Bluetooth-to-Cloud abilities, today it’s the NXP FRDM-MCXW71. At this point, it’s almost becoming routine! As a general rule, we look for the following in devices that can talk back to the cloud through our standard BLE-GATT based gateway:

• A board that is running Zephyr, optimally with in-tree support (though custom hardware is also possible)
• A device with a working BLE sample, including the HCI for communications

So far we have enabled the ST Microelectronics STM32WB5MM-DK, the Arduino Nicla Sense ME (with a Nordic nRF52833), the nRF52840-DK, and the NXP RW612. In all of these cases, we were able to send back generic packets (filled with our sensor data) to the cloud. Most of the time spent in our previous blog and video output centered around configuring Zephyr to be able to pull in external sensor readings. This made more realistic data flowing through the standard Golioth gateway up to the cloud.

A second NXP board

We have already enabled the RW612, so why spend the time enabling a different part on their ecosystem? The nature of the parts matters. And in fact: it’s all about Matter!

The RW612 is meant as a Thread border router, which enables Matter smart home setups. It has more communication mechanisms (Bluetooth, 802.15.4, Ethernet, Wi-FI) and generally a lot more horsepower. As such, it has a much higher price tag. The MCXW71 is the ‘node’ chip in that system, meant to be a Thread (and by extension, Matter) sleepy device: low power, lower cost, reduced functionalities. This matches the abilities of other chips we have enabled so far. Small, low power microcontrollers meant to take readings and then go back to sleep are a perfect fit for what we’re often doing with our Bluetooth-to-Cloud. And while Thread actually runs using 802.15.4, it’s nearly universal that the pairing process for Thread devices is done over Bluetooth.

Challenges with this board

If you’re looking to run the FRDM-MCXW71 on your bench, there are two potential pitfalls to getting started (also highlighted in the video above):

1. Getting the LinkServer utility working – This is the debug interface for modern NXP boards. They list JLink as another way to debug this board, but we couldn’t get it working. The tricky part is that LinkServer wasn’t enabled until Zephyr 4.1, whereas our current Bluetooth builds were against 4.0. A bit of reworking in the west manifest and we were able to call out the correct version and also pull in the appropriate NXP HAL to make things build smoothly.
2. **The Bluetooth HCI / NBU ** – On this board, it’s required that you program the Bluetooth HCI image into a secondary Cortex-M3 processor. This is separate from the build process for Zephyr and requires a tool called blhost. Check out the NBU section of the Zephyr docs for more info.

We’re excited to have another NXP board included in the list of boards that work with Golioth’s Bluetooth-to-Cloud capabilities. We will continue to add new vendors and chipset variations in the coming weeks. If you’d like to join the private access program, sign up here!