Start a new topic

.TFT Update, OTA (WiFi ESP8266) from remote Server.

Hello Everyone,

Further to efforts earlier this year in,

Firmware Update without Nextion Editor?

I had an idea to move this up a level or two, and try to implement an OTA solution that essentially could be fully automated. Freeing the end user from any business with device updates.

Today I can announce achieving the first leg of that goal. I've modified a sketch by Markus Sattler using his ESP8266HTTPClient class library. Many thanks to Markus for your excellent work.

Running on the ESP, we can call a remote Apache server for our new .tft file.

Then we poll an update connection to the Nextion Display over serial, and stream the new data. Data transfer speed is dependent on baud rate, the wifi appears to have no issues so far. After successful download, Nextion reboots to the new HMI. Simples (actually it wasn't :) 

I'll make the source code available.

Let's discuss....


1 person likes this idea

Allright, everything is working and uploaded to the project page here.  The example code from indev2 was really helpful and the HTTP routine is largely intact (although itself taken from an example, yay open source!).  I've done away with all the delay statements, and am checking for return values on each block before proceeding.  I'm not issuing the "connect" command as this is a fixed-case setup and also because I'm lazy.

The result is that an Arduino sketch that can connect the Nextion to any MQTT-enabled automation platform, and you can issue an MQTT message to the device telling it to update along with the URL from which to fetch the update.  The result thus far has been fast and reliable.

Thanks again for the help Patrick and indev2!

SUCCESS!  My plans to develop a clean-room implementation hasn't really worked out as I kept hacking away at indev2's provided example while working it into my own code.  The result is currently extremely ugly, but IT WORKS!  Thanks to indev2 and Patrick for jumping in to help here, I think I can get this sorted out and presented in something approaching a usable manner.

DOUBLE THANKS to indev2 for sharing his code with a permissive license, I don't think I could have made this work without the example you provided.


For the whim I'll set up some tests to see where the code might be failing. You are right in that it doesn't wait for any kind of acknowledgement before pushing the upload, and perhaps that is the answer right there.

Just to make doubly sure that Nextion is pre-configured with the correct baud, upload the bauds=115200 with another file prior to executing this method. 

I'll be back later with my findings. 

"Your output was showing you further ahead than you are reporting now."

That's what had me confused - it turns out the code posted here in the thread doesn't wait for a response from the panel until after everything has happened.  The "connect" and "whmi-wri" strings are sent but isn't called to look for a response, nor is it called after every 4k chunk.  So it sends the commands and then starts pushing TFT data to the panel without ever checking to see if the panel has acknowledged any part of the transaction, which is why my output is showing things happening but the panel never goes white.

In manual testing the panel does in fact show the firmware upload screen when I send it the command, so it's working in concept.

This is OK, it's just my own misunderstanding about the nature of the example posted here.  Now that I know that it is incomplete I can start on my own clean-room implementation (although I'm going to copy the HTTP download stuff, that's too handy to pass up).

You would have had, or should have had the white screen earlier.

Your output was showing you further ahead than you are reporting now.

connect is your first command to Nextion,

so if you do not get a response from this

there is no need to issue a whmi-wri.

If you are getting a response, it maybe a timing issue.

Ensure you are allowing your ESP to wait for Nextion to catch up

I'm not getting the white screen at all which tells me the whmi-wri command isn't being received for some reason.  I was working from your example posted here but I think it might help me understand things better if I start from a clean slate.  I'll try to put some code together and post here if I have further questions.

As always, I really appreciate the help from the community here, and I hope to give back a working implementation that can be used by others in their own projects!

Hey Steve ...  !!!! 

The man that discovered the b[ ] array!

2 people like this


This from 8 months ago states......

"Hi Everyone,

Just to bump this back up the list so to speak, I did refine the code and got it working as I'd originally envisaged.

The 0x05 issue is solved and the whole thing runs as fast as your Nextion will allow.

Timings showed that once the first block was in, the process ran with an average return ack (0x05) time of 21ms per 4k chunk.

I also did some work on file serving from another 'remote ESP8266'. Using the 3MB of Spiffs available on chip. I can send the .tft from an ordinary web browser for storage and serving as you would do with something like Apache on a PC. Technically you could get the file from anywhere on the Internet. Using a key on Nextion the Update can be called on demand, all very seamlessly and fuss free.

I hope we can now generate some interest here :)

Steve. "

The code as posted was an early development release, but it does work.

If I remember correctly some models of Nextion would require a Power Off/On cycle after upload to get the new .tft to run.

By the sound of things you are 99% there, the code is counting the 0x05 ack's as it should, so connections would appear to be OK. Your just missing the 0x88 right at the end.

Is the white .tft upload screen visible during the process?

1 person likes this

Well, indeed indev2 completed this for the ESP8266.  But indev2 did not make his source open-source.

I am also sure it was done by a few other members for ESP and again not open-source.

I've done in other languages and other platforms, but again, sorry not open source.

You have the two most important documents for doing so.  I prefer my programming in pascal.

Understood and agreed on the commercial users, their code is their code.  For my part, I'm developing an open source/open hardware platform to provide an MQTT gateway for Nextion devices to allow users of common IoT platforms to interact with Nextion panels through MQTT messages.  As such, I need to use code with open licenses or figure it out myself :D

As you probably know, every microcontroller comes with it's own quirks, so the question was specifically centered around successful implementations of OTA code upload using the ESP8266.  To the best of your knowledge - has this been done?

For any other developers out there writing open software, if you have any examples of a successful upload routine I'd be very interested in any direction or hints you might offer.  I've been looking at the provided Upload Protocol documentation and Arduino library but haven't had much luck getting it to function correctly on the ESP8266.

To be clear

- the Upload Protocol is Published, and most exacting

  (the 0x05 after all data, was perhaps ambiguous = after each 4K and at final).

Hundreds have accomplished this for commercial use.

Working code - generally is by commercial endeavours.

 - for which of 10,000's of chips and 100's of programming languages?

So really it is more for users to implement as per the Protocol for their chip and language

   and less likely commercial endeavours give the work they paid for away for free.

1 person likes this

Reading through the code I'm seeing the same. A is never issued after each block to check for a response.

Has anyone worked out functioning code for OTA panel updates from an ESP8266?  The discussion above suggests it's possible but I wonder if I'm chasing ghosts and there doesn't appear to be any publicly-posted working code.

So re-reading the thread.  I think the code copied and pasted was pre handing of the 0x05 bytes.

Therefore if your uploaded TFT didn't run afterwards - it wasn't a success.

Have others been able to make the code provided by indev2 above to work successfully?  I've copied and pasted the code as provided, changing the SSID, WPA password, and http: file url leaving everything else untouched.  I've wired up a WeMos D1 mini per the sketch, with the panel on RX/TX for hardware UART and an external serial interface connected to D6 (GPIO14) to monitor the process.  The file downloads and the process reports a success but the HMI is never applied and I never get receive the "Nextion Upload Success !" message shown in the example above.  

Here is a link to the serial output I receive when running this script:

Other details:

  • The panel has had "bauds=115200" applied so it should be running at the correct speed.
  • The target TFT file I'm looking to flash is able to flash using the Nextion editor process which suggests it should be correct for the panel.
  • Issuing a "connect" command via serial (outside of the sketch) returns the response outlined in the update process docs. 

Login or Signup to post a comment