More flexible config mode reset

[enavarro222]

I'm thinking on how to make the reset (to config mode) more flexible.

At first step a method resetConfig that can be call from main code could be a nice step. It will allows any user defined reset (why not a konamicode on the device keypad ;)).

However the current reset (GPIO0==D3 low for 5sec) might be problematic if this pin is used for other something else. It could generate undesired reset...

An radical solution would be to let entirely the user defined (and code) the reset trigger... Not satisfying as with NodeMCU D3 is already bind to push btn (flash) and is a very good candidate for a default reset method !

One other solution may be to have tho other methods:

• setResetTrigger(D4, HIGH, 6000): configure that config reset will be trigger if D4 is high for 6sec (with level and timing as option);
• unableResetTrigger(): disable "homie-managed" reset

Other ideas ?

[marvinroger]

At first, Homie-ESP8266 was designed for NodeMCU v1.0, but this obviously has to evolve. To sum up:

• We keep the NodeMCU button as the default reset trigger. Not sure about this, though
• setResetTrigger(D4, HIGH, 6000) customizes the reset trigger
• setResetFunction(func). if func() returns true, the device resets. But setResetFunction() is already a function that allow to define a function to run (e.g. clean custom EEPROM) when a reset is triggered. Maybe we could rename this one setResetHandler() or setResetHook? The hook one is the most explicit, as it is actually an hook
• disableResetTrigger() disables the inner reset trigger only

[enavarro222]

It seems clever for me to keep the default reset trigger. Note that to have an ESP8266 to boot from flash (normal boot) you need to have GPIO0 high, so in most set-up GPIO 0 will be pullup.

For "manual" reset I was more thinking to a Homie.resetConfig() method that can be called from the user code (basically from the loopHandler) that just directly trigger the reset...

[marvinroger]

The loopHandler is only called when the network is in a good state (connected to both Wi-FI and MQTT). So if you want to reset because you've changed your Wi-Fi credentials, you're stuck as the loopHandler will never be called. So a resetConfig could eventually be called from the loop(), but this is sad to add code there, where there is only a pretty Homie.loop() call.

[enavarro222]

good point :) Maybe one can add a warning about that in the doc ! So your solution with a callback fct is clearly better.

I'll need all this for one of my devices where all GPIO are used. So I'll work on this when I update the FW of that device (to make it use Homie). However I don't know when it will be...

[marvinroger]

I'll create a proper documentation, as the project is becoming more and more feature-rich. ;)

I don't know how I will implement those methods either!

[marvinroger]

Docs are more complete about the loopHandler now. More flexible reset is the next thing I will implement.

[marvinroger]

Done: cfbcb5925520d091b86f9b46dd73ca80bf75cb71 and b9d4b6b358ad435cf1049758f704f4a91e84184f

You can see the usage in the Wiki

[enavarro222]

Great ! Nice work :+1:

I hope to have some time to test it one evening next week...

Thanks !

[marvinroger]

Take your time! Feel free to reopen if it does not work for you.