IOT with the ESP – Here comes the killer app.
The little ESP8266 and its relatives have already found it’s way into the developments of commercial devices as well as hobbyists. It is cheap, with tons of features and works super well when connected to an on-line power source. But it’s relatively large hunger for power – because it is WiFi based – was a big disadvantage whenever it came to battery powered devices – that is – until now.
I am developing technology for the cloud-less “Lumosur” IoT environment. We already have sensors, wall switches, plugs, color lights – you name it. They all are connected to a power supply and work reliable and really nice. But certain sensors or switches (think “door bell” button) require a “battery power” approach. While that is possible, the “old” approach took some time (around 10 to 15 seconds) to deliver a payload once the button was pushed.
Because the chip – in a battery powered environment and when there’s noting to do – is either in a deep-sleep mode or even powered down. All those power saving mechanisms require a boot once there is some action going on. So – boot, read data from EEPROM, scan for the required WiFi network, get a DHCP address and finally connect to the host and deliver the payload. Though one can shave away a second or two with a fixed IP-address, 8 to 10 seconds is still not acceptable for a switch. You want something to happen – fast.
This is were the new ESP-NOW protocol comes in. You may have heard about it, it skips the WiFi Access Point and contacts another ESP chip directly. By the time I wrote this blog entry, ESP-NOW was not yet supported within the standard ESP/Arduino environment – but it can easily be used by including
extern “C” {
#include <espnow.h>
#include “user_interface.h”
}
We did some serious R&D around this functionality and found it very promising. However – the documentation is lacking and not transparent, we also found a serious security flaw within the security environment of ESP-NOW – so we finally decided to just use the basics (receiving and sending data from and two ESP chips) and adding an AES encrypted protocol ourselves.
The “receiver” chip is connected to the Lumosur server and forwards valid events to it. The battery powered devices communicates (encyrpted) with the receiver and are powered down when not active.
In other words – as long as nobody “presses” the button, there’s no power drain to the battery – so – in theory it should last a long, long time. But so would the “old” version of our switch – that communicates with the Lumosur server via WiFi.
How does it compare to the “new” ESP-Now version? The “old” version took around 12-15 seconds.
Let’s see (click to play GIF):
The whole process is done in less than 2 seconds. Booting – Flash Access – wireless messaging, crypto and all. Wow. No only is that blazing fast, it also reduces the drain on the battery (for wireless operations) around factor 5. This is super cool.
Here’s a look inside the (development) switch: Nothing but a cheapo ESP01, a RGB LED, a battery container and a push button. No need for Bluetooth, Zigbee, ZWave and all those “other” protocols. No need for expensive chips or complicated setups,
Just fire up the old Arduino IDE (or use alternative methods) and hack your heart away.
Alright – what’s next for ESP-NOW? We just experimented with a simple star configuration in which every “switch” node (called a “controller” in ESP lingo) communicates with the same central server (called a “slave”). So they have to be in a somewhat limited (around 50ft in our office) distance to be able to talk to each other. But there are “Mesh” modes in development in which in-between “controllers” pass along messages if the originating “controller” can’t talk to the “slave” directly.
For now however – we are super excited about ESP-NOW and developed a “Gateway” plug-in for Lumosur that allows to attach a variety of “slave” nodes into our environment. That – of course – makes it easy to configure and control everything via Lumoscript.
The example above was “Lumo-” scripted like this:
To wrap it up: The ESP-NOW environment makes it possible and feasible to create battery powered devices that delivers the payload fast and with only a second or so in battery draining action mode. All that is required is an ESP-01 (less than $4), a battery and a switch to hack an ultrafast remote switch (just make sure you unsolder the LEDs from the board).
Just remember: At the time of this writing, there’s a somewhat serious security flaw in the crypto of the current ESP-NOW environment. It allows a “controller” to send messages without crypto even if crypto is activated on the “slave”. As the whole cryptographic interface is very in-transparent, we opted to create our own crypto on top of the basic ESP-NOW functionality. But YMMV.
This will get you started: https://github.com/leonyuhanov/ESP-NOW-TX-RX
About the author:
Michaela Merz is an entrepreneur and first generation hacker. Her career started even before the Internet was available. She invented and developed a number of technologies now considered to be standard in modern web-environments. Among other things, she developed, founded, managed and sold Germany’s third largest Internet Online Service “germany.net” . She is very much active in the Internet business and enjoys “hacking” modern technologies like block chain, IoT and mobile-, voice- and web-based services.
Hi Michaela,
Awesome work really like this project. I have been developing a similar control system and am at the same point in your blog in that encryption within ESP is not viable at this moment. I have playing around with lots of encryption examples but can’t find the ideal solution that gives me exactly a payload output of 250 bytes for an input of 250 bytes. What I would ideally like to do is encrypt my structure, then transmit and reverse this back on the other end decrypt back to payload structure. I would be ever so grateful if you would share your AES approach. Regards Dans
There will never be an exact one-to-one ration in encryption, unless you always us the same (shared) initialization vector (which is of course unsafe). All encryption mechanisms require additional data to be able to decrypt. I suppose you could do a simple x-or, but again – not recommended. I am using AESlib to encode the payload. The way our crypto works is that the ESP generates a master-key in combination with other elements (e.g. the MAC address) to connect for the first time. After the first successful connect, it receives a new key to use for the subsequent request. When this request is made, it again gets a new key. A foe needs to get the first exchange (and has to know the master key algorithm) and has to record each and every communication afterwards to be able to record (or replay) and to decode the data transmissions.
Hope I could help.
Michaela