ESP-NOW and HaLow: good networking for IoT at last?
ESP-NOW and HaLow: good networking for IoT at last?
Some years ago, I invested the better part of a year in a project based on Zigbee. It did not become an actual startup, but could well have been. We ran into some problems with Zigbee chip and stack we had chosen. To move forward, we would have to bet in a new stack, but nobody wanted to pay (again) the hefty price of a new version of the IAR compiler. Replacing the chip was difficult since the available alternative was more expensive (we hinged on offering ultra-cheap hardware). The partner was already invested on the old chip that happened to work well for his needs. We didn't have the grit to pivot a different solution, since all of us had their day jobs to tend.
For me, Zigbee left an aftertaste of being much more complicated than it needed to be. It didn't deliver many promises, in particular the interoperability. Sometimes the paired networks simply stopped to work for no reason and all nodes had to be re-paired (certainly a problem of the Zigbee stack supplied by the chip manufacturer, but it was impossible to debug). In theory it is an open standard, but in practice the available stacks are proprietary and compiling it for some chips demand expensive tools — proprietary software using non-free toolchains, two very anachronic things. Zigbee lies on IEEE 802.15.4 link layer, which is an open standard, but good luck trying to find a chip+stack that gives you raw access to the link layer.
It is a pity, since Zigbee and/or 802.15.4 could dominate the IoT landscape. I happen to have a home alarm system with wireless battery-powered sensors based on 802.15.4 in the 900MHz band, and it works extremely well. It would be great to use the same tech in my IoT indie devices, but it is simply not available for amateurs.
Bluetooth has similar problems, even though the Low Energy version is a whole lot better. There is a Bluetooth Mesh standard for IoT; but where is the implementation to get our hands dirty with? Where are the cheap breakouts for Arduino so everybody can put that into good use?
This, and the ubiquity of WiFi, make WiFi the default choice for IoT. It is actually inadequate for IoT. But it works, people understand how it works, it is an open standard (except for the radio firmware, but nobody cares except RMS), and has few interoperability problems.
WiFi is not ideal for IoT for many reasons, among them:
When the cats are away, the mice will play.
I have just started to play with the Espressif's ESP-NOW protocol. This is not a mice, it is a "rat" in the pejorative sense of a term. Proprietary, simple to a fault, works only on Espressif chips, documentation is still not 100%, the crypto feels half-baked. But it has a decisive advantage: it is ready for use, on a hardware that every maker has a handful in their drawer.
The idea of ESP-NOW is to allow direct, peer-to-peer communication between nodes without the need of an access point. The advantages over WiFi are:
ESP-NOW can send packets up to 250 bytes. The address of each peer is the MAC address; there is no TCP/IP. It remembers the UDP protocol, but ESP-NOW does confirm packets, though the confirmatio window is just 25ms. If you want to retry for longer, you need to implement it yourself. Or adopt some existing protocol like MQTT-SN.
ESP-NOW and WiFi usage can coexist, which would be the case for e.g. a concentrator that intermediates communication between peripheral sensors and the cloud. You just need to be sure that both will use the same channel, since the radio hardware is just one. If the ESP-NOW and WiFi network use different channels, the thing will be flaky, sometimes it works, sometimes it doesn't and you will grow crazy.
In order to send a data packet, the target must be registered as a peer. There is a limit of 20 peers without crypto, or 7 to 17 with crypto (default limit is 7). This means that every device can only send data to so many others, at the same time. Peers can be replaced in the registry, so there is no limit if communication can be staggered.
In order to receive data packets, the sender does not need to be in the peer registry, as long as you don't enable crypto. In a straightforward system where peripheral devices just send data blindy, and the concentrator just receives data, any number of peripherals could be associated to a single concentrator.
If you need bidirectional communication, then unfortunately both sides must register each other as peers, at least during the communication session. If the communication is mostly unidirectional, and sporadicaly bidirectional, the concentrator could add the peripheral to the registry only during a certain time window.
There are broadcast packets, simply sending to ff:ff:ff:ff:ff:ff. They are received by all ESP-NOW devices listening to the same channel.
The crypto suppied by ESP-NOW feels funny. There is a general password (PMK) and another for each peer (LMK). The PMK is only used to encrypt the LMK (the PMK is not equivalent to the password of a WiFi network). It is possible to have encrypted and unencrypted sessions with different peers. The receiver of encrypted packets must add the sending peer to the registry (along with the LMK), even if the communication is strictly unidirectional.
The latter means that, if the system employs the ESP-NOW crypto, the concentrator can shepherd just a few peripherals (7 to 17, default is just 7). I believe that a real-world product would not use the ESP-NOW crypto at all, and implement its own (which would be necessary anyway to implement some sort of secure simple pairing).
All the practical knowledge I have collected can be found at this module that I am developing for a personal use case: an LP tank scale. Since the LP bottles are in a remote place without WiFi, the idea is to make the actual scale as a peripheral device that sends data via ESP-NOW once a day (which would allow for battery operation, or even solar, avoiding bringing electric energy into the LP room). The receiver/concentrator forwards the data to MQTT.
It is obviously a convoluted solution, it would be easier to simply send an RS-485 cable to the LP room, but there would be no fun factor in it. The idea is to get some seasoning in this use case to be able to use ESP-NOW in more elaborate scenarios, if necessary.
ESP-NOW has potential to replace Zigbee in some use cases. Not by itself, since it is a bit too simple; the application protocol must make up for the difference. But its simplicity leaves open many venues e.g. one could implement a mesh network based on ESP-NOW (actually there are already a couple projects on GitHub doing exactly that).
"HaLow" is a WiFi standard for the 900MHz band. Slower speed, much higher range, plus a couple features to save energy and support the assoociation of much more devices to a given access point.
One selling point of HaLow is to be efficient enough to be usable in coin-cell devices (seeing is believing). Besides the proven excellent penetration of 900MHz in enclosed spaces, it promises to have an incredible range (3km@1Mbps), enough to steal some use cases from LoRa.
The speed can be dialed from 78Mbps down to 150kbps — dividing the speed by 4 means a 6dB gain, which doubles the range in diameter. Different speeds can coexist in different sub-bands, so in theory HaLow can take care of almost every conceivable need of data communication.
I am a bit skeptic of tech that promises too much (does anyone remember of WiMax?) but it is tempting. The advantages of WiFi and Zigbee in a single package!
The standard exists since 2017, but I heard about it just 3 months ago. At last there are some HaLow products in the market! Most of them are long-range repeaters, whose biggest selling point is not needing a directional antenna. There are a couple access points and network cards too, but for now they are rare and expensive.
What else we need for HaLow to explode? Some ESP32 variant from Espressif with HaLow support, of course :)