Think about fallback features
Closed this issue · 5 comments
There should be some basic fallback (and documented how it works) to situations like:
- MQTT server is not running on start
- MQTT server stopped later
- ESP crashes
- ESP not boots / is removed
It is good practice in smart home UX to keep non-smart features if smart devices are not working. In lighting, switch on the wall should turn on and off the light (white, 100% brightness).
Hmm... This is good to think about. I'll look into adding handling for MQTT server problems. I'd also add WiFi connection issues to that list.
By nature of the way I've wired the pull-up resistors, removing the ESP will cause the lights to go to full-white.
This should also be issue to think about - if something crashes and is restarted, it is good to keep state (e.g. in the night not turn on lights for a few seconds).
- 2016 v 16:31, Corban Mailloux notifications@github.com:
Hmm... This is good to think about. I'll look into adding handling for MQTT server problems. I'd also add WiFi connection issues to that list.
By nature of the way I've wired the pull-up resistors, removing the ESP will cause the lights to go to full-white.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #5 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAlfWBZ-3_DwYZ6DTq5RjVkQCRl-jDRqks5qpWIxgaJpZM4J6pK_.
That is actually something I thought about. Home Assistant saves state, so I don't want to maintain the full state internally.
Because there are pull-ups on the MOSFETs in my wiring, the lights will likely flash on reboot anyways. That is specific to the way I've wired the circuit to cover the "best practice" above (and because some pins need to be pulled high on the ESP for it to boot correctly).
Thank you for the issue report. I'll do some experiments and see what works best.
Btw, is it possible to electronically suppress the first few seconds? E.g. by another MOSFET on GND for LEDs what will be closed by pull-down until some capacitor is slowly charged.
Just keep fallback if ESP will not start, but delayed.
I have ho experince in this math, just brainstorming :-)
To close out this conversation for now:
It would probably be possible to hold the MOSFETs low for a second, but this issue hasn't bothered me enough to complicate the circuit.
I'm going to close this for now. I know I'm compromising some UX by not turning on the light if it can't connect to the MQTT broker, but the trade-off is that the lights don't randomly turn on in the night if my WiFi drops for some reason.
If there's real interest in this, I could add a configuration option to set the fallback action if it can't connect.