Nothing with WiFi will ever be coin cell battery powered. But that doesn't mean it couldn't be battery powered for a year or longer with bigger batteries. Otherwise you'll need a different radio technology.
I don't know, I think the downsides outweigh the benefits. I don't want to have to secure a bunch more IP-based devices that can talk to my computers. I'd rather they were separated at the radio level, like Zigbee.
Thread is also IP(v6)-based. But in this context, Thread would go a fair ways toward solving stavros's concern, as it means security could be enforced on the Border Router(s), rather than each individual device.
Few years ago I made a custom RGB LED rope light controller using ESP32 C3 DevKit and Rust embedded, connecting light to homeassistant via MQTT auto discovery. Was surprisingly easy to get started as someone who had limited experience with embedded programming, and only hobby Rust experience.
But the supported hardware in Rust crates was limited at the time and C3 dev kits weren’t widely available, so I never used it for anything. HAL support has only gotten better since then.
I may try to resurrect that project now with Pico 2 and Matter.
I'm desperate for people to make tech that's searchable. I'd like to figure out some of the thread/matter bits for my own projects and this is terribly annoying to do
I love the Pico product line and think they are severely underutilized. Many Pi 3/4/5 projects can be performed with one of these little guys. Don’t chain yourself to a whole Linux distro unless you really need it.
What I'll never understand about this whole thing is why most people seem to easily tolerate the rigamarole of maintaining an entire host SBC OS and sending or even cross compiling binaries to it, for microprocessor work. I much prefer maintaining a dev env on machine(s) and sending and flashing a binary over the wire. Maybe I just dislike state, but the pico (and several other MCU ecosystems these days) make it so easy to
Like: I suck at code. But I've known how to walk around in *nix systems and use things like bash to chain together commands like awk, grep, and sed for ~30 years. Maybe I'd even toss in some badly-cooked perl or python (or both!), when that seemed necessary.
For a very long time, I've been able to get some things done, but my skillset was focused on doing these things with real computers with live filesystems and real user interfaces, not MCUs.
So, some years ago: When I wanted to turn a window fan on and off based on some network-retrieved weather conditions, I didn't even consider an MCU. I didn't want to learn a new way of doing things; I just wanted a computer to get some data and decide whether to turn the fan on and off. And I wanted that done sooner instead of later.
I accomplished this with a Raspberry Pi Zero W -- with the whole OS. I didn't cross-compile anything. I didn't have to target some weird-looking external environment, or learn a new way of doing things.
Setting up the dev environment was very familiar: Dump a binary onto an SD card, boot it, get it onto the network, and use it.
I just SSH'd into that tiny little computer like I would any other Linux box and wrote my stupid little cobbled-up scripts right there, in-situ, on the final device that would be performing the work -- with a familiar interactive shell.
The end result worked very well. I'm not ashamed of any of this at all.
---
Later, I switched from networked weather reports to an RTL-SDR dongle and software decoding to listen for over-the-air broadcast reports from someone else's nearby APRS weather station, and used that as a source of weather data instead.
Can we even get that done in MCU land? (Should we even try to do so for just one window fan?)
In MCU land you can definitely listen to and decode OTA sensor data without using something as powerful as an RTL-SDR.
Consider common consumer wireless indoor/outdoor thermometers which have a temperature sensor you place outside and a display you place inside. Most of these use a much simpler radio protocol than WiFi or Bluetooth, and have nowhere near the compute power or memory resources to come anywhere near running Linux.
On the transmit side they typically have a fixed frequency oscillator (commonly near 433 MHz or a little over 900 MHz) connected to an antenna through a transistor. They send data by turning that transistor on and off. There are a variety of ways they might do this. Some might do it as pulses with different widths for 1 and 0. Some might do it by having have say 200 us on followed by 200 us off mean 1 and 200 us off followed by 200 us on mean 0. There are many more.
For home built stuff you can by cheap transmit modules to help with this, such as this one [1]. I'm linking to Sparkfun because they have good documentation, but you can find these all over the place.
On the receive side they use a simple receiver tuned to the same frequency (but with enough tolerance that it isn't a problem that both sides are probably using cheap oscillators that aren't very stable or accurate). Here a receiver module for home built stuff [2].
From what I've read the ways these work is that they automatically adjust the gain to have a constant high output level, but there is some lag in that. If there is nobody transmitting the output is just amplified background noise.
Then when someone starts transmitting the gain gets turned down so it is just enough for their signal to have max output. Let's say they are sending 1s as a pulse of 200 us on, 100 us off and 0s as 100 us on, 200 us off. With the gain set so the on level is at maximum output the off level will be quite a bit below that. As long as the gain adjustment is slow enough that it doesn't turn up the gain too much during that up to 200 us off, the next on will still be readily distinguished.
In that example the transmitter is sending 1 bit every 300 us. The firmware in the receiver can look for high/low and low/high transitions in the radio output, looking for the pattern of several consecutive 300 us intervals with 100 us on/200 us off or 200 us on/100 us off. Interpret that is a bit string, and make sure when you design your protocol your transmissions start with some kind of signature so you can tell you are actually listening to the right sender, and it should work. If you designed the radio protocol reasonably you should be able to do the recognition with some kind of efficient state machine.
Regarding the SDR, the Pico can act as a USB host (honestly a huge win as you can plug in a keyboard/mouse). But it’s not able to run at USB 2 speed. There’s no software for it and the CPU probably isn’t powerful enough. So in that case a Linux machine is completely justified. I tell people to reach for a Pi when they need both Linux and GPIO. But if you just need GPIO you should really save the money (and get major wins in simplicity) with the Pico.
I get the familiar angle of using a Pi Zero. But don’t be intimidated by the Pico. Especially these days with the help of an LLM, you’re not slowed down too much. The version of Python they run feels very familiar. The tooling is good. They’re awesome!
Oh, these days I still suck at code. And with the bot, I can hammer out a project for ESP32 or a Pi Pico in no time. (I didn't even put together the dev environment for that. I had the bot do it.)
And because I still suck at code: If I want to create something myself, then I still get to do that with a Linux box using unix methods.
That all said: I do enjoy working with RP2040 PIO assembler sometimes. The combination of its severe limitations and robustly resolute timing makes it both approachable, and fun. :)
Anyway, I think all methods are OK. There's no reason to judge them. (I think it's also OK to just use a computer to read Facebook, or as a porn machine, or to become an Amish leatherworker and leave all of this digital nonsense behind.)
I'm sure you're aware, but for the record the Pico has state. That's one of the best things about it. You have a very fully featured Python environment (or rust, or C) with a read/write filesystem. The WiFi SDK is also super useful. They can make HTTP requests (and HTTPS without full CA validation), host an HTTP server, even host an access point.
Well all of the linker script is just two standard memory map files, one for the 2040 and one for the 2350, so really it suggests that this needed very little code to make this work. The 6.4% shell represents a shebang line, two comments, and a single `set -e` call, after all.
There's nothing about embedded development in Rust that would make it more reliant on linker scripts than any other language. Github's count is misleading here.
I’ve been experimenting with the new Raspberry Pi Pico 2 W (RP2350) and wanted to see how difficult it would be to build a fully compliant Matter smart device from scratch using Rust.
I put together a complete "Blinky" example using the rs-matter stack and the embassy async framework. It uses BLE for the initial commissioning phase and Wi-Fi for network connectivity. Once flashed, you can provision it directly into Apple Home, Google Home, or Home Assistant using your smartphone—no cloud accounts required. It exposes a standard Matter On/Off cluster that toggles a physical LED wired to the GPIO pins.
A few interesting technical notes from the build:
Bare Metal: It runs entirely no_std on bare metal using embassy-rp.
Radio Coexistence: Getting the CYW43439 wireless chip to handle concurrent BLE (for commissioning) and Wi-Fi (for Matter IP traffic) on the RP2350 took some tweaking. We actually had to dial back the PIO SPI clock divider specifically because the RP2350's faster 150MHz core clock was causing bus corruption when the radio was saturated!
Async Rust: The repo includes the full async CoEx (coexistence) runner setup to safely multiplex the radio between the Bluetooth and Wi-Fi stacks concurrently.
If you’ve been wanting to build local-only smart home devices but felt intimidated by the massive official C++ Matter SDK, doing it in Rust is actually becoming incredibly approachable.
Would love to hear if anyone else is building custom smart home gear in Rust.
The initial approach was to run BLE and Wi-Fi simultaneously. Provisioning sometimes worked. It seems like there was some interference. Then switched to run BLE with Wi-FI off. When I got Wi-Fi credentials, switched BLE off, and turned Wi-Fi on. It still had some issues. Turned out when slowed down SPI bus, it started working. Only tested with Home Assistant and have to fork and patch rs-matter-embassy
That sounds like the crate didn't have coexistence enabled or the defaults were really odd - so much boring stuff to write about BLE/WiFi Coex, but the short is "the default settings" are pretty good for low bandwidth IoT devices.
Use a digital storage scope, many of them can directly decode protocols like SPI . Then a lot of trial and error to figure out when exactly the issue happens and what else is happening around that time.
Rust on embedded is becoming more approachable with Embassy and the Pico SDK. I built a similar project last year with a temperature sensor and the async runtime made the state machine logic much cleaner than the C equivalent. Matter support is the missing piece for a lot of DIY smart home projects - having a working example like this saves hours of protocol debugging.
Cool project! Just one thing: It says "ultra low" power.
But ultra low is not necessarily the same as battery powered, which itself doesn't necessarily mean coin-cell battery powered.
My experience with wifi modules I've built so far has been, they've all been "low" but not usually battery powerable.
I wish the README provides more info whether it's suitable for battery-powered operation, and if so how which.
Nothing with WiFi will ever be coin cell battery powered. But that doesn't mean it couldn't be battery powered for a year or longer with bigger batteries. Otherwise you'll need a different radio technology.
Think about Matter what you want, but the fact that it is simply IP-based so you can hack something like this together is pretty amazing.
I don't know, I think the downsides outweigh the benefits. I don't want to have to secure a bunch more IP-based devices that can talk to my computers. I'd rather they were separated at the radio level, like Zigbee.
Matter is just the protocol from my understanding, it can also be used over Thread, which is a seperate radio and made to replace Zigbee/Z-Wave.
Thread is also IP(v6)-based. But in this context, Thread would go a fair ways toward solving stavros's concern, as it means security could be enforced on the Border Router(s), rather than each individual device.
Yes, this is true, but I think over Thread it's also fairly complicated, as a protocol. I'm not very familiar with it, though, admittedly.
Rust on embedded is fun to play with.
Few years ago I made a custom RGB LED rope light controller using ESP32 C3 DevKit and Rust embedded, connecting light to homeassistant via MQTT auto discovery. Was surprisingly easy to get started as someone who had limited experience with embedded programming, and only hobby Rust experience.
But the supported hardware in Rust crates was limited at the time and C3 dev kits weren’t widely available, so I never used it for anything. HAL support has only gotten better since then.
I may try to resurrect that project now with Pico 2 and Matter.
I'm desperate for people to make tech that's searchable. I'd like to figure out some of the thread/matter bits for my own projects and this is terribly annoying to do
Thread isn't interested in hobbyists.
https://news.ycombinator.com/item?id=40326269
I love the Pico product line and think they are severely underutilized. Many Pi 3/4/5 projects can be performed with one of these little guys. Don’t chain yourself to a whole Linux distro unless you really need it.
What I'll never understand about this whole thing is why most people seem to easily tolerate the rigamarole of maintaining an entire host SBC OS and sending or even cross compiling binaries to it, for microprocessor work. I much prefer maintaining a dev env on machine(s) and sending and flashing a binary over the wire. Maybe I just dislike state, but the pico (and several other MCU ecosystems these days) make it so easy to
The advantage is familiarity, I think.
Like: I suck at code. But I've known how to walk around in *nix systems and use things like bash to chain together commands like awk, grep, and sed for ~30 years. Maybe I'd even toss in some badly-cooked perl or python (or both!), when that seemed necessary.
For a very long time, I've been able to get some things done, but my skillset was focused on doing these things with real computers with live filesystems and real user interfaces, not MCUs.
So, some years ago: When I wanted to turn a window fan on and off based on some network-retrieved weather conditions, I didn't even consider an MCU. I didn't want to learn a new way of doing things; I just wanted a computer to get some data and decide whether to turn the fan on and off. And I wanted that done sooner instead of later.
I accomplished this with a Raspberry Pi Zero W -- with the whole OS. I didn't cross-compile anything. I didn't have to target some weird-looking external environment, or learn a new way of doing things.
Setting up the dev environment was very familiar: Dump a binary onto an SD card, boot it, get it onto the network, and use it.
I just SSH'd into that tiny little computer like I would any other Linux box and wrote my stupid little cobbled-up scripts right there, in-situ, on the final device that would be performing the work -- with a familiar interactive shell.
The end result worked very well. I'm not ashamed of any of this at all.
---
Later, I switched from networked weather reports to an RTL-SDR dongle and software decoding to listen for over-the-air broadcast reports from someone else's nearby APRS weather station, and used that as a source of weather data instead.
Can we even get that done in MCU land? (Should we even try to do so for just one window fan?)
In MCU land you can definitely listen to and decode OTA sensor data without using something as powerful as an RTL-SDR.
Consider common consumer wireless indoor/outdoor thermometers which have a temperature sensor you place outside and a display you place inside. Most of these use a much simpler radio protocol than WiFi or Bluetooth, and have nowhere near the compute power or memory resources to come anywhere near running Linux.
On the transmit side they typically have a fixed frequency oscillator (commonly near 433 MHz or a little over 900 MHz) connected to an antenna through a transistor. They send data by turning that transistor on and off. There are a variety of ways they might do this. Some might do it as pulses with different widths for 1 and 0. Some might do it by having have say 200 us on followed by 200 us off mean 1 and 200 us off followed by 200 us on mean 0. There are many more.
For home built stuff you can by cheap transmit modules to help with this, such as this one [1]. I'm linking to Sparkfun because they have good documentation, but you can find these all over the place.
On the receive side they use a simple receiver tuned to the same frequency (but with enough tolerance that it isn't a problem that both sides are probably using cheap oscillators that aren't very stable or accurate). Here a receiver module for home built stuff [2].
From what I've read the ways these work is that they automatically adjust the gain to have a constant high output level, but there is some lag in that. If there is nobody transmitting the output is just amplified background noise.
Then when someone starts transmitting the gain gets turned down so it is just enough for their signal to have max output. Let's say they are sending 1s as a pulse of 200 us on, 100 us off and 0s as 100 us on, 200 us off. With the gain set so the on level is at maximum output the off level will be quite a bit below that. As long as the gain adjustment is slow enough that it doesn't turn up the gain too much during that up to 200 us off, the next on will still be readily distinguished.
In that example the transmitter is sending 1 bit every 300 us. The firmware in the receiver can look for high/low and low/high transitions in the radio output, looking for the pattern of several consecutive 300 us intervals with 100 us on/200 us off or 200 us on/100 us off. Interpret that is a bit string, and make sure when you design your protocol your transmissions start with some kind of signature so you can tell you are actually listening to the right sender, and it should work. If you designed the radio protocol reasonably you should be able to do the recognition with some kind of efficient state machine.
[1] https://www.sparkfun.com/rf-link-transmitter-434mhz.html
[2] https://www.sparkfun.com/rf-link-receiver-4800bps-434mhz.htm...
Regarding the SDR, the Pico can act as a USB host (honestly a huge win as you can plug in a keyboard/mouse). But it’s not able to run at USB 2 speed. There’s no software for it and the CPU probably isn’t powerful enough. So in that case a Linux machine is completely justified. I tell people to reach for a Pi when they need both Linux and GPIO. But if you just need GPIO you should really save the money (and get major wins in simplicity) with the Pico.
I get the familiar angle of using a Pi Zero. But don’t be intimidated by the Pico. Especially these days with the help of an LLM, you’re not slowed down too much. The version of Python they run feels very familiar. The tooling is good. They’re awesome!
Oh, these days I still suck at code. And with the bot, I can hammer out a project for ESP32 or a Pi Pico in no time. (I didn't even put together the dev environment for that. I had the bot do it.)
And because I still suck at code: If I want to create something myself, then I still get to do that with a Linux box using unix methods.
That all said: I do enjoy working with RP2040 PIO assembler sometimes. The combination of its severe limitations and robustly resolute timing makes it both approachable, and fun. :)
Anyway, I think all methods are OK. There's no reason to judge them. (I think it's also OK to just use a computer to read Facebook, or as a porn machine, or to become an Amish leatherworker and leave all of this digital nonsense behind.)
I'm sure you're aware, but for the record the Pico has state. That's one of the best things about it. You have a very fully featured Python environment (or rust, or C) with a read/write filesystem. The WiFi SDK is also super useful. They can make HTTP requests (and HTTPS without full CA validation), host an HTTP server, even host an access point.
Languages:
75.4% Linker Script
18.2% Rust
6.4% Shell
About sums up embedded development in Rust.
Here are the line counts:
I guess "Alex" would be the linker scripts ending in .x?Well all of the linker script is just two standard memory map files, one for the 2040 and one for the 2350, so really it suggests that this needed very little code to make this work. The 6.4% shell represents a shebang line, two comments, and a single `set -e` call, after all.
Most of the code is already in libraries. rs-matter includes a lot of batteries, so for simple clusters you end up writing little code.
It looks like github is just buggy in this case.
There's nothing about embedded development in Rust that would make it more reliant on linker scripts than any other language. Github's count is misleading here.
Hi HN,
I’ve been experimenting with the new Raspberry Pi Pico 2 W (RP2350) and wanted to see how difficult it would be to build a fully compliant Matter smart device from scratch using Rust.
I put together a complete "Blinky" example using the rs-matter stack and the embassy async framework. It uses BLE for the initial commissioning phase and Wi-Fi for network connectivity. Once flashed, you can provision it directly into Apple Home, Google Home, or Home Assistant using your smartphone—no cloud accounts required. It exposes a standard Matter On/Off cluster that toggles a physical LED wired to the GPIO pins.
A few interesting technical notes from the build:
Bare Metal: It runs entirely no_std on bare metal using embassy-rp. Radio Coexistence: Getting the CYW43439 wireless chip to handle concurrent BLE (for commissioning) and Wi-Fi (for Matter IP traffic) on the RP2350 took some tweaking. We actually had to dial back the PIO SPI clock divider specifically because the RP2350's faster 150MHz core clock was causing bus corruption when the radio was saturated! Async Rust: The repo includes the full async CoEx (coexistence) runner setup to safely multiplex the radio between the Bluetooth and Wi-Fi stacks concurrently. If you’ve been wanting to build local-only smart home devices but felt intimidated by the massive official C++ Matter SDK, doing it in Rust is actually becoming incredibly approachable.
Would love to hear if anyone else is building custom smart home gear in Rust.
This looks very interesting. Thanks for sharing!
> bus corruption when the radio was saturated
How do you even diagnose this?
The initial approach was to run BLE and Wi-Fi simultaneously. Provisioning sometimes worked. It seems like there was some interference. Then switched to run BLE with Wi-FI off. When I got Wi-Fi credentials, switched BLE off, and turned Wi-Fi on. It still had some issues. Turned out when slowed down SPI bus, it started working. Only tested with Home Assistant and have to fork and patch rs-matter-embassy
re: wifi/ble together
That sounds like the crate didn't have coexistence enabled or the defaults were really odd - so much boring stuff to write about BLE/WiFi Coex, but the short is "the default settings" are pretty good for low bandwidth IoT devices.
I'll peek at the code out of interest :)
What OP says
> Turned out when slowed down SPI bus, it started working.
reeks of either RF interference issues or power rail issues. Power is not the strongest domain of anything RPi so that's where I'd look first.
Use a digital storage scope, many of them can directly decode protocols like SPI . Then a lot of trial and error to figure out when exactly the issue happens and what else is happening around that time.
Rust on embedded is becoming more approachable with Embassy and the Pico SDK. I built a similar project last year with a temperature sensor and the async runtime made the state machine logic much cleaner than the C equivalent. Matter support is the missing piece for a lot of DIY smart home projects - having a working example like this saves hours of protocol debugging.