Start a new topic

Inventarisation of requests

Hello Nextion design team,

I am very happy with this concept, but... After hacking a few days with the displays (see the Gallery), I have a list of requests. Some are already mentioned, but necessary for a good and fast design in the nearby future.

1. Use for all communication between the displays and mcu ASCII codes messages. The decoding of the (the binary coded) feedback from the display to the mcu is a crime. Whats the reason not to use ASCII here also?

2. Make it possible to use the symbolic names of the objects. For example the waveform object: add mypage.mywaveform 1, 0, 55

3. Make the range of indicators and controls between 0..100%, porting the design to another display is much more easy.

4. Make it possible to use transparent parts in images. For example: define in the Nextion Editor a specific color for transparency and don.t update the pixels with that color. I think it's very easy to implement and helps a lot (see earlier discussions).

5. The waveform object knows multiple channels, Do the same for gauge objects (see the proposal of your own design team member) so we can add more indicators (clock hrs/min, gauge with min/max indicators) in one gauge.

6. My students would like a joystick to control their mobile robots. Multi-touch is not necessary, a filled circle flowing your finger and returning the x- and y- coordinates (preferable 0..100%)

7. Save the the compiled results (.tft files) in the (current) project directory.

I hope you can implement those request, I let you know in the future.

Thanks and regards...



2 people like this idea


8. The current mode for the waveform is "sliding", the whole graph is shifting to the right, the new data is added on the left. It would be nice if there is also a mode "overwrite", first data left, next data behind each other to the right (like an oscilloscope). Reference lines in another color?

2 people like this
After a year of other projects, I started again with the Nextion displays in the hope that real progress was achieved. In the forum I see often the same requests. If the Nextion team also wants to participate in the professional field (and not only in the Arduino/hobby sector) it have to change their philosophy. It's a pitty of such a good concept. Make it open software and a lot of people wil help the team to make it perfect.


1 person likes this

Wijnand Nijs

I would like to refer you to the Free Chat topic HOT or NOT: Open Source ...

So when given the opportunity to influence an open source initiative with the ear of the owner

what happened?  A few people posted, and there is few if any lines of code.

Nextion Editor / USARTHMI is not theirs to give to open source. 

So we as the users would have to be willing to do work to give our work away for free.

And somewhere around there it falls silent.



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

8) Left-to-Right, Rigth-to-Left, Right Align - has been implemented and bugs fixed in 0.40

7) all tft's across multiple versions are in the same bianyi folder, backups for previous version  in backup folder

6) sendme is only solution for coordinates currently (I recall the joystick request)  xc,yc - variables requested

5) Layered gauges still an issue, multi needles - requested

Analog Clock possible with three hands via GUI and lots of coding

4) Transparency 1555 is being advocated - will break much existing code

3) Component byte range offers higher resolution, % achieved via code.

2) waveform over serial by compID to save bandwidth for keeping waveform most efficient

    - waveform add command requested to use va0.val value parameter.

1) Some ascii messages, data format is hex - enhancements requested

So this is where this stands.  A review of requested features is currently being undertaken.

I think the ASCII vs. binary issue depends on the MCU programming language you are using.  When using assembly language, binary is much easier to work with than ASCII.  If I could just send a binary number to a numeric component instead of having to program logic to decide whether to send a "-" sign then send each digit, my life would be much easier.

However regardless of the above I think it should be consistent.  To me the best approach would be to make it settable via a system variable.  Set the system variable one way and all communication (in both directions) is ASCII... set it another way and it's all binary.  And maybe there could be a third setting where data going to the Nextion is ASCII but returning is binary, to maintain backward compatibility.



The ascii/hex issue is with the Nextion Debug Simulator Return Code values being returned in non human readable Hex.

The requests made in this post are already being considered.

However Eric, you bring an interesting point not previously made.

Please create a new Feature Request for your point, so that it isn't lost.

Will do!


Login or Signup to post a comment