Flashing ESP32 OTA via Node red + MQTT?

Hello everyone
I working on a way to update an esp32 firmware via MQTT. I have seen this example for ESP8266 with HTTP and this post without code, which is precisely about MQTT OTA to Esp32 from Node red, all mentioned in this other post. All are great tips to start but since these are over 1 year old posts. could there be any developments that are published but I'm not finding?
I can manage to send the whole bin file data to esp32, the trick I'm missing now is how to use this data to flash esp32.

Thank you.
Cheers, LuĂ­s Pereira.

I do not see how Node-Red could possibly be of assistance here, once at this stage... what you are looking for is custom OTA firmware to work with the alternatively downloaded data.

An OTA update of microprocessor code can certainly be "orchestrated" by Node-RED which is great for that.

There are 3 elements to manage

  1. Compiling the source code - you probably wont want to use Node-RED for this.
  2. A GUI to allow selection of the appropriate built code and the device to upload to - certainly Node-RED can do this in several ways such as Dashboard or uibuilder.
  3. The actual command that uploads a specific file to the device. Again, Node-RED can do this easily. The actual command may well depend somewhat on the framework you are using (if any). For example, I'm moving all of my ESP devices to use ESPhome (even though I don't use HA) and that has a command such as esphome upload m5basic01.yaml --device OTA to do the upload over WiFi. It is actually a Python prog and is easy enough to call from Node-RED using the exec node.

Interesting Julian - can i ask why you are moving to ESPHome rather than one of the other frameworks ?

I have just finished consolidating all of my stuff on Tasmota because i did not want to manage any more code base. Previously i had a mixture of Espurna, ESPhome, Tasmota, ESPEasy and some home grown stuff.

Craig

I've tried all of the frameworks and always hit the buffers somewhere and ended up wanting to do something they don't support.

While ESPhome isn't perfect, it does cover most things just with configuration, no code required. But where you do need to do something different, it has a couple of ways of integrating code very easily. You can include your own c++ file which gets compiled in and you have lambda functions in the config files.

ESPhome also has good facilities for including settings from other files. In conjunction with the fact that it supports a lot of different hardware, it means that I can have a single, flexible configuration base with all of the standard stuff in include files that work with lots of different platforms. I have 2 different types of ESP8266 and 3 or 4 ESP32 platforms that I am using it with already. If I were to add, lets say, a BH1750 light sensor and a BMP280 temp/humiity sensor to each of them, I only need to include the appropriate settings files and I get consistent MQTT outputs.

Also, 2 of my ESP32 platforms have display's built in and they are both supported directly by ESPhome with a standardised page configuration. So it is very easy to create multiple pages to show on my 3 button 320x240 M5Stack Basic. The ability to easily subscribe to MQTT topics and include those in the output also makes it pretty trivial to display data from all over the house.

It took a bit of setting up to get ESPhome working the way that I wanted and there are a few rough edges to ESPhome but it has been a much quicker move for me and has helped me produce a new generation of sensor platforms very quickly and consistently.

Of course, one final benefit would be that if, in the future, I wanted to use HA instead of Node-RED (yes unlikely I know) or if someone wanted help setting up sensors for HA, I have a standard, documented method that would let people quickly get their sensors going.


Oh, I also nearly forgot - the reason I looked at ESPhome in the first place was my annoyance with the excellent hardware but dreadful software for the 2 M5Stack devices I have (an Atom matrix and the Basic). These had been causing me no end of problems but work well with ESPhome with the 1 exception that I have an early Basic and the screen is colour inverted - I was easily able to go in and hack the ESPhome driver for the appropriate display to add another option with the screen colours inverted.

ESPhome even gives you an easy way to include new or override existing drivers.

1 Like

I do this for a bunch of ESP8266s. All I do from memory (as it was a long time ago that I implemented it, but it still works fine) is send a msg from the NR dashboard via mqtt to the device in question "advising" it there is a new firmware to pick up. The firmware resides on a web/file server. The device then puts itself into firmware update mode, picks up the file and reboots back into normal mode.

I wrote all the boilerplate code (not difficult), so no proprietary firmware is involved. The advantage of doing that is nothing changes in the dev process without you changing it.

I've yet to try on the esp32 but assume the ota framework is the same as for the esp8266.

Hi Bobo

Any chance of sharing that code? I alrady have the mqtt server part running on a raspberry for other issues, so once I get the esp8266 part it should be simple for me.

Thank you.
Cheers, LuĂ­s Pereira.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.