Start a new topic
Not Taken

timers stops if the page is inactive

Timer run only when the side of the timer is active. This applies regardless of whether the timer is local or global.

Thus, it is not possible to use the timer for background work if the page is not active.

The only way is that each side has its own timer with the identical Timer Event.

This is very error prone and costs unnecessary memory.



OR an RTC chip which is now included on the Nextion Enhanced versions.


Without using Nextion Enhanced versions, a more accurate time, is to keep time on your connecting host MCU and only "update" the Nextion Display with the appropriate value as needed.  Especially when using a HH:MM format, it does not chew up significant resources.


It is possible to have a global timer function across pages with small inaccuracies by placing a time holder global variable on page0, and timers on each page.  Upon exiting the page just before page call, store final time value in this global variable.  In the loading page, in its Pre Initialization Event, retrieve the value from the global holder and enable timer on the loading page.  When exiting this now loaded page, again store current value to global holder ahead of the page change and again retrieve in the loading pages Pre Initialization Event.


With the introduction of the "click m1,1" command, it is even more possible to trigger events as long as m1 is global.


As far as unnecessary memory goes, using the connecting host MCU for critical time events and sending visual display string to the Nextion display is MOST efficient and always has been.  In the Identical Timer issues, if all timers are local in the method described above, there is actually only one timer in memory, as the leaving pages timer is discarded when the page is destroyed before new page is loading and this does not waste resources at all.

>>It is possible to have a global timer function across pages with small inaccuracies by placing a time 

holder global variable on page0, and timers on each page.


yes, this is possible for work with accurate time on each page.

But in my case, i dont need the timer for accurate time, rather to refreshing objects of other pages in the background.

See the concept pic here conceptPic


You are confusing your own design objectives with capabilities (and hence possibilities).


You CAN NOT refresh an object in a NON active page, without adding additional code in a PreInitialize Event of the loading page.  Order of execution:


PreInitialize Event

Load HMI design and set variables and objects to default of HMI design

PostInitialize Event

Wait for external events to occur (touch, receiving commands, timer, etc)


Every call to directly set gauge in non active page will be wiped out by your default values defined in your HMI design - UNLESS you include the code in the PreInitialize Event to store, and PostInitialize Event to retrieve and set to passed values (sys0, sys1, sys2 work well if values are numeric).


Since you are doing this PreInitialize and Postinitialize coding, you are in control.

But you most definitely cannot fetch 1000 values for waveforms.  Thus the logical choice is for the Host MCU to store these values (Especially since the DHT22 values are sent to the Host MCU).  Then when it becomes necessary to send data to update the WaveForm (because a user changed page to where the WaveForm is displayed - which you logically caught through using a "sendme" command issued in your Page0 postinitialize event so you would know when and what pages the user is wanting to change to), then and only then is it necessary to send the data across the wire to update the display to reflect the then current state.


The tools to accomplish all of this is already in the Nextion Instruction Set, including print and printh giving you the capabilities to create your own protocol.


The FUNCTION of Nextion is to overcome many RX/TX bottlenecks by having images fonts and some code stored on the Display Side of RX/TX and therefore avoid bottlenecking and update full screen pictures at ~8MHz (internal systick) rather than 9600 baud.  But first Nextion is a display, and not an MCU.


You have an MCU, and you are trying to push too much code responsibility of your project onto your Display rather than on your MCU which you have in hand.  Your host MCU has much more powerful libraries for programming capabilities (including floating point functionality) and yet your design attempts to get val from DHT to your MCU, and then push that value to the Nextion for storage, to be retrieved by your MCU to go back across RX/TX again to update another component.


For you to accomplish this on the Nextion without the RTC and EEPROM in the Enhanced Model, can be accomplished - but by the time you spent all the coding required in PreInitialize and PostInitialize Events, you could have easily accomplished 5 times with the better library located on your Host MCU and then use the Nextion as a Display updating when events required.



I would think that the conciderations for Feature Requests is for generic tools/commands that can be used across all projects, as the basic models, and thus the least common denominator is limited to 8K of Flash which 3584 is devoted to Nextion HMI and the remainder to hold firmware.  Bloating firmware will proportionately decrease Nextion HMI capacity.


So when you look at the Nextion Instruction Set, you will see most scenarios are actually covered by combining several commands in sequence to accomplish almost all given tasks.  It then becomes a selection and ordering of these for the individual goal to be achieved.  But that is a programming thing.   You have demonstrated in your modified WaveForm code, you have the ability to code well, and maybe you have not yet realized the power of each of the Nextion Instructions when combined.


Thx Patrick for your answer.


 >>You CAN NOT refresh an object in a NON active page, without adding additional code in a PreInitialize Event of the loading page.

 

 Thats right. Let me try to explain what I mean.

 

 I have a MCU and the MCU prints temperature to the NEXTION display.

 

 MCU communicate simple in this form:

 print_over_UART("page1.tempNew.val="+newTemp)  

 

 The Display has 3 pages (first-temp values, second values+gauge, etc)

 Every pages needs the new temperature if the temperature changed.

 

 The MCU sends temp to a global variable page1.tempNew.val

 The page1 has a second global variable page1.temp and a global timer tm0 and variables for interim results.

 In Timer Event from page1 tm0 i check if newTemp<>temp and if so, i update the object.val from other pages (not refresh)


 

if(dht1.tempNew.val!=dht1.temp.val)   //if temp changed
{
  dht1.temp.val=dht1.tempNew.val               //update global temp 
  dht1.tempIntN.val=dht1.temp.val/10           //integer 
  dht1.tempDecN.val=dht1.temp.val%10           //decimal
  cov dht1.tempIntN.val,dht1.tempIntS.txt,2    //string for int
  cov dht1.tempDecN.val,dht1.tempDecS.txt,1    //string for decimal
  dht1.t0.txt=dht1.tempIntS.txt+","+dht1.tempDecS.txt   //make complete string for temperature on page1
  dht2.t0.txt=dht1.t0.txt                               //update temperature on page2 
  dht3.t0.txt=dht1.t0.txt                               //update temerature on page3
  dht2.z0.val=dht1.tempGauge1.val                       //update gauge on page2
}

This works fine, see my HMI

But, because the timer on page1 stops if the page1 not active, i need another timer with the same Timer Event on each page. 

This is not so good, but it works.


You can test the HMI in the debugger  on page1/page2 or page3

tempNew.val=300  //set the temterature on all 3 pages to 30,0Grad

humNew.val=500   //set humidity on all 3 pages 


Sorry for my bad English. I hope you understand me anyway


HMI
(834 KB)

@Patrick

>>But first Nextion is a display, and not an MCU.


Display there like sand at the sea. Many cheaper and perhaps in better quality.

But displays with an MCU and a scripting language there are few, and they are much more expensive.

And therefore, first Nextion is an MCU with a scripting language and also a good display;-)


Evaluations, Analysis and Light Critiques:


Humidity gauge on dht2 should be positioned at x,y (85,149) to match outer edge gauge, inner dot should be adjusted slightly lower.  Angle 0 = 20% humidity, angle 180 = 100% humidity.  80 points 20 through 100 in 180 degrees.  Gauge markings every 2%, 180/80 reduces to 9/4 therefore humidity in % for 1/2 mark on gauge is humidity *9 /4 ...   HOWEVER, the gauge markings are not even with 20-40 being larger than 60-80 and 80-100 is smaller yet ... the graphic designer is going to make you work hard for an accurate humidity marking.


Temperature Gauge on dht2 has to deal with negative values where angle is below -22

32 degrees C in 90 degrees, but is evenly spaced.  Calculations are much easier.


NOTE: Usage of overloading assignment statements is a wrong approach and will catch you off guard with bugs you cannot explain, likewise the undocumented % (modulo) is undocumented as it has flaws and does not work in all cases.  ANY division is whole number result only.  Floating point not supported.


Your Timer on DHT2 is set to 20 times per second. Your gauge a max of 50C.  In any real situation, the only need to track temperature every 50ms is in case your house is catching fire, then there may be changes occurring each 50ms, but then your gauge should maybe reflect 3200C or 5600C depending on the contents in the house.


Place m2 hotspot on dht2 out of the way (I would choose 5x5 size in inconspicuous place)

Place variables temp and hum on PageConfig as global numeric

Place va0 numeric variable on dht2

In m2 Hotspot on dht2 Touch Press Event (5x5) and invisible if desired


if(pageConfig.hum.val>19)

{

va0.val=pageConfig.hum.val-20

va0.val=va0.val*18

va0.val=va0.val/8

z1.val=va0.val

}else

{

z1.val=0

}

if(pageConfig.temp.val>-23)

{

va0.val=pageConfig.temp.val+22

va0.val=va0.val*45

va0.val=va0.val/16

z0.val=va0.val

}else

{

va0.val=0-pageConfig.temp.val

va0.val=va0.val-22

va0.val=va0.val*45

va0.val=va0.val/16

z0.val=360-va0.val

}

cov pageConfig.temp.val,t0.txt,0

cov pageConfig.hum.val,t2.txt,0


when it changes at sensor send

hum.val=22

temp.val=17

click dht2.m1,1


IF the above is sent from host MCU when sensor changes, no need for timer on DHT2

IF user is NOT on dht2, no need to update the click dht2.m1,1


A similar timer issue on dht3.  Time in WaveForm is 50 data points per hour or every 72 seconds, yet timer is set to go off 180 times every data point.


Markings on the Waveform account for temperatures from 0 to 40, so calculations should be 256/40

To add a new temperature when 72 seconds elapses

But this add will have to actually be added from your host MCU to load the 299 datapoints that will not show the last 6 hours when user changes into the dht3 page.  Since the 300 points are sent from your Host MCU (and you proved you know how to send a set of 100 data points) it makes most sense for your host MCU to issue the needed add every 72 seconds .. timer not needed on dht3 and adding to confuse your design


To accurately reflect on Waveform,

if temp (value at Host) > -1 and temp < 41 then

addvalue = temp * 32/5

when needed issue add 3,1,addvalue


For humidity, your WaveForm goes from 0 to 80, it again is same calculation in the add

IF hum (value at host) < 81 then

addval = hum * 32 / 5

when needed every 72 seconds issue add,3,0,addvalue


Note markings on waveform do not match markings for humidity gauge on dht2

Adding a similar Hotspot on dht3 will allow you to update Humidity and Temperatures in t0 and t2

using a click m2,1 ... as needed issued from host. -- when user is on dht3


Adding a similar Hotspot on dht3 will allow you to update Humidity and Temperatures in t0 and t2 using a click m2,1 ... as needed issued from host. -- when user is on dht1


On pageConfig slider min value should be 0, as dim=0 is valid and used to decrease power consumption

pageConfig PreInitialize Event


the use of cov bauds,t0.txt,0 should be using baud and not bauds just to avoid possible conflict calling a current value from baud, verses a set as default bauds.


In each page, you have a print ":state:#" printh ff ff ff

I get that this is your page number being sent


using the command sendme will accomplish the same

The Nextion sends: 0X66 0X02 0XFF 0XFF 0XFF  every page change once sendme command received. 0x66 - data following is page in response to sendme command.

0x02 - means page with id number 2 has been selected - in your case dht2 has pageid 2

0xFF 0xFF 0xFF - data terminator, as you are accustomed to already.


So your MCU would already know what page your user is on, and can respond to ONLY the needed changes and updates issued from your MCU.


Hope some of this is helpful to you.

=)  Nextion is a beautiful piece ... but even though it has some functions in firmware, I would refrain from trying to implement it as a scripting language.  In actuality, the Nextion Editor is the interpreter for what you have typed.  It is the editor that parses and HARD CODES those instructions into the TFT.


NOTE: an HMI object can not be moved across the screen, its x, y, w, and h are permanent once defined in the HMI and no attempt at changing this during runtime will succeed.  Hard coded.  So RAM is precious, flash is not user writeable except for what is allocated in the HMI up to 3854 bytes.  Even in Enhanced Models, only an addition 1024 bytes of EEPROM.  So the objection to firmware bloating causing less to be available to the resource starved HMI user, every byte gained by firmware is a byte not accessible to program with.  Some function makes your HMI no longer function in the new version because you have no more RAM available to your page.  Your title.txt no longer functions as title is now too long and depletes HMI available RAM.  Your programs become less powerful as you cannot implement what you wanted to.  Most recent change to buttons strips another minimum 6 bytes .txt length for no reason on every button.  So, one day you will see why I fight for those bytes.


Many users want variable width fonts - that will most likely require 1 or 2 bytes extra per character, where these bytes will be found?  who knows.  What gets gained in efficiencies becomes spent in waste.


Maybe if code was movable, if restrictions weren't 3584 bytes, if the microSD card became user writable and accessed the full 32 Gigs of what we want with great flexibility - but sadly this is not the case.

CORRECTION: in Humidity calculation for waveform there are 2 percentage point, thus 32 * 10, my error.


IF hum (value at host) < 81 then

addval = hum * 32 / 10

when needed every 72 seconds issue add,3,0,addvalue

@Patrick

Thank you very much for your efforts. You have certainly sacrificed a lot of time for the analysis of my scrappy HMI.


First, the HMI ist only a test example to gather experience with the display. NOT A REAL PROJECT (yet).

My intention is, to program the display, so that it can use with arduino or raspberry etc. with a minimum of changes and without specific libs.

And I think that's quite possible.

But for that simple functions such as mapping etc. must be programed on the display.


>>Humidity gauge on dht2 should be positioned at x,y (85,149)

yes, the design is bad yet, see above.


>>NOTE: Usage of overloading assignment statements is a wrong approach and will catch you off guard with bugs you cannot explain, 

>>likewise the undocumented % (modulo) is undocumented as it has flaws and does not work in all cases.  

>>ANY division is whole number result only.  Floating point not supported.

Yes, unfortunately. I hope, that common basics like modulo(%), Parentheses, multiplication and division first, then addition and subtraction etc. be corrected  in future versions.


>>Your Timer on DHT2 is set to 20 times per second

Yes, yes;-) I just wanted to see if the display has problems with meny events. But so far I can not find any problems.


>>Place m2 hotspot on dht2 out of the way

Interesting, I'll try.


>>when it changes at sensor send

>>click dht2.m1,1

Just things I would like to avoid;-)


hum.val=22

temp.val=17

should be enough


>>last 6 hours when user changes into the dht3 page

Yes, in current form is not practicable. 

As long as it is not possible, to use the SD card for storing data, makes no sense.

Currently i have a timer on the MCU wich every 72sec sends with add-command.

But I consider to use an array of the last 300 values at the MCU to fill the waveform with "addt" when the page changed.


>>On pageConfig slider min value should be 0, as dim=0

That's right. But I wanted that the user can still see the slider;-)


>>the use of cov bauds,t0.txt,0

thx


>>In each page, you have a print ":state:#" printh ff ff ff

>>I get that this is your page number being sent

On the MCU i use a state machine and a "page change" must generate a "state change event". sendme sends only a number and the SM cant recognize that this is a page.  


Please don't misunderstand the break down as some sort of attack


As you stated that you are new and are still learning some of the commands and their use, to show you some examples and notated why or why not should be useful.  I could have attempted such in analogies and examples that had nothing to do with your project, but using your project provides you with a base of familiarity and possibly easier to see the connections put into practice.


Have fun coding.


Correction

>>sendme sends only a number and the SM cant recognize that this is a page.  

I have just found, i can use CURRENT_PAGE_ID_NUMBER_RETURN 0x66 instead.


As others read these boards looking for solutions, I am going to add for correctness


I stated:

> In each page, you have a print ":state:#" printh ff ff ff

> I get that this is your page number being sent On the MCU

> using the command sendme will accomplish the same

> The Nextion sends: 0X66 0X02 0XFF 0XFF 0XFF every page change once sendme command received.

> 0x66 - data following is page in response to sendme command. 0x02 - means page with id number 2

> has been selected - in your case dht2 has pageid 2 and 0xFF 0xFF 0xFF - data terminator

> as you are accustomed to already.


You responded:

> I use a state machine and a "page change" must generate a "state change event".

> sendme sends only a number and the SM cant recognize that this is a page.


For correctness:


If a connecting host MCU does not receive the bytes coming in over Rx/Tx from the Nextion, the functionality of the communications will break.  Therefore only two choices exist.  Choice one is to send that data into a black hole where it will be read, ignored and cleared (much like the linux port /dev/null when programming for the Internet protocols).  Choice two is to receive the incoming data, interpret and respond.  So a choice is being made to keep communication lines functioning.


You state your State Machine does not recognize this as a page. You are capturing the :state: as a page, so you are already receiving the data, interpreting and responding as you see necessary.  Choice 2.


Capturing ":state:0" as page 0, and ":state:1" as page 1 is implementing interpreting in your code already.

Nextion sends in hex "66 00 FF FF FF" as page 0, and "66 01 FF FF FF" as page 1, where hex 66 is ascii lowercase "f" ... and the only time that hex 66 occurs as a leading byte value is ONLY when the next byte represents the page ... means that interpreting this data and setting a state machine to page 0 or page 1 is easily accomplished. 


It means the mechanism is already in the Nextion Instruction Set and did not need to be reinvented.


Okay, so you have posted just before me.   You have found the sendme in the Instruction Set and the corresponding Response codes.


Just NOTE: that the page response does not start automatically.  It will only start after the "sendme" command has been received and processed.  A good place to put this if you know you will always be using it throughout your design is in PageID 0 (pageConfig in your HMI) PreInitialize Event - add the line

sendme


Another NOTE: once sendme has been received and starts sending the Page Response there is no command to rescind it, it will always send.



Login or Signup to post a comment