Announcing Beta Support for Zephyr in the Golioth Firmware SDK

Announcing Beta Support for Zephyr in the Golioth Firmware SDK

We are excited to announce the availability of a public Beta for support for the Zephyr RTOS in the Golioth Firmware SDK! But wait, you say, doesn’t Golioth already support Zephyr? We do! Goloith has always been, and will continue to be, a big proponent of the Zephyr RTOS and its community. We built the first version of our product specifically to work with the Zephyr RTOS. But our goal is to serve the IoT community at large, and that includes folks who choose to use an operating system other than Zephyr.

To that end, we created the Golioth Firmware SDK, which is designed from the ground up to be portable to any RTOS. It already has full support for ESP-IDF and Modus Toolbox, limited support for Linux, and a pathway for porting to any other operating system. It also incorporates all of our learnings over the last few years building IoT firmware, with the result being a cleaner internal architecture and more flexible external APIs.

This left us with two SDKs to support, meaning every bugfix or new feature required twice as much work. Like many of you, we have finite resources, and doing everything twice didn’t feel like the right way to scale. So, we chose to invest in bringing our same first-class support for Zephyr to the Golioth Firmware SDK.

What does this mean for Zephyr support?

Golioth’s support for Zephyr remains as strong as ever. We continue to be financial sponsors of the project, sit on the Technical Steering Committee, and provide free Zephyr training. In short, we love Zephyr!

What’s next?

We are already hard at work on the next set of improvements to Zephyr support in the Golioth Firmware SDK. Our focus now is on driving down the resource usage – RAM, ROM, and CPU cycles – of the SDK when running on Zephyr (with some of those improvements applying to our other ports as well). We will incorporate your feedback on our APIs, functionality, and reliability, and we expect Zephyr support in the Golioth Firmware SDK to be generally available by early next year .

How can I help?

You can help by test-driving Zephyr RTOS on the Golioth Firmware SDK. Follow our guide for setting up your build environment. The Firmware SDK includes a collection of sample code that demonstrates API calls for all Golioth services. And of course, we have an SDK Reference if you really want to dig in. Most importantly, don’t forget to share your thoughts on the experience with us: .

What if I’m already using the Zephyr SDK?

You can continue to use the Zephyr SDK as you do today and devices in the field running the Zephyr SDK (or earlier versions of the Golioth Firmware SDK) will continue to function.  We will continue to support you with bugfixes and new features for the near term.

Of course, if you are curious about where we are headed, we would love to have you try out the Golioth Firmware SDK! We are here to help you with the transition to the new SDK – please reach out to [email protected] or post on the Golioth Forum with any questions.

I’m starting a new project with Zephyr, which Golioth SDK should I choose?

For devices going to production in 2023, we recommend using the Golioth Zephyr SDK. The Firmware SDK supports all the features of the Golioth platform today, but is not yet as optimized as the Golioth Zephyr SDK.

We expect to reach general availability of Zephyr support in the Golioth Firmware SDK in early 2024. If you are building a Zephyr based device with plans to go to production in 2024 or later, you may want to consider beginning development in the Golioth Firmware SDK to reduce the burden of transitioning later. 

/by
,

Golioth Announces Connection ID Support

At Golioth, we pride ourselves on doing both the deep technical work—as well as the routine maintenance—required to ensure we back up our claim of being the most efficient way that devices in the field can securely talk to services in the cloud.

In service of this mission, last week we turned on DTLS 1.2 Connection ID support in Golioth Cloud. While most users will not see any visible differences in how their devices connect to Golioth, behind the scenes many devices are now enabled to perform more efficiently. This is especially true for those connecting via cellular networks.

Devices using Connection ID can see a meaningful impact on bandwidth costs, power usage, and battery life. This not only benefits users of Golioth, but also means that more devices are able to operate for longer, reducing waste and energy use. Because we believe deeply in this potential widespread impact, we have been and will continue to do all work in this area in the open.

What are Connection IDs?

We have written previously about how we use CoAP over DTLS / UDP to establish secure connections between Golioth and devices. Because UDP is a connection-less protocol, attributes of each datagram that arrive at a local endpoint must be used to identify the remote endpoint on the other side.

In short, DTLS uses the IP address and port of the remote endpoint to identify connections. This is a reasonable mechanism, but some devices change IP address and port frequently, resulting in the need to constantly perform handshakes. In some scenarios, a full handshake may be required just to send a single packet. Performing these handshakes can have a negative impact on battery life, drive up bandwidth costs, and increase communication latency. For some devices, this cost makes the end product at best more expensive, and at worst, infeasible.

Connection IDs provide an alternative solution, allowing for clients and servers to negotiate an identifier that can be used in lieu of the IP address and port. Once negotiated, the endpoint(s) that are sending a Connection ID — typically just the client but sometimes both the client and the server — are still able to have their DTLS connection state associated with incoming records when their IP address and port changes. The result is that a device could travel from one side of the world to the other, continuing to communicate with the same server, while only performing the single initial handshake.

How was Connection ID support implemented?

Efficient communication between devices and the cloud requires compatible software on both sides of the connection.

Cloud Changes

On the cloud side, we are beneficiaries of the work done by folks in the Pion community, which includes a set of libraries for real-time web-based communication. Conventional use of these libraries is enabling video streaming applications on the internet, such as Twitch. However, the protocols they implement are useful in many constrained environments where the network is lossy or unreliable.

The Golioth team contributed Connection ID support in the pion/dtls library. This consisted of both the implementation of Connection ID extension handling and modifications to UDP datagram routing. The former involved careful updates to the parsing of DTLS records; Connection IDs change record headers from being fixed length to variable length. As part of this work, we are also adding a very small new API in the Golang crypto library.

Previously, pion/dtls utilized an underlying net.Listener, which was conventionally supplied by the pion/transport library. This UDP net.Listener handed net.Conn connections to the pion/dtls listener, which would in turn establish a DTLS connection by performing a handshake with the client on the other side of the connection. However, the net.Conn interface does not allow for consumers to change the remote IP address and port to which packets are sent. When not using Connection IDs, this is not an issue because the IP address and port are what identifies the connection. However, when Connection IDs are in use, the ID itself is used to identify the connection, and the remote IP address and port may change over time. Thus, a new interface, net.PacketListener, was added to pion/dtls, which enables the changing of the remote address of a connection, and an implementation of the interface that routes based on Connection IDs when present was supplied.

Device changes

On the device side, most users leverage the Golioth Firmware SDK to communicate with Golioth services, such as OTA, Settings, Stream, and more. The SDK is meant to work with any hardware, which is why we integrate with platforms such as Zephyr, Espressif ESP-IDF, Infineon Modus Toolbox, and Linux. Many of these platforms utilize DTLS support offered by mbedTLS, which added support for the IETF draft of Connection IDs in 2019, then included official support in the 3.3.0 release in 2022. The SDK uses libcoap, which implements CoAP support on top of a variety of DTLS implementations, including mbedTLS. libcoap started consuming mbedTLS’s Connection ID API in July of this year. We have been assisting in ensuring that new versions of libcoap are able to build on the platforms with which we integrate.

However, these platforms frequently maintain their own forks of dependencies in order to integrate with the rest of their ecosystem. We have both been contributing and supporting others contributions wherever possible in order to expedite the use of Connection IDs in the Golioth Firmware SDK. With Connection ID support already in place in ESP-IDF and Nordic’s sdk-nrf, and coming soon in the next Zephyr release, we hope to turn them on by default for all platforms in upcoming Golioth Firmware SDK releases.

How do I use Connection IDs?

Using the Golioth Firmware SDK is the only requirement to utilize Connection IDs. As support is added across all embedded platforms, update to the latest version in your device side code and your connection will automatically be enabled. The video at the top of this post shows how you can inspect your own device traffic to see the functionality in action.

What comes next?

In total, we have made contributions across many open source projects as part of our effort to make Connection IDs widely available, and we look forward to continuing to lend a hand wherever possible. While this post has provided a brief overview of DTLS, Connection IDs, and the ecosystem of libraries we integrate with, ongoing use of the functionality will allow us to provide tangible measures of its impact. We’ll make sure to make announcements as support continues to be added across platforms and consumed in the Golioth Firmware SDK.

Until then, go create a Golioth account and start connecting your devices to the cloud!

 

/by

Open Sourcing Golioth Reference Designs and Template

The Golioth Reference Design Template is now publicly available to review and use with your IoT products. Our reference designs (and the template they are all based on) are now using the Apache 2.0 open source license. Over the last nine months of beta testing and development we’ve been sharing the source code only upon request. Starting today, we’re moving to stable releases and we’re making the repositories public for each design.

We began developing reference designs at the end of 2022 as a way to help customers jumpstart their fleet deployments. This goes far past hello-world, and gets your hardware up and running with an encrypted connection to every device, time-series and stateful data pipelines with the cloud, remote logging, remote procedure call, fleet settings, and of course over-the-air (OTA) firmware updates.

All of our specialized designs begin with the Golioth Reference Design Template. This is a firmware jumping off point that lights the way to customizing an implementation for your unique hardware needs.

You can try it right now using off-the-shelf parts (all that’s needed is a Nordic nRF9160 Development Kit) or on your own hardware using Zephyr RTOS.

What’s Included in a Reference Design?

Golioth Reference Design Template sources list

Our reference design template demonstrates how to use all of the Golioth services, broken out into bite-sized files.

  • dfu: all of our reference designs implement over-the-air (OTA) firmware updates. The files in this folder handle all the details for you.
  • app_work: the core work for the application happens here. Sensor readings, data processing, and storing time-series data is found in this file.
  • app_state: bi-directional stateful data is handled in this file. The device will write information about its actual state using functions in this file.
  • app_settings: update your entire fleet at the same time, or drill down to specific devices. This file registers the Golioth Settings service and takes action when new settings are received.
  • app_rpc: command and control gets truly powerful with the ability to call functions remotely, optionally supplying arguments that weren’t available at compile time.
  • battery_monitor: an example of how to monitor and report device battery state back to the cloud.

Each of these files include API calls using the Golioth Zephyr SDK. Within that SDK, you’ll find samples of each of the above services as well; this is actually how we built the reference design template. An easy way to think about these layers:

  • The Golioth SDK defines the service and assists in connecting to the Cloud-side capability
  • The SDK samples are a simple implementation of a standalone service, such as LightDB Stream
  • The Reference Design Template puts together multiple SDK samples in a format that approximates how product teams will build an all-inclusive firmware design. See below for a real-world example we built on top of the Reference Design Template.

Code Walkthrough

Mike and Chris walk through the code that’s part of the Reference Design Template

DC Power Monitor Reference Design

DC Power Monitor on top of graphed data

Today we are also releasing the DC Power Monitor Reference Design which illustrates voltage, current, and power monitoring for direct current applications like battery monitoring for micro-mobility fleets. This design was built on top of the Reference Design Template.

As with the template, this reference design can be run with off-the shelf parts. Support is included for the Nordic nRF9160 Developer Kit, along with an adapter board and two INA260 sensors from MikroElektronika. Full details on the features and hardware used in this reference design are available from the Golioth Projects page.

More Reference Designs Coming Weekly

Golioth Projects shares reference design details

The Reference Design Template and the DC Power Monitor are both live right now. We plan to publish one or two more each week until all of our reference designs are public. Keep an eye out for those weekly announcements, with the OBD-II / CAN Asset Tracker and the Air Quality Monitor as the next planned releases.

Sign up for the Golioth newsletter to make sure you don’t miss any of these announcements!

What Will You Build?

IoT shouldn’t be so hard, that’s why we’re here! Use Golioth as your instant IoT Cloud and finish your proof of concept quickly.

We’d love to know what you’re building. Post about your projects on the Golioth Forum and get in touch with our developer relations team to help with any questions you have along the way.

/by

Introducing MongoDB Time Series and InfluxDB Output Streams

We are excited to announce the general availability of two new output stream destinations: MongoDB Time Series and InfluxDB. With Golioth, you can now stream your IoT device data directly into these popular databases, eliminating the need for additional backend APIs to ingest data. This expands your integration possibilities with Golioth, bringing more flexibility and efficiency to your IoT data handling.

Why MongoDB Time Series and InfluxDB?

As an enabler of a broad range of IoT applications, Golioth understands the diverse requirements of various remote sensing applications. Sensor data, by nature, is time series data – it’s collected at regular intervals and is most valuable when observed over time for trends and patterns.

MongoDB Time Series and InfluxDB are databases specifically designed for this kind of data.

MongoDB Time Series is a powerful extension of MongoDB, specifically tailored for time-series data. Its strength lies in its built-in capabilities for handling large-scale, high-throughput, and complex querying scenarios. With this, storing and analyzing time-series data becomes effortless, making it ideal for IoT use cases.

InfluxDB, on the other hand, is a high-performance data store purpose-built for time-series data. It stands out for its support for high throughput ingest, compression, and real-time querying. This makes InfluxDB particularly suited to handle the high write and query loads commonly associated with large IoT deployments.

Expanding Your IoT Data Integration Possibilities

At Golioth, our goal is to streamline the path from idea to deployment in IoT development. The addition of MongoDB Time Series and InfluxDB to our output streams is a major milestone, enhancing the way you can route your IoT data directly to your preferred databases.

If you’re already using MongoDB Time Series or InfluxDB, this update allows for a seamless flow of information from your IoT devices to your databases, unifying your tech stack and simplifying your development experience.

With the incorporation of these new output streams, we’re supporting a broader spectrum of use cases and accelerating the journey from prototype to production.

Learn More about the New Output Streams

You can get started with MongoDB Time Series and InfluxDB output streams by following the guides in our documentation:

To understand more about output streams, how they work, and why they’re beneficial to your IoT projects, take a look at our previous post on output streams.

Need Help or Want More Database Support?

If you have any questions or need help getting started with MongoDB Time Series or InfluxDB output streams, don’t hesitate to reach out on our community forum. Our team and fellow Golioth users are there to help you.

If you’re using a different database and would like to connect it to Golioth, please let us know at [email protected]. Your feedback will help us prioritize support for other database output streams in the future.

We’re excited to see what you build with these new capabilities. As always, we’re here to support your IoT journey. Your feedback and questions are always welcome.

Happy building!

/by

How Golioth Built a User Interface with ePaper and Back-lit LEDs for Our IoT Hardware

How do you show a device connected to and controlled from the Internet? Golioth is literally doing this every day, so we built a piece of custom hardware that shows what’s going on when a device is passing sensor data up to the cloud and receiving commands in return. We call it Ostentus, and it’s a beautiful combination of ePaper, back-lit LEDs, and capacitive touch.

The origins of the word Ostentus come from the Latin: expose to view, exhibit, show. This is a perfect codename for the modular faceplate we built to show off Golioth’s reference designs. Let’s see it in action and dive into the details of how we built it.

Add to any project via I2C

Ostentus communicates with its host hardware over i2c, receiving a simple set of commands to update the display and LEDs.

Golioth is headed to the Embedded World conference next week and you’ll see these faceplates on a number of different demo units. They scroll through different sensor readings, including the option for a summary page. At boot, they display the logo that accompanies the demo. They can also be used to read out connection and other information from the device.

There’s a helper library that is added to an existing project as a submodule. For most of our demos, we just insert a couple dozen lines of code to pipe six(ish) different readings to the display.

Ostentus’ Hardware Origin Story

User interfaces grow in complexity very quickly. Our primary goal was to make it simple to add Ostentus to any IoT project, for any of the SDKs that we support (3 and growing!). That means simplicity from both the hardware and firmware side of things.

The latest Golioth reference designs use the MikroElectronika Click ecosystem for sensors, and include at least to Qwiic connectors. This means two things:

  • We don’t have a ton of extra pins to drive something like a display direct from our chosen microcontroller
  • I2C is already used in pretty much everything we demonstrate

We chose to utilize I2C and have the Ostentus board act as just another I2C peripheral.

Next, we’ve done a lot of work with ePaper through our trainings (and other shenanigans). It is kind of magical how easy it is to read, and how it retains an image even when powered off. We ordered an assortment of different displays in December to spec them out for our purposes.

The chip shortage drove our choice of microcontrollers. We landed on the RP2040 microcontroller because of its knack to remain in-stock. It also helps that it’s a powerhouse, with 133 MHz dual-core, “PIO” which are hardware-based state machines (more on those later), abundant pins, SRAM, external flash…all for a somewhat low price. We had originally planned to populate the RP2040 and its necessary circuitry directly on the PCB, but the ease, availability, and cost of the Pico boards led us to include them as modules.

Finally, we have a wealth of past experience producing circuit boards that themselves were meant to look amazing without being placed in a case. This informed the board design and passive component decisions for a fantastic aesthetic. The LEDs are on the underside of the board, shining up through the substrate to appear as illuminated icons. There are also three capacitive touch pads that allow for user feedback. All of this is wrapped in matte black solder mask, making it look more like a (Dark) Apple product and less a PCB. The result is a perfect replacement for the plain plastic covers of the project boxes we told you about last week.

Is it Firmware or Software?

PCB faceplate on a Golioth power monitor reference design

The heavy lifting for the display graphics is all handled by the RP2040 on the board. When we landed on this chip we looked around for other projects using it along with ePaper and found the Pimoroni Badger 2040. That dev board is based around MicroPython, which we hadn’t originally set out to use, but it makes a lot of sense. You can plug USB into it and upload new graphics without rebuilding/reflashing firmware. That has modularity written all over it! We did some early testing to see if the pimoroni-pico repository could be extended for Golioth’s needs and it looked promising.

Unfortunately, Ostentus didn’t have enough physical space for the same ePaper display. We spun up our own driver based on the Good Display sample code for the GDEH0154D67, a 1.54″ square display that packs in a remarkable 200×200 pixel resolution.

Communications proved a bit of a challenge. Ostentus is an I2C peripheral device and needs to listen on the bus while a lot of other stuff is going on. We were lucky to find Daniel Gorbea’s I2C multi-address library. It builds for the Pico-SDK, utilizing the PIO and interrupts for tight hardware timing. This receives incoming I2C messages over the Qwiic connector, immediately updating LED state for certain commands, and buffering the rest for MicroPython to access.

MicroPython makes images, fonts, and screen control a breeze. There was a learning curve in getting the C code to play nicely with the Python, but it’s not to hard to pick up. For this year’s conference we’ve set up the MicroPython layer to run a slideshow of sensor values. The controlling device registers each slide over I2C, sending a string as the label and assigning a unique key. That key is later used to send updated values as they become available.

What a Show!

It’s been a whirlwind adventure getting to this point. But let’s be honest, most of the Internet of Things industry happens in abstract and non-obvious ways. Golioth moves the ball on securely connecting and controlling microcontroller-level devices, and lots of them. Ostentus makes it much easier for us to show that story in real-time, at a booth, in the middle of tens of thousands of awesome embedded engineers. We can’t wait you see you next week. At the very least, you’ll want to stop by for a hands-on view of our sleek new Ostentus board!

/by
,

Sipping Celluar IoT Power – A Golioth Webinar with Jared Wolff

Cellular IoT products struggle with battery life. Getting and staying connected to a cell tower takes a good amount of energy. Though we’re past the days of GSM drawing amps of current (!), it is still costly to open sessions to the tower. Understanding how your device is communicating with the Cloud is crucial to building robust devices that will last years in the field.

This webinar will include Golioth team members, alongside Jared Wolff of CircuitDojo. Jared is an early adopter of Golioth and a Golioth Ambassador, as well as an advocate for Zephyr devices. Golioth utilizes Jared’s nRF9160 Feather board designs in all of our current cellular-based Reference Designs.

What you can expect from this Webinar

First and foremost, we hope to make this a more dynamic and interactive session than many technical webinars. (No one will be reading Powerpoint slides in a monotone voice here!) The session will cover:

  • Understanding your connection to cellular towers
  • Understanding your power draw when in a passive or sleep mode
  • Measurement challenges for embedded cellular projects
  • Methods for saving data (and power) when connecting to the cloud
  • Building robust device health metrics for your fleet
  • System architecture decisions for lower power circuit boards

Sign up now!

This webinar is at 1 pm EST / 10 am PST on January 18th, 2023. If you can’t make it the day of, you can still still sign up to access the on-demand content. Those who attend will have an opportunity to ask questions towards the end of the presentation.

/by
, ,

Introducing Golioth Certificate-Based Authentication

Golioth is secure by default, offering a couple of different ways for your devices to establish a secure connection to the Golioth Servers. When trying out features in the lab, pre-shared keys (PSK) are fine. But when moving devices into production, there is no substitute for certificate-based authentication.

Today we are announcing the ability to use Certificates with the Golioth platform.

Certificates deliver numerous security benefits when compared to pre-shared keys. This is especially true when it comes to provisioning your IoT fleet. As devices roll off the assembly line, they can be granted individual device certificates signed using a trusted chain of root certificates and intermediate certificates. At that point, the devices are not yet registered on the Golioth server. When they first connect, the certificates are verified against the chain of trust and a record of the trust-verified device is created. This simplifies the registration of a large influx of new devices, as happens in a production environment.

Let’s walk through the process used to get to that point.

How to generate and use certificates with Golioth

Generating a self-signed root certificate

A root certificate is a cryptographic public/private key pair. The private key is used to sign all device certificates. The public key is uploaded to the Golioth server and used at the project level to verify each device certificate when establishing a secure connection.

SERVER_NAME='golioth'

# Generate an elliptic curve private key 
# Run `openssl ecparam -list_curves` to list all available algorithms
# Keep this key safe! Anyone who has it can sign authentic-looking device certificates
openssl ecparam -name prime256v1 -genkey -noout -out "${SERVER_NAME}.key.pem"

# Create and self-sign a corresponding public key / certificate
openssl req -x509 -new -nodes -key "${SERVER_NAME}.key.pem" -sha256 -subj "/C=BR/CN=Root ${SERVER_NAME}" -days 1024 -out "${SERVER_NAME}.crt.pem"

The code above generates two files. The golioth.key.pem is the private key which you must safeguard. All credentials created from this private root key will be fully trusted. Golioth will not have a copy of this key.

The golioth.crt.pem is the public key that is uploaded to Golioth. This serves as a way to verify device credentials as trusted. It cannot be used to sign new device certificates, only the private key has that power.

Upload the root certificate public key to Golioth

Certificate authentication

As of December 2022, the Golioth console includes a “Certificates” option on the left sidebar menu. The resulting window is used to upload the root certificate public key. This is all that you need to do to prepare the Golioth Cloud for your fleet. As long as each IoT device has its own certificate signed with your root certificate’s private key, it will be added to this project the first time it tries to connect to Golioth.

Generate device certificates

PROJECT_SLUG='project_slug'
PRIMARY_HARDWARE_ID='primary_hardware_id'
SERVER_NAME='golioth'
CLIENT_NAME="${PROJECT_SLUG}-${PRIMARY_HARDWARE_ID}"

# Generate an elliptic curve private key
openssl ecparam -name prime256v1 -genkey -noout -out "${CLIENT_NAME}.key.pem"

# Create a certificate signing request (CSR)
# (this is what you would normally give to your CA / PKI to sign)
openssl req -new -key "${CLIENT_NAME}.key.pem" -subj "/C=BR/O=${PROJECT_SLUG}/CN=${PRIMARY_HARDWARE_ID}" -out "${CLIENT_NAME}.csr.pem"

# Sign the certificate (CSR) using the previously generated self-signed root certificate
openssl x509 -req \
    -in "${CLIENT_NAME}.csr.pem" \
    -CA "${SERVER_NAME}.crt.pem" \
    -CAkey "${SERVER_NAME}.key.pem" \
    -CAcreateserial \
    -out "${CLIENT_NAME}.crt.pem" \
    -days 500 -sha256

# Convert device certificates to DER format
openssl x509 -in ${CLIENT_NAME}.crt.pem -outform DER -out ${CLIENT_NAME}.crt.pem.der
openssl ec -in ${CLIENT_NAME}.key.pem -outform DER -out ${CLIENT_NAME}.key.pem.der

The root certificate is the source of trust, and all device certificates are created using this private key. This is why it is crucial that you safeguard your root certificate(s). Device credentials are created using the private key and added to your fleet during production. If newly created devices are compromised, it will not affect any other device credentials already out in the field because they don’t hold the (root) private key, they were simply generated from it.

The code above uses the Golioth Project ID as the PROJECT_SLUG and the SERVER_NAME to connect to the correct project. The root certificate public key was uploaded to this project in the previous section. When creating device certificates, the PRIMARY_HARDWARE_ID is a unique identifier that you generate (e.g. MAC address, naming scheme, any string will work). You need one of these for each device in your fleet.

As with the root certificate, the device certificate creation process will generate a public/private key pair. Both are loaded onto the device and used when establishing a secure connection to the Golioth Servers.

Golioth uses ECDSA (a note for other encryption geeks like us)

When a device is ready to connect to Golioth, it will request and download a server-side (public) certificate. That too will be signed by a trusted authority. The device will need to verify that certificate to ensure it’s not attempting to connect to a bad actor, such as someone pretending to be Golioth by using a “man-in-the-middle” (MITM) attack.

At Golioth, we are embedded developers as well as Cloud experts, so we chose an encryption that is as friendly as possible to resource-constrained devices. That is why we have all the certificates in the chain use ECDSA keys. They are significantly smaller to transfer and less resource intensive for embedded processing.

Summary

We’ve previously written about the importance of using certificates for Internet of Things (IoT) authentication. Certificate validation scales well, especially when it comes to provisioning devices during manufacture. New credentials can be signed with a root certificate without needing to share them back to the cloud server. And since those devices will be sent out into the field there’s an additional security benefit: compromised devices don’t expose symmetrical keys as is the case with PSK-based encryption.

In most cases, production deployments should consider certificate-based authentication for their IoT fleet. The certificate feature is built into Golioth and ready to use today.

We’d love to hear about how you are securing your company’s IoT fleet. Share your questions and tips on the Golioth Forum and don’t hesitate to reach out to our Developer Relations team if you’re interested in a guided tour of our certificate-based authentication!

/by
,

Golioth is headed to the Hackaday Superconference this weekend!

Jon Beri, Chris Gammell, and Mike Szczys are headed for Pasadena this weekend for the Hackaday Superconference! After a hiatus of several years, we’re excited to get back out into the hardware community and this has become something of a can’t miss event for that crowd.

This is the first time the three of us will be there showcasing Golioth. We’d love to discuss what our next-gen device management can do for you IoT fleet. Let us know you’ll be there using the DevRel email, so we don’t miss a chance to discuss in person.

Open Source RTOS on a Connected ePaper Badge

To kick off the con this Friday we’re presenting our developer training as a Supercon workshop. It focuses on getting started with the Zephyr RTOS.

We’ve been polishing our approach to training all year and this is the culmination of that work. A month ago Chris wrote about the Kasm “container in a browser” experience we’re using to pre-install all the build tools. We’ll be using that approach this weekend so that attendees can be up and compiling within minutes of starting. The workshop will build some muscle memory on the compiling/flashing process, then dive into Devicetree, Pin Control, working with sensors, and the basics of device/cloud interactivity needed in a successful IoT deployment.

The tickets for the workshop sold out right away. If you’re at Supercon, we’d be happy to go through the training with you during “alley-con”. Find us at any time during the weekend to try it out yourself, or even to get a quick badge demo. If you can’t make it to the conference, you can do a self-guided version of the Golioth Developer Training or sign up for future versions of in-person and remote hardware training.

Super-what?

This is the sixth Hackaday Superconference and the first in-person even following a two-year pandemic hiatus. An intimate gathering of fewer than 500 people, everyone you see there has a fascinating backstory, usually involving (or adjacent to) electronic hardware creation. There’s a workshop on designing your own ASICs, talks on wearables, manufacturing, grant-writing for open-source, and the list goes on. Our own Chris Gammell is presenting on his experience as a one-engineer dev shop. Both Mike and Chris helped to kickstart the conference 6 years ago and we’re thrilled that it’s still such a vibrant gathering of hardware enthusiasts.

Almost everyone brings along demos of what we’ve been working on; you can bank on us having a bunch of Golioth demos in our backpacks. There’s also a custom electronic badge, this year it’s an intricate handheld 4-bit computer, complete with a 12-button input register for shifting in your machine-language formatted commands.

Given that there is an input/output expansion header on this badge, it would be a shame if we made it through the weekend without connecting this thing to the Internet in an interesting way. Hit us up on the Golioth Forum thread for this post if you have some ideas on where we can go with that concept.

Take Us for a Test-Drive

We’re not stopping until we’ve spread the word about Golioth. Device management is the piece of IoT ecosystem that companies keep reinventing–a painful and fraught process. Our Dev Tier is free for the first 50 devices.

As your fleet moves from 10 to 100 to 1,000 devices, you face a growing set of problems with handling the data, command and control of the devices themselves, remote firmware updates, and the big one: making sure it remains secure. Give us a chance to show you how we’ve solved these problems, and many you haven’t even thought of yet.

Head over to the Golioth Console to get your free account, then checkout out the Getting Started docs, or jump into the Developer Training we mentioned earlier. Interested in joining a future in-person or remote training? Sign up here.

/by
,

What is Golioth LightDB State?

What is Golioth LightDB State

The Internet of Things is all about transferring data between devices and the cloud. Of course not all data is equal, but with just a few core services you can cover all the bases. One example is the need for persistent data that is easily accessible.

With the Golioth LightDB State service, data can be stored and retrieved from the both the Device and the Cloud side. This is useful for reporting status information, restoring configurations after a power cycle/network outage, and indicating desired changes.

How Golioth enables persistent data

Recording sensor readings might be the first use that comes to mind for IoT devices (our LightDB Stream service is built for that!) but many times we also need stateful data.

State data has no concept of time but instead answers the question: “what was the last status we received?” It acts as a single point of truth that’s quick and easy to access from both the device side and the cloud side. Every time you request a state endpoint you can be sure you’re getting the most recently updated value.

Devices in the field can use state data to report their actual state, things like:

  • What is the timestamp of the last reboot?
  • How full is that SD card used for offline storage
  • What units has the user set for sensor data?

From the Cloud side, state data may be used for command and control. By setting a “desired state” in the Golioth LightDB State, devices with infrequent connects will receive their marching orders the next time they reconnect. Of course this use-case is also solved by the Golioth Device Settings Service which allows project-wide settings adjustments.

LightDB State data can be as simple as a single key/value pair, or as complex as a nested data structure. Devices registered to observe values will be notified every time there is new state data available.

LightDB State using Zephyr RTOS

Your device chooses a path to store and access the LightDB State data. The cloud doesn’t need to be prepared in advance. If your device sends data to a new state endpoint it will automatically be created. There are number of examples of LightDB State API in the Golioth Zephyr SDK.

/* Setting a value on the "counter" endpoint */
err = golioth_lightdb_set_cb(client, "counter",
                 GOLIOTH_CONTENT_FORMAT_APP_JSON,
                 sbuf, strlen(sbuf),
                 counter_set_handler, NULL);

/* Observing data changes on the "desired/my_config" endpoint */
err = golioth_lightdb_observe_cb(client, "desired/my_config",
                 GOLIOTH_CONTENT_FORMAT_APP_JSON,
                 desired_state_handler, NULL);

Here we see asynchronous API calls to set a counter endpoint and to observe data changes on a desired/my_config endpoint. In both cases a “handler” callback function is registered to process the received data (in the case of the observe operation) or handle error messages received from the server.

The Golioth Zephyr SDK also includes the option to send your sensor data using CBOR encoding. This is an alternative to JSON which serializes the data stream to a more compact form to save battery (less radio-on time) and bandwidth (fewer bits being transmitted).

LightDB State using ESP-IDF

The ESP-IDF SDK shares a very similar set of API calls. The device again chooses the endpoint to use on the Golioth LightDB State service. The golioth_basics sample code demonstrates how to use the set/get/observe functions.

/* Setting a value on the "counter" endpoint */
golioth_lightdb_set_int_async(client, "counter", counter, NULL, NULL);

/* Observing data changes on the "desired/my_config" endpoint */
golioth_lightdb_observe_async(client, "desired/my_config", on_my_config, NULL);

Here we see asynchronous API calls used to set the counter endpoint and observe the desired/my_config endpoint.

LightDB State using your own solution

For the extra ambitious out there, you could roll your own device side code that allows you to connect to Golioth. This is the kind of work our wonderful firmware team does whenever they spin up a new SDK. Some of the required elements include:

  • mbedtls in order to create a DTLS connection to the Golioth Cloud
  • A CoAP library
  • (optional) a CBOR library to encode the data

We hardly ever recommend doing this unless you are a very advanced user. Instead, our existing SDKs cover a wide swath of parts, ecosystems, and Real Time Operating Systems. If you are interested in one we don’t already cover, please let us know.

Formatting data and access from the cloud

The Golioth LightDB State service will accept and store any properly-formatted data encoded in either JSON or CBOR. If the endpoint doesn’t yet exist, it will be created when data is received. null will be received when requesting a non-existent endpoint.

As an example, your device might send the following JSON string to LightDB state:

{ "status": { "last_reboot": 1666586559, "location": {"lat":42.988814,"lon":-90.139254,"alt":369.7,"accuracy":2.3,"speed":0.0,"heading":0.0,"time":"2022-10-31T22:49:03.239Z"}, "debug_mode": 0 } }

This imaginary device is recording the last time it rebooted, saving a location from its GPS unit, and reporting on whether or not the debug mode is activated. Whether this data is sent as JSON (which is the case here) or CBOR, the Golioth Console will unpack the information and display it as human-readable JSON:

Golioth LightDB State

What’s really great is that once the data arrives on the Golioth Servers it’s incredibly easy to work with. You can get real-time updates using WebSockets, connect your data to your favorite cloud provider (e.g. AWS, Azure, or GCP) using our Output Streams, and access/update the data using the Golioth REST API.

Start using LightDB State Today!

All of our Device SDKs show how to use LightDB State with minimal code writing from the user. Just pass your state data up to Golioth and you’ll be on your way. Stop by our Forums or send us an email if you get stuck.

/by
,

Golioth is now included in Infineon’s ModusToolbox™!

Golioth added to Infineon ModusToolbox

Golioth now supports Infineon parts via the ModusToolbox™. We added Golioth device management to the ecosystem a few weeks ago and the example code is available right now to run on Infineon’s line of microcontrollers talking to their Wi-Fi parts.

ModusToolbox™ (MTB) is a software support tool from Infineon Technologies. It includes partner SDKs alongside the company’s officially supported IDEs, drivers, and examples. You can pull in the Golioth example and all dependencies using the Eclipse IDE that is included in MTB, or via the command line tool.

Infineon’s PSoC™ 6 chips are feature rich 32-bit Arm microcontrollers. Paired with the Infineon 4343W, it’s a perfect platform for IoT device builders, and exactly the kind of constrained device that Golioth was built for.

Take advantage of Over-the-Air (OTA) firmware updates, time-series databases, state data management, remote logging, plus the command/control features like remote procedure call (RPC) and the device settings service. The API calls for each of these are demonstrated and well-commented in the golioth_main.c file.

Try the Golioth example using ModusToolbox™

PSoC 6 Wi-Fi BT Prototyping Kit (CY8CPROTO-062-4343W)

We run the Golioth example on the PSoC™ 6Wi-Fi BT Prototyping Kit (CY8CPROTO-062-4343W). Here’s how to try it for yourself:

1. Install Infineon’s ModusToolbox™

Begin by downloading and installing ModusToolbox™ for your system. Then run modustoolbox-eclipsewhich is located in the ide_3.0/eclipse/ subfolder.

2. Create a Golioth Example project

With the Eclipse IDE open, click on File→New→ModsToolbox Application. This will launch the project creator window.

Select the CY8CPROTO-062-4343W from the list of PSoC™ 6 boards and then click next.

Choose the Golioth Example from the Wi-Fi list and click on the Create button. This will take a couple of minutes to clone the Golioth code and all dependencies.

3. Compile and Install MCUboot

Golioth uses MCUboot as the secure bootloader for our Over-the-Air updates. Before flashing the app to the board, we need to compile and install MCUboot. I did this using the IDE’s built-in terminal.

First, we need to install the MCUboot dependencies.

cd ~/mtw/mtb_shared/mcuboot/v1.8.1-cypress/scripts/
python -m pip install -r requirements.txt

Now we can compile and flash MCUboot. Remember to plug a USB cable into the KITPROG3 connector on your PSoC™ 6 devboard before running the program command:

cd ~/mtw/Golioth_Example/bootloader_cm0p/
make build_proj -j8
make program_proj

4. Compile and flash the Golioth App

Before compiling the Golioth App we need to give it credentials to connect to Wi-Fi and also to authenticate with the Golioth server. These are set in the ~/mtw/Golioth_Example/golioth_app/source/golioth_main.hfile.

Use the Wi-Fi credentials for your local access point. Get device credentials from the Golioth Console. If you’ve haven’t yet set up an account, check out our Quickstart. (With Golioth’s Dev Tier your first 50 devices are free.)

Once you’ve saved your changes to the golioth_main.h file, use the terminal to compile and flash the app to your PSoC™ 6 board:

cd ~/mtw/Golioth_Example/golioth_app
make build_proj -j8
make program_proj

Taking the Golioth App for a test drive

[INF] MCUBoot Bootloader Started
[INF] External Memory initialized w/ SFDP.
[INF] boot_swap_type_multi: Primary image: magic=unset, swap_type=0x1, copy_don3
[INF] boot_swap_type_multi: Secondary image: magic=unset, swap_type=0x1, copy_d3
[INF] Swap type: none
[INF] User Application validated successfully
[INF] Starting User Application (wait)...
[INF] Start slot Address: 0x10018400
[INF] MCUBoot Bootloader finished
[INF] Deinitializing hardware...
External Memory initialized w/ SFDP.
=========================================================
[GoliothApp] Version: 1.0.0, CPU: CM4

=========================================================
[GoliothApp] Watchdog timer started by the bootloader is now turned off to mark.
[GoliothApp] User LED toggles at 1000 msec interval

WLAN MAC Address : 74:7A:90:D4:5F:04
WLAN Firmware    : wl0: Jul 18 2021 19:15:39 version 7.45.98.120 (56df937 CY) FWID 01-69db62cf
WLAN CLM         : API: 12.2 Data: 9.10.39 Compiler: 1.29.4 ClmImport: 1.36.3 Creation: 2021-07-18 19:03:20 
WHD VERSION      : v2.5.0 : v2.5.0 : GCC 10.3 : 2022-09-23 13:14:02 +0800
Wi-Fi Connection Manager initialized.
Successfully connected to Wi-Fi network 'MyWiFiAP'.
IP Address Assigned: 192.168.1.153
Secure Sockets initialized
I (5515) golioth_main: Waiting to Golioth to connect...
I (5638) golioth_coap_client: Start CoAP session with host: coaps://coap.golioth.io
I (5643) libcoap: Setting PSK key

I (5649) golioth_coap_client: Entering CoAP I/O loop
I (5886) golioth_main: Golioth client connected
I (5996) golioth_fw_update: Current firmware version: 1.0.0
I (6060) golioth_fw_update: Waiting to receive OTA manifest
I (6258) golioth_fw_update: Received OTA manifest
I (6258) golioth_fw_update: Manifest does not contain different firmware version. Nothing to do.
I (6260) golioth_fw_update: Waiting to receive OTA manifest
I (6322) golioth_main: Synchronously got my_int = 42
I (6323) golioth_main: Entering endless loop
I (9006) golioth_main: Callback got my_int = 42
I (9286) golioth_main: Setting loop delay to 5 s

By monitoring the serial output from the device (that’s /dev/ttyACM0 on my system) we can see all the parts of the app at work. The board powers up and reports the firmware version before connecting to Wi-Fi. Once a Golioth connection is established it checks for firmware updates before it starts writing data to the cloud.

You can view device logs remotely through the Golioth console. Here we see “Sending hello!” messages arriving along with a counter.

Viewing state data for this device, the counter variable is update at the same rate as the hello messages. In the Device Settings on the left sidebar of the console you can add LOOP_DELAY_S and remotely control how how many seconds the device pauses for between sending back these message. It’s a perfect way to control sensor reading frequency across your entire fleet.

Adding Golioth to existing Infineon PSoC™ 6 projects

The Golioth example that is part of ModusToolbox™ is a great blueprint for adding device management to your PSoC™ 6 projects. We’d love to hear what you’re build, and if you need some help we’re here to lend a hand. Show off your successes and post questions on the Golioth forum. Feel free to reach out to the Golioth Developer Relations team to set up a demo or discuss the needs of your IoT fleet.

/by