PidgeIoT is a fully open source, cloud native, device management platform. Originally targeted at cellular connected devices, now aimed at everything! Currently only HTTPS and WebSockets are supported, but CoAP is planned. Bring your own SIM (if needed) and telemetry store.
Its features include: device shadows, per-device keypairs (no JWTs!), telemetry ingestion with history, user-defined telemetry graphs, conditional email alerts, remote logging (on Zephyr), remote diagnostic shell (also on Zephyr via a WebSocket), OTA firmware updates (and hosting), and probably other things I've forgotten about at this point.
PidgeIoT is built in Rust from front to back. The frontend is WASM (Dioxus) and the core is built around Cloudflare Workers and Durable Objects (also WASM). The backend uses a managed PostgreSQL DB (for now). The IAM is self-hosted Ory Kratos.
You may be asking "Why not just use a JS library for your SPA like a sensible person?" To that I say, I hate JavaScript! Okay, okay, it's not thaaat bad; but it's not my cup of tea and WASM is cool (and the future).
Some Background:
A couple years ago I was new to embedded systems and working on a project for a Regional Transit Authority (RTA) that required realtime data over a cellular connection. The system needed to receive a relatively large amount of data (around 4kB - 20kB) every 30 seconds. The data vendor “refused” to remove unnecessary information from the data or create a custom endpoint for me, and the RTA wasn’t keen on maintaining a middleware server to transform the data.
Those constraints made existing IoT platforms unsuitable for the project, as they either had low data limits or charged excessively for each transmission. Other platforms required a Kubernetes cluster, an enterprise contract, or a project rewrite around their firmware.
That frustrated me. I had a working system and no way to remotely manage it. So I made my own platform. A platform that hopefully makes getting into this space easier and less cost prohibitive!
Currently all of the example projects are Zephyr based and include configs for native-sim plus the devices I have with me. Let me know if you have a different device/firmware and need me to whip up an example for you!
I know having to signup and compile firmware are annoying barriers to test it out, but I think they're necessary for what PidgeIoT is.
Plus I made these nice, Non-GMO, links just for you:
- Getting started guide that requires no hardware: https://pidgeiot.com/getting-started
- A live demo: https://pidgeiot.com/demo
Please give me plenty of feedback; let me know what you want to see; tell me if I'm crazy for even trying this when AWS IoT exists!
Is this another case of xkcd #927?
* All PidgeIoT usage is free during early access; no credit card required. Pricing will come later with the express goal of not making past Justin think another platform needs to be built.
GitHub Links, all repos AGPL-3.0 licensed:
- pidgeiot: https://github.com/justins-engineering/pidgeiot
- pigeon: https://github.com/justins-engineering/pigeon
- pigeon-examples: https://github.com/justins-engineering/pigeon-examples
Voxorin•2h ago
- Q: Is it self-hostable?
- A: Well yes, but actually no. You can self-host Ory Kratos and PG. The core is deployable to your own Cloudflare account, but can't be run on bare metal (well technically it could, but you shouldn't). I would like to make a fully self-hostable version in the future, but that's low on the priority list right now.
- Q: Why not use JWTs for device authentication?
- A: 1. JWTs are a poor design; See: https://github.com/jedisct1/rust-jwt-simple#why-yet-another-... 2. JWTs are stateless tokens that are valid for their lifetime. That makes revoking them a pain; See: https://stackoverflow.com/a/40385939
- Q: AGPL in my firmware!? Isn't that going to infect my firmware and make it yours?
- A: No, AGPL binds people modifying/serving PidgeIoT itself, and the device talks over a documented HTTP protocol; your firmware is yours.
- Q: Have you heard of ThingsBoard?
- A: I have heard of ThingsBoard, I even tried it out! It's good software and I hope to meet their functionality in the future. With that said...
I feel it has a severe lack of simplicity and a high barrier to entry. Somewhat similar to AWS, ThingsBoard is a product family with per-product licensing. I want one coherent service. Not a tangled mess that requires a degree to set up (exaggeration, but you get my point).
Easy to use, easy to scale, one product, one price, open protocol, etc, etc.
Just one accessible service.
I also plan on enabling Cloudflare's Workers for Platforms which gives users their own data-processing workers. That's pretty much synonymous to ThingsBoard's rule engine, without the fragile (IMO) visual rule chains.