logo elektroda
logo elektroda
X
logo elektroda

TuyaMCU analyser - UART packet decoder for Tuya devices - unknown packets

Samezrp1 204 6
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
  • #1 21333968
    Samezrp1
    Level 13  
    Howdy,
    I am sitting on a new device: Carbon Monoxide (CO) detector. Details once there's something to present, for now I'm stuck on the communication between the MCU and the TuyaMCU.
    A dedicated BA45F6746 from Holtek is used as the MCU for detection, with display support. A CBU is being used as the TuyaMCU. Datasheet attached.
    Block diagram of carbon monoxide detector with components. .
    MCU handles display, sensor, status and failure LEDs, test button, alarm buzzer.
    The TuyaMCU handles the battery status, WiFi LED, reset button + one more, as yet unidentified signal (I'm betting on a CO detection alarm).
    The rest of the communication is over the UART:
    The illustration shows the pin diagram of the Holtek BA45F6746 microcontroller in a 48 LQFP-A package with connections for Tx1 and Rx1 to the CBU module highlighted. .

    The problem is that between the circuits, the communication goes through messages that are unknown to me.
    Below are examples of these. After switching on the device, 3 packets each go on Rx and Tx and silence. I am very much asking for help in possibly understanding them:

    Rx
    07 
    55 07 03 01 00 00 60
    55 07 03 01 00 00 60
    55 07 03 01 00 00 60 07 00 00 00
    
    Tx
          AA 13 00 18 00 0A 01 36 00 00 02 8B 00 00 00 01 01 
    55 FA AA 13 00 18 00 0A 01 36 00 00 02 35 00 00 00 01 01
    55 A4 AA 13 00 18 00 0A 01 36 00 00 01 E4 00 00 00 01 01
    55 52
    
    .
  • ADVERTISEMENT
  • #2 21335394
    p.kaczmarek2
    Moderator Smart Home
    According to the topic:
    TuyaMCU protocol - communication between microcontroller and WiFi module .
    The TuyaMCU header is 0x55AA, the next byte is the version, generally 0x00 or 0x03.

    In your case it is:
    55 07 03 01 00 00 60
    This does not look like TuyaMCU.
    In addition it is:
    55 07 03 01 00 00 60
    55 07 03 01 00 00 60 07 00 00 00
    I don't see a length byte (or two bytes) here, as long as these are whole packets....

    Let's check here:

    55 A4 AA 13 00 18 00 0A 01 36 00 00 01 E4 00 00 00 01 01
    while 13 is the length, 13 in hex is 16+3 = 19, doesn't add up anyway.... unless it's the whole packet that has 19? And not the payload?

    It could be a different protocol, for example in the case of this device it was:
    Reverse engineering of the unusual Tuya FS-05R UART-based dimmer protocol .
    There was supposedly a TuyaMCU-compatible package there, but a different way of sending.

    BL0942 also has communication starting with 0x55:
    https://www.elektroda.com/rtvforum/topic3887748.html

    So it could be a slightly different protocol, just because the start is 0x55 doesn't mean anything yet. Alternatively, maybe you intercepted with interference?

    And do the checksums match?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #4 21335535
    Samezrp1
    Level 13  
    I see that PuTTY can add its line ends (0D 0A), so I've attached the logs from CoolTerma.

    Plus additionally what the flasher reads from the config.
    
    {
    	"abi":"0",
    	"id":"null",
    	"swv":"1.0.2",
    	"bv":"40.00",
    	"pv":"2.2",
    	"lpv":"3.4",
    	"pk":"uade6fhqmx2hxxxx",
    	"firmk":"null",
    	"cadv":"1.0.3",
    	"cdv":"1.0.0",
    	"dev_swv":"1.0.2",
    	"s_id":"null",
    	"dtp":"0",
    	"sync":"0",
    	"attr_num":"0",
    	"mst_tp_0":"0",
    	"mst_ver_0":"null",
    	"mst_tp_1":"0",
    	"mst_ver_1":"null",
    	"mst_tp_2":"0",
    	"mst_ver_2":"null",
    	"mst_tp_3":"0",
    	"mst_ver_3":"null "
    }
    
    .
  • ADVERTISEMENT
  • #5 21352938
    Samezrp1
    Level 13  
    I've been away for a while, I've taken some timestamp logs and linked them so you can see the correlation between TuyaMCU and MCU, maybe this will get someone closer to a solution.
    By the way, do you know how to strigger the carbon monoxide sensor without the monoxide itself? I'd like to trigger an alarm and see how the TuyaMCU is informed of the alarm.
  • #6 21352978
    p.kaczmarek2
    Moderator Smart Home
    Only two bytes and the checksum at the end change, have you tried checking what is in those bytes? What do they look like as a 16 bit integer for example?

    Tuya debug log with highlighted byte values. .
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #7 21353863
    Samezrp1
    Level 13  
    Today I came across this topic:
    url .

    some of the finds in common, maybe it's worth combining them?

Topic summary

The discussion focuses on analyzing UART communication packets between a Holtek BA45F6746 MCU and a TuyaMCU (CBU) in a Carbon Monoxide (CO) detector device. The MCU manages sensors, display, LEDs, buzzer, and buttons, while the TuyaMCU controls battery status, WiFi LED, reset button, and an unidentified signal likely related to CO alarm detection. The user encounters unknown UART packets starting with 0x55 but not matching the typical TuyaMCU protocol header (0x55AA). Packet length and structure appear inconsistent with standard TuyaMCU formats, suggesting a different or modified protocol. Logs from UART lines during button presses and device startup were shared for analysis. Additional data includes device configuration readouts and timestamped logs correlating MCU and TuyaMCU communication. Attempts to decode variable bytes and checksums were made, with suggestions to interpret changing bytes as 16-bit integers. The user also inquires about methods to trigger the CO sensor alarm without actual CO presence to observe communication changes. References to similar reverse-engineered protocols and related devices (e.g., Tuya FS-05R dimmer, BL0942) were mentioned as potential comparison points for understanding the protocol variations.
Summary generated by the language model.
ADVERTISEMENT