WireGuard for the ESP32 | Hacker News Reader

WireGuard for the ESP32

github.com

401 pointsbishopsmother125 comments

It's interesting how the ESP32 has become the de facto IoT MCU used in almost all new IoT products.

Other companies like TI and STMicro had their own cheap WiFi/BLE MCUs but their devkits used to be too expensive for hobbyists and students. But the Chinese startup behind the ESPxx chips made sure that their devkits were cheap enough for hobbyists and students and through that influence they now also dominate the professional industry.

> they now also dominate the professional industry.

is that true? it wasn't a couple of years ago.

I only meant IoT devices. Most embedded systems that don't have WiFi/BLE requirements are probably using ARM32, MSP430 or AVR.

Mostly only IoT devices from Asia. There are a small handful of things coming out of the west on ESP32, but professional users still stay away as they don't have the kind of engineering connections into Wwstern industries that Nordic et al do. That includes sales reps, training, etc etc. The things that matter to large engineering firms aren't really present from Espressif (although I wish them well and the ESP32 is an awesome platform).

Yea, I would assume a large percentage of startups that use Wi-Fi adopt esp32 since it's much easier and cheaper to get up and running compared to the competition.

More established companies don't need to adopt it but I assume it will change as time goes on. Kind of like how Webview or React Native was scoffed at in the beginning but now it's pretty commonplace even at large companies. Or like when Twilio IPO'ed it started targeting larger firms by building out their sales department because at the time it was mainly a hobbyist platform.

Esp8266 doesn't have Flash Encryption, or Secure Boot, whereas Esp32 does and Espressifs SDK ESP-IDF is maturing. So it's definitely going that direction.

Nordic announced its Espressif Competitor but haven't released the cost yet. Espressif seems to be throwing things at the wall to see what sticks (S2, S3, C6, H2, etc). I think their IPO definitely helped them raise more cash to do more things.

They also had a virtual conference with a bunch of talks https://www.youtube.com/@EspressifSystems

Espressif seems to be pulling $180m per year [0], so I guess on the order of 100m devices. The likes of ST and NXP have 10-20x the revenue, but I would venture the majority of what they are selling isn't connected. Nordic revenue was $600m, most of it BLE likely. So I guess Espressif is somewhat significant but definitely not dominant.

[0] https://www.espressif.com/sites/default/files/financial/Espr...

Which is sad, considering how bad is ESP32 documentation compared to other microcontrollers.

What documentation? (RTOS source code doesn't count!)

Turns out good documentation doesn't help anyone if they can't buy the thing eh?

While I do agree with you, I haven't found the lack of depth in register-level documentation too limiting. On the other hand, I find esp-idf much easier to use than STM32 HAL library and a lot easier to integrate in projects (I do like cmake).

Definitely agree on the HAL. I didn't find the ESP32 docs too lacking though (for UART etc; for Wifi/BLE docs are non-existent of course).

With STM32 they often have 3+ different kinds of timers (advanced, basic, sometimes also low-power). Instead of having one chapter about all of them and saying this and that feature is only available in TIM1, they will copy&paste the 100+ pages chapter for every kind of timer... They must be auto-generating this stuff somehow.

edit: The NRF52 docs and architecture are much nicer than both (the registers seem to be designed by a programmer not a hardware person).

Gotta say, I just don't understand STM32's "HAL". ST's headers has proper macros (and structs IIRC), and it's so much more readable by just using those macros rather than the weird indirection library which is still a 1:1 match with hardware registers

HAL is designed to work with their code generator across product families. It suffers from design mistakes that can't be fixed. Their LL library provides a lower degree of abstraction while still affording ease of migration and is harder for them to screw up.

Everybody has their preference. But none of them are well documented. And all BSPs are buggy messes.

ESP32 is dominant for WiFi devices but I'd say Nordic nRF is dominant for Bluetooth and BLE. You see it a lot in IoT sensors (like Ruuvi tags) and things like BLE keyboards (at least the DIY mechanical ones, in the form of the nice!nano).

There's also the BangleJS2 smartwatch that runs on an nRF52840

https://www.espruino.com/Bangle.js2

> You see it a lot in IoT sensors (like Ruuvi tags)

Even Apple AirTags (nRF52832 to be precise).

https://www.ifixit.com/News/50145/airtag-teardown-part-one-y...

I think this may be because they're very good at consuming little power. That's not exactly the ESP's domain (though you can kind of make it work), with WiFi itself being more power-intensive.

Let's remember that when the ESP8266 came out, it was basically the only WiFi MCU you could just use. Maybe there were others, but they had no community, so Espressif won out for the makers. And the makers went on to ... make ... IoT devices.

It's wild how few have stepped up to making wifi, even now, while Espressif made it easy & cheap back in 2014. Nordic is just getting around to it, for example, with then nRF7002 chip announced this summer, but it's notably just a companion chip, has no microconyroller available for your application, & modules as compared to espessif are pretty pricey. It is at least wifi-6 ehich Espressif announced ~18 months ago but afaik still isnt sampling. There's a Realtek part but lacks the documentation/support to be hobbyist usablrle.

As for power consumption, yeah, Nordic is pretty good. I feel like Silicon Labs is often the primary pick for low power.

At a Nordic event this fall it was noted that the nrf54 line of MCUs is likely to be announced this year, as the nrf53 line will not be expanded on. Could be nice for power draw, new process node and everything

Will be exciting to see the new device. Probably 20s node. But why wouldn’t you expect the nRF53 to be expanded on?

The TI chips were like 16usd in volume it looked like a mess from the datasheet anyway

I feel like Nordic offerings are more attractive these days

could you post some hyper-links to said offerings?

https://www.nordicsemi.com/products

But impossible to get hands on supply, or am I missing something?

> de facto IoT MCU

Not at all, at least not professionally. Mostly mocked and avoided professionally. But prosumer and hobbyist, it’s probably the most popular. They are fun to prototype with and use around the house but I would never stake my business on them.

What are some reasons for that?

Perhaps they're mocked and avoided in your sphere but there's certainly plenty of consumer products using them. Both sonoff and Tuya produce enormous amounts of products with them.

What exactly is your problem with them? The chips are fairly capable and the newest ones have transitioned to RiscV in case you're unaware. Sure I wouldn't use them for anything serious realtime but that rarely requires wifi/ble anyway so not sure why you'd pick an ESP to begin with for that :)

Why not? Plenty of businesses like Sonoff do just that. In fact it's a selling point for a lot of them.

Absolutely.

I've bought several things specifically because they use esp32 and I can flash Tasmota or EspHome on them. In fact it's a far bigger factor than price.

I've never heard of them being mocked or avoided professionally. They're not usually the go-to or the most popular, but I've got no issue using them in a professional device.

RISC-V might change the game soon with chips such as the Boufallo Lab BL616/BL618 RISC-V MCU.

> Boufallo Lab BL616/BL618 is a 32-bit RISC-V wireless microcontroller with support for 2.4 GHz WiFi 6, Bluetooth 5.2 dual-mode, and an 802.15.4 radio for Zigbee, Thread, and Matter designed for IoT applications. [1]

Boufallo chips are becoming available on Pine64 products (Ox64, Star64, Pinecil) [2].

[1] https://www.cnx-software.com/2022/12/29/boufallo-lab-bl616-b... [2] https://www.pine64.org/2022/11/15/november-update-tuned-in/

Maybe, but Espressif already has their own RISC-V chip (ESP32-C), which is perfectly compatible with their development platform (IDF), with a Thread-compatible model (ESP32-H2) coming next year.

Both cheap and profiting from the big community.

I'll buy an Ox64 (the ability to run Linux interested me), but Espressif isn't giving up easily. A few years ago, when Espressif was in more of a niche, it would've been an advantage to not have to use their weird Xtensa instruction set. But nowadays most toolchains have apparently added support and it's not a big problem anymore.

It seems to be a direct competitor to the ESP32-C6 which also has WiFi 6, BLE and 802.15.4. It will only be supported in v5.1 of the IDF, so not quite there yet.

https://www.espressif.com/en/products/socs

The Linux support on the Ox64 is supposedly pretty poor so far.

It’s not the matter of CPU arch, raw performance or even power consumption.

“640KB of RAM” is all you ever need in a great range of use cases that isn't currently well explored, and ESP8266/ESP32 serves that market very well with Arduino IDE integration and affordable devkits.

e: added absolutely necessary positivity to languages, sorry!

If they hit the price that could be really interesting.

Direct links to Pine64 products ...

128Mb Ox64 SBC - $8 USD https://pine64.com/product/128mb-ox64-sbc-available-on-decem...

16Mb Ox64 SBC - $6 USD https://pine64.com/product/16mb-ox64-sbc-available-on-decemb...

Both currently out of stock, schedule restock in January 2023.

Yet again the most frictionless solution wins out. Who’d have thought? If only there were examples of this being the case…

Also easy support by Arduino probably helps a lot of people get going, a lot of MCUs can be hard to get started with for people new to embedded programming.

Price and availability had a lot to do with it.

When you’re trying to squeeze every dollar out of a BOM, the cheapest chip that gets the job done is going to win. The TI and STM parts were more expensive and less available, so they did not win.

The landscape is slowly evolving, though. Espressif is getting a reputation as the Raspberry Pi of IoT MCUs: Easy to get started and everyone knows about it, but too many people are trying to use it in places where it’s not really the right tool for the job.

A few years ago I’d hear “can’t you just use a Raspberry Pi…” from people who knew just enough to be dangerous. Now it’s “can’t you just use an ESP32…”

Well, since ESP32 is available as chip, you can design a product which is just as robust, safe, resistant to ambient temperature effects, manufacturable at scale as you could with any other TI/ST alternative. With Raspberry Pi, up until the introduction of compute module you would still have been limited to whatever board-level properties Raspberry Pi foundation decided to go (limited temperature range, flakey USB sockets that don't tolerate high vibration, requiring hand assembly, difficulties sourcing reliable SD cards, default OS settings wearing out the SD card, difficulties sourcing in large quantities etc)- in addition to the same judgement on the side of person implementing the design.

It's not just devkits being cheap (there have been plenty of knockoff cheap ST boards) its

* integrated WiFi/BT with no/near zero extra engineering needed

* generous amount of RAM/Flash so you can afford to be sloppy

* SDK making it fast to get to the "the wifi is working and I can get on with my development"

* momentum from ESP8266 that already (due to same "super cheap with wifi") had a chunk of market.

Even now in middle of chipaggedon you can get WIFI/BT breakout board for like $3-5. That's not "just" "cheap enough for hobbyist breadboard", that's cheap enough to get the whole product built around.

I think partly due to how cheap WiFi/BT has become the likes of Zigbee didn't got as popular as they probably should, between licensing costs it was just cheaper for IoT companies to not touch it, even if it would make more sense in places.

Also Arduino IDE programmable fairly early on. Before boards manager stuff iirc.

It went from hackaday being lol you can use this WiFi module like a MCU. To why would you ever do anything else?

in IoT wifi became commerically successful over zigbee for 2 reasons, the cost was not one of them IMO

1. Vendors want Cloud control over the product, they want it to phone home. Zigbee is built for Local Control

2. Consumers prefer "hub free" products that just "work", They are willing to give up privacy, security and possible performance issues for that convenience. They do not think or care about what will happen when their shitty comcast service breaks for the 100th time this year, or if the IoT vendor is hacked, they want to pull out of the box, and have an app connect it in 2 seconds via a QR Code so they can blink the light quickly and not have a fuss about with a hub.

WiFi is better than Zigbee at both of these things. Zigbee is beter for home automation where you want Local Control, and security. Local control and security has been losing that battle though the tide seems to be turning lately (I hope )

I don't see the advantage of Zigbee for local control. Implementing local control over wifi is just as easy and can even work without a hub. I'm designing a custom automation system for the ventilation in my house and I failed to discover any reason to use Zigbee.

I think their point was that WiFi devices can be made cloud-only (or de-facto so by limiting what can be done locally) but that is hard/impossible with ZigBee, so companies will tend to standardize on WiFi. This will mostly be cloud-based, but this will push non-cloud options that direction as well.

Yeah. I made the mistake of purchasing a “Wi-Fi controllable” mini split from Menards, not realizing there is no way to control it without internet access.

Why do you believe WiFi is easier for local control than Zigbee. WiFi is more complex to setup and consumes alot more power.

WiFi you have all kinds of underlying network issues to setup that do not happen or you do not have to account for like WiFi, things like IP Address, Routing, vLAN's, Firewalls, Ports, etc

None of that is a problem for Zigbee.

>>I'm designing a custom automation system for the ventilation in my house and I failed to discover any reason to use Zigbee

Then you are not looking very hard or do not value Dependability and security.

Matter will likely absorb both Zigbee and WiFi anyway as Google, Amazon, and Apple are all backing Matter

WiFi may be be complex and power hungry, and I’ve had the displeasure of trying to build low-power IoT devices with it, but you can easily put in the time and effort to build a rock-solid future-proofed IP network.

My home Zigbee and Z-Wave networks have never come as close in reliability or versatility as my home IP network. I can always put in money incrementally to increase bandwidth or lower latency because the commercial off-the-shelf world for IP is so big — I can do point-to-point microwave links or send my IP network over 120V. And I know for sure, IP networks will never ever be deprecated.

I have some stage lights (just for fun - home light shows) — they speak DMX and not IP, but I just encapsulate DMX over IP and bam, a data connection anywhere in the house without extra data lines. I can send video over IP or make up my own protocol and my IP network can handle it no problem (though maybe with some upgrades if I were to send a lot of video).

> Matter will likely absorb both Zigbee and WiFi anyway

Zigbee will probably be absorbed/obsolete on the long run, but Matter is an application layer that runs on both Wi-Fi and Thread.

Zigbee solutions seems to be ~10mA, while WiFi / ESP32 seems to be ~100mA.

The 10x difference in power can be papered away by running the radio 1/10th the frequency. Ex: instead of updating every minute (Zigbee), you can update every 10-minutes (WiFi).

--------

I think a lot of these WiFi internet-of-things are fine with the ~15 minute update routine to minimize the use of the (relatively power heavy) 100mA+ WiFi radio.

Zigbee is simpler, but not so simple that you can program it yourself. It is found in cheaper $5 microcontrollers with less oomph than the ESP32... and those microcontrollers also use less power since its just innately a slower protocol. Though... I guess ESP32 is also $5 so cost really isn't a factor anymore.

-------

The absolute limit of 10mA vs 100mA is also pretty interesting.

10mA is just barely what is reasonable to push out of a CR2032 coin cell battery. 40-ohms internal resistance at 3V, so 10mA is a .4V drop... which can be solved with enough capacitors to buffer up the current. A lot of these devices still work at 2.3V or so (-.3 volts from age, -.4 volts from internal resistance), so you have enough headroom for an IoT Zigbee radio with CR2032 coin cells.

You ain't getting 100mA out of a coin cell battery (lol 4V drop on a 3V cell), unless you're also adding a super-capacitor to the circuit or other rather significant forms of power-storage. Then again, 100mA is more than reasonable out of Li-ion / AA NiMH / etc. etc. So ESP32 is still a battery-operated device... just a larger one than any Zigbee solution.

Mind you, the CR2032 coin cell is designed to average ~0.4 mA or less. So you really need to keep the radio "sleeping" most of the time. 10mA is really close to the "temporary burst" limits of the cell, and you're already suffering from significant degradation of the cell's lifespan by running it at 10mA, even temporarily. But the fact that Zigbee "fits" inside of this means that you can design devices around CR2032 cells, rather than AA or Li-ion packs.

-------

EDIT: The setup/teardown speed of Zigbee is also much faster. IIRC, you can connect, send data, and disconnect in ~30 milliseconds on Zigbee. But it requires seconds on WiFi (find an Access Point. Call Access Point. Setup negotiations, etc. etc. 3-way TCP handshake: Syn, Syn-ack, Ack. And then HTTP finally begins...).

A 470uF capacitor can power 5mA across a .4V drop for 36 milliseconds. (I = C * dv/dt). Assuming half the power comes from CR2032 + the other half the power from the capacitor (that's not how electronics work but I'm doing quickie napkin math), that's 5mA from the CR2032 + 5mA from the capacitor. So the 470uF capacitor gives you the headroom to run other parts (sensors / uC, etc. etc.) within the 10mA limits of the CR2032 cell.

Good luck getting a capacitor to do that kind of work across the ~5 seconds needed to setup / teardown a WiFi connection.

Since "Energy" == "Power * Time", the 100x time to connect + 10x power leads to ~1000x energy usage in practice, for WiFi vs Zigbee.

I was recently playing with an ESP32-C3 and was astonished at how fast it could boot and make an http request. (Can’t remember if it was ssl or not). I was measuring just under 1 second. Still an eternity compared to Zigbee, but I was quite surprised. I expected it to be more like 5-10 seconds.

It makes me wonder why far more powerful devices (iPhone, MacBook) take so long to connect to or change WiFi networks.

Its probably just the nature of optimizing for your customer.

iPhones / MacBooks don't care about battery life, or connecting/disconnecting from WiFi all the time. Optimizing from 5s connection to 1s connection is completely irrelevant. Its not like people normally disconnect/reconnect to WiFi. The few times I do it (ie: walk into my house / WiFi is back in range), my phone reconnects long before I even take it out of my pocket. Once connected, it stays connected and active.

ESP32 however, is an IoT chip. Optimizing from 5s to 1s connection time is a reduction of 80% of your power usage in practice. Because almost every IoT device will immediately sleep after the WiFi message is sent.

That is impressive though. Good on them for making this process more efficient. It'd never beat a specially designed protocol like Zigbee (or any of the 802.15.4 stuff). But so many people use 802.11 / WiFi these days that these kinds of optimizations are hugely relevant.

As a consumer wanting local control ZigBee is an advantage for off the shelf products. Almost every off the shelf product that uses WiFi does not offer local control (and if it does then it often only offers that in conjunction with cloud control).

Wifi is a massive pain for everyone.

You don't feel it because you've spent the time to make it work. But the average person from the street's wifi sucks hard.

If you think the average person's wifi network is bad, just wait until they have to buy a second wireless network. As bad as wifi can be, you have to have it for a million other devices and use cases. If your wifi is bad for IOT, it'll be bad everywhere probably.

My wifi is great already, but I decided to try some of the Ring lighting products. They use Zigbee/Sidewalk which is supposed to be perfect for this kind of use case. Guess what? It isn't. Now I just have a second wireless network to troubleshoot.

At no point does having a second wireless network just for my IOT devices become less work than using the wifi I already have. And if I improve my wifi coverage for IOT, I improved it for everything else at my house too.

if your IoT shares the same WiFi network as your normal devices you have already failed at security. Home Automation, and IoT should be separated at the network level from everything else

>>Sidewalk

Is terrible.

>>Ring

Ring is probably the worst HA brand out there, sorry your experience with Zigbee was bad because you choose a poor implementation of it.

Hell I have zigbee devices I bought of Ebay from failed companies that work better than Ring products.

I think you (and perhaps the GP) might have it backward. It isn't that Zigbee is so much better for local control, it's that it's a lot more work to do cloud control with Zigbee, as you need a separate hub with... you guessed it, WiFi.

And customers want cloud control, it seems, and don't seem to care about the security and privacy issues around it. So why build two separate devices (the smart device + the hub) when you can just build a single device (the smart device) and put the WiFi directly in it? Sure, there might be a cost difference in the case where the customers might have many smart devices (many cheap Zigbee devices + one "expensive" hub vs. many "expensive" WiFi devices), but I'm not convinced the cost is all that different overall.

The main issue I do see is power consumption. It's much easier to make a battery-powered Zigbee (or Z-Wave) device where the customer won't have to change the batteries every few months. WiFi is a power hog compared to Zigbee/Z-Wave, even if you assume that the device (or at least its radio) will sleep a significant part of the time. But many of these smart devices end up being hard-wired, so often it isn't that big a deal. (To be fair, though, I have a WiFi battery-powered smart/keypad lock in a rental property, and its batteries last 9-12 months, so even the power consumption issue is often not much of an issue!)

Beyond that, if a company is going to put WiFi in their device, most of the more "mainstream" vendors are going to have it connect directly to their cloud service, and not bother with local control, except possibly as a fallback when internet access is down. That fallback is nice, when implemented, but for those of us who don't trust these vendors to secure their backends, the "cloud service by default" attitude is a liability. At least with Zigbee/Z-Wave, I know that it's local-only-by-default.

So to summarize: WiFi gives a better UX for customers, and is probably cheaper, too.

Personally I buy only Z-Wave kit for the smart devices in our primary home, connected to my custom-built hub, and don't allow a third-party to manage (and probably screw up) the cloud control bits. It's definitely more work to manage, and troubleshoot when there are issues. Certainly not suitable for your average homeowner.

Most WiFi IoT products I own have no form of local control, have to be flashed, intercepted or reverse engineered.

Zigbee which I'm a huge supporter of, offers this out the box and setting up is as easy as 10 seconds of pairing.

I don't want to spend more time than I need to automating my home or making it a full time job.

> Consumers prefer "hub free" products that just "work", They are willing to give up privacy, security and possible performance issues for that convenience.

This is tptally wrong - I need to control Ikea Lights, Xiaomi smart vacuum and use Aquara to control blinds and a third company for radiator valves - well guess what, you are going to need 4 separate hubs and the only way they can talk to each other is through the internet.

It doesn't matter how much money you spend, Iot shit is not inter-compatiable and no one company makes everything.

>This is tptally wrong

its not, Ikea Tradfri lights I believe are just Zigbee today which can connect to other hubs. Some Aquara products are also just zigbee, and will support matter so any Matter or Zigbee hub will work with them.

Not sure sure about the Xiaomi

Of course the vendors will try to sell you a hub, but you can connect just about any zigbee device to any zigbee hub

> * generous amount of RAM/Flash so you can afford to be sloppy

Actually, the major benefit is the ability to use higher level languages or interpreted languages such as python and js. It also allows for more complex network stacks and protocols.

I wonder why Hardware vendors like TI and STMicro did not learn the lesson from Software Vendors like Microsoft, Adobe, and to a lessor degree Google.

Who have long offered their software free or heavily discounted for students because then they would demand that software when they entered the workforce and businesses would pay out the nose for it.

TI was extremely generous with free IC samples when I was a student, so at least some of the company learned that lesson.

yeah its just that as a student or hobbyist, an IC without a board is of limited use

As a student, I certainly wouldn't buy into a WiFI SoC platform without reasonably-priced boards, good SDK, etc. But I did find free access to their bare ICs very useful at the time.

Not just price- Espressif has done a really good job making their SDK and hardware documentation available to overseas hobbyists. Even hiring an English speaking dev to work SDK features that people were asking for in English, and doing a good job communicating with/engaging with the community.

They're not great if you're coming from solely-software land, but their SDK and dev experience (you can just use the Arduino IDE for a gentler learning curve, step up to FreeRTOS, esp-idf, or go more bare-metal) is still leaps and bounds ahead of competitors, like the STM32CUBE cluster fuck...using their Hal was the only time in my life where deleting whitespace in C code could break a build. If the developer experience is awful, it doesn't matter that the STM32 chips perform better per second and per watt than an ESP32.

Or in my case - if you can not buy the STM32 at all, while ESP32 is in stock just fine.

> But the Chinese startup behind the ESPxx chips made sure that their devkits were cheap enough for hobbyists and students and through that influence they now also dominate the professional industry.

The rest of the industry failing to learn from how Microsoft came to dominance by basically ignoring piracy among students and private individuals.

It's not completely related but I've been thinking that having a router connected via wireguard might be a good way to do IoT deployments.

Generally IoT devices make an outbound connection to a server and use MQTTS for bi-directional data flow, because of the difficulty of inbound connections due to firewalls, NAT etc. But this has some downsides in that you have to run an MQTT server, each device is doing it's own TLS (which uses a lot of ram and increases firmware size on an ESP32), and MQTT doesn't really have end-to-end message confirmation.

It seems like a better way would be for each esp32 device to be in a wireshark network and to be running it's own HTTP webserver (which is easy to do with the SDK). Therefore any device can be sent a message from the server using a simple POST request to its ip address, and can send messages to the server using the servers HTTP api. It's much easier to test HTTP api's than mess about with MQTT, and individual devices don't need to do SSL because all data between the devices and server is encrypted by wireguard.

I suspect there's something I've overlooked, I think addressing individual devices could be difficult if you only know their IP addresses.

If your network setup (be it wireguard or whatever) is such that you're okay with plain HTTP vs HTTPS, you should also be fine to use plain MQTT vs MQTTS, right?

I agree that it's easier to test HTTP but lots of IoT stuff plays nicely with mqtt.

That's an interesting idea, you'd probably be able to know ip addresses via wireguard. Protocols like CoAP or SenML can be used to keep payloads small.

MQTT, aside from being pubsub, has more functionality that is especially useful in IoT though: robust sessions with LW&T to monitor onlineness, and retained topics to deliver messages as devices come online again

HTTP, well, at least an implementation that allows for easy testing/human readable messages isn't particularly lightweight. I know for ESPHome, they chose to use a socket-based protobuf-esque protocol to communicate with Home Assistant. They claim it's even more lightweight and reliable than MQTT, which certainly seems reasonable given MQTT (as light as it is) has tons of functionality that isn't needed.

There seems to be people in these comments that know, so: is there something similar to the ESP32 but for cellular networks? A small, cheap microcontroller that I can add a SIM to and get connectivity?

The only ones I've messed with before were from Adafruit, but they are all 3g which is, afaik, completely decom'd now.

Haven't used it, but I've heard good things about Nordic's nRF9160 platform.

e.g.: https://www.adafruit.com/product/4753

There's lots of cellular modems that only requires a serial port / uart connection. I think espressif sdk supports "AT" commands for them.

Toit (platform for the ESP32) has some cellular drivers that all use a serial/UART connection. https://pkg.toit.io/search?query=cellular. (Disclaimer: I work for Toitware.)

What about https://randomnerdtutorials.com/lilygo-t-sim7000g-esp32-lte-...?

Blues Wireless has included data and a robust seeming SDK.

I've been buying cheap combo 4G/wifi routers that contain Sim card slots, setting the router up as usual, and then connecting the esp32 to the router's wifi network. So far it's been a more stable solution than any standalone microcontroller / module I've used, and easier to replace with local parts if anything happens.

That's clever. Have you had good luck with a particular model?

haven't had any major issues post-deployment with any of the random amzn/aliexpress ones I've used so far, fingers crossed

i've noticed that if your phone doesnt get full signal in the spot you want to place the router at all times of the day, a cheaper router usually doesnt stand a chance of getting a good signal without an external antenna

the ones where you can attach an external antenna with a wire lead are usually easier to position in just the right spot for full bars, and they just seem 'hardier' of the bunch, but you need the antenna, tradeoffs

on a similar note, what are people using for 4G/LTE IoT providers? I've used freedompop and hologram.io before, but not sure what is best for low volume data traffic?

As you noted, in the US, 3G and older cellular modems aren't usable.

For current cellular technology, the keywords to look for are LTE-M [0] and NB-IoT [1]. Most of these types of dev boards aren't cheap. Particle makes a 65 USD board [2] and they seem to have a free tier for cellular data access.

[0] https://en.wikipedia.org/wiki/LTE-M

[1] https://en.wikipedia.org/wiki/Narrowband_IoT

[2] https://store.particle.io/collections/ethersim/products/boro...

Did anyone test it on the ESP32-CAM? A quick search didn't produce much, although I believe that small module could benefit a lot from the added layer of security, assuming the hardware could withstand the added overhead on streamed video.

https://docs.ai-thinker.com/en/esp32-cam

https://www.youtube.com/watch?v=visj0KE5VtY

It's decent, the newest version is esp s3 eye. Looks like the main issue is the psram is fixed to ~8mb? So it has been struggling with processing higher res images? Also it lacks dcmi so you can't get images from high mp cameras (vs something like rasp pi)

A Tailscale IoT mesh would be killer.

What about the power consumption? ESP32 is not the best in term of energy efficiency, I guess that a series of crypto operations like the ones requested by a WG tunnel would have an impact on power and this can be a problem for a battery-powered ESP32.

WiFi is just not really well suited for battery use. They're really power hungry.

It's usually nRF52 series in use there. Maybe the ESP32s with Thread or Bluetooth LE, although I'm not familiar with that.

Depends on your use case/application - for sensors, most people use deep sleep, so the module wakes up after some interval, takes a reading and then either does a http post to a service or sends off MQTT message and then goes back into sleep mode.

Well there's another project I can cross off my to-do list.

This is awesome, any benchmarks on bandwidth so far?

Are there memory safe language options for programming security critical internet facing interfaces like this on ESP32?

Rust is getting there, but I don't think it's production ready yet: https://github.com/esp-rs

I'm glad you asked: Here's one: https://toitlang.org/

Is there a significant difference between doing HTTP over TLS vs HTTP over WireGuard?

I enjoy WireGuard and it's tooling but in this case TLS seems like the better, battle tested option without any significant downsides if all you are doing is HTTP anyways...

I see this as a handy option for 2 way comms. How much power it would use is a different question.

The point of WireGuard is to set up a VPN across the services you need. You could use it for point-to-point connections but it does much more than that.

One use case is probably as gateway, I could put IRC on it and wireguard and have an emergency entry into a network.

How is IRC a gateway?

use IRC to give it commands and see logs so vpn is not always on (i.e: when you want vpn, you tell it to connect to an external IP, perhaps spin up a vm for that). Don't expose it directly as it would be easy to flood it into submission in addition to it being insecure.

Once connected - use it to tunnel traffic back to network.

Anything else would work though (telegram/cloudflare tunnels/...), It's just what I would use.

WireGuard supports TCP and UDP directly, which allows securing MQTT or AMQP directly without adding an extra layer of HTTP/QUIC.

Certification also works differently: TLS (and OpenVPN) rely on Certificate Authorities while WireGuard relies directly on the public key of hosts. This has implications in how trust is managed in the network.

> WireGuard supports TCP and UDP directly, which allows securing MQTT or AMQP directly without adding an extra layer of HTTP/QUIC.

MQTT over TLS is pretty standard, and supported out of the box by virtually all clients/brokers. I suspect the same is true for AMQP.

Some time ago I did a set of benchmarks of MQTT+TLS vs MQTT+WireGuard. Although I was rooting for WireGuard to blow TLS out of the water, the overall bandwidth requirements are quite similar. Under normal conditions WireGuard overhead is a bit higher than TLS, though various network pathologies can swing things the other way. The main one being roaming: if the client frequently switches networks, WG tends to handle this far more gracefully than TLS (not surprising given the underlying design and protocols).

In short, TLS can actually be made to work really well in a context like this - I jotted some notes on an optimal setup here: https://medium.com/p/b880285da526

Beyond this, there are some really interesting efforts to unify MQTT and QUIC - from an architectural perspective I feel like that’s the future for IoT comms. (https://www.emqx.com/en/blog/getting-started-with-mqtt-over-...)

What are some of the things you can do when you have wireguard in your embedded device?

The use case that comes to mind for me is transparently and securely tunneling back to a central control server/common network with other devices it needs to talk to independent of the local network. So I could make a sensor for my parents and have it automatically tunnel its MQTT traffic back to my home network to monitor without them having to host an MQTT server locally. There are of course other ways to achieve this, but Wireguard is pretty elegant and straightforward to keep secure.

Another thing that comes to mind is if you're building a device that jumps wifi networks a lot. WG makes roaming networks pretty seamless, though I'm kinda struggling to think what an actual use for this might be.

Edit: Thinking about it more, you could use it as the backbone of some kind of cross-network mesh system. A bunch of distributed devices connected to their respective local wifi network but then form a common network over WG and are able to route packets. Maybe you could bridge the endpoints to Bluetooth or some other RF protocol as a mesh with the Internet as the backhaul but not having to think about the local network. This sounds pretty wild but would be fun to play with.

One thing I've wanted to do is put a battery charge monitor on the escooter I leave at work. I'd like it to report the charge back to a computer I have at my house. Running WireGuard on an ESP would let me send battery telemetry back to machine I control, even if the scooter was on public wifi, and without having expose any of my ports to the wider internet (except 51820).

> except 51820

Even then, it's technically open but it's using UDP so it's not like it'll show up in port scans or anything.

UDP port scans are a thing:

https://nmap.org/book/scan-methods-udp-scan.html

Wireguard protocol is specifically designed not to show up on port scans. See section 5.1 of the white paper: https://www.wireguard.com/papers/wireguard.pdf

Very cool - I didn't know that!

But, speaking generally, it's still good to know that UDP port scans are very much possible.

You can have devices in different locations linked together (by opening ports on the WG interface) without opening holes in your network

I've wanted something like this as a hardware level firewall to ensure that all traffic over an outbound interface is transiting over a wireguard server.

Seems like you could do that with any router hardware that supports OpenWRT? An ESP32, although capable of running the algorithms, is going to have rather poor performance.

Yeah, definitely true. I like the simplicity factor though.

Is there a performant hardware platform which is openwrt compatible and has a single pair of input/output ethernet ports? I seem to remember an Intel device that worked for this, let me see if I can dig up the link

EDIT: I think I was remembering the Intel Compute Stick, which was discontinued in 2020: https://en.wikipedia.org/wiki/Intel_Compute_Stick

Just get a router with a WAN port and N lan ports. Internally, they're all a switch and a CPU with two independent ports. Sometimes the WAN port goes straight into the CPU, but quite often all the external and internal ports are switched and the WAN port is just VLAN isolated to one of the CPU's internal ports.

I've accumulated half a dozen WRT1200AC and WRT1900AC devices from eBay for about $30 each. They have dual core 1.2Ghz ARM CPUs and something like 256MB of RAM. I use one with wifi disabled as my router (and run wireguard on it for my phone), two for APs in the main house, and another as a wireless WPS bridge to the garage. I can pump 400-500Mbps of TCP traffic over the wireless bridge. The router hardly even registers the wireguard traffic from my phone, but then my ISP link is only 46Mbps.

I just ordered Netgear r8000p router on eBay for $40 to play with, at the recommendation of another HN commenter. It has 6 antennas for beam forming, a dual core 1.8Ghz ARM CPU, and 512MB of RAM.

It basically boils down to - you can reach it behind a NAT.

I’m currently planning on installing a second small home-server at my parents place as a backup target. I thought about an easy, energy efficient way to turn it on and off. My current plan was using a raspberry pi but it would have been a bit overkill. So this is perfect. I already have a wireguard setup between my home server, laptop, smartphone and a cheap rented VM that acts a a router. I can just add the ESP to it know and use either the serial Interface of just a digital out connected to the power pin.

Wow, congratulations. There's something lovely about seeing systems being configured in C source code. While I wasn't around at the time I imagine this is the way many of machines of the 1970s were configured as well (unless you had some kind of fancy Unix machine that could host its own compiler.)

> I imagine this is the way many of machines of the 1970s were configured as well

Which machines are you referring to?

I don't get that remark either. First, it's snarky, and second, the C handbook is from 1978. Only a small number of Unix(TM) systems had C compilers at that point. And third: what does configured even mean in this context?

No snark at all. I'm sorry you read my comment that way. What I got from this release announcement was a feeling of coming full circle, back to an older time when configuring a system meant compiling with different compile-time options (possibly with compilation happening on another system) as opposed to using something more complex like compiling once and reading config options from an rc file. (I was reminded if this also by dwm, which too is configured at compile rather than runtime.)

I use an ESP32 for motor control, and being able to push an rc file to the sd card is far better than static C configuration- compare GRBL-ESP32 to FluidNC.

Check out the qmk keyboard firmware configuration if that's your thing :)

nice.

Reply on news.ycombinator.com