Further to efforts earlier this year in,
Firmware Update without Nextion Editor? http://support.iteadstudio.com/support/discussions/topics/1000062718/page/1?url_locale=
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.
As always I love a good discussion.
What size TFT, or is it passing bytes from webserver straight through to the Nextion device?
Welcome, I've just got this working a few hours ago, file is 187KB. Streams from the server, split to 4096 chunks on the ESP and straight on to Nextion. I guess the acid test will be something in the MB range.
The project is an add on to Andreas Spiess' great work on remote updates. In fact I'll probably invite him over here, as it would nicely complement his current project see...
Okay, so I have that kind of thing happening with several databases on an Intel Edison.
The limitations of an ESP 4M being limited to a 2 MB TFT delivery for the Nextion is concerning.
My ESP8285 is limited to 1M, so this equates to a 1/2MB TFT at best.
And of course the Edison has 1.3 GB to spare, so hold multiple versions for the 32GB enhanced is viable.
There should be a means to have a minimal pass through overhead on the ESP
to deliver a full 32MB file to the Nextion device.
If the update fails to notify the ESP so that it can maybe jet a response via email, twitter, whatever going "help me, update failed".
It should be able to retry the TFT update without needing to store the whole TFT before transfer. Timing would be important to not interfere with the Nextion transfer.
Then again, an ESP with a microSD would be able to house the TFT for download, as well as use it when it comes time to update the Nextion.
Have you found the upload specs posted on the Itead Blog?
This was provided for the Commercial customer to ensure timings are correct.
I would like to know the timeout value between 4K chunks.
They would be some nice features to include, and the main reason I'm throwing it in here for development.
Sending twitter responses is beyond my scope at the moment.
One big problem, is that upload failure doesn't (to the best of my knowledge) invoke a response code of sorts from Nextion, so how will ESP deal with that ?
Maybe a workaround is to fire a command of sorts and check the return right after the upload.
In this implementation nothing is stored on ESP, as you rightly point out SPIFFS is limited, although I tinkered with that method also, and it's a good route to go for smaller files. SD would also be a viable option. It's a case of tailoring you needs.
The upload specs, I deciphered from the Itead library over on github
There is little change from what has been discussed on earlier posts.
cmd = "whmi-wri " + filesize_str + "," + baudrate_str + ",0";
I'm currently testing the chunk delay at 350ms, and getting mixed results, can't say if it's bad bytes going to Nextion or delay too short. One thing though, the upload always delivers 100% byte count, and Nextion confirms, just sometimes it's won't work because of DATA ERROR!
The response to know if upload is success goes something like
all_is_okay := true;
for each full_4K_chunk
send each of the 4096 bytes
wait 500ms timeout
if 0x05 byte not received
all_is_okay := false;
// handle last partial chunk
send each byte in final partial
wait 500ms timeout
if 0x05 byte not received
all_is_okay := false;
// test upload successful
if all_is_okay = true
I can get a clean upload response like this actual HEX reply capture, and it still fails occasionally.
Guess we can only check with a command/reply !relpy at the end of the routine.
1a ff ff ff 1a ff ff ff 1a ff ff ff 1a ff ff ff .ÿÿÿ.ÿÿÿ.ÿÿÿ.ÿÿÿ 63 6f 6d 6f 6b 20 31 2c 33 38 30 32 34 2c 4e 58 comok 1,38024,NX 34 38 33 32 4b 30 33 35 5f 30 31 31 52 2c 36 38 4832K035_011R,68 2c 36 31 36 39 39 2c 44 33 36 33 33 43 31 32 45 ,61699,D3633C12E 33 33 35 32 36 33 37 2c 33 33 35 35 34 34 33 32 3352637,33554432 ff ff ff ÿÿÿ 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 05 . 00 00 00 ff ff ff 88 ff ff ff ...ÿÿÿˆÿÿÿ
One thing to note though, I don't currently check for the 0x05. It was a case of build the basics to get it working. I'll build that in next and let the code determine the chunk delays.
Yeah, early discussions in that thread it is going back to days before v0.33.
At that time, people were designing the HMI in the Nextion Editor and putting the TFT onto the TJC version hardware. The tools created were to work with the chinese TJC firmware which used "tjchmi-wri" and the early Nextion used the "hmi-wri". So they had their tools to be able to do the upload and swap to what was needed by whichever device was being loaded.
This was usually always Nextion Editor TFT -> TJC Hardware.
Up to and including v0.32, the only distinction for an HMI design was
- pixel width x height
- landscape vs portrait
- factory firmware wasn't being altered with a TFT update
Since version v0.33 and forward, many things have changed
- most of the firmware is updated in the TFT upload (remnants remain that are not)
- each model is defined
- few more mechanisms to prevent the TFT going on the wrong model
With these new mechanism, that thread gets few hits anymore as they are not having success
Are you inserting the ff bytes? or are these being returned by the device?
00 00 00 ff ff ff is a nextion reboot (this is not, but is present on all device resets)
88 ff ff ff is a nextion bootup success (this line is in Nextion Return Codes)
Just confirmed this is the return codes on a nextion device reset
- So this is your confirmation if the entire TFT was successful.
Good to know what those last codes are. Thanks for that.
Currently weaving in an 0x05 check.
Hope we get a few more folks on this.
How goes your checking?
I am having to rebuild a new serial component to suit.