node.dsleep() reliability - zombie mode
Posted: Wed Jan 28, 2015 10:52 am
I have been doing some testing using dsleep in anticipation of creating battery operated sensors that can work unattended for long periods.
To that end, I have a modified ESP-01 that "works" for resuming from dsleep.... most of the time.
The original code was a DS18B20 temperature sensor that ran on a tmr.alarm() and posted the temperature to my web site once a minute. It was reliable. For about 40 days, it worked perfectly every time. It just used to much power for battery operation.
So the hardware and the code is in good shape.
Replacing the tmr.alarm with a node.dsleep after the disconnection and with a second "watchdog" alarm that initiates dsleep after 10 seconds in case something goes wrong, everything looked good for over a day. The watchdog tmr.alarm is the first line of the init.lua.
And then, it didn't resume from sleep. Testing for several more days reveals that it can resume properly up to 2,000 times at best and a few hundred at worst. Not resuming seems to be a random thing. Nothing is changed in the hardware or software.
When it doesn't resume, current consumption is on the order of 10 mA. This is an odd number. While sleeping, normal consumption is in the microAmps. While working I see 70-120 mA normally.
So, it appears that the failure to resume (or maybe failure to go to sleep properly) is an inbetween mode.
I don't know if this is Lua code related or an underlying firmware issue (more likely). It might even just be this particular part.
So, I wonder if anyone else has done any long term sleep/resume testing and how reliable it was?
I will probably simplify down to nothing but an alarm and dsleep and do some more testing. I need to know that no matter what, the dsleep will resume the processor. Otherwise, an external clock will be needed.
To that end, I have a modified ESP-01 that "works" for resuming from dsleep.... most of the time.
The original code was a DS18B20 temperature sensor that ran on a tmr.alarm() and posted the temperature to my web site once a minute. It was reliable. For about 40 days, it worked perfectly every time. It just used to much power for battery operation.
So the hardware and the code is in good shape.
Replacing the tmr.alarm with a node.dsleep after the disconnection and with a second "watchdog" alarm that initiates dsleep after 10 seconds in case something goes wrong, everything looked good for over a day. The watchdog tmr.alarm is the first line of the init.lua.
And then, it didn't resume from sleep. Testing for several more days reveals that it can resume properly up to 2,000 times at best and a few hundred at worst. Not resuming seems to be a random thing. Nothing is changed in the hardware or software.
When it doesn't resume, current consumption is on the order of 10 mA. This is an odd number. While sleeping, normal consumption is in the microAmps. While working I see 70-120 mA normally.
So, it appears that the failure to resume (or maybe failure to go to sleep properly) is an inbetween mode.
I don't know if this is Lua code related or an underlying firmware issue (more likely). It might even just be this particular part.
So, I wonder if anyone else has done any long term sleep/resume testing and how reliable it was?
I will probably simplify down to nothing but an alarm and dsleep and do some more testing. I need to know that no matter what, the dsleep will resume the processor. Otherwise, an external clock will be needed.