Hacker News Reader

Comment by sandos | Hacker News Reader

Wooha, thats kind of awesome. Does this mean you could make your own zigbee sensors or whatever?

Zigbee?

My man, ESP32 boards get you 802.11 WiFi for like $5 these days.

Zigbee is the kind of protocol designed for even simpler, more power efficient microcontrollers. Think closer to a $1 microcontroller instead.

There is a reason we have lol WiFi light bulbs. The uC that powers the smarts are really cheap these days.

AFAICT your home-grade wireless router / AP will start having trouble when you have dozens of Wi-Fi devices actively working in your home. ZigBee is somehow more resilient. It's also much lower energy, more comparable to Bluetooth, but much longer range: the sweet spot for smaller battery-powered devices.

OTOH I remember that ZigBee is somehow more buttoned-up than BT and even wi-fi, so it's not commonly seen on likes of ESP32 and other small MCUs.

I think zigbee is more "resilient" because it piggybacks off all the other zigbee devices via mesh instead of each device talking to the central router.

Zigbee is also far lower data rate than even first-gen WiFi, which makes it more resilient. Radio protocols are usually a compromise between 1) range 2) power efficiency 3) throughput 4) robustness. Zigbee prioritizes 2, achieves 1 through meshing, 4 through error correction and other stuff, and mostly writes off 3. Point being it's not just meshing doing the work here, it is overall designed differently from Wifi and tuned for the purpose in multiple ways.

Note that 802.11 (original) is specified with 50% error correction at MCS 1 aka 1 Mbit/second rate. That is, for 1000 bits transmitted, 500 were data, and 500 were error correction. (Plus all the error detection codes like CRC32 on top of that).

This is a good example of tradeoffs: slower and less throughput, but way more robustness.

Higher MCS levels of 802.11 cut down on error correction to 25% or 10%, achieving more throughput but less robustness.

I dunno how Zigbee does it, but I assume it has more error correction at slower (ie: more reliable) speeds than even WiFi MCS 1.

You don't need to connect dozens of devices. Esp32 can communicate as a server or a client so you can directly connect them without getting the router involved.

Say, your house has 15 light switches on esp32 running Tasmota.

Do they all talk to each other in a mesh network, or do they all connect to your router in WIFI infrastructure mode?

There's a protocol called ESP MESH, with which multiple ESP32 (and ESP8266) can talk to each other.

> ESP-WIFI-MESH is a wireless communication network with nodes organized in a mesh topology using the simultaneous AP-STA feature on Espressif SoCs. It provides a self-forming and self-healing network, with ease of deployment. The network topology of ESP-WIFI-MESH can scale up to 1000 nodes in large areas.

https://www.espressif.com/en/products/sdks/esp-wifi-mesh/ove...

https://randomnerdtutorials.com/esp-mesh-esp32-esp8266-painl...

---

I didn't know that home WiFi routers have difficulty with more than a dozen connections, but I imagine ESP MESH could be a way around it, where a few devices connect to your router and act as access points for the rest of them.

In addition to ESP-Mesh protocol as mentioned in the sibling's comment, alternatively ESP-Now protocol also enabled lightweight support for direct networking without AP:

https://www.espressif.com/en/products/software/esp-now/overv...

https://github.com/espressif/esp-now

There are some mesh protocols (ESP-Link i believe) but tasmota doesnt support them. It doesn't even support SoftAP for anything but initial configuration. However there are some wifi repeater projects for the ESP series that might be of use.

I have a few ESP boards. I still try to go for everything-Zigbee in my smart home setup. It's much less chatty, uses much less power and works with a standard protocol (no need for flashing TasmOTA etc). So much easier to integrate than anything WiFi.

I think his point was something to sense zigbee? Would be nice to set it in your house and bridge your power meter, water meter, whatever, onto your wifi. Could have it incorporated into your budget app live. "huh, no dinner out this week, better turn down the heat!".

And if anyone figures outbhow to use that NPU you could even do some inference to get some trends or something. Or even a classifier that could detect a short or water leak perhaps.

Hmm.

I dunno radios (skipped that class way back in college). I'm guessing that although 802.11 and Zigbee use 2.4 Ghz, you might need 2x radios physically tuned for the correct frequencies, and listening at the same time.

Looks like channel 1 802.11 is different than channel 15 Zigbee for instance, so bridging the two might need two different radios.

So you'd need a 802.11 radio + Zigbee Radio working as a team (even if ESP32 has enough CPU power to handle both, there are likely physical limitations to radio designs).

And I'm pretty sure that the radios use more power than the microcontroller in any case.

------

In any case, there seem to be many 802.11 to Zigbee bridges already available. So you should only attempt the project as a learning experience.

You can already do that with all kinds of boards. You don’t necessarily need it to run Linux.

I would think that Zephyr would be better suited for this. Linux is great for many things, but it can also be overkill.

The ultimate "wireless sensor" experience would probably be something like an ESP32 size, power, and price that provides a nice Node-RED interface on the sensor.

Generally I would agree with that sentiment, but when we have Linux running on cheap low power MCU grade hardware, why not use it?

I have a pie zero w doing things with its GPIO. It’s super nice to ssh right to the board to update src code without having to go through the flash dance. I know Linux is not “hard real-time” but it’s close enough. All the real-time reqs I have get offloaded to a dedicated pwm breakout and communicated with over i2c anyway.

Reply on news.ycombinator.com