Start a new topic

ESP32 Hardware Serial to nextion enhanced 7.0

I'm having an issue where I cannot get my ESP32 to send commands (using Arduino sketch) to the Display. The ESP32 has an external power supply that is shared with the Nextion (5v 5A) So I believe they have a common ground. I have verified that the ESP32 is sending the commands by replacing the display with a USB to Serial converter and reading that on another COM port on my PC. I also verified that the display can receive commands when plugged into my pc using a USB to Serial converter. I can show my code if you need, but it is a stupid simple serial1.print + the 3 0xff

Well, perhaps seeing the code, eliminates software as the issue.


also, i was able to run the debug tool in nextion editor and use my MCU, it worked fine.


void UpdateTemps(){
  int currentAmbientTemp = round(ambientSensor.getTempFByIndex(0));
  String ambientActualUpdateCommand = "ambientTemp.val="+String(currentAmbientTemp);

void endNextionCommand(){


I have to assume this is just a snippet

 - I don't see an equivalent of a Serial1.begin() - so which baudrate?

 - I don't see a loop() equivalent - two functions but no call to is no code execution

 - confirm with your MCU documentation, but unless flash is internal as the 8285

   Serial1 is only TX1 (RX1 pin used for flash), perhaps all that you intended.

 - check your documentation, that Serial is the full hardware serial for RX/TX.

send over serial bkcmd=3ÿÿÿ - capture Nextion response

  - bkcmd=3 will be 0x01 0xFF 0xFF 0xFF on success, other if not

   Nextion Instruction Set - Return Data Format - table 1

ensure Nextion baudrate is same as MCU baudrate

Yes, sorry this is a snippet of a very long sketch. I apologize for that, but I have a bunch of passwords and stuff in it, and felt it was easier to just give the relevant info.

I created a debug sketch and uploaded (to rule out the other stuff). attached the file below.

Serial1 which is UART2 for the ESP32 and natively resides on GPIO16 and 17. it can be changed to any other port due to some IO-MUX thingy (that is the technical term, im sure)

I changed the baud rate of the nextion a few times for troubleshooting. I connect my PC to the nextion at 115200 COM4 and the ESP32 at 115200 COM6

Keep in mind, I have verified that It does send data over those pins (havent checked RX) to my computer so I have ensured that data is passing. even using the same wires that are currently hooked to my Nextion (to rule out bad wire/connection)

(1.03 KB)

ill run that command and report back shortly.

 I changed the loop to below, and get no response. im not 100% sure i have the code right for listening for a response though.

void loop() {
  int array[4];
  String testCommand("bkcmd=3");
   while (Serial1.available() > 0) {
      for (int i = 0 ; i < 4; i++) {
        array[i] =;


I just plugged the display back into my usb-serial converter and hooked it to the editor. its connected at 9600. I guess the baud rate change doesnt persist after reboot? give me a minute to change my sketch for the baud rate. ill feel pretty stupid if this is the case.

works perfectly... TX and RX...

is there a way to change the baud rate and have it persist?

*hangs head in shame*

Nextion generally will not lose its baud

 - but extreme rare cases - possible.

baud=115200 will not persist, bauds=115200 will persist.

In HMI bauds=115200 in page 0 Preinitialize Event means

  HMI will start up with this assignment - Nextion will run at 115200.

Also, beware delay(750) is a halt on this code line for 750ms and do nothing command.

included in every loop() iteration at 115200 baud, this can indeed lead to buffer overflows

 - 8640 bytes can theoretically be sent from Nextion in that amount of time

 - loop() code is mere microseconds before next long delay().

 - buffer is surely way less than this

You may want to consider putting Dallas into a "drive by reading" mode.

   read() reset() request() type algorithm and use a time offset as to when to pick up reading.

Seek out Dallas and OneWire on how to tweek Dallas library for this.

Indeed your reading would then be 3/4sec old by the time you have the reading

  but you wouldn't be blocking your MCU from code execution for other tasks

  - such as picking up bytes out of RX register and placing into buffer

     which is occurring at the end of each of your loop() iterations

I appreciate the insight.

there won't be a delay in the finished product. i use millis() to set the next RequestTemps() function. this was super broke down for testing. i will look into the "drive by reading" thing some more, as that may shed light on a better way of getting the temps. 

Out of curiousity which ESP32 board do you have?

ESP32 Thing by Sparkfun

Login or Signup to post a comment