logo elektroda
logo elektroda
X
logo elektroda
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

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

markusdd 1701 103
Best answers

How can I cloud-cut the Dreo 517s wall heater, identify its Beken module, and back up/flash its firmware safely?

The heater appears to use a Hesung Innovation Limited MBL01 / BL2028N Beken module, and the suggested backup path is to treat it like a Beken/Tuya device: dump the stock flash first with BK7231GUIFlashTool/Easy Flasher, using TX1/RX1 for flash read/write and TX2 for logs, then restore the RF partition if OBK won’t connect because the dump showed RF at 0x1E0000 while OBK expects 0x1D0000 [#21856107] [#21856302] [#21857178] The UART protocol is TuyaMCU-like but not identical: frames start with 0x55 0xAA 0x00 , the sequence increments from 0 after boot, and the checksum is roughly (sequence + sum(payload bytes) - 1) % 256 [#21856296] The live capture showed a 10-second heartbeat/ping-pong, with full status frames carrying all datapoints, and the parsed DPs included power, operating mode, submode/context, target temperature, and several mode flags/constants [#21856296] [#21856379] A Dreo-specific driver/repo already appeared on GitHub, and an early OpenBeken port was put into PRs, so the path forward was to use that driver instead of reverse-engineering everything from scratch [#21856568] [#21868387] [#21857261]
ADVERTISEMENT
  • #61 21868986
    divadiow
    Level 38  
    it'd be the BK7231N rbl file when you get a working OpenBK7231N running.

    p.kaczmarek2 wrote:
    think I need to enable it for Beken first.

    but this still the case. so here's a build with it enabled for Beken: https://github.com/divadiow/OpenBK7231T_App/actions/runs/23458842900

    Screenshot of OpenBK7231N web dashboard with a DP table and buttons for Config, Restart, and About

    Added after 3 [minutes]:

    markusdd wrote:
    I have it here on the bench and can erase and write to it with the gui flasher just fine but nothing works afterwards...


    flashing the BK7231M QIO?
  • ADVERTISEMENT
  • #63 21868994
    divadiow
    Level 38  
    no boot log, no AP (after restoring your RF from backup)?
  • #64 21868997
    markusdd
    Level 2  
    >>21868994

    nothing. I had to do a flash erase back then to get cleanly from openbeken to ESPHome, otherwise it would not work.
    Now I am trying the other way round and something is off
  • #66 21869004
    markusdd
    Level 2  
    OMG now I cannot even get it to get a bus... :(((
  • #67 21869007
    divadiow
    Level 38  
    yikes. what's happening to it!

    what does your setup look like? short cables, grounds all common, etc etc
  • ADVERTISEMENT
  • #68 21869023
    markusdd
    Level 2  
    yes. same what I've used through all we did here.

    Added after 10 [minutes]:

    ....how can I investigate if it is bricked?
  • #69 21869030
    divadiow
    Level 38  
    is it getting super hot or anything?

    I think I've had it before that no amount of erase/rewrite with Easy Flasher could rescue a chip once, so I had to use BKFIL, I may be misremembering, but worth a try?

    There's a full-erase toggle and you can easily burn QIO from 0x0 with it.

    https://dl.bekencorp.com/tools/bkfil/v4
  • #70 21869031
    markusdd
    Level 2  
    >>21869030 no it is not getting hot.

    I will try this tool

    Added after 5 [minutes]:

    Oh my god this is so annoying. Windows is the worst OS EVER. now the programs are fighting over the serial ports although I close them.

    Added after 11 [minutes]:

    mmh. now it is getting hot

    Added after 3 [minutes]:

    Ok. I think he is dead Jim. Wonderful...

    So what to do now? I have some ESP32C3 SuperMini flying around. I guess we're swapping for an ESP ...
  • #71 21869048
    divadiow
    Level 38  
    no way!

    any whiskers of solder or something causing a short? do you have a multimeter to check continuities?
  • #72 21869051
    markusdd
    Level 2  
    yeah I mean it's pretty obvious. When just connecting power to the 2 pins with a 3.3V lab supply it pulls like an Amp continuously.
  • #73 21869054
    divadiow
    Level 38  
    damn. yes. that's when I know I've killed a module :/
  • #74 21869058
    markusdd
    Level 2  
    >>21869054
    it was extremely annoying to handle anyway compared to ESPs and the like. Just even the regular flashing we did before and converting to ESPHome took me many tries. The resetting was extremely unreliable. Worked like every tenth try. (compared to the Argo heater where I had basically no issues).

    Anyway. ESP is prepared. Do we have a build of OpenBeken that can be used with this to the build. Otherwise the experiment is over I guess and I have to use the ESPHome version.

    How to flash OBK onto ESPs?
    Close-up of a PCB module with colored wires connected next to an LED display labeled “ECO”.

    nevermind...it's in the flash tool. duh.
  • ADVERTISEMENT
  • #76 21869065
    markusdd
    Level 2  
    >>21869064

    mmh.

    Code: Text
    Log in, to see the code


    I do not see an AP being opened, but actually I also flashed a OBK config with my network.

    Added after 47 [minutes]:

    mmh. stuck here, cannot get an AP or preconfigure the wifi. also in your pipeline the build fails for ESP, it looks a bit as if the driver is not getting compiled as it cannot find the functions in link stage.

    Need assistance here.

    Added after 3 [hours] 31 [minutes]:

    OK: That was stupid difficult but I have a running OpenBeken on the ESP now and it is in the housing.

    So once we have a build for ESP32_C3 we can test.


    Screenshot of OpenESP32C3 status page with device stats and buttons: Config, Restart, Launch Web Application.

    Added after 19 [minutes]:

    made also my own fork and placed the dreo define in more places, it also fails e.g. for the linux build.
    Is there some header entry missing? It really seems it does not find the driver functions at all, but only notices once it starts linking: https://github.com/markusdd/OpenBK7231T_App/actions/runs/23471266516/job/68294314235
  • #78 21869099
    markusdd
    Level 2  
    >>21869098

    I just noticed this as well.
    Made the modification on my branch, pipelines are running. Will test in the morning.

    Added after 8 [minutes]:

    not clean for all platforms but we have a build for C3_4M. I OTA'd it. Now what to do?
  • #79 21869239
    markusdd
    Level 2  
    ok @p.kaczmarek2 and @divadiow I now have the ESP32 C3 running after the original module decided to die on me.


    Screenshot of a debug log showing “StartDriver Dreo” and repeated “sent cmd 0x00, 0 payload bytes” lines

    I put "StartDriver Dreo" into autoexec.bat and enabled the flag 26 for secondary UART. I now see 0x00 command messages in log but nothing else happening. I have UART soldered up to pins 6/7 which should be correct for C3.

    How to proceed? This is the startpage now:

    Screenshot of OpenESP32C3 web page with Dreo Heater DPs table and buttons: Config, Restart, Launch Web Application.

    Added after 6 [hours] 37 [minutes]:

    And maybe can someone cross-check this pipeline: https://github.com/markusdd/OpenBK7231T_App/actions/runs/23471597638/job/68295398116

    I succeeded in getting a c3 build with adding the missing filelist entries in the Makefiles and also in the config but I guess some of the build failures are still related to the driver not being compiled where it is expected.

    I simply forked the dreo branch.
  • ADVERTISEMENT
  • #80 21869545
    p.kaczmarek2
    Moderator Smart Home
    Interesting, let me add a number of received /sent bytes to the UI and we'll know if your ESP receives anything at all.
    Helpful post? Buy me a coffee.
  • #82 21869641
    p.kaczmarek2
    Moderator Smart Home
    It's easier for me to just fix build on my side. Here is PR with fixes, makefiles updated, and esp32 build enabled with driver.
    https://github.com/openshwprojects/OpenBK7231T_App/pull/2041
    Helpful post? Buy me a coffee.
  • #83 21869647
    markusdd
    Level 2  
    Thanks.

    OTA'd it and this does not look like we're receiving something:
    OpenESP32C3_4954E2AC status page for a Dreo Heater with buttons Config, Restart, and Launch Web Application.

    Any way to check if it really uses the second UART on pin 6/7?
  • #84 21869653
    p.kaczmarek2
    Moderator Smart Home
    I seem to remember that it was mentioned some time ago by @insmod that UART may not be ready on ESP32? Or is it ready?
    Helpful post? Buy me a coffee.
  • #85 21869659
    markusdd
    Level 2  
    >>21869653 as far as I could see in the HAL everything was there.

    Otherwise I also wouldn't expect the build and sending to work?

    EDIT:

    On Pin 21, which is UART0, I see activity but the decoder clearly says this is logging:

    Rigol oscilloscope screenshot showing RS232-TX decoding with a visible character string

    So that at least is not where our stuff supposedly comes out.

    Added after 28 [minutes]:

    I think the driver is watching the wrong UART.

    When I press the front panel button to turn it on I clearly see that the MCU is sending us something:
    Rigol oscilloscope screenshot showing an RS232-TX waveform and a horizontal timebase settings panel.

    But there is complete radio silence on our TX pin.
  • #86 21869697
    divadiow
    Level 38  
    does flag 26 work for ESP32C3, I don't recall if it can be expected to.
  • #88 21869708
    divadiow
    Level 38  
    markusdd wrote:
    flag 26 for secondary UART.

    ah :)
  • #89 21869720
    markusdd
    Level 2  
    ok, so how to debug this further?

    Added after 38 [minutes]:

    I just did a better decode capture of the RX line going to pin 6 of the ESP when I press a front panel button. This is 100% good.

    So who can help on the driver issue?

    Rigol oscilloscope screenshot with RS232 decoding and bytes: 55 AA 00 0F 0E 00 00 03 01 01 06 27.

    Added after 1 [hours] 18 [minutes]:

    Ok, so I switched to a normal ESP32 as the C3 kept having wifi issues whenever measurement equipment was connected.

    When I do NOT enable Option 26 the command data very obviously comes out together with the normal logging, and I get send+receive data:


    Screenshot of OpenESP32 status page showing Dreo Heater stats and buttons: Config, Restart, Launch Web Application, About.


    Obviously, this leads to total garbage, because we keep pumping the general log into the MCU:

    Screenshot of a serial monitor showing ESP logs, garbled characters, and network info values

    The problem is when I enable Option 26 I do not see data coming out anywhere, and that is our issue. So how to fix that?

    Added after 48 [minutes]:

    it seems to me that setting the option has the effect of indeed not polluting UART0 anymore, but trying to switch to UART1 or 2 ends up in not exposing it on the pins. It could be that some IDF API call is missing to actually set the pinmux
  • #90 21869844
    DeDaMrAz
    Level 22  
    p.kaczmarek2 wrote:
    Or is it ready?


    I should check before posting this - but UART is ready and working on ESP it's just that the pins for it are not mapped yet. Problem with UART on ESP is that there is no standardized path for pin initialization as every chip/module has a slight difference. I've enabled that on GPIO6 and GPIO7 (ESP32-C3) for my Ariston testing and it's been working fine for me.

    Need to spend some time on that and figure out something to suggest as a possible solution that will work on most ESP32 chips.

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.

FAQ

TL;DR: Cloud-cutting the Dreo 517s works by speaking its UART protocol: a 0x55 0xAA 0x00 header, rolling ID, and a ~10‑second heartbeat. “Header is always 0x55 0xAA 0x00 .” Use 5 V bench power for safe sniffing and back up flash at 230400 baud. [Elektroda, markusdd, post #21856296]

Why it matters: This lets you keep full local control (no cloud) while retaining buttons and safety features, and paves the way for OpenBeken/ESPHome drivers.

Quick Facts

What exactly is “cloud cutting” for the Dreo 517s?

Cloud cutting is a local-control retrofit that replaces the vendor cloud link with a direct UART protocol between the Wi‑Fi module and the main MCU, keeping buttons and safety logic intact. It relies on decoding 0x55 0xAA framed packets and the 10‑second heartbeat. [Elektroda, markusdd, post #21856296]

Which Wi‑Fi module is inside the Dreo 517s wall heater?

The PCB carries a Hesung Innovation MBL01 module labeled BL2028N, which the community maps to the Beken BK7231N family used by OpenBeken-compatible devices. A user posted FCC imagery matching MBL01. [Elektroda, divadiow, post #21856107]

How do I safely capture UART without tripping the heater or the logic analyzer?

Power the logic board with a stable 5 V bench supply and keep mains disconnected to avoid ground issues. With RX/TX/5V/GND reconnected, the app still links and reports temperature for clean captures. [Elektroda, markusdd, post #21856029]

What is the Dreo 517s UART packet format and checksum?

Packets start 55 AA 00, followed by a 1‑byte transaction ID that increments from boot, payload bytes, then a checksum computed as (ID + sum(payload bytes) − 1) mod 256. Heartbeat exchanges occur about every 10 seconds. [Elektroda, markusdd, post #21856296]

How do I back up the stock firmware before any flashing?

Use BK7231GUIFlashTool. Connect TX/RX/3.3 V/GND, click “firmware backup,” then power or briefly pull CEN low to enter boot. A successful dump used the BK7231M profile at 230400 baud. [Elektroda, markusdd, post #21856327]

Does the 517s behave like TuyaMCU devices?

Yes, the framing and DP-style fields resemble TuyaMCU, but IDs and checksum differ. Status messages are full-state frames, and the driver can likely reuse TuyaMCU parsing with a different frame runner. [Elektroda, p.kaczmarek2, post #21856491]

Can I use ESPHome today, or should I wait for an OpenBeken driver?

You can use ESPHome now by transplanting an ESP module; a community repo reports full operation. Porting to OpenBeken is feasible but slower without test hardware. “Go ESPHome route for now.” [Elektroda, DeDaMrAz, post #21856933]

How are modes and ECO temperatures encoded on the wire?

Multi‑DP set frames include DP01 power, DP02 mode, DP03 level, and DP04 parameter. ECO uses Fahrenheit byte targets: 15°C→0x3B, 20°C→0x44, 25°C→0x4D, 30°C→0x56, derived from C→F. [Elektroda, markusdd, post #21856387]

What failure modes should I expect while probing?

Ground loops with mains connected can crash captures, and removing the mains-board MCU shows “E0” and stops operation. Always bench-power at 5 V during logic analysis to avoid these faults. [Elektroda, markusdd, post #21856029]

Do physical buttons and IR still work after cloud cutting?

Yes. Buttons are on a separate capacitive line into the main MCU. Presses trigger MCU→Wi‑Fi status messages, so local controls and IR remain functional during UART-based control. [Elektroda, markusdd, post #21856436]

Which serial speed and lines should I monitor?

Use a logic analyzer on the module UART RX/TX at LVCMOS levels. A successful flash dump ran at 230400 baud, while normal UART captures used standard analyzer settings with LSB‑first decoding. [Elektroda, markusdd, post #21856327]

What extra features are exposed (beep, child-lock, display, °C/°F)?

Toggles for display on/off, beep, child lock, window‑open detection, ambient temperature compensation, and °C/°F switching appear as DP fields and cause MCU→Wi‑Fi messages when changed. [Elektroda, markusdd, post #21856404]

How do I put the unit into pairing or observe boot handshakes?

Capture the startup sequence from cold power‑on. You’ll see init queries (cmd 0x01/0x03), a ready trigger (0x08), then status and heartbeat frames. Use that to clone boot timing in your driver. [Elektroda, markusdd, post #21856338]

Is there a known constant or sentinel in the DP set?

Yes. Users observed DP07 as a constant 4‑byte value (0x0000004A) across samples, plus multiple zeroed 4‑byte DPs (e.g., DP09, DP0F, DP11). Treat them as required template fillers. [Elektroda, DeDaMrAz, post #21856379]

What heater power does this effort target?

The reverse‑engineering follows a prior 1000 W/2000 W wall‑mount heater project; the Dreo 517s is a quieter, popular variant tackled with a similar UART approach. [Elektroda, markusdd, post #21855755]

What 3‑step process should I follow to send a mode change?

  1. Send a DP‑prep frame (cmd 0x06) with new rolling ID. 2. Send a 0x07 multi‑DP set using the fixed 126‑byte template, update power/mode/level/param, and recompute checksum. 3. Expect 0x07 ack and a full status frame. [Elektroda, markusdd, post #21856387]
ADVERTISEMENT