As we are all more or less experienced Nextion HMI developers, we are familiar with the default operational mode of our displays: Without any additional effort, data which comes in over the serial port is parsed and interpreted as if it were one or more instructions in Nextion language, for example in a local TouchPress or Timer event handler. Furthermore, when preceded by commands like addt or wept, we can transmit data over serial bulk-wise towards a Waveform component or towards the internal EEPROM. Finally, when using the appropriate protocol, our Nextion handles even a complete firmware update without requiring us any action on the Nextion side. But what if you want your Nextion HMI to handle data streams which do not follow the Nextion protocol by terminating every sequence by the terminator 0xFF 0xFF 0xFF? What if bulk data arrives and is not intended to land either in a Waveform component or in the EEPROM? As always, many paths lead to Rome. You might feel inspired to write code for an external MCU (for example an Arduino or a Raspberry Pi) to receive or generate these "unsuitable" data streams, to filter and process them, and to send them out in an appropriate form towards a Nextion HMI. This approach is probably efficient and meaningful for complex data streams like CAN bus data where much information arrives at high speed but you need to display only a small subset of these. For simpler data structures, our Nextion HMIs have a less know functionality, called active parsing mode or protocol reparse mode as my Canadian colleague Patrick prefers to name it. It allows to handle and to interpret incoming data your own way, even in a Nextion standalone setup, without external MCU. With this short series of articles, I want to shed some light on this mode, show what can be (meaningfully) done with it and where it is (probably) better to avoid it.