logo elektroda
logo elektroda
X
logo elektroda

Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU

markusdd 93 10
ADVERTISEMENT
  • #1 21855755
    markusdd
    Level 2  
    As mentioned in https://www.elektroda.com/rtvforum/topic4166319.html where we were successful in cloud cutting one of the generic 1000 W/2000 W wall-mount heaters, I would like to attempt this with the Dreo 517s, which is nicer, very popular, and supposedly quieter. I got one coming in today.

    We know these are NOT Tuya/TuyaMCU, but from the GitHub dreo-cloudcutter https://github.com/ouaibe/dreo-cloudcutter, which did this for a tower fan from Dreo, we know they use OpenBeken-compatible modules. And they use UART towards an MCU. So close enough.

    This will probably end up being logic analysis and figuring out command values, read-back values, and CRCs.

    But at the end of the day it probably won't end up being rocket science. I will post here what I find and hope for help where I get stuck.

    If this works, many people will be happy.

    Added after 5 [hours] 11 [minutes]:

    So. It is here.

    I have attached photos of the device and what it looks like taken apart.
    It is now coupled with Dreo cloud and I intend to sniff the UART comms at the level shifter transistors.
    I have therefore attached 2 wires and a ground connection where my slogic LA is now connected.

    All of this looks extremely similar to a TuyaMCU device, I would almost say the MCU is basically identical to what was in the argo heater.

    So let's see what we get, I will share some captures in due course.

    Any more ideas what we should look at? Also: which openBeken compatible chip is this and what do we need to do for saving the stock firmware and flashing our own later?
  • ADVERTISEMENT
  • #2 21856029
    markusdd
    Level 2  
    OK, first hurdle: Grounding issues with the logic analyzer. You can't have the heater connected to the mains. But it is intelligent, and also needs the HV board connected, which makes the 5 V.
    So I backfed the connector from my lab supply with 5 V and reconnected the RX/TX/5 V/GND connector.
    Compared to the other heater, the Dreo has another MCU on the mains board, probably it has fancier control of fan speed, etc. It also monitors stuff, because if this MCU is disconnected, the display just shows "E0".

    Good news is: with this setup, the app works and even reports back the temperature, and I can select heating cycles, etc.
    So in that setup, we can capture everything. I will report back.
  • #3 21856047
    markusdd
    Level 2  
    First capture when idle. Everything is off and wifi is connected. There seems to be some kind of status and alive ping-pong every ten seconds:
  • ADVERTISEMENT
  • ADVERTISEMENT
  • #7 21856116
    markusdd
    Level 2  
    >>21856107

    That looks bang-on. But I guess before we do any flashing, etc., we probably need to crack the protocol first.

    I'm currently running the CSVs by Grok to see what it can come up with. I think we have some of a fixed header a la 0xAA 0x55 0x00 0x<some rolling code>.

    Has something like this been seen before or is this even similar to TuyaMCU? Looks like a transaction ID to me.
  • #9 21856129
    markusdd
    Level 2  
    >>21856124

    I have checked, and it seems the answer is no, except start with 0xAA.

    Here is my conversation with Grok, based on a long idle capture and the on/off one. Interesting.

    That being said, could be the idle transmissions follow a different protocol than actual commands and status updates.

    https://grok.com/share/c2hhcmQtMi1jb3B5_9d03e382-aa8c-448e-822a-838b987263cd
  • ADVERTISEMENT
  • #10 21856174
    markusdd
    Level 2  
    OK, more stuff from Grok.

    There seems to be a similar but not identical checksum algo compared to dreo-cloudcutter. Interestingly, for idle the ping/pong method also works. Pretty neat.

    Grok already disassembled a lot of the command structure: https://grok.com/share/c2hhcmQtMi1jb3B5_7035a89c-f460-4692-bed5-ccd60504c905

    I will now cycle through more modes and temperature settings and see what happens, but this doesn't seem extremely complicated overall from the command side.
    Disassembling these huge state messages is probably a bit more work.

Topic summary

The discussion focuses on reverse engineering the Dreo 517s wall-mount heater's communication protocol to enable cloud cutting similar to the TuyaMCU approach used for other generic heaters. The device uses an OpenBeken-compatible module, specifically identified as a Hesung Innovation Limited MBL01 - BL2028N (BK7231N), communicating via UART with an MCU. Initial challenges include grounding issues when connecting a logic analyzer due to the heater's mains-powered high-voltage board supplying 5 V. The heater contains an additional MCU on the mains board responsible for fan speed control and system monitoring, indicated by an error display ("E0") if disconnected. Captured UART traffic reveals periodic status and alive ping-pong messages every ten seconds, with command sequences changing upon temperature adjustments and power toggling via the app. Protocol analysis shows a fixed header starting with 0xAA and a rolling code, with a checksum algorithm similar but not identical to the one used in the dreo-cloudcutter project for a Dreo tower fan. Disassembly of command structures and state messages is underway, with temperature setpoints appearing to be scaled values. The protocol differs from TuyaMCU but shares some structural similarities, suggesting feasible protocol cracking through logic analysis and CRC verification. Further testing involves cycling through modes and temperature settings to fully map command and response patterns.
Summary generated by the language model.
ADVERTISEMENT