search

chaeplin / esp8266_and_arduino

esp8266 mqtt node / esp8266
290 stars 89 forks source link

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

Closed kentaylor closed 3 years ago

kentaylor commented 7 years ago

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 https://github.com/esp8266/Arduino/issues/1488#issuecomment-174268749 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 commented 7 years ago

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 :

kentaylor commented 7 years ago

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 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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 notifications@github.com 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 https://github.com/chaeplin/esp8266_and_arduino/issues/37#issuecomment-314985828, or mute the thread https://github.com/notifications/unsubscribe-auth/AKLtWQlHufaKOzZ_jgr-cSxSCeaxNWjsks5sNbs3gaJpZM4KqbEk .

union7 commented 7 years ago

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)