Start a new topic

Return codes of commands

From the Nextion Instruction Set it is not very clear to me if and what all command return.

i.e. Do the command like cirs or line return anything? What about command like com_stop or com_star? Are there returns when I use ".val= ..."

Can you shed some light on this please

Please refer to the Format of Device Return Data Tables in Nextion Instruction Set

There are varied responses based on setting of bkcmd (power on default of 2)

 - See #15 bkcmd in System Variables List

Running HMI in Debug Simulator will for the most part also simulate returns

 - (excluding eeprom, gpio functions, but very few others)

sending cirs in Instruction Input Area will also generate Nextion Simulator Return Data

0x71 is numeric Return for commands as

   get n0.val

where numeric data is being requested to be sent

A numeric assignment is not such a one.

0x01 success or code for why failed is expected with command as


Debug Simulator is fairly telling of Nextion responses

I was looking at that also.  To parse return values is a pain.  It would have been nice if the return values were in the escape area of the alphabet and not valid ASCII character.

for example:  get object.txt return 0x70 which is the letter p.  get object.val returns 0x71 which is a q.

So if your data has those letters in it you need to do some extra checking.


Mike don't see the answers as characters because they aren't. They are just numbers between 0 and 255. And some of those numbers have a special meaning. Its possible to see them as single characters but not very convenient.
@patrick So what you're telling me is to just experiment with the debug mode to see which command is returning what ... ? I was hoping for an extension of the instruction set documentation specifying what return values can be expected

Look, there is a simple means to working with Nextion Return Codes.

With the exception of 0x70 string data, they are all fixed length.

if 0x71(q) then you know there is 0x71 followed by 4 bytes and verify the three after this is 0xFF

 - you have an easy means to verify valid over any line noise / interference

if 0x01 then you know this return is only 4 bytes total, verify next three are 0xFF

Want a pain, TFT driver start up sequences, or SPI flash command sequences.

When your datasheet is above 1700 pages, now you have pain,

Nextion is very very few times that fix length isn't known by leading byte.

Waveform addt, eeprom, gpio exceptions


I am saying Debug Simulator quickly confirms most questions.

Yes, I am here so often, and yes, with an answer often within hours

 - and honestly, too many times Debug can

     - authoritatively provide answer in seconds, compared to hours.

     - such command in Instruction Input Area as a test is quicker than posting

So I am NOT saying just experiment, it is your means to debug an issue.

 - but it isn't going to spit out anything that isn't already in the Tables.

There is little to expand on what is not said in the Return Code Tables.

Unless it is

  - an eeprom rept response

  - user specific print/printh response

  - upload protocol

The Nextion will not return anything outside the Return Code Tables.

System variable bkcmd sets what you get from 0x00 to 0x23

  bkcmd=0, no debug type returns, so 0x00 to 0x23 don't come.

  bkcmd=1, each successful command sends 0x01 0xFF 0xFF 0xFF - all else not.

  bkcmd=2 (default) 0x01 is NOT sent, only failure sends 0x02 to 0x23 depending on reason

  bkcmd=3 0x01 if success else 0x02 to 0x23 depending on failure reason.

Sure, with print/printh and bkcmd=0 you can completely define custom protocol - did it.

Alternatively, you can get a logic analyzer, I love mine

 - takes more time to clip the hooks on - so unless I need exact timings - Debug is so easy.

How to expand

If I use command get t0.txt I am expecting string data

  0x70 (one byte for each char) ... 0xFF 0xFF 0xFF terminated

  or I get a 0x02 to 0x23 failure depending on reason of failure

If I use command get n0.val I am expecting numeric data

  0x71 0x01 0x02 0x03 0x04 0xFF 0xFF 0xFF little endian

  or I get a 0x23 to 0x23 failure depending on reason of failure

When should we expect a 0x23 failure code?

  when component name is longer than 29 chars

  14 max for pagename + "." + 14 max for component .objname

All of this is Nextion Instruction Set depending on system bkcmd setting

Patrick, your third paragraph was the answer i was looking for.... so on bkcmd=1 every command that doesnt ask for a value returns a 0x01 if successful... that was all i was looking for. If that is in the specification then i guessed i missed it

But that is clearly stated in #15 of the System Variables.

 ... of the Nextion Instruction Set

The explanation is also clearly printed above each Table

 ... in the Nextion Instruction Set.

Must have missed that part when reading it
Just reread it... and it is there. It just wasn't how i understood it. But maybe i can suggest you let a native English speaker review your text. I'm not a native speaker either but i find it to be interpretable in multiple ways. Anyway thanks for your clarification

1 person likes this

No issues.  No one retains total on first pass through - of any document.

Each time through the Instruction Set, you absorb a bit more.

- but mostly only what is either immediately relevant (for a problem) or interesting (for a possibility)

- the rest is always information overload, and needs yet another pass through   =)

Yes, I looked at the documentation several times and missed that to send a command you need to add three 0xff to the end of it and not just send a carriage return like you do in debug mode.  Once I spotted that I was good to go.

In most serial code the program is looking one character at a time and then responding or jumping to a routine based on that one character.  Having to receive several characters and save them so that it can look back to see what it should have processed is a little bit of a pain.  But that's what coding is all about.

Login or Signup to post a comment