Wake up triggered by either the RTC or a momentary switch?

[kentaylor]

Thanks for providing this information, circuit, videos and explanation at http://chaeplin.github.io/project-01-button.html.

It can detect the momentary switch while awake which is nice but as far as I can tell it is not suitable for the case described by @me-no-dev at esp8266/Arduino#1488 (comment) where the ESP wake up from deep sleep is to be triggered by either the RTC or a momentary switch. Is that correct and if so, is there a simple modification?

I have ambitions of sampling temperatures at regular intervals and detecting contact closures from a tipping bucket rain gauge while the ESP remains mostly in deep sleep and am puzzling over a simple circuit that doesn't drain the battery to achieve it.

[chaeplin]

Hello.
It's not suitable for using both wakeup by internal rtc and external momentary switch.
As GPIO16 is used to control NPN TR.

If deepsleep interval is 5 mins, and 'tipping bucket rain gauge' generates low pulse
---> gpio16 to rst, and rain guage output to rst also.
---> 'tipping bucket rain gauge' output should be one time low pulse.

deepsleep : can't sleep more than 7 ~ 8 mins using internal rtc( http://www.esp8266.com/viewtopic.php?f=32&t=7867 )

I think attiny85 + DS3231 + momentary switch + esp8266 is good choice.

1. esp8266 : deepsleep(0) sleep forever
2. attiny85 :

• control esp8266(a gpio out to rst of esp8266)
• control ds3231 alarm(i2c + int)(Or esp8266 can control ds3231)
• input from momentary switch
• DS3231 has alarm pin to use ( INT/SQW) : https://github.com/Makuna/Rtc/blob/master/examples/DS3231_Alarms/DS3231_Alarms.ino
• DS3231 is used to wake up esp8266 : https://github.com/chaeplin/esp8266_and_arduino/tree/master/_54-atmega328p-nrf24-gy-521-hx711
• pin change interrupt / sleep on attiny85 : https://github.com/chaeplin/esp8266_and_arduino/blob/master/_60-tiny85-pin-int/a-02-PinChangeInterrupt-sleep/a-02-PinChangeInterrupt-sleep.ino

[kentaylor]

Thanks for the fast and comprehensive response. It seems not to be as simple as I'd hoped.

It's not suitable for using both wakeup by internal rtc and external momentary switch.
As GPIO16 is used to control NPN TR.

It can use another GPIO if the circuit can deal with the pin acting as an input during deep sleep. Then GPIO16 could be used to provide its usual wake up signal.

If deepsleep interval is 5 mins, and 'tipping bucket rain gauge' generates low pulse
---> gpio16 to rst, and rain guage output to rst also.
---> 'tipping bucket rain gauge' output should be one time low pulse.

This hits the simplicity criterion. The tipping bucket magnet closes a reed switch as it tips to produce a momentary closure which can be configured to be either VCC or GND. The bucket could tip anytime which means a running program could be interrupted and that is why I was looking around for alternatives.

Thinking about it some more though I wonder if there is an algorithm that will work.

The issues :-

1. If it was during a temperature reading it would be lost but that wouldn't matter much and a temperature can be included with each bucket tip report.
2. A lost bucket tip can seriously impact rainfall measurement accuracy. The minimum interval between bucket tips is 0.4 secs which is long enough for a user program to start running but not long enough to send a message.
3. It is quite likely that in a downpour associated with a maximum tipping rate WiFi wouldn't get through the rain.
4. The ESP will lose track of time when reset by a bucket tip.
5. Reporting no more often than 30 seconds intervals helps with battery consumption.

Possible Solution

1. Maintain a bucket tip counter in RTC memory.
2. Always send the total so tips are never missed.
3. Timing for determining tipping rate is done by the receiving station.
4. Wake up every 5 minutes.
5. By default wake up with radio off to reduce power consumption a lot. Figures are 40 mAsecs to transmit a sample using UDP vs 15mAsecs to wake up with WiFi but not transmit vs 5mAsecs to wake up with WiFi off.

Possible Algorithm

If just powered up set to wake up in 5 minutes with WiFi off.

If woken with WiFi on and (if woken by RTC or (reported tip counter - tip counter>10)) then report temperature and tip counter.

• If message transmission successful set to wake up in 5 minutes with WiFi off, clear message failure counter, and set reported counter to tip counter.
• If message transmission fails, set to wake again in 5 minutes with WiFi on and increment message failure counter.

If WiFi is off, there has been a bucket tip or temperature change and message failure counter = 0 wake up in 30 sec with WiFi on.
Else if there has been a bucket tip and message failure counter >0, wake up in 5 min with WiFi on.

Not sure that it covers all the scenarios?

I think attiny85 + DS3231 + momentary switch + esp8266 is good choice.

That is more physically complicated than I hoped but makes for a simpler algorithm.

[kentaylor]

Some more information on the weather station is at https://forum.makehackvoid.com/t/weather-station-wake-up-triggered-by-either-the-rtc-or-a-momentary-switch/972

[PuceBaboon]

Ken,

You might want to look at a hardware alternative. I had a temperature
sensor which used the interrupt output from a DS3231 RTC to turn on a
P-Channel MOSFET as a power switch for the ESP8266. In other words, the
ESP8266 is not in deep sleep; it's completely powered off until the DS3231
triggers (no worries about quiescent current, or about maximum sleep
time). The DS3231 was running from it's own, separate coin-cell battery.

Once the ESP is woken, it reads the sensor and sends the reading to the
MQTT server, then it programs the next "alarm" (wake time) into the DS3231,
which causes the DS3231 to reset it's interrupt line, switching off the
MOSFET and removing power from the ESP.

I have a second version where the MOSFET has a momentary switch across
it which will supply power to the ESP when the switch is pressed. The
first thing the ESP does on start up is to drive a GPIO pin low to latch
the power switch on. The ESP then runs the rest of its normal routine and,
when done, simply toggles its own power off.

This second version is used in doorbell/dash-button type applications
(no DS3231). The schematic is available here:-
https://hackaday.io/project/12866-esp8266-power-latch

Both versions completely remove power from the ESP8266 when its task is
completed. Both use three, AA batteries and a Holtek HT7333 low quiescent
current regulator to provide 3v3 to the ESP. The RTC version ran for in
excess of 3-months last winter (logging the temperature in our basement)
before being re-purposed for something else. The doorbell/dash looks as
though it will last pretty much the shelf-life of the battery (it is used
very infrequently).

Either way, this idea of switching power using a p-channel MOSFET isn't
novel, but it is a great technique to use with the ESP8266 in
battery-powered applications. It's also trivial to OR inputs together
(with something as simple as a couple of diodes) to allow multiple triggers
to power on the ESP.

Hope this gives you some food for thought on the project. Please keep
us posted on that rain gauge, I've wondered just how well those little
blocky ones work.

                                      -John-

[kentaylor]

Thanks @PuceBaboon and @chaeplin for providing input on the rain gauge switch design. I've incorporated some of the feedback into an updated discussion and revised design.

[union7]

PuceBaboon , does your door bell wireless send a trigger packet to a receiver? If so how long does it take to go from a doorbell press>>>start the esp8266>>>connect to receiver/AP>>>transmit the "button pressed" packet?

[PuceBaboon]

Union7, It's not too long; about two seconds from the press to arrival of the packet at the MQTT server. It's a noticeable delay for something like a light switch, or a doorbell, though. I distract the user by having an LED light display (which is actually also showing debug progress ...different colours for WiFi connecting, connected, MQTT connecting, message sent, etc). -John-

…

On 13 July 2017 at 15:37, union7 ***@***.***> wrote: PuceBaboon , does your door bell wireless send a trigger packet to a receiver? If so how long does it take to go from a doorbell press>>>start the esp8266>>>connect to receiver/AP>>>transmit the "button pressed" packet? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKLtWQlHufaKOzZ_jgr-cSxSCeaxNWjsks5sNbs3gaJpZM4KqbEk> .

[union7]

thanks for the quick response! i'll try a deep sleep solution first since i am datalogging something with timetamps,,, and the stamp occurs at the AP hub (local wifi network of esp's)