FDRS Update ESP32/ESP8266 nodes via OTA updates

[aviateur17]

FDRS Node updateFDRS to put controller into WiFi Access Point mode with ability to use a PC and Arduino or Platform IO to perform an OTA update on ESP32 or ESP8266 controllers. Update mode will time out in 5 minutes. Update mode to be called by user with additional functionality to come in future commits to this PR.

[timmbogner]

This looks great! I've been distracted all month, but hoping to get back to it next week.

I don't have a lot to add just yet. Something I hadn't fully considered is how the only mode that needs to drop out of normal operation is ESP-NOW. Otherwise any ESP device can just silently enable WiFi, connect to an AP, and start doing OTA stuff in the background. With that in mind, is there anything stopping us from letting a LoRa node stay connected to a WiFi AP all the time (if it was on AC for example)? We could add USE_CONSTANT_OTA or something to invoke it.

Or going further, could a LoRa node OR gateway keep its own AP running while handling the radio interrupt. I assume so, but it sounds intense.

That's all I have right now, both these things are just spur-of the moment ideas because I don't have a lot else to say right now :) I assume the SystemPacket mechanism will follow? As always, thank you so much for all your help!

[svdrummer]

Is there really a need for this? Is there higher priority items? These are the questions I asked myself on another project. How often do we do ota, and in reality, we should check remote items and while we are there, do an ota.

[timmbogner]

Is there really a need for this? Is there higher priority items? These are the questions I asked myself on another project. How often do we do ota, and in reality, we should check remote items and while we are there, do an ota.

I agree that there's a good argument for manually updating the device so you can inspect the hardware, etc. However, OTA support has been very commonly requested for FDRS over time. Some people use OTA as their main method of flashing devices, so to those people this feature probably seems absent currently. The biggest argument for adding it is to ease the updating of hard-to-access devices in remote places.

There are some bigger items that could be added, but we do this in our free time and work on what we think we have time for.

[aviateur17]

Is there really a need for this? Is there higher priority items? These are the questions I asked myself on another project. How often do we do ota, and in reality, we should check remote items and while we are there, do an ota.

@svdrummer what feature or features are you excited about being implemented?

[svdrummer]

Is there really a need for this? Is there higher priority items? These are the questions I asked myself on another project. How often do we do ota, and in reality, we should check remote items and while we are there, do an ota.

@svdrummer what feature or features are you excited about being implemented?

Stability and documentation. Seems a lot of GitHub questions are about config errors etc. I know we all like software and hate doing the documentation. Mind you, it would be interesting to see how FDRS keeps ESPnow on channel one, when mixing wifi into the mix.