This is our "end of the year" release, and we did want to focus on improving what we already have, rather than introducing a bunch of new functionality, before leaving for the holiday season/Christmas. So we put a lot of effort into cleaning up, filling some gaps that we identified, and polish the current functionality.
We love Kubernetes and the standardized API it brings to deploying applications in the cloud. For running a local instance of Drogue Cloud, minikube is already a great alternative. But sometimes, you just want to have an easy getting started experience, to reduce turnaround time when testing changes to Drogue Cloud itself, or for running in environments where Kubernetes is not available.
Read on to learn how you can run Drogue Cloud standalone.
Earlier we've seen examples of drogue device using LoRaWAN using an STM32 discovery board. Since then, the hardware support in the community has improved even more.
The 0.7 release cycle ran through summer and with that, two things happened: people got on vacation, and Google Summer of Code was going on. So instead of forcing out a release, we decided to just wait and release at a later time. By the way, a decision we discussed during our open community calls: come and join!
This article shows how you can setup X.509 certificates to authenticate devices connecting to Drogue Cloud and an example of how drg makes it easy.
We recently added a websocket endpoint in drogue cloud, to easily get a stream of events for an application, using the well-known websocket protocol. Let's have a look and build a small demo apps to consume events.
As we all know, the S in IoT stands for security. However, one reason IoT has a bad security track record is that it consumes a lot of resources and is not that easy to setup. One piece of this puzzle is having good client side libraries for doing TLS. Read on to learn more about how you can secure your device to cloud communication.
Drogue Cloud 0.6.0 ran a bit late. But, it is ready when it is ready! This time, the focus was more on improving on what we already have. And taking a look back, we improved a lot.
In the previous post we introduced Func project as a very useful framework for writing serverless functions in the Knative world. The post ended with the question what can we do with it? So let's explore one practical use case now.
What does embedded development and WebAssembly have in common? Turns out it's quite a lot! Read on to see how Drogue Device can run in your browser.
For most IoT developers, drogue-cloud is designed to be used "as a service". But if you have admin access to the cluster on which drogue-cloud is running, i.e. you installed it yourself on minikube or kind, it's possible to "extend" the platform by triggering a function each time an event from a device is processed.
Today we released Drogue Cloud 0.5.0. It brings together a lot of things that have been cooking for a while.
Writing code is easy, writing documentation is hard. True, some people might disagree with that. We wanted to make it easier for everyone to understand what we already have, and how it works. As we have multiple major topics (embedded and cloud), we need a modular way of structuring our documentation. Here is our approach.
For the past few weeks, we explored removing the allocator from drogue-device and adapt drivers to a more restrictive Actor model. Read on to learn why and how drogue device will change, and the benefits of this change.
A guided tour of drg, the command line client that aims to make your life easier when interracting with a drogue-cloud instance.
Today we released Drogue Cloud 0.4.0. This is a huge step forward in so many areas, let's take a look.
So far, we didn't really release anything. We created tagged versions, so that you don't need to rely on latest,
which might change any second. We had a release pipeline in the CI. Still, it just didn't feel ready enough.
This time it is different.
In previous posts we've seen how to run drogue-cloud, how to use LoRaWAN in rust, and the introduction of the drogue-device. In this post, we'll tie this together and walk through the process of running LoRa on drogue-device, sending data to drogue-cloud.
You might have noticed, we talk about Rust a lot. Mostly in the context of embedded programming. However, we also have a few bits and pieces in the cloud side of things. If you have a device that gathers data, you might want to send that data somewhere for further processing and storage. Now, if we are using Rust to implement the embedded side, why not use it on the backend as well?
Trying to bring reusable and efficient components to embedded Rust has been a challenge for our team.
We think we've started to make headway, and want to introduce the Drogue Device project.
Good news, everyone! Google Summer of Code 2021 is coming up. This gives you the chance to throw yourself at some horrifying tech problems, learn some new skills, and maybe get to know a few more memes. We are participating, how about you?
So far when we talked about serverless IoT cloud we focused only on one way communication, devices sending telemetry data to the cloud. But in order to have a complete IoT solution, we need to be able to control our devices as well, by sending commands back to them.
LoRa is a low power long range wireless protocol that operates in a lower frequency spectrum than WiFi, ZigBee and Bluetooth. This enables IoT use cases not possible with the shorter range technologies. And, you can use Rust!
Pushing temperature readings in JSON structures to the cloud is fun, but more fun is to restart your pods by saying:
"Hey Rodney, …". It also is a nice demo, and a good test, to see what fails when your Content-Type is audio/wav
instead of application/json.
If we start living the async lifestyle, we can potentially get more use out of our limited hardware resources. Maybe not, but it's worth exploring. Let's explore.
The BBC micro:bit is a popular development kit often used to teach kids how fun programming can be. Lets see how we can hook it up to the cloud!
async/await within Rust is a convenient way to gain parallelism,
even on an embedded device where we ostensibly have exactly one userland
thread by default.
Minikube is a convenient tool for developing cloud services on your laptop, but how can you access them from your IoT device? In this article, we'll walk through deploying the drogue-cloud project on minikube and then use some drogue crates to post data to its knative endpoint via an ESP8266 WiFi module.
Exchanging messages with devices is great. As I tried to explain in the last blog post about the cloud side of things, having a modular system, and normalizing the transport protocol can make things a lot easier. However, exchanging messages is only the first step towards an IoT application.
Up until now, we have focused on "Rust on embedded devices", at least when it comes to writing blog posts. Let's change that.
Non-technical post -- Hey, we have a new logo!
While the S in IoT stands for "security", the T stands for "things", and things move. Wouldn't it be nice to know how they move, exactly?
Routinely we have to deal with recognizing patterns within text or byte streams. While LL(k) and LALR are common types of parsers, the nom crate brings parser combinators to the embedded Rust world.
There's a lot of variety in the embedded world. While we've implemented the ESP8266 WiFi-offload board over USART last time, now we're doing the Inventek eS-WiFi over the SPI bus. Let's explore some of the differences.
In the embedded world, quite often you don't have a wall clock sort of clock. You may have something that can reckon the passage of time, though. The various current solutions for managing time within embedded Rust has yet to be completely abstracted. We leverage some up-and-coming libraries to help paper over the differences.
Getting started with an ESP-01 isn't one of the easiest things. At least if you are not used to embedded systems. It is a nice solution though to add Wi-Fi capabilities to an existing platform.
We've recently gotten TLS functional for embedded systems in Rust. TLS (Transport Layer Security) is one of the backbones to secure communications over TCP/IP, helping protect data in-flight between two parties. There's a lot of moving parts involved in bringing easy-to-use functional cryptography to small 32-bit ARM Cortex-M devices. Let's dive in, shall we?
My recent work has been around Cortex-M embedded development using Rust and RTIC. I'm using a handy little development board in the form of the STM Nucleo-F401RE. Unfortunately, it's handiness stops as soon as you want to communicate with TCP over WiFi, because it lacks WiFi.
As noted in the first post, I'm working towards doing more IoT using Rust in an embedded ARM Cortex-M world. Thankfully, the Rust compiler leverages LLVM and can target quite a few different processors.
Welcome to the Drogue IoT blog. This is where I intend to document my progress through discovering how to build enterprise-grade IoT device systems using Rust and ARM Cortex-M MCUs.