Sleeptime

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Sleeptime

#1 Post by M*I*B » 07 Jul 2019, 17:36

Hello there again...

... meanwhile I have ready my prototype for testing. It's simple a ESP-07 with a BME280 and BH1750 to catch temperature, humidity, pressure and light. For testing I have glow the BME on the BH and wireed it free. I also have fire it all by two AAA and use the Sleepmode- function. The ESP send it via MQTT to FHEM...

Here I have set the wakeup-time to 15sec and the sleeptime to 285 to get 300sec = 5min in result... But that does'n work well...

After 8:4 sec the ESP have send it to FHEM, but they goes to sleep much to late after 24:5sec and not after 15sec I have set...

Why ?

Two other things...

1. Will it be possible to fire up the BME and BM via a GPIO-pin? At the moment both are under fire the whole time... Not a good idea for battery use. Will the GPIO can handle enough power (nominal arround 8µA with some jumps up to 1,3mA)? If yes (I believe) what I have to do to switch the used GPIO to HIGH after power up resp. if awake and shut it down to LOW before the ESP takes a nap?

2. Two AAA with nominal 3,1V works at the moment but I think not a long time. Better I use 3 AAA with nominal ~4,5V... But that's too much for that... A normal regulator (i.e. 7833) takes too much power for battery use... Have anybody an idea to solve that?
Attachments
proto 1, test 1.jpg
proto 1, test 1.jpg (147.67 KiB) Viewed 7389 times
DLzG
Micha

User avatar
grovkillen
Core team member
Posts: 3324
Joined: 19 Jan 2017, 12:56
Location: Hudiksvall, Sweden
Contact:

Re: Sleeptime

#2 Post by grovkillen » 07 Jul 2019, 17:56

Quick answer, use 18650 batteries, same as in Powerbanks.
ESP Easy Flasher [flash tool and wifi setup at flash time]
ESP Easy Webdumper [easy screendumping of your units]
ESP Easy Netscan [find units]
Official shop: https://firstbyte.shop/
Sponsor ESP Easy, we need you :idea: :idea: :idea:

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#3 Post by M*I*B » 07 Jul 2019, 18:01

... quick reply: Not a good idea :D
Why? If you use rechargeable you will often need new ones if you don't take attention about deep discharge ...
DLzG
Micha

User avatar
grovkillen
Core team member
Posts: 3324
Joined: 19 Jan 2017, 12:56
Location: Hudiksvall, Sweden
Contact:

Re: Sleeptime

#4 Post by grovkillen » 07 Jul 2019, 18:07

You would of course monitor them?
ESP Easy Flasher [flash tool and wifi setup at flash time]
ESP Easy Webdumper [easy screendumping of your units]
ESP Easy Netscan [find units]
Official shop: https://firstbyte.shop/
Sponsor ESP Easy, we need you :idea: :idea: :idea:

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#5 Post by M*I*B » 07 Jul 2019, 18:29

Does the ESP resp. ESPeasy a function to monitor the operating voltage and send to FHEM? I did not find anything like that ....

QUARK :roll: I have forget the ADC... works well (100k/20k). Next I will try 1M/200k... :lol:
DLzG
Micha

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#6 Post by M*I*B » 08 Jul 2019, 11:07

Ok, meanwhile I have follow your idea with the LiION; I have many of them for my E-Shisha...

I set the ESP to sleep 295 seconds and stay awaked for 5 seconds. I Also have figure out how to swith on a port while booting and switch it of before it goes back to sleep. For that it seems to be important that you buffer the port with an small condenser to let the switched sensors working stable. I use a 4µ7 and it works well now.
Last night at ~23:00 I have install it in a small transparent box (from screws) under my roof outside to test WLAN- communication and test how long the battery will work.

One thing I have find this morning in the logfile inside FHEM. Many of the Data are more then twice, sometimes only one value, ... It's every 5 minutes different... I.e. here a received block to show what I mean:

Code: Select all

2019-07-08_00:20:15 ESPEasy_ESP_test presence: present
2019-07-08_00:20:15 ESPEasy_ESP_test B: 0.23 H: 64.52 P: 1012.55 T: 13.40 V: 4.44
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.52 P: 1012.55 T: 13.40 V: 4.44
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.52 P: 1012.55 T: 13.40 V: 4.44
2019-07-08_00:20:39 ESPEasy_ESP_test V: 4.45
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.52 P: 1012.55 T: 13.40 V: 4.45
2019-07-08_00:20:39 ESPEasy_ESP_test T: 13.27
2019-07-08_00:20:39 ESPEasy_ESP_test P: 1012.57
2019-07-08_00:20:39 ESPEasy_ESP_test H: 64.79
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.79 P: 1012.57 T: 13.27 V: 4.45
2019-07-08_00:20:40 ESPEasy_ESP_test B: 0.23
2019-07-08_00:20:40 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.45
2019-07-08_00:20:40 ESPEasy_ESP_test V: 4.44
2019-07-08_00:20:40 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.44
2019-07-08_00:20:43 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.44
2019-07-08_00:20:44 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.44
B = Brightness in LUX
H = Humidity in %
P = Pressure in mBar
T= Temperature in °C
V = Cell- Voltage in V

What I realy need is the line offered in the "state" like "B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.44". But if I set a filter for "state" in FHEM for the logfile I get nothing.

Question is why are there so much data sending in that singe block every time the ESP wake up?
DLzG
Micha

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#7 Post by M*I*B » 09 Jul 2019, 12:46

BTW:

There is an BUG in the "Generic Dummy Device". It is not possible to choose anything other than "single" or "quad" here. Any other selection is ignored and replaced by "single"

Concerns...

ESP_Easy_mega-20190630_normal_ESP8266_4M

... and ...

ESP_Easy_mega-20190630_normal_ESP8266_1M
DLzG
Micha

TD-er
Core team member
Posts: 1924
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Sleeptime

#8 Post by TD-er » 09 Jul 2019, 14:20

@M*I*B
Have you also saved in between?

Anyways the way the selector works now is not optimal, so it is definitely worth an issue @GitHub to look at.

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#9 Post by M*I*B » 09 Jul 2019, 14:45

... yes, shure. I have try many things, also flash and empty ROM and flash it new... It's not possible in this version ...

In this context, I think it would be better to allow a free input of the required data fields. So just the selection "X fields" and an input field for the really required amount. I just had the situation that I needed 5 fields and forcibly had to open two dummies.

What is also missing is the option to be able to assemble a string in a single field, e.g. ...

LUM: [Sensor # LUM] - TMP: [Sensor # T] - ... a.s.o.
DLzG
Micha

TD-er
Core team member
Posts: 1924
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Sleeptime

#10 Post by TD-er » 09 Jul 2019, 15:04

More than 4 values is not going to happen anytime soon.
That would require a lot of changes and/or rendering existing settings useless.
There was already some similar setting like this for the Dummy plugin, which is needed for controllers like Domoticz that need some types of data formatted differently. (e.g. Temp/Hum/Baro is different from CO2 in formatting)
For the same reason I had pull some tricks to make the output selectable in number of values. (e.g. the recent change of systeminfo plugin to output 4 values did change behavior on Domoticz)

A plugin currently can only output up-to 4 floating point values, or one larger integer (needed for RF-id scanner for example).
There is no support for strings.
For the parts that allow strings (e.g. publish to a HTTP url) you can use that syntax in rules.

For example:

Code: Select all

on bme#T do
  SendToHTTP example.com,80,api/add/single?id=%mac_int%&long=[gps#lon]&lat=[gps#lat]&T=[bme#T]&P=[bme#P]&H=[bme#H]
endon

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#11 Post by M*I*B » 09 Jul 2019, 15:10

... ahh ok, I understand ...

Ty for the hint with the URL.. I will give it a try ...
DLzG
Micha

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#12 Post by M*I*B » 10 Jul 2019, 12:54

Is there any way to disable that for testing? It is extremely annoying to put the ladder to the house in this case, to take the thing off the roof, unscrew it, unsolder the battery and get everything started again :evil: :evil: :evil:
FS : Daily flash write rate exceeded! (powercycle to reset this)
DLzG
Micha

User avatar
grovkillen
Core team member
Posts: 3324
Joined: 19 Jan 2017, 12:56
Location: Hudiksvall, Sweden
Contact:

Re: Sleeptime

#13 Post by grovkillen » 10 Jul 2019, 17:29

I would imagine it being less time consuming to read the manual:

https://espeasy.readthedocs.io/en/lates ... mmand.html

:twisted: :evil: ;)
ESP Easy Flasher [flash tool and wifi setup at flash time]
ESP Easy Webdumper [easy screendumping of your units]
ESP Easy Netscan [find units]
Official shop: https://firstbyte.shop/
Sponsor ESP Easy, we need you :idea: :idea: :idea:

Shardan
Normal user
Posts: 1122
Joined: 03 Sep 2016, 23:27
Location: Bielefeld / Germany

Re: Sleeptime

#14 Post by Shardan » 10 Jul 2019, 19:13

M*I*B wrote:
08 Jul 2019, 11:07
Ok, meanwhile I have follow your idea with the LiION; I have many of them for my E-Shisha...

I set the ESP to sleep 295 seconds and stay awaked for 5 seconds. I Also have figure out how to swith on a port while booting and switch it of before it goes back to sleep. For that it seems to be important that you buffer the port with an small condenser to let the switched sensors working stable. I use a 4µ7 and it works well now.
Last night at ~23:00 I have install it in a small transparent box (from screws) under my roof outside to test WLAN- communication and test how long the battery will work.

One thing I have find this morning in the logfile inside FHEM. Many of the Data are more then twice, sometimes only one value, ... It's every 5 minutes different... I.e. here a received block to show what I mean:

Code: Select all

2019-07-08_00:20:15 ESPEasy_ESP_test presence: present
2019-07-08_00:20:15 ESPEasy_ESP_test B: 0.23 H: 64.52 P: 1012.55 T: 13.40 V: 4.44
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.52 P: 1012.55 T: 13.40 V: 4.44
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.52 P: 1012.55 T: 13.40 V: 4.44
2019-07-08_00:20:39 ESPEasy_ESP_test V: 4.45
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.52 P: 1012.55 T: 13.40 V: 4.45
2019-07-08_00:20:39 ESPEasy_ESP_test T: 13.27
2019-07-08_00:20:39 ESPEasy_ESP_test P: 1012.57
2019-07-08_00:20:39 ESPEasy_ESP_test H: 64.79
2019-07-08_00:20:39 ESPEasy_ESP_test B: 0.11 H: 64.79 P: 1012.57 T: 13.27 V: 4.45
2019-07-08_00:20:40 ESPEasy_ESP_test B: 0.23
2019-07-08_00:20:40 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.45
2019-07-08_00:20:40 ESPEasy_ESP_test V: 4.44
2019-07-08_00:20:40 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.44
2019-07-08_00:20:43 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.44
2019-07-08_00:20:44 ESPEasy_ESP_test B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.44
B = Brightness in LUX
H = Humidity in %
P = Pressure in mBar
T= Temperature in °C
V = Cell- Voltage in V

What I realy need is the line offered in the "state" like "B: 0.23 H: 64.79 P: 1012.57 T: 13.27 V: 4.44". But if I set a filter for "state" in FHEM for the logfile I get nothing.

Question is why are there so much data sending in that singe block every time the ESP wake up?
After wake up ESPEasy sends all data to a home control server.
The "state" is a summarize of the actual values generated by FHEM, not by ESPEasy.

I've never tried that but it should be possible to write a few lines perl code to either cut off the "state" part
from that line or add the separate values to one string. FHEM can do this with a separate Perl modul or inside some functions.
Regards
Shardan

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#15 Post by M*I*B » 10 Jul 2019, 22:32

@grovkillen: I have read it but there is no option to switch that off. There is just an option to reset the counter. That only works sometimes if the ESP online. The most time you can send it many times and it was ignored due the ESP have much to do in the time they is online / not in DeepSleep.

@Shardan: You have misunderstand me, maybe about my ugly english... The question is, why the ESP send it more then once and also in different ways... Near the same happens if you don't let the Task send it, create a Rule and let the Dummy's send it...

An other thing... I figure out some "funny" things while checking out some different ways...

As base for the funny things take a look at the following:

Code: Select all

on System#Boot do
  GPIO,12,1   // works well
endon
on WiFi#Connected do  // the following lines don't work resp. don't work well
//on Clock#Time=All,**:** do  // the following lines work well!
  delay,5000
  SendToHTTP 192.168.1.10,8083,fhem?cmd=setreading%20ESP_20%20state%20VCC%20[VCC#VCC]%20TMP%20[THP#TMP]%20HUM%20[THP#HUM]%20BRI%20[LUM#BRI]%20PRS%20[THP#PRS]%20RSSI%20[SYS#RSSI] // Ok on Clock, nothing on WiFi
  TaskValueSet 10,1,[THP#TMP]  // most well
  TaskValueSet 10,2,[THP#HUM]  // most well
  TaskValueSet 10,3,[THP#PRS]  // often zero except Clock
  TaskValueSet 10,4,[LUM#BRI]  // often zero except Clock
  TaskValueSet 11,1,[VCC#VCC]  // most well
  TaskValueSet 11,2,[SYS#RSSI*-1] // ever zero on WiFi, well on Clock
endon
on System#Sleep do
  GPIO,12,0   // works well
endon 
1.: DeepSleep
If I use it as it shown I have believed that it must work this way... But it doesn't. The HTTP will never been send to the Dummy at FHEM, the ESP- dummys are often not filled with the data and at FHEM often some or all data are "0"

2.: By Time
If I use the Clock for testing (no sleep) the HTTP will send without errors to the FHEM- Dummy, the ESP- Dummys will send also well...

The question is, what is going wrong while I use "on WiFi#Connected do" ???
DLzG
Micha

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#16 Post by M*I*B » 11 Jul 2019, 00:48

... and the next Joke before bedtime ...

Code: Select all

on System#Boot do
  GPIO,12,1
endon
on System#Sleep do
  on WiFi#Connected do
    SendToHTTP 192.168.1.10,8083,fhem?cmd=setreading%20ESP_20%20state%20VCC%20[VCC#VCC]%20TMP%20[THP#TMP]%20HUM%20[THP#HUM]%20BRI%20[LUM#BRI]%20PRS%20[THP#PRS]%20RSSI%20[SYS#RSSI]
  endon
  GPIO,12,0
endon 
That work's perfect! I have delete all dummy-devices and all controller. Also I have set the "Sleep awake time" to 1 second and "Sleep time" to 300sec. It looks like that the one second is only needed to wakeup. They need longer to connect to the WiFi but I believe they don't go sleep before finnish all jobs. So the running time is now the shortest possible and the battery live the longest possible. They go to sleep right now after sending the HTTP... And also don't hassle with the logfile; the logfile is perfect now without drops and doublettes...

With two words: That's it!

Good N8 all :roll:
DLzG
Micha

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime (Outdoor- Light/Temp/HUM/PRS)

#17 Post by M*I*B » 07 Sep 2019, 12:25

Just an update fore some who are interest in that:

In the meantime, I have been trying to reduce energy consumption to a minimum over the past few weeks so that the sensor can run for a long time with a 18650 cell.
Despite all the effort and tricks, operation with a cell is unfortunately only possible for a maximum of 5 weeks, with data transmission every 5 minutes.
Unfortunately, more is not possible. In the Deepsleep the whole only consumes about 3-4μA, but as soon as data has to be sent, the power consumption increases to about 72mA. The Wi-Fi part is unfortunately not satisfied with less.
The runtime is also heavily dependent on how good the WLAN connection is. The worse (the antenna), the longer the ESP needs for a connect, which significantly increases the duration of the increased power consumption.
With built-in antenna are not more than 3 weeks to create, with external antenna I come to the said 5 weeks.
ESP07 and ESP07S (soldered out the power LED) were used here. Compared with identical external antenna (the ESP07S has no internal antenna) it makes no significant difference which of the two ESPs is used.

Conclusion:
For purposes that are only for 1-2 weeks, this solution is good to use, for permanent use, unfortunately, completely useless.

This is how I stamp this project.

The next attempt will be a line fed system with a battery buffer. The base will probably be a stainless steel tube, which houses one of the light sensors on four sides and the support battery, the ESP and the BMP module inside. The tube will remain open at the top and at the bottom and closed only with a round plate, which has three large holes, which are closed with a stainless steel mesh to protect against insects to ensure proper ventilation and correct temperature measurements. It is merely a conical roof, so that even in storm no rainwater can get into the pipe. Nevertheless, of course, the electronics must also be sealed.

The whole comes then with a short mast on our house roof
DLzG
Micha

TD-er
Core team member
Posts: 1924
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Sleeptime

#18 Post by TD-er » 07 Sep 2019, 23:08

Just as a small remark on the battery consumption.
If you're using static IP, you may also decrease the connection time.
But since the last few builds, this gain may not be as much as before, since I did manage to cut down the DHCP time needed.
Also using B/G-only may reduce the WiFi power consumption.

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#19 Post by M*I*B » 07 Sep 2019, 23:51

... ty for the hint; I use a fixed IP due the connect goes much faster then DHCP and that also shorten the time the ESP take power.
I think that all opimisations are can't be enough to stretch the time to, let us say, an half year. I think that's impossible with WLAN and a single cell... Are you similar with me?
DLzG
Micha

TD-er
Core team member
Posts: 1924
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Sleeptime

#20 Post by TD-er » 08 Sep 2019, 00:25

M*I*B wrote:
07 Sep 2019, 23:51
... ty for the hint; I use a fixed IP due the connect goes much faster then DHCP and that also shorten the time the ESP take power.
I think that all opimisations are can't be enough to stretch the time to, let us say, an half year. I think that's impossible with WLAN and a single cell... Are you similar with me?
Not sure if we could stretch it to a factor 5 - 6 you're already getting now.
WiFi is not the only thing here.
I think you should also "disconnect" the sensors from power when in deep sleep.
For example by switching them off via a FET with very low quiescent current.
On top of removing the sensors as power consumption when asleep, you may also look at the power converters having a low quiescent current.

To lower the WiFi on time, we can some day move to ESP-now instead of WiFi.
Then sending data can be done in 50 - 200 msec and power down again.
That's a factor 12 improvement over WiFi connection time.
But like I said, it isn't just the WiFi burning power here.

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#21 Post by M*I*B » 08 Sep 2019, 10:44

I think you should also "disconnect" the sensors from power when in deep sleep.
... sure. If I had not done that, surely the end would have been reached after 2-3 weeks.
With the LowPower / LowDrop regulator, however, a different picture has emerged. I had a total of 4 identical test setups with exactly the same power consumption. Three of them were equipped with different regulators, one without. After about 2-3 weeks, the test setups with regulator have already passed.
The ESP and sensors easily tolerate the 4.3V of a fully charged cell (at least the 07x). After deducting the self-consumption of the regulator, I get extra time from the non exist dropout. And even if I did not expect it, the attempt shows that sometimes a straight forward thinking is better than a complicated one ...
we can some day move to ESP-now instead of WiFi.
Can you explain that? I don't know what you talking about :cry:
But like I said, it isn't just the WiFi burning power here.
That's true... But do you know how much the Core and how much the WIFI take? Anyway... we can't decouple it at this time so we talk about things we can't change yet... right?
DLzG
Micha

TD-er
Core team member
Posts: 1924
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Sleeptime

#22 Post by TD-er » 08 Sep 2019, 11:20

ESP-now is a protocol specific for ESP nodes.
It is something I plan to add later, since it does allow for really short WiFi on times.
In short, you can send data from one node to another one (only a limited set of MAC addresses can be "paired" for this)
It is using the WiFi radio, but does not need to connect to an AP, but rather sends it directly to another node.
You can send a payload of about 250 bytes, which would be perfect for sending sensor values.
Since it does not need to scan for all channels, it saves waiting for 12x 200 msec (WiFi scan) and thus saves quite some WiFi-on-time.

Another option could be to store the values in RTC memory and send a number of updates as soon as the RTC memory is full.
But not all use cases are suitable for this.

User avatar
M*I*B
Normal user
Posts: 99
Joined: 22 Jan 2018, 15:47
Location: Germany
Contact:

Re: Sleeptime

#23 Post by M*I*B » 08 Sep 2019, 12:15

Yes, that's a brilliant idea! This would perhaps make it possible to come to a cell with a term of 6 months. When the time comes, I will do it again, regardless of my modified project.
Saving is also a good idea, but as you already noticed, not for all applications (like mine) to use. I need the data latest all 5 minutes (every minute will be very good, all 10 seconds is planned for the changed project)

Thank you for the explanation!
DLzG
Micha

TD-er
Core team member
Posts: 1924
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Sleeptime

#24 Post by TD-er » 08 Sep 2019, 15:17

Maybe we could also have a look at the ESP32 for really low power solutions.
The ESP32 has (apart from the dual core) another ULP core (Ultra Low Power) and it has Bluetooth.
Programming the ULP core is a lot harder, but it does allow to collect data and store it in its own RTC memory.
This could then be sent once every so many samples or time to another node.
Bluetooth is more power efficient compared to WiFi.
Only thing is that Bluetooth does need something to receive the data and transfer it to somewhere else. (is also needed with ESP-now)
With WiFi you're already at network level, so it is easier to get the data to where it is being processed.

User avatar
enesbcs
Normal user
Posts: 429
Joined: 18 Jun 2017, 11:02
Location: Békéscsaba, Hungary
Contact:

Re: Sleeptime

#25 Post by enesbcs » 11 Sep 2019, 18:08

TD-er wrote:
08 Sep 2019, 11:20
ESP-now is a protocol specific for ESP nodes.
It is something I plan to add later, since it does allow for really short WiFi on times.
In short, you can send data from one node to another one (only a limited set of MAC addresses can be "paired" for this)
It is using the WiFi radio, but does not need to connect to an AP, but rather sends it directly to another node.
Quick note: I've read about ESP8266 and broadcasting with ESPNow is not working, but according to my tests with ESPNow and Core 2.5.2 the broadcast sending works. (COMBO role)

Post Reply

Who is online

Users browsing this forum: No registered users and 16 guests