Add OTA support via ArduinoOTA

[aviateur17]

Add ability to update sketch on ESP32 and ESP8266 via Over the Air Updates by use of ArduinoOTA library.

[timmbogner]

I haven't read it yet but the idea sounds good. but I'm a bit in-the-weeds with some SX1262 compatibility issues. I'll catch up on your PRs once I figure that out, and perhaps take a breather.

[aviateur17]

This PR should be complete. I don't plan on adding any more related functionality to this for awhile. Some features that could be added would be to make sure this works with wired Ethernet.

[timmbogner]

Just checking... the static IP stuff isn't actually needed for OTA, right? It's good to have, but I'll maybe take it out of repeater configs.

I used to care about keeping the gateway config files pretty much all the same (and filled with all of the possible configs), but I'm sort of changing my tune on that.

I don't have a ton of experience with OTA, but here are my only notes:

• It seems to work fine with ethernet.
• I'm getting the impression there isn't an OTA equivalent outside of ESP chips. I think PicoW support was added since you started this PR, and OTA breaks it. We'll have to protect that code from other MCUs.
• Minor detail: It could be nice to add the UNIT_MAC to the hostname in case there are multiple FDRS systems on one WiFi network.

If you want to make the changes just let me know, otherwise I'll probably add them and pull this tonight or tomorrow.

[aviateur17]

Correct, static IP isn't required for OTA.
There is no OTA equivalent outside of ESP32 and ESP8266 and only the ESP8266 with 1MB of flash or more will work and that depends upon the size of the code. Yeah, I'm not sure right now if the code is isolated from other architectures. I can go back and look at that again. I can try to add the MAC to the hostname. Up to you on the repeater configs. I can remove that stuff since WiFi will not be used.

[timmbogner]

The easiest thing might be to just enable it with a USE_OTA macro. Then the user is responsible for making sure they actually can use OTA.

I'll just go through and clean up the repeater configs later, don't worry about that.

[PerRieland]

Will it be posible to use OTA when using LoRa and not WiFi ?

[aviateur17]

Will it be posible to use OTA when using LoRa and not WiFi ?

Unfortunately not. LoRa is really meant for low bandwidth and small messages transmitted at relatively long intervals between transmissions which is not suitable for software updates.

[PerRieland]

It's a shame. Since I use LoRa and my controllers are too far away to be able to use WiFi. Some controllers are mounted so they are difficult to access. But I can get very close with a laptop. I can bring a mobile access point if it can in any way help ensure wireless updating. If it is possible to update the controllers wirelessly it will be a huge help.

[aviateur17]

Agreed. What micro controllers are you using for LoRa? ESP32, ESP8266, etc? What would you think about having a long button press have the controller go into Access Point mode to then do an OTA update and then reboot? Do your controllers have a LED to indicate different statuses and a button that you can hold a long time? I would guess if you have to get to the button that you'd have to be close to the controller anyways. Maybe a command that can be sent via LoRa to the controller to remotely restart it and go into Access Point mode to then update via OTA? What are your thoughts? Not sure how soon this would be implemented though.

[timmbogner]

I think the idea of a SystemPacket that invokes WiFi/OTA mode seems doable. So for example, you'd use a special device that sends an ESP-NOW command to a specific gateway to put it into OTA mode. Then you could get nearby with a laptop broadcasting an access point and update with OTA. This is really better for hard-to-access devices than far away ones.

[PerRieland]

A physical button is not a good way for my setup. Special packages are fine to go in WiFi/OTA mode. Another method could be to start the board for the first 30 sec. by going into WiFi/OTA mode.

[timmbogner]

I think we could invoke it by either button or SystemPacket, with both options available. Once this PR is closed I'll break the idea off into a new discussion topic. (Unless you want to get it into this PR, @aviateur17 that's up to you!)

This just occurred to me... If a LoRa repeater with an ESP isn't using ESP-NOW, there's no reason it couldn't listen for OTA updates with the WiFi modem (except the extra power use). Perhaps this is another reason for a USE_OTA flag: so that a gateway can use OTA even if not otherwise using WiFi/MQTT. It's a bit extra, so I'm not strongly attached to the concept. Thoughts?

[aviateur17]

Once this PR is closed I'll break the idea off into a new discussion topic. (Unless you want to get it into this PR, @aviateur17 that's up to you!)

Yeah, I think we should make a different discussion topic on this. It wouldn't be super high on my list right now. I'm planning on working on the RTC time module and GPS time as my next PR.

This just occurred to me... If a LoRa repeater with an ESP isn't using ESP-NOW, there's no reason it couldn't listen for OTA updates with the WiFi modem (except the extra power use). Perhaps this is another reason for a USE_OTA flag: so that a gateway can use OTA even if not otherwise using WiFi/MQTT. It's a bit extra, so I'm not strongly attached to the concept. Thoughts?

Good idea. I just hate to have a device broadcasting a WiFi signal if it's not going to be utilized but for only a small amount of time. I think going down the route of only enabling WiFi access point if a button is pushed or SystemPacket is sent makes sense and then it would time out after a certain amount of time.

[timmbogner]

Thanks again, @aviateur17!