Start a new topic

I need an explanation of a statement

As i am 2-3 day old on Nextion programing , i did not have time to read all the tutorial or watch all the hundreds YouTube video.

And in fact is not a full tutorial for real time clock.

I read one which was posted here but i stil do not understand some statements like:


wd.txt is a field i get it

page0 of course is page 0

Now is the hard part:

That "b"after page zero.

and also, why we add 13 to the rtc6.

In fact what is rtc6?

Reading here i understand that




rtc3= hour



I did not found mentioned rtc6 yet.

And again, what is the "b"after page zero ?

Thank you

 sorry Ion, but it seems that you neither read my answer in your other RTC thread, nor didn't you even open the link I provided you nor did you even open the attached screenshot I provide you ...

RTC6 is explained there very clear ...

Posting the same answer multilple times wouldn't prevent you from reading ... and posting the same answer does not mean you have less to read ...

Things you ask for are already answered a few times, even in your own thread ...


(302 KB)
(944 KB)
Sorry Gerry for trouble,
But as mentioned in my post, my experience with Nextion is not bigger than 3-4 days.
It is happen to forget, or just not paying to much attention and skip over.
It is too much info to retain in such short time.
I will search twice next time.


honestly, to read carefully saves you finally much more time than ask again and again for already answered ...

to ask for something real unknowen is good and valid. But it should be the last step and not the first in your approach to find a solution. 

And again, every answer is only as good as you also read it and absorp the offered information. That's indeed something you must do ...

we will help, but we also have not a lot understanding for users showing that they even didnt read our answers ... 

that just waste a bit our time, and maybe another user is happy when we have this time leftover to answer his questions ... or not?


If you find the answer post it here - to me it makes no sense.


If rtc6 is the week of the year as the documentation suggest ('rtc6, week;') there must be at least 13+52 (a year has 52 weeks)=65 buttons on page 0 (assuming that buttons are always labeled b followed by a number).

If rtc6 is the day of the week as the example suggests I think it is clear that wd.text shall contain the weekday. And that b13.txt contains Monday, b14.txt Tuesday and so on (if the weekday starts with Sunday it is different ofc.).

The string 'b' is the object type, a button in this case.

The Numbers '13', '14' etc. is the object id. - The object ID has nothing to do with the object name. And as such, it depends on the order that you added the buttons to the project.

What I understand:

You can access all objects by it's name, and some object (buttons: yes, text: no) by it's id. This allows you to create something very similar to arrays. The index of that array depends on the object id (the object id depends on the order the components were added to the HMI project).

I would never recommend to implement such a logic on the Nextion display other than for demonstration purposes - it is just not manageable in the long term.

Thank you Maze


Sorry Maze,

   but Ion please disregard Maze.

I finally got it.
They are 12 variable for month, and variable 13 is the first one for the week.
They took the whole page variables as an single array, and b represent the element on the array number.
Thanks god they did not use a multidimensional array :)
What is hard for as is because the array was not declared on the start or comments so we can know how to deal with it.
The week start with 0 AKA Sunday. Common RTC setting. My PIC18F87K90 start wit 0 = Sunday.
But that one it is joy to read it.


There is no ambiguity to be had

  - spend just a moment to read the documentation

    and then spend just a bit of play time

How hard is it to put n0 component on canvas

  and then in Nextion Debug Simulator assign it rtc6?

Debug -> Operation -> Nextion Simulator RTC Calibration.

Today, right now, still Sunday for most

  what does this little play experiment reveal

     rtc6 is 0 ... Sunday  

My basic version code on line 88 and 89

     if rtc6 == 0 is  Sunday

Downloadable testRTC.HMI

    Page 0 preinitialize code

        Sunday is wd0.txt="Sun", wd0 is .id 13

There is no ambiguity to be had


  when testRTC is run on either Debug or Device

    indeed weekday shows in placeholder of wd Text component.

b is not for buttons.  no 65 buttons  b is not for buttons.

If you don't have an Enhanced version Maze

   check facts before making things even more confusing

If you do have an Enhanced version Maze

   then check facts before posting conflicting info.

Others will read, be accurate for the 1000 that follow. Atleast try.

Assuming this and that ... wrong conclusions.

How if you read the thread and examined the provide code/HMI

  does it make no sense?

what is the structure called when the square braces [] is used?

   - anyone?  it is an array.

An array of values is not a complicated structure, is it?


Hmmm, and from the results

   The Yet-to-be-Documented B[ ] Component Array

oooh, perhaps this could be a relevant thread ... at least maybe.

Circle back to this one after reading the thread and see if there is any

   real questions about the b[.id].attribute component array

So there is no button b13.txt   b[13] is Component with .id of 13

  - Variable Component with .sta String  

It is not the order they are added to the HMI project

It is their order of their .id numbers

 - changeable with the "Bring Top" and "Bring Bottom" toolbar arrows.

  - visual in the Attribute Pane component dropdown list.

Next I will deal with implementing the logic Nextion side

  what an uninformed statement .... I'll shed some light momentarily.

I would never recommend to implement such a logic on the Nextion display

other than for demonstration purposes - it is just not manageable in the long term.

Thank you Patrick


The Enhanced Nextion has an onboard RTC

 - because of the Nextion interpreted code

   this is not as fast as a full access I2C implemented RTC

 - it may perhaps take 2ms to warm up and access for write.

- Second point is that the Nextion side timers is also

   indeed interpreted code, so a 1000ms timer is not driven

   by an interrupt, but its behaviour is more close to a

   1000ms delay started after timer code has completed.

I will indeed argue that Nextion's RTC is implemented

   within Nextion logic, Nextion side of the RX/TX demark.

When the purpose of the code Nextion side is to give a

   human operator a sense of time of day, this is indeed

   something that makes sense for Nextion side Logic

Even with the delays of interpreted code, the task to display

   is finished before the commands to do so over TTL Serial

   have even arrived to the Nextion.  With display over TTL

   serial methodology, even after such commands arrive

   to the Nextion, they would still need to be processed from

   then buffer on the triple 0xFF command termination and

   is then processed by ... none other than interpreted code.

So implementing it within Nextion side logic removes all the

   added delays of travelling across serial and buffer handling

   time .... both will be implemented via interpreted code.

The values of the Nextion RTC are driven by standard RTC

   with standard RTC crystal on Nextion's back side.

This is not some atomic clock, but standard RTC with all the

   inherent nature and drift behavior, with one exception.

   - native I2C handling done by firmware, much faster than

     by Nextion's interpretive code.

But the application to display daytime to HMI operator via RTC

   isn't timing for Olympic World record in 10µs accuracy

   - it is however as accurate as an RTC as RTC is the source.

     (without delving into that Alien's vs Quantum debate please)


   To say that such logic should never be implemented Nextion side

other than for demonstration purposes and not manageable?

That would be to say that whole HMI should not be Nextion side

as the HMI is made from exactly Nextion logic Nextion side.  It is

as manageable in the long term as the HMI is. 

  - when the testRTC.HMI was examined, it even contained a

    fully implemented means for manual adjustment

  - all RTCs will be argued that adjustment becomes necessary at

    some point, some just sooner than others, including MCU side

  - the included manual means of adjustment in no means

    prevented synchronization via code (as if slave to source)

Having an MCU remain in control has nothing to do with the MCU

delegating in proper fashion to any subsystem.  The fact that RTC

is indeed such a subsystem independent of the MCU, then any and

all uses of RTC is such a delegation.

So where is RTC source (Alien's vs Quantum debate), it matters not

if standard RTC with all of its inherent flaws is MCU or Nextion side.

The fact Nextion side eliminates slower over Serial implementation

and introducing further inaccuracy and flaws is a pro for Nextion

Management of a subsystem is programming, for RTC ... called sync

Managing serial traffic on slow 115200 baud lines is also a necessary

design consideration when the Nextion is a TTL Serial two wire device.

As the Nextion is an Human Machine Interface device

 - The Nextion is more obviously equipped for touch and visual

The Nextion should be responsible for Human Inputs and Status

The MCU should be responsible for evaluating requests

   - provide user with "now valid" choices and options for selection

   - deciding if request is valid and safe to execute at this time

   - execute only if safe to do so

   - provide operator with status of decision and progress

So if time of day is not such a status, ...  ahhh, ... really?

Sorry, but try this (the button b0 in this code example has the id 2 and txt "foobar"):

Once this code is run all b0, t0 and t1 will show the same text "b0_id2".
And of course this code gives the same result:

For me it looks like buttons are stored in an array, and accessible like an array index. If you never ever change the amount of buttons in your project it might work, otherwise you'll have the wrong starting index for your array somewhere in the code. This is my understanding and I still consider it not manageable.

when you say "not manageable for me" I can agree ... :-)

but as a generic statement ... no ...

the fact that you dont know how to manage, does not mean it is not manageable ... ;-)

Sorry Maze.

You still have not understood the b[.id].attribute Component array 

  - not what it looks like, but rather what it is

Page canvas component of every page is .id 0

Component .id of every component

  - just simple sequential array (hence use of [ ]) of Components

Read about the component array

   The Yet-to-be-Documented B[ ] Component Array 

Likewise the p[pagenum] index will not be an array of pictures

  and is combined into p[index].b[id].attribute p[0].b[2].txt

(refer to keyboards code by unlocking keyboard page)


   able to be managed, controlled, or accomplished without great difficulty.

Management is not understanding, maybe requires understanding

What management of the RTC becomes unmanageable?
 - within Nextion logic once synced ... runs
What is the management of this that becomes unmanageable?
 - resync will need to occur at sometime
   rtc5=32ÿÿÿ  seconds now resync'd.
Oh product just made new country new language
   Preinitialize needs to change from one to another



 could even be dynamic set from MCU side.

Regardless of 1000 languages change one spot of code
  - or send via serial to update until next reboot.

Even manual setting of the RTC via an included page

So what part was it that is unmanageable?

Which is easier for code maintenance
  reviewing crazy if then else for each 19 names
     find line, make change without typo
  or change variable holding name for static/dynamic ability

What was unmanageable?

Honestly. I'd rather write a very long if clause that is re-usable on every HMI with copy-n-paste - instead of messing around with button id's.

@Patrick/Gerry: If you think it's a brilliant idea using buttons as arrays just because they are accessible by an index (their component id) I can't agree.

Login or Signup to post a comment