@NeverDie said in Looks as though ESP-NOW is finally working...:
Anyhow, sleep current for ESP8266 and ESP32, the last time I checked anyway, was still kinda high, but I do wonder what the startup time would be if an ESP module were kept in a totally turned-off state until it was needed. Perhaps the higher transmit speed that is possible with a wifi PHY would allow high power to be used only briefly (~250ms in the example in the video), and so maybe total power consumed from the start of wake-up through the transmission may yet turn out to be a win?
Power consumption in deep sleep is really low if using a barebone ESP32-WROOM or WROVER. I did a project in 2020 before the lockdown using a custom ESP32-WROOM in a Soil Moisture capactive sensor and took some measurements to check the power consumptions in each state. The results were:
Power Consumption
With delay (idle): 39,29 mA in the 3V3 input from FTDI adapter.
In deep sleep: 5,4 uA in the 3V3 input from FTDI adapter.
While transmiting (ESP-NOW protocol) the power spike was huge, an average of 200mA, and I think the peak demand was even higher (400 mA?)
With 600mAh LiFePo4 Batteries, the expected duration is aprox. 5 months. No Regulator needed when using LiFePo4. If using regular LiPo or Li-Ion batteries, careful selection of the regulator is crucial because of the spike while transmiting if the regulator is not capable enough or close to the 3V3 pin of the module, a Brownout is quite probable.
This duration (5 months) is calculated assuming that the processor wakes every 15 min to take a sample of the soil for 2 seconds. If the difference between the measured content and last reported value is less than 5% (aprox. Error of the probe), the value is not sent to the controller (no wifi used). It is estimated that 4 measurements per day are sent. If there is no different in moisture content in a days cycle (every 96 wakeups) the sensor reports the measured value along with voltage. Voltage is sent in every moisture report. It is not considered important to send more frequent updates of voltages, LiFePo4 have a flat discharge curve.
The most impacting measure in extending the battery life in this design was the On-Time of the sensor necessary to stabilize the output (feeding the capacitive soil moisture sensor). It is observed that reducing the On-Time has an impact in the measured output. In the sensor, whenever I woke the sensor from deep-sleep I activate a mosfet to drive the feed to the capacitive soil moisture sensor and wait for 2,4 seconds.. that is the part of the cycle that is more critical to battery life.
The time to transmit the data was on average 80 miliseconds (from ESPNOW initialization to data sent). Here is a dump from the serial monitor to check this duration:
16:21:19.694 > rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
16:21:19.694 > configsip: 0, SPIWP:0xee
16:21:19.694 > clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
16:21:19.694 > mode:DIO, clock div:2
16:21:19.694 > load:0x3fff0018,len:4
16:21:19.694 > load:0x3fff001c,len:1044
16:21:19.694 > load:0x40078000,len:8896
16:21:19.694 > load:0x40080400,len:5828
16:21:19.694 > entry 0x400806ac
16:21:19.694 > Boot count: 8
16:21:19.982 > Moisture level (pre): 722.62
16:21:20.853 > Moisture level %: 0.00
16:21:20.853 > Voltage level: 2389.50
16:21:20.853 > Voltage Battery: 3.34
16:21:20.853 > Startig Wifi Now...
16:21:20.853 > Wifi Setup complete.
16:21:20.934 > Send success
There is a possibility to further reduce power consumption. Yo can manipulate pint status and read the ADC while maintaing the main cores in deep sleep by using the low power co-procesor. This coprocesor would check if the value has changed since the last transmission and wake the main processor if it is necessary.
And in relation to ESPNOW and MySensors, I used a TTGO-Lora board with ESP32 and LORA transceiver as the MySensors and ESPNOW gateway. The gateway processed the value from the sensors received by the ESP-NOW "custom" protocol to MySensors... the controller (Openhab) was only aware of sensors atached to the
ESP-NOW Sensor --> TTGO-Lora (Translates from ESP-NOW to MySensor Message) --> Openhab
I did also a proof of concept with a Repeter-translator from ESP-NOW to Mysensors:
ESP-NOW Sensor --> TTGO-Lora (Translates from ESP-NOW to MySensor Message) --> TTGO-Lora (receives MySensor Messages) --> Openhab
The ESP-Now MySensors gateway sketch was not very elegant but worked.
The next step would be using ESPNOW as a new MySensor Protocol... to do it myself I should spent quite some time learning how MySensor Code works.. I have tryed in the past but never have the change to work enough time to understand it fully.
If this transport is supported, I see quite an advante of ESP32 vs NRF5284, both would use the 2,4 GHz band, but ESP32 transmission power is +20dbm (vs +8 dbm for the NRF5284 if I am not mistaken), also, a barebone ESP32-WROOM price is 2 € and is not hard to hand-solder... to that you have to add the components to design a custom board but overall quite competitive.
Pre-production test:
[image: 1624899685783-20200501_114856-resized.jpg]
[image: 1624899705979-20200501_114912-resized.jpg]
Custom board (first try.. a cable to fix some design errors . :upside_down_face: )
[image: 1624899814991-20200613_102550-resized.jpg]
[image: 1624899848632-20200613_102608-resized.jpg]
