Start a new topic
Not Taken

Component value assignments.


I am new to Nextion HMI display. I think it’s a very novel way to handle the interaction between a graphical display and a micro controller. The editor brings back memories from programming the Automanager Workflow environment in Dos and Windows. That experience reveals something about my age I think. Now before I get conditioned by working with this system I want to write about my first impressions.

It took me some time to fiddle out how to assign a value to a component. This was so simple that probably nobody thought to include it in the instruction documentation. I think the instruction list should contain an entry about “=” with some examples :-)

Digging deeper I noticed an asymmetry between the way the Nextion reports back to the micro controller and the way you can control the display with the micro controller.

For example:

Setting a number have to sent: n1.val = 123

Getting the number you sent get n1.val and this returns: 0X71+variable binary data(4 bytes little endian mode, low in front)+End

For integers you sent the value in ASCII and receive it back as a 32 bits integer.

The touch event reports back: 0X65+Page ID+Component ID+TouchEvent+End

So you have to use component names to sent a command but you receive the ID.

Using names for components and attributes is a wonderful thing in the editor but in the communication with the micro controller a real pain.

I feel that the commands to control the Nextion must be in the same format as the Nextion returns the data so that you can set an attribute by sending: 0x3A+Page ID+Component ID+Attribute ID+Value+End for a component and 0x3B+Page ID+Attribute ID+Value+End for a page. 0X3A and 0x3B are arbitrary chosen, take whatever comes handy.

To ease the maintenance of the component ID’s I think that the Editor must have a button that copies the Component name – Component ID list to the clip board like:

enum NextionComponents {
	pageMain = 0,
	btnCancel = 0,
	btnOk = 1,
	temperature = 3
} NextionComponent;
Now you can control the Nextion with a command like

Nextion1.set( pageMain, temperature, attValue, 21);

Some other first impressions:

I think that instructions like vis, tsw and ref should be replaced with attributes like visible, disabled and refresh.

Instead of returning 0X71+variable binary data(4 bytes little endian mode, low in front)+End with get n1.val it should return 0X71+Page ID+Component ID+Attribute ID+variable binary data(4 bytes little endian mode, low in front)+End to make sure to which page, component and attribute the value is referring too.

The reason is that when a user change the value of an alarm setting you now have to sent a button touch release event and the changed value (or ask the Nextion for the value), with the extra data you only have to sent the value with: get alarm.val (should really be named: return alarm.val) in the touch release event as the addition of Page, component and attribute make it clear which value has to be updated.

Now these are first impressions only :)

Hey Edwin and Welcome.

Yes, the Nextion does bring memories of DOS days back.  I attached cp437-32.zi for you to enjoy the DOS Font, although iso-8859 is not fully compatible.

One tip to keep in mind is that on your host MCU, when you receive notification from Send Component ID (beginning with 0x71) your host program now knows which component.  This HMI running on your nextion is of your design, so there is a reason why you sent the compID across the tx/rx wire.  Leveraging this to send get commands to systematically retrieve the values you need to deal with this event will help a lot.

serial.write('get t0.txt') will send string value (0x70) one number per character.  serial.write('get n0.val') will send numeric value (0x71).  Serial.Read will be able to retrieve that value before moving on from dealing with the compID touch event.

Examples are nice, check the Gallery section and the Free Chat section - you will see many examples come to the surface.  I am not the Arduino dude, so you need to refer to documentation in which ever libraries you are using.  Definitely fluid.


(3.53 KB)

Correction: touch events start with 0x65


Thank you Patrick for you warm welcome.

What I’m trying to achieve that the MCU updates global variables like temperature, position of a valve, alarm value etc in the HMI. The HMI displays these values on one or more pages. When a user wants to alter a setting like an alarm level, he changes this value in the HMI and sent back the altered value to the MCU when he presses the Ok button. The MCU then updates the variable in the HMI so the user can see that his the action was successful.

I think that the simplest solution is to sent back the value with an identifier which value has changed. I found out that you can make your own responses with the print and printh functions so I can use that as a workaround. I also found out I can use a timer to execute the update instructions in the HMI :) See my modulo example in this topic.

Just a note on modulo,

As your case stated the sign can be lost, shows it doesn't work in all cases (and thus not always reliable, and hence undocumented).

The challenge presented with the Nextion is the limited resources (as compared to desktops), and hence a nice hobby for the DOS dudes who were use to working with few resources.  I think that having graphics stored in flash display side of the Rx/Tx is a strength of the Nextion design saving valuable transmit time.

As programmers, I guess there are many ways to arrange the commands to achieve a goal.  I advocate approaches keeping the Tx/Rx wires quiet until needed when some event needs to be dealt with. Perhaps when the user is finished with their changes and satisfied with their value and has decided to commit to this value - then that is an event that must be dealt with by the MCU.  I also am satisfied with receiving the touch response without a value, as the bigger question becomes what values will I want, in some cases many values, others only one.  For me, to use the existing command allows me chose at that time to fetch what I desire.  Consider

catch message

  if message = expected_event1 then

     serial.write(get variable.att)

    .. other updating

    serial.write(get variable.att)

     .. as needed


  if message = expected_event2 then

     .. process as needed



The print/printh functions are flexible enough to create your own protocol, what bothers me is that I need to know that dual data is coming (as the hmi designer, I guess it isn't so difficult) and have to deal with the second message immediately rather than when I am ready. When I need to retrieve additional data to handle my event, is that all contained within my print/printh protocol, or has that wasted by Rx/Tx and I still need to fetches (Serial.writes/Serial.reads) regardless.  I suppose I could have designed the print/printh protocol to fit my needs.  So the difference becomes that using serial.write(get var.att) and all ready exists in the firmware and I don't need to use limited resources to implement it.

I do find the nextion is capable.  I recently put an example of setting six timers with two pages: list and form (at end or near end of thread here).  For me the plus is it only sends Rx/Tx when the user is committing to a timer value.  The rest is contained within the HMI.

I can say that it is interesting to see the many approaches to attain a result.


If you make your own protocol you can do this:

catch message

if message = newAlarmSetting then

alarmSetting=extractValuefromMessage(message) // retrieve value from message

serial.write(NexAlarmSetting.val=alarmSetting) // echo value back to Nextion


if message = expected_event2 then

   .. process as needed



Looks shorter to me :)

I guess I have become spoiled with an Intel Edison as a host, not needing to constantly look for space savings. I have 1GB of ram, 1.8GB of storage for my programs, 40GB of data storage over NFS, wifi, Bluetooth, on a stable Linux system with dual cores at 500MHz.  I sometimes miss saving a line or two.

I am now reviewing all of the Feature Requests, this will take some time, patience please.

Although this wasn't a real feature request, it is now marked as reviewed.

Future questions should be posted to the Free Chat Section.  That goes for you too Patrick

Login or Signup to post a comment