How do you properly handle external interrupts?

[Rf3w8]

I suggest you look at the ESP8266 low power modes e.g. the esp library http://docs.micropython.org/en/latest/e ... y/esp.html and search this forum to see what others have done. It seems that you set the sleep mode and everything works (with code such as you've outlined) auto-magically but I haven't tried this in practice.

Thank you! Will look into it

[kfricke]

The really power-saving sleep modes need to disable WiFi completely. So waking up and connecting to a previously known WiFi does take a few seconds... ~4 including when getting a DHCP lease and only ~2 seconds less with a static IP.

I do not like to sound pessimistic, but this seems to not be a responsive switch. I am considering to watch into the mesh modes the ESP has in the in the SDK. This ad-hoc mesh mode is not available from MicroPython (yet?).

[Rf3w8]

The really power-saving sleep modes need to disable WiFi completely. So waking up and connecting to a previously known WiFi does take a few seconds... ~4 including when getting a DHCP lease and only ~2 seconds less with a static IP.

I do not like to sound pessimistic, but this seems to not be a responsive switch.

I didn't look into sleep modes yet, but I guess another issue, specific to the esp-01, is that wake up from deep sleep is impossible unless you rewire the circuitry with some pins on the board. Maybe a sleep mode without deactivating wifi is possible..

I am considering to watch into the mesh modes the ESP has in the in the SDK. This ad-hoc mesh mode is not available from MicroPython (yet?).

What would you use it for?

[kfricke]

I didn't look into sleep modes yet, but I guess another issue, specific to the esp-01, is that wake up from deep sleep is impossible unless you rewire the circuitry with some pins on the board. Maybe a sleep mode without deactivating wifi is possible..

Yes, you do need to wire GPIO16 to RESET. This enables the ESP8266 to wakeup from deep sleep. Missing this will need an external wakeup signal on GPIO16 for wakeup.

I am considering to watch into... ad-hoc mesh mode ...

What would you use it for?

It came across my mind when thinking about a switch which is able to do send a MQTT within a minimum timeframe after wakeup from deepsleep. So this seems to be the the exact same idea as you have had. My intent is to switch light bulbs connected to my instance of Home Assistant. Commercial "smart home switches" are far too expensive at the moment. There are open-source solutions using low cost parts, but most are bloated imho. It should be as simple a cheap radio which can send pulses when switched on nothing more... like a Attiny85 + NRF24L01+ radio... or an fast waking up WiFi ESP8266... or an ESP8266 with an NRF24L01+ radio.

Unfortunately I could not find that much documentation and details about the mesh mode. Only the parts from the ESP SDK. I have no clue if this is a way to go at all. Any ideas?

My current way to go is to avoid the ESP8266 WiFi and use a NRF24L01+ radio module. Currently prototyping with an ATmega328, possibly using a ESP8266 with WiFi disabled to pull costs to a minimum.

[Rf3w8]

By the way, I'd like to test how much it takes for the esp to connect to the wifi network: it looks rather fast even with DHCP (at least in my case), maybe with static IP it will be even faster and can overcome the initial boot up delay..

Also, I'm willing to test how much power it will consume when running into an infinite loop and sleeping every, idk, 100ms...

I'd be very glad if I can avoid soldering extra circuitry to the esp-01 to wake it up from deepsleep because it looks like is not an easy task since the GPIO 16 is not exposed/available

[mr_exit]

I remember reading in another thread that with a static IP it's between 2 and 3 sec, with dhcp it's about 4.

Is there a command to run to check when you're on the network? I've got a built in 5 sec delay in my projects before connecting to the MQTT broker, but I'd like to replace that with something more reliable

[kfricke]

...
Would a polling solution like the following work fine?

Code: Select all

while True:
    # Check if GPIO(0 or 2) is high/low
    # Act accordingly
    time.sleep_ms(100)

No, sorry this is a wrong assumption. There are the following sleep modes and their power consumption:

• Modem sleep - 15 mA
• Light Sleep - 0.9 mA
• Deep-Sleep - 10 uA
• Power Off - 0.5 uA

The first two are not that applicable for a battery powered scenario imho. The later two have radio modem disabled and will take several seconds to wake up from. As far as i know "Power Off" ist not implemented or reachable.

That code example above does only apply to the first two power saving modes.

(edit: add quote to the post this answer is referring to)

[kfricke]

...Is there a command to run to check when you're on the network? I've got a built in 5 sec delay in my projects before connecting to the MQTT broker, but I'd like to replace that with something more reliable

Sure take the following example:

Code: Select all

...
print('Connecting to WLAN...')
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
cstart_ms = utime.ticks_ms()
if not wlan.isconnected():
    wlan.connect(config.WLAN_SSID, config.WLAN_PSK)
    while not wlan.isconnected():
        utime.sleep_ms(100)
        if utime.ticks_diff(cstart_ms, utime.ticks_ms()) > 10000:
            print('Connecting to WLAN timed out. Resetting!')
            machine.reset()
mac_address = ubinascii.hexlify(wlan.config('mac')).decode('utf-8')
...

Taken out of context from https://github.com/kfricke/micropython- ... tch.py#L76

[mr_exit]

There was an interesting recent ADAfruit video where they were using arduino and an external super low power timer chip ( TPL5110) to wake up the arduino at a set interval, let it's do it's thing, then when it's done the arduino was giving a signal back to the chip which would then cut power to the arduino.

If boot time wasn't a problem you could use one of them when running off battery

https://www.youtube.com/watch?v=-cRiN8sxQ5k

[kfricke]

A few weeks ago i did read in a vanished (blame the DMCA) article about the second generation of Amazon dash buttons:

They do use a user exposed push-button to switch a transistor/MOSFET which powers up the MCU. Then the dash's MCU uses one of its own GPIOs to take over to keep the transistor/MOSEFT on. After doing the desired work (ordering a product on Amazon) the GPIO lets loose the transistor/MOSFET to drop back into really low-power off state.

Sure you do not need the responsiveness of a light switch or something like a remote, when waiting for UPS to deliver a new package of toilet paper with over night express