Start a new topic

NexNumber.setValue and getValue not working correctly when lenth attribute set

See test case attached: We have a simple NumberBox on a page. 'lenth' is set to '6' so that the max value you can input is 999,999. When setting values bigger than 99,999, getValue starts to return nonsense values, see debug output.

What's the cause of this and how can I workaround the problem?


+++++++++ 9 ++++++++++
recvRetCommandFinished ok
recvRetNumber :9
+++++++++ 99 ++++++++++
recvRetCommandFinished ok
recvRetNumber :99
+++++++++ 999 ++++++++++
recvRetCommandFinished ok
recvRetNumber :999
+++++++++ 9.999 ++++++++++
recvRetCommandFinished ok
recvRetNumber :9999
+++++++++ 99.999 ++++++++++
recvRetCommandFinished ok
recvRetNumber :4294936223
+++++++++ 999.999 ++++++++++
recvRetCommandFinished ok
recvRetNumber :16959


1 person has this problem

Sorry, the test case was missing...


(876 Bytes)
Now that the missing test case is provided: Anyone and idea, what's wrong with this?


999.999 is floating point - Nextion is integer based, no floating point.

Please have a look at the provided code and the HMI. I do set the values correctly. That's only the debug output, just printed strings. Can you reproduce it? I'm using the latest Nextion Editor V0.43, Arduino Library 0.9.0.


I cannot reproduce this effect on an STM32 F103 32 bit MCU.

But you failed to state what MCU this is being produced on

There literally 1000's and 10's of 1000's of MCUs.

The problem does not exist within the Nextion Editor - irrelevant which versions

The problem does not exist within the Arduino Library per se

  - it has .h files that give the definitions and .cpp that show the rendering.

As the .h file has provided the requirement the parameter needs to be a uint32_t

Then this absolves the Library from being the culprit

So looking at your code:

  Are you passing a required uint32_t as a parameter?

  in your getValue, it would appear you indeed are.

  but what about in your setValue?  what is this?

#1)  You deviated from convention - not sure why, but alas - code shows you did.

#2)  So many people are self absorbed in their own projects, you buried your details

   - are people suppose to spend the time to download and load these up just to look?

   (You're fortunate I was bored and my current project was closed allowing me to open yours)

   - I will not always download, you must state your questions without hiding clues

   - this is a public forum, many users could have answered, in 3 days you see there become

     few takers when you make a dump and fix that requires them to download to investigate.

#3) When you look for answers, search in the right place.

   - I normally don't try to find auto-parts in the produce isle.

     - Nextion is typically screen side of the RX/TX pair - HMI file (this forum)

     - Compiler is typically where you write your code (assumed to be Arduino)

     - MCU is typically what will run the code (most Arduinos are Atmel's - never assume)

     - sensors, various manufacturers of what you connect to

So if I do surveys at the produce isle for solid state drives

  MAY~be, someone may know and I get lucky

  But I am almost certain to get answers quickly and many of them if I am in a Computer Shoppe.

The answer to this issue is probably only twice (yours) on this Forum

- but probably has been answered 350+ times on Arduino Forum.

Again, I would perhaps try casting


Thank your for your feedback! I'm using an Arduino MEGA 2560 with an Atmel ATMEGA 2560 16 AU (8 bit processor). Nextion editor version is V0.43, Arduino library version is 0.9.0.

user post has been edited due to its offensive and unqualified nature ... we won't tolerate this

I have worked quite some time on other open source projects, and there it is quite normal to provide a test case if you think you have found a bug (so that others can check it). And note: The provided code above is not a project of mine (e.g. some kind of house automatisation app using the nextion display). It's a test case which isolates a problem since something does not work correctly for me.

But I don't want to digress, and to put it short: No, the code does not work for me on my ATMEGA 2560
  • NexNumber.setValue is defined as NexNumber::setValue(uint32_t number), see NexNumber.cpp line 31.
  • unit32_t is a fixed size inter type of always 32 bit, 4 bytes, independet of the platform (in contrast to normal C int's which size could vary, see )
  • NexNumber.cpp line 36 setValue converts the number to a string with 'utoa(number, buf, 10);'
  • But I think, this it already wrong. I had to change it to 'ultoa' which correctly converts the uint32_t, see
  • Moreover: Why is the buffer in line 33 only 10 bytes big? We are creating a string object so as to output it as a command to serial. The max value of uint32_t is 4294967296, these are already then digits, and the command-prefix in the string "objectName.val=" is still missing. So we are risking a buffer overflow, aren't we?
  • All in all I could make setValue work with the above changes, however getValue still returns rubbish although the code in NexHardware.cpp line 45 seems to be correct and ready for 4-byte uint32_t.

But I think I will put this simply on the bug tracker at github. This seems not to be the right place to discuss it.



@PatrickMartin: See . You could have also mentioned, that this issue is already known. Any idea for a work around? Where can I find the code which runs on the display side? Thanks!


An incorrect user coding error is not a bug. Sorry.

The code that runs on the Nextion display side is closed source.

The way to program is to code what is needed to obtain the desired the result

Not state what you have coded doesn't work and request to change firmware to fit your error.

I apologize, I overlooked the fact that you are using the Latest(Unstable) version 0.9.0.

As such, that library would be expected to have errors contained within - it is listed as Unstable.

Login or Signup to post a comment