Looks as though ESP-NOW is finally working...

[NeverDie]

ESP-NOW is a peer-to-peer protocol that doesn't go through a wi-fi router, so it doesn't encounter the usual multi-second delay it might if it were waking up and reconnectig with a wi-fi access point first.

This guy gives a nice overview:
https://www.youtube.com/watch?v=_cNAsTB5JpM

I would have preferred to see an implementation of wi-fi direct, which is similar in concept and which has had android support for about 10 years, but I'm not sure where to find modules that are easily wi-fi direct capable.

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?

[idanronen]

@NeverDie not sure what you mean by "finally working" as it has been working for a few years. Do you mean it's now supported by mysensors?

If you're following Andreas spiess on YouTube, he's been doing some comparisons recently with different esp32 boards and documenting their operating current, sleep current, chargers/regulators, and some other interesting information. Some relatively cheap Chinese boards show promise IMO with a few dozen uA in deep sleep.
Either way, like you said, you can power the entire circuit off with a mosfet or something and wake up from your sensor. I'd actually love to see a proper circuit like this, as I'm less savvy than most here with electrical engineering, and after seeing a few of those I have no idea which would be better.

[NeverDie]

@idanronen This: https://www.kevindarrah.com/wiki/index.php?title=TrigBoardV7
Not sure ifhe's using esp-now lately, but it would be an obvious match for his trig boards. Early on he was doing typical wi-fi connections through a router, which is obviously slow if having just awoken.

[idanronen]

@NeverDie I see. I know I'm a minority with this, but I really prefer to add an external circuit for waking up a generic mass produced board, rather than designing an entirely new board (as I'm not proficient with that).

[NeverDie]

I referenced Kevin's board merely as an example. I'm sure lots of alternatives exist if you were to go looking for them.

[CarloMagno]

@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:

Custom board (first try.. a cable to fix some design errors . )