Start a new topic

Challenge - not all page elements getting updated

Hey gang.  I have a sizeable weather project that updates approx 25 page elements (weather values, and weather icons mostly) every 15 minutes.  I find that during each round, some values fail to update while others get updated.  I understand that the Nextion will auto update values when updates are sent.  However, this is not happening all the time.

For example:  I am sending:

current temp, current humidity, and feelsLike values directly from a JSON pull.  The Serial debugger shows these values changing, and they are getting sent to the Nextion, but not all updating there.  Current Temp has remained the same after 3 iterations (even though it changed).

Thoughts?  Is there a need to do some sort of page refresh after each update?  

It depends on the code, possibles?

... overloading the serial? 

Nextion is interpreting your HMI at runtime and may not have been given the time to react

...  baudrate is low?

put a text component on the screen named br and run following to display working baudrate

sendCommand("cov bauds,br,0");

...timings of your loop to send values ... how much time between iterations?

Are you merely dumping all the values to the Nextion ?

  or are you tracking last value on MCU and only sending value when changed?

As far as page refresh, if using Nextion Editor above v0.38,

   every change to a component triggers a component refresh

Thanks Patrick.  A few comments:

- baud is set at 115k

- refresh happens every 15 minutes - so iterations are far apart

- not tracking last value, just sending all for every iteration and expect the Nextion to just update all.

- Im using Editor 0.41

I am currently testing doing a page refresh before my code refreshes all the values. I'll see if by clearing all the values back to the default fixes the issue.  Not pretty, but may do the trick. I'll report back.  My other though was do I need to have some sort of delay between sending updates to the Nextion over Serial?  i.e.

myNextion.setComponentText("tLastUpdated", observationTime);


myNextion.setComponentText("tTemp", currTemp);


And you are certain that serial between MCU and Nextion is dormant between interations?

A delay=100 on Nextion side pauses all for 100ms.  Rather you might want delay on MCU side.

[ removed next to posts ]

Info sent.

So here is my quick MCU question that you may already know the answer to

Does the ESP MCU you have, does it have a Hardware UART? 

Which Pins, how does Arduino address it ... as "serial"? or other?

Steve helped me with this last week over on this thread.  I'm using (hardware) Serial1 to send data to the Nextion.  Pins D4 for TX, and using the Serial RX pin to receive responses from the Nextion (which is working). I understand that Serial 1 only has the TX pin, and the RX pin is shared.   Do you think my Serial debugging may be interfering with the Serial1 comms?

Yeah ... I am going to read Steve's thread, he is the goto guru for ESP

I was aware that the MCU had like 1 1/2 UART.

Since Debug never sends to the MCU (or does it?)

My thoughts go towards me wanting to use the 1 TX pin for Debug

and the  RX/TX pair for the Nextion ....

But I think there is a naming convention in Arduino where it wants

Debug named as serial and the other UART serial1/serial2/serial3 etc,

- this may be down deeper in the board definitions.

My ESP8266 just recently arrived and I haven't been able to play yet.

But if you are on hardware serial (I'll read the thread), my thought that SoftwareSerial

might be interfering becomes moot.

(You have a fair number of code lines, takes me a while to read C)

Hi guys,

If using Serial1 for your Nextion, then yes make sure it's not being used for any other traffic, debug or whatever. Part of the reason I started using that line is that we can steer clear of ESP's boot data dump

which goes out at startup on Serial0, and being hardware, it's more robust than using Software Serial.

I've had similar issues to those you describe Dave. Even sent a component refresh to some items that should not require it to patch a fix so to speak.

Since using Serial1 however, everything appears to be working as it should.

Patrick can forward your code privately, if you'd like me to take a look.

I've always got a spare NodeMcu doing nothing on the desk ;)


Thanks Steve. Patrick, feel free to fwd my project along to Steve. As an aside note Steve, I turned my debugging off and there are still cases where components don't update. One that is consistent is tLastUpdated.



Hi, I've had a little time to briefly review your project code.


Some observations that I would consider changing are....


Putting all your static print strings in the (F(string)) wrapper, I see a lot is done already but there are hundreds of bytes to go. With such a text intensive app this could give you some breathing space.


Leading straight on to the Json strings, there are well proven methods to do the parsing on the fly (as it's being downloaded from the server).

Daniel Eichhorn has done some great work in this area. See

His json-streaming-parser should be of particular interest to you.


If you can streamline your app with just these two things to start with, I think you'll be on your way to something much more stable.


I can't see any obvious problems with your Serial set up. Perhaps when you get running again you could hook up an FTDI or similar to Serial1 and do an analysis of the output strings. By that I mean that they all conform to being valid instruction strings for Nextion, and that there is no other data contamination going on. If some responses need to be triggered by a Nextion event, then leave Nextion TX connected to ESP's RX, hit the appropriate keys and see what's happening back on the SM.



Thanks for the tips Steve. Question. I am not sure I follow where you are suggesting I put the F(string) calls? Is this for my serial debug statements, or the set component calls to the Nextion?

Any fixed text strings debug or otherwise can be called from Progmem with  (F(string))


Whilst we're not short of SRAM @ 80KB on ESP it's good practice and doesn't affect performance.

Stuff like


Big waste of SRAM !


Nextion serial analysis.

A typical serial capture would produce something like this...   

tt0.txt=""ÿÿÿtt1.txt=""ÿÿÿtt2.txt=""ÿÿÿtt3.txt=""ÿÿÿtt4.txt=""ÿÿÿtt5.txt=""ÿÿÿtt6.txt=""ÿÿÿtt7.txt=""ÿÿÿtt8.txt=""ÿÿÿtt9.txt=""ÿÿÿÿÿÿtt4.txt="SSID = XXXXX[00]"ÿÿÿtt6.txt="PASS = XXXXX[00]"ÿÿÿtt8.txt="WSIP =[00]"ÿÿÿtt0.txt=""ÿÿÿtt1.txt=""ÿÿÿtt2.txt=""ÿÿÿtt3.txt=""ÿÿÿtt4.txt=""ÿÿÿtt5.txt=""ÿÿÿtt6.txt=""ÿÿÿtt7.txt=""ÿÿÿtt8.txt=""ÿÿÿtt9.txt=""ÿÿÿtt0.txt="WiFi connected"ÿÿÿtt1.txt="IP address:"ÿÿÿtt2.txt=""ÿÿÿtt3.txt="WebSocket Connected.."ÿÿÿtt4.txt="Welcome. Server Ready 3 "ÿÿÿt3.txt="Power OFF"ÿÿÿt3.bco=63488ÿÿÿtt4.txt="Welcome. Server Ready 3 <p0> "ÿÿÿtt4.txt="Welcome. Server Ready 3 <p0> "ÿÿÿtt5.txt="<iDCC++ BASE STATION FOR "ÿÿÿtt6.txt="ARDUINO MEGA / ARDUINO MOTOR "ÿÿÿtt7.txt="SHIELD: BUILD Sep 14 2016 "ÿÿÿtt8.txt="15:46:03> "ÿÿÿtt8.txt="15:46:03> <N 0: SERIAL> "ÿÿÿtt8.txt="15:46:03> <N 0: SERIAL> "ÿÿÿtt9.txt="<Via WI-FI ESP8266> "ÿÿÿtt9.txt="<Via WI-FI ESP8266> "ÿÿÿb22.txt="Online Please

 If I copy/paste that to notepad and insert the cr's after the 0xff's we get something we can read....


tt4.txt="SSID = XXXXX[00]"ÿÿÿ
tt6.txt="PASS = XXXXX[00]"ÿÿÿ
tt8.txt="WSIP =[00]"ÿÿÿ
tt0.txt="WiFi connected"ÿÿÿ
tt1.txt="IP address:"ÿÿÿ
tt3.txt="WebSocket Connected.."ÿÿÿ
tt4.txt="Welcome. Server Ready 3 "ÿÿÿ
t3.txt="Power OFF"ÿÿÿ
tt4.txt="Welcome. Server Ready 3 <p0> "ÿÿÿ
tt4.txt="Welcome. Server Ready 3 <p0> "ÿÿÿ
tt5.txt="<iDCC++ BASE STATION FOR "ÿÿÿ
tt7.txt="SHIELD: BUILD Sep 14 2016 "ÿÿÿ
tt8.txt="15:46:03> "ÿÿÿ
tt8.txt="15:46:03> <N 0: SERIAL> "ÿÿÿ
tt8.txt="15:46:03> <N 0: SERIAL> "ÿÿÿ
tt9.txt="<Via WI-FI ESP8266> "ÿÿÿ
tt9.txt="<Via WI-FI ESP8266> "ÿÿÿ
b22.txt="Online Please Continue..>"ÿÿÿ

  Which in my case is the expected output from my ESP all as legitimate instructions.

Login or Signup to post a comment