Getting Pellet Stove display messages to home assistant via UART decoding

[jazzmonger]

First I put an old NodeMCU ESP8266 in action and hooked up GPIO16 to the RX line of the displays UART wire coming from the MCU. I also hooked up my oscilloscope to this line in the hopes it would show me the waveform and give me a clue as to what the baud rate is.

here's the trace

2400 baud looks plausible. The smallest wave form (a bit) I measured looks to me to be about 400us in length which is really close to the 2400 value in this table:

esp8266:
  board: nodemcu

logger:
  level: VERBOSE #makes uart stream available in esphome logstream
  baud_rate: 0 #disable logging over uart

uart:
  id: uart_bus
  tx_pin: GPIO1 #D1 to tx pin on mcu board
  rx_pin: GPIO5  #D1 turns out is the only pin I could use to sniff data.  Fine... swap them and move on.
  baud_rate: 2400
  rx_buffer_size: 80

  debug:
    direction: BOTH
    dummy_receiver: true
    sequence:
      - lambda: UARTDebug::log_hex(direction, bytes, ' ');

Now you stare at data streams and try and figure out what it all means.

I started with the data line going from the display to the MCU. This seemed easier as the data from the MCU was a jumble of info. Basically 3 temp sensors sending continuous updates, and all the various status messages.

pressing the power level buttons on the display cycle P1,P2,P3,P4,P1,P2,P3,P4,etc and watching the data stream gave me repeatable results which translated into this:

That was enough of a clue to decipher all the main functions the display could send.

Now I turned my attention to the data stream from the MCU to the display. That gave me this

The rest of the messages are the 3 temp sensor updates which I don't care about since the TuyaMCU gives us those in all the datapoints.

The next step is to take each state change and put it into a table in home assistant that can be matched on lookup and then used in Lovelace to show what the stove is doing in real time.
Why? Why not! The engineer in me likes to see what the equipment is doing before or during a failure. And this pellet stove fails a lot.

For example, the random dreaded "Goodbye!" Message can now be immediately recognized in the UART data stream and fixed (turn the stove back on right away) inside an ESPHome routine instead of waiting for the room to cool and comparing temps and then fixing it in an automation in home assistant which may or may not be reachable or functional.

[jazzmonger]

So, all my initial findings about the data in the posts above were basically all crap. But it got me started. After staring at HEX all day, I've discovered that the display unit controls everything. The MCU brain controller just does what the display unit tells it, sending and ACK msg after each relevant command along with sending update on the 3 temp sensors once per second.

Here's the spreadsheet w/ all the final data points that matter:
https://docs.google.com/spreadsheets/d/1m9CPk7aLwiysgwgC_VOkevEM1vgZ2OK64gpq-gSBXlM/edit?usp=sharing

I now need help getting this info into home assistant. I'm not a programmer (hack at best), so unsure of where to start. I think I need a table or array of hex values and how they map to display messages. Once the lookup finds a match, a text sensor could be defined that exposes its value to home assistant. Easier said than done!

This looks promising as it processes HEX data (the only one I've found to date) and that's what I'm doing @mulcmu
https://github.com/mulcmu/esphome-ge-laundry-uart

Im just loathe to start as these rabbit holes consume multiple days and hours upon hours of troubleshooting. And lots of stupid questions posed by yours truely on Discord.

[mulcmu]

So after a quick review the goal is to create sensors for the UART data sent between the display unit and MCU brain. This data isn't exposed on the serial connection used by the ESPHome Tuya MCU component. The ESP8266 will tap into the UART data sent from the display to the MCU. The UART data will populate one text_sensor with the data highlighted in yellow above. Am I following along okay so far?

[jazzmonger]

Yup, that's it! My head is just spinning trying to comprehend custom components and c++... Why do I long for Visual Basic at times like this? :)

[mulcmu]

I would recommend the uart-debug-hack approach summarized here.

The logic would look something along these lines. I didn't test this but gives example of how to evaluate the hex data with a bit of error checking to arrive at which value to set the text_sensor to.

uart:
  baud_rate: xxx
  tx_pin: xx
  rx_pin: xx
  debug:
    direction: RX
    dummy_receiver: true
    after:
      delimiter: [0xCC, 0x33]
    sequence:
      - lambda: |-
          UARTDebug::log_string(direction, bytes);  //Still log the data
          
          //Some packets have 5 bytes  //might have to make this 3 if delimitar bytes get removed....
          if (bytes.size()==5) {
            if(bytes[0]==0xAA && bytes[1]==0x00) {
              //4B heartbeat, ignore
              if(bytes[2]==0x6A)
                id(rawString).publish_state("Goodbye!");              
              if(bytes[2]==0x69)
                id(rawString).publish_state("Cleaning");
              if(bytes[2]==0x63)
                id(rawString).publish_state("Cleaning Error");
              if(bytes[2]==0x65)
                id(rawString).publish_state("Lighting");
              if(bytes[2]==0x66)
                id(rawString).publish_state("Stabilization");
              if(bytes[2]==0x67)
                id(rawString).publish_state("Stabilization");
              if(bytes[2]==0x62)
                id(rawString).publish_state("Switching OFF");
              if(bytes[2]==0x67)
                id(rawString).publish_state("Cooling");  //same as Cleaning????                
            }
              
          }

          //Some packets have 6 bytes
          if (bytes.size()==6) {
            if(bytes[0]==0xAA && bytes[1]==0x01)  {
              //... similar logic for the ECO
            }

          }

[jazzmonger]

Ok, I added a text sensor to hold rawString. I hope that was correct...

and just to test the heart beat I added:
if (bytes.size()==5) {
if(bytes[0]==0xAA && bytes[1]==0x00) {
id(rawString).publish_state("Heartbeat");
//4B heartbeat, ignore

text_sensor:
- platform: template
  id: rawString
  name: text_sensor
  on_value:   # When value simply changes
      then:
        - logger.log: 
            format: "text_sensor = %s"
            args: ['id(rawString)'] 

and the output changed to string.

[12:57:16][D][uart_debug:158]: <<< "\xAA\x00K\xCC3"
[12:57:16][V][text_sensor:016]: 'text_sensor': Received new state Heartbeat
[12:57:16][D][text_sensor:067]: 'text_sensor': Sending state 'Heartbeat'
[12:57:16][D][main:294]: text_sensor = (\"@ �\xff?�
[12:57:16][V][json:031]: Attempting to allocate 512 bytes for JSON serialization
[12:57:16][V][json:051]: Size after shrink 84 bytes
[12:57:17][D][uart_debug:158]: <<< "\xAA\x00K\xCC3"
[12:57:17][V][text_sensor:016]: 'text_sensor': Received new state Heartbeat
[12:57:17][D][text_sensor:067]: 'text_sensor': Sending state 'Heartbeat'

and my sensor is now

[mulcmu]

Try removing the delimiter. Looks like that strips off two bytes from the packet that would make the packet size ==5 or ==6 logic fail.

    after:
      delimiter: [0xCC, 0x33]

Can change the debug output back to UARTDebug::log_hex(direction, bytes, ' ') instead of log string too.

[jazzmonger]

see my edited reply. I think I'm on my way! Im not in my shop and cant press buttons, but I can send new Power values, which are 6 bytes? each pair of digits is treated as 1 byte...

I was a little confused at first by the 6 byte pkg:

if(bytes[0]==0xAA && bytes[1]==0x01)

I think this is right:

EDIT: Got it!!

         //Some packets have 6 bytes
          if (bytes.size()==6) {
            if(bytes[1]==0x01 && bytes[2]==0x4A && bytes[3]==0x00) 
              id(rawString).publish_state("P1"); 
            if(bytes[1]==0x01 && bytes[2]==0x4A && bytes[3]==0x01) 
              id(rawString).publish_state("P2"); 
            if(bytes[1]==0x01 && bytes[2]==0x4A && bytes[3]==0x02) 
              id(rawString).publish_state("P3"); 
            if(bytes[1]==0x01 && bytes[2]==0x4A && bytes[3]==0x03) 
              id(rawString).publish_state("P4"); 

HUGE Thanks @mulcmu. All I needed was the right syntax, a liittle HEX primer and then a little push!

I'm curious why I was directed to build and use a custom component for this by one of the devs? Seems like that approach just adds complications.

EDIT: For completeness, heres the final debug config that completely echos what the display is says is going on:

  debug:
    direction: RX
    dummy_receiver: true
    after:
      delimiter: [0xCC, 0x33]
    sequence:
      - lambda: |-
          UARTDebug::log_hex(direction, bytes, ' ');  
          //Still log the data     
          //Some packets have 5 bytes  
          //might have to make this 3 if delimitar bytes get removed....
          if (bytes.size()==5) {
              if(bytes[0]==0xAA && bytes[1]==0x00) {
              //id(rawString).publish_state("Heartbeat");
              //4B heartbeat, ignore
              if(bytes[2]==0x6A)
                id(rawString).publish_state("Goodbye!");              
              if(bytes[2]==0x69)
                id(rawString).publish_state("Cleaning");
              if(bytes[2]==0x63)
                id(rawString).publish_state("Cleaning after Error cleared");
              if(bytes[2]==0x65)
                id(rawString).publish_state("Lighting");
              if(bytes[2]==0x66)
                id(rawString).publish_state("Stabilization");
              if(bytes[2]==0x67)
                id(rawString).publish_state("Stabilization");
              if(bytes[2]==0x62)
                id(rawString).publish_state("Switching OFF");
              if(bytes[2]==0x67)
                id(rawString).publish_state("Cooling");                
            }              
          }
          //Some packets have 6 bytes
          if (bytes.size()==6) {
            if(bytes[1]==0x01 && bytes[2]==0x49 && bytes[3]==0x80) 
              id(rawString).publish_state("Stabilization"); 
            if(bytes[1]==0x01 && bytes[2]==0x49 && bytes[3]==0x81) 
              id(rawString).publish_state("ECO2"); 
            if(bytes[1]==0x01 && bytes[2]==0x48 && bytes[3]==0x80) 
              id(rawString).publish_state("ECO1"); 
            if(bytes[1]==0x01 && bytes[2]==0x48 && bytes[3]==0xC0) 
              id(rawString).publish_state("ECO2"); 
            if(bytes[1]==0x01 && bytes[2]==0x48 && bytes[3]==0x83) 
              id(rawString).publish_state("ECO1"); 
            if(bytes[1]==0x01 && bytes[2]==0x48 && bytes[3]==0xC3) 
              id(rawString).publish_state("ECO2"); 
          }
text_sensor:
- platform: template
  id: rawString
  name: display_text_sensor

[mulcmu]

Looks good!

I'm curious why I was directed to build and use a custom component for this by one of the devs? Seems like that approach just adds complications.

The custom component gives you better control over reading and processing the RX data. Using the debug lambda is a hack to access and process the data without the effort to implement the custom component. It seems to work well when the UART data has delimiters or big pauses between data so that the packets can be processed consistently in the lambda expression. There are lots of UART custom component examples but it still adds another source file and C++ language elements beyond the typical Arduino sketch syntax. The processing logic in the debug lambda and the custom component would be pretty similar.

[jazzmonger]

Sound like I should go that route. Is there a tutorial somewhere that I can follow to convert it now that it's working? https://github.com/jazzmonger/uart-HEX-sniffer/blob/main/uart-sniffer.yaml

[mulcmu]

If the current code works reliably then I don't see a lot of benefit to convert it. The UART traffic isn't high speed and all the packets end with the 0xCC 0x33 sequence so the uart after: configuration can split the data nicely and process it consistently. This example would be the most concise for custom text sensor from UART data. It is text oriented. This example would give you an idea for what would need to be implemented to assemble the hex data and then process the packet. All the packet assembly stuff you basically get for free when using the debug hack approach.