RFE: Support for momentary switches

[squeed]

Thanks for the great library! I think this is awesome.

Anyways, I see that the current suggested way for doing momentary switches (the "garage door opener" example) has Home Assistant doing the momentary logic. It might be nicer if the momentary logic was implemented on the ESP itself.

My thoughts:

1. The timing would be more accurate
2. Less likely for an output to be "stuck on" if HA crashes or wifi / mqtt goes down.
3. Can also be reliably "restored" if the ESP crashes and reboots.

In my case, I have an ESP wired up to my apartments door buzzer. That thing is definitely not rated for continuous duty - I really don't want to ever have it stuck on! I currently have some custom code on my ESP for this, but I'd love to migrate.

If you think this is a good idea, I'm happy to implement this.

[OttoWinter]

Are you referring to this page? https://esphomelib.com/esphomeyaml/cookbook/garage-door.html

Because all the automation you write within the esphomeyaml configuration file is actually executed entirely on the ESP, without any of Home Assistant.

But a fair warning about this: Currently if WiFi/MQTT cannot be connected to, the ESP will restart itself after a minute or two. This is because sometimes the low level IP interface somehow gets into an invalid state and needs a full reset to work again.

This means that if the node cannot re-connect to WiFi, it will restart itself after a while, thus making the garage door potentially "stuck open". I'm working on improving this, but there are a lot of edge cases that need to be handled and it's quite complicated.

[squeed]

Ah, gotcha - thanks for the clarification. I misunderstood that example.

As for the "stuck" state, perhaps it makes sense for GPIO pins to have some kind of a "default" or "onBoot" setting.

Feel free to close this if you like.

[OttoWinter]

GPIO pins are LOW by default on boot (or HIGH if the inverted property is set to True in the pin schema).

However, all switches will try to recover their state on boot (on the ESP32 for now, but hopefully soon also on the ESP8266). I'm thinking of creating an on_boot trigger in which users can manually execute any action when the device boots up (with an option to choose whether the trigger should start before or after wifi/mqtt is initialized).

[OttoWinter]

The on_boot trigger has been added and will be in v1.7.0; closing as I think it would solve the issue...

[squeed]

amazing, thanks!