Reparse Protocol

Hi need to use Reparse Protocol to connect the Nextion directly to HM-17 BLE Module, without use arduino or esp chip.
Someone can help me to explain how to ‘read’ incoming bytes?


Can you please detail a little bit what it is exactly what you are trying to achieve? From the datasheet, that BLE module has an UART connection, so it should be able to communicate in the same way an arduino, esp or other MCU would…

Protocol Reparse mode is a very specific way of sending data to the HMI screen. Unless you have some special use case there shouldn’t be a need for Protocol Reparse mode…

Do you mean you already are in Protocol Reparse mode and want to access the data in the ringbuffer on the HMI? Please explain a little more, thanks.

Yes, i know that the Reparse Protocol is high specific.
But the HM-17 send out the raw data, that him received from bluetooth device connected to the him, to the serial port.

I want to capture this data, and “parse” the bytes (i know the message format).

I want to avoid an Arduino between Nextion and HM-17, because it’s no so necessary.

The Nextion have to send out specific commands to the serial, and read reply from the HM-17 module.

I search some tips to correct read/copy/clear from the serial-in buffer.

For example, i want to send thias command from Nextion to HM-17:

0x05 0x00 0x01 0x2 0x03

The HM-17 will reply with:

0x03 0x00 0x01

To tell me the operation successfull

Each command/reply has different lenght

Okay, that use-case indeed warrants the use of Protocol Reparse mode. The Nexxtion will behave as a MCU in this setup. I haven’t used this before, so I’m going off the information in the Nextion Instruction Set.

Here is what I set up as a proof-of-concept:

The button has this code:

  • b0

      // Enable Protocol Reparse mode
      // Clear fields
      result.txt="Waiting for reply"
      // Send Command
      printh 05 00 01 02 03
      // Enable TimeOut timer
      // Enable ReadBuffer timer

Create two timers with property enabled = 0:

  • tm0 Event:

      // The operation timed-out
      covx usize,buffersize.txt,0,0
      // Disable Protocol Reparse Mode (this clears buffer)
      // Status update
      result.txt="Command time-out"
      // Disable timers
  • tm1 Event:

      // Check the ReadBuffer
      covx usize,buffersize.txt,0,0
        // Status update
        result.txt="Reply received"
        // Data received
        ucopy data.txt,0,usize,0
        // Disable timers
        // Disable Protocol Reparse Mode (this clears the buffer)

The button enables Protocol Reparse mode (it clears the buffer) and then sends the command via UART.
It enables a ReadBuffer timer (tm1) and a Time-Out timer (tm0).

Depending if the expected number of bytes is received before tm0 runs out, you either get the result “Reply Received” or “Command time-out”.

The recmod is enabled and disabled with each command, which clears the buffer each time. If the BLE also sends data at random times, you need to keep the recmode active and clear the buffer using code_c.

I hope this helps. This is just my adhoc solution, so other options might be available. I’m curious of how this works in real-life. Please keep us informed!


Ok, thank you so much.
i’ll try it as soon as possible.
I make a video, when it’s finished.

1 Like

One other use-case I found for Protocol reparse mode is to turn one of my screens into a Serial Monitor. It will just spit out the serial buffer to the screen, so you can monitor what’s being sent. For example when booting an MCU.

Here’s a quick test run:

This runs standalone on the Nextion/TJC screen, so no MCU needed to drive the display. Just hook it up to a serial interface and watch the output scroll by…


fantastic…can you pubblish the code?


Sure, I also added a basic keyboard and a settings page, so you can send data too:


Here’s a TJC and Nextion version:


this is really interesting.
There are a couple of interesting devices (for my taste/projects) which can be controlled with RS232, so with a TTL <->UART RS232 converter Nextion should be able to handle communication without the need of an intermediate Arduino.

Yes indeed, the only limiting factor being the awkward scripting language. It doesn’t really let you write elaborate programs or you have to jump through lots of hoops and apply work-arounds even for the simple things.

I’m curious to which projects you have in mind and would be interested if you can share some results when finished.

1 Like