logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

markusdd 2370 104
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]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #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?

    EDIT: attached manual
    Attachments:
    • Dreo517s_manual.pdf (6.73 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU PXL_20260306_165838694.RAW-01.jpg (5.78 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU PXL_20260306_165159417.RAW-01.jpg (6.23 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU PXL_20260306_164325055.RAW-01.jpg (5.61 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU PXL_20260306_163942939.RAW-01.jpg (4.93 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU PXL_20260306_163917471.RAW-01.jpg (5.82 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU PXL_20260306_163852891.RAW-01.jpg (5.66 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU PXL_20260306_163711675.RAW-01.jpg (7.27 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU PXL_20260306_163704936.RAW-01.jpg (7.11 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU PXL_20260306_142117438.RAW-01~2.jpg (5.25 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU PXL_20260306_164807059.RAW-01.jpg (6.35 MB) You must be logged in to download this attachment.
  • 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.
    Attachments:
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU PXL_20260306_181747066.RAW-01.jpg (8.28 MB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #3 21856047
    markusdd
    Level 2  
    First capture when idle. Everything is off, and Wi-Fi is connected. There seems to be some kind of status and alive ping-pong every ten seconds:
    Attachments:
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU idle.png (252.39 KB) You must be logged in to download this attachment.
  • #4 21856059
    markusdd
    Level 2  
    Next step. Idle. App open. Hand on temp sensor so it goes from 23 °C to 24 °C. Some longer TX messages appear.
    Attachments:
    • idle_hand on temp sensor_23to24C.csv (23.45 KB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #5 21856074
    markusdd
    Level 2  
    Next one. On at approx. 8 s, followed by off at 9 s (both from app). RX, followed by short tx, then a long tx and then another RX.
    The regular idle packets are at 4 s and 14 s.
    Attachments:
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU on_8s_off_9.png (31.62 KB) You must be logged in to download this attachment.
    • on_8s_off_9s.csv (25.44 KB) You must be logged in to download this attachment.
  • #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
    Attachments:
    • long_idle_capture.csv (21.16 KB) You must be logged in to download this attachment.
  • 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.
    Attachments:
    • on_off_multiple_times_then_h3_h2_h1_eco_off.csv (151.47 KB) You must be logged in to download this attachment.
  • #11 21856189
    markusdd
    Level 2  
    Now working on the temperature set. Seems to be scaled somehow.

    ]Link
    Attachments:
    • On_eco_temp_down_from_29_to_19C.csv (99.61 KB) You must be logged in to download this attachment.
  • #12 21856296
    markusdd
    Level 2  
    Ok, some further findings: Temperature seemed to behave erratically, and Grok (correctly) suggested that indeed everything is probably LSB-first. So, back to square one.

    I fed this in, and we already have some findings:

    - It is somewhat akin to TuyaMCU from the structure, but it is different. Good news is that the basic idea is very similar; hence a new driver is probably not rocket science.
    - Header is always 0x55 0xAA 0x00 0x<ID>, where ID is just incrementally counting up from 0 after boot. This seems to act as a ping-pong ID, so you know which message is a response to what.
    - The checksum (1 byte) seems to be something like this: 0x55AA00 ignored always; (ID + sum(all payload bytes) - 1) % 256.
    - There is a heartbeat ping-pong every 10 seconds.
    - Status messages always seem to be the full meal containing all info.

    EDIT: I should add: Everything in those captures is as viewed from the MCU. So, RX is what the Wi-Fi module is sending, and TX is what the MCU is responding.
    Attachments:
    • LSB_plugging_mains_in_no_command_sent.csv (39.72 KB) You must be logged in to download this attachment.
    • LSB_On_H3_H2_H1_H2_H3_Fanonly_Off.csv (62.7 KB) You must be logged in to download this attachment.
    • LSB_On_Eco15_Eco20_Eco25_Eco30_Off_Roomtemp23.csv (51.01 KB) You must be logged in to download this attachment.
  • #14 21856300
    divadiow
    Level 38  
    also, have you backed-up factory flash yet, not flash OBK, just the backup
  • #15 21856301
    markusdd
    Level 2  
    >>21856299
    If they help, I can try. But the pulseview version I am using has the problem of being beta as the SLogic 16 is very new and not on mainline yet. I had problems with it crashing during export. Let me see.

    @DeDaMrAz, it does work at least for the startup capture. Can you try to open it? (Had to zip because forum does not like the sr extension)

    Added after 52 [seconds]:

    >>21856300

    No, I have not yet. I am only doing UART analysis now.
    Can you point me to the tutorial for that module on how to dump it?
    Attachments:
    • LSB_plugging_mains_in_no_command_sent.zip (21.69 KB) You must be logged in to download this attachment.
  • Helpful post
    #16 21856302
    divadiow
    Level 38  
    markusdd wrote:
    No I have not yet, I am only doing UART analysis now.
    Can you point me to the turorial for that module on how to dump it?


    sure. if it's the same as Tuya Beken then probably debug log from TX2 and flash read/write from TX1/RX1.

    https://github.com/openshwprojects/BK7231GUIFlashTool/releases

    Screenshot of BK7231 Easy UART Flasher showing the message “Write done”

    power-on (3.3v) or quick pulldown CEN pad after clicking "firmware backup" for Easy Flasher to catch and begin dump https://www.elektroda.com/rtvforum/topic3951016.html
  • Helpful post
    #17 21856317
    DeDaMrAz
    Level 22  
    markusdd wrote:
    Can you try to open it? (Had to zip because forum does not like the sr extension)


    Got it and can open it, will look into it soon.
  • #18 21856327
    markusdd
    Level 2  
    >>21856302

    OK, with that setting it complained about the encryption key. I then chose, as recommended by the flasher, BK7231M, and then it started dumping at 230400 baud. It then said it found no Tuya or OBK config, which makes sense.

    Here is the binary.
    Screenshot of BK7231 Easy UART Flasher showing “Reading success!” and a warning about a non-standard encryption key
    Screenshot of BK7231 Easy UART Flasher showing “Reading success!” and a read log.
    Attachments:
    • readResult_BK7231M_QIO_Dreo517s_2026-07-3-10-07-10.bin (2 MB) You must be logged in to download this attachment.
  • Helpful post
    #19 21856328
    divadiow
    Level 38  
    ah yes, of course. BK7231M. nice one.
  • #20 21856338
    markusdd
    Level 2  
    Also, I soldered it back in and left me a line for TX2, so here is the startup log Just censored parts of the WPA strings not sure if they contain anything important:

    Code: Text
    Log in, to see the code


    EDIT: The log is not much use after that, no messages when turning things on and off via the app.

    Added after 23 [minutes]:

    Ok @DeDaMrAz I ahve attached another more elaborate capture.

    Here I turn it on (it comes up in H1) then I cycle to H2, H3, back to H1, then to Eco at 30C, 25C, 20C, 15C then I go to Fan only mode and then turn it off.
    Attachments:
    • LSB_On_inH1_H2_H3_H1_Eco30C_Eco25C_Eco20C_Eco15C_Fanonly_Off.zip (17.63 KB) You must be logged in to download this attachment.
    • LSB_On_inH1_H2_H3_H1_Eco30C_Eco25C_Eco20C_Eco15C_Fanonly_Off.csv (84.85 KB) You must be logged in to download this attachment.
  • #21 21856376
    divadiow
    Level 38  
    I'm just messing about with an early DreoMCU emulator.

    Screenshot of “Dreo WHS17S MCU Emulator” showing COM port logs and a control panel

    Have you captured anything yet to reset device/get back into pairing mode?
  • Helpful post
    #22 21856379
    DeDaMrAz
    Level 22  
    DP 01 bool Main power / run enable
    DP 02 enum Main operating mode
    DP 03 enum Submode / context flag
    DP 04 value Temperature / eco target byte
    DP 07 value4 Constant here: 0x0000004A
    DP 09 value4 Constant zero here
    DP 0D value4 Constant zero here
    DP 0E value4 Fanonly-specific value, 0x0000001E in this capture
    DP 0F value4 Constant zero here
    DP 11 value4 Constant zero here
    DP 13 bool Usually 1 in heating states, 0 later
    DP 14 bool 0/1 flag, changes with some modes
    DP 15 raw4 constant-ish in this sample
    DP 16 raw4 constant-ish in this sample

    Code: text Expand Select all Copy to clipboard
    Raw bytes   Field
55 AA   header
00 06   sequence
07   cmd
00   version / reserved
00 7E   payload length
01 00 01 00 01 00   DP01 entry
02 00 04 00 01 03 03   DP02 entry
04 00 01 00 01 03   DP04 entry
04 00 02 00 01 56   DP04? / next entry as captured
05 00 01 00 01 00   DP05 entry
06 00 01 00 01 00   DP06 entry
07 00 02 00 04 00 00 00 4D   DP07 entry
08 00 01 00 01 01   DP08 entry
09 00 02 00 04 00 00 00 00   DP09 entry
11 00 02 00 04 00 00 00 00   DP11 entry
0D 00 02 00 04 00 00 00 00   DP0D entry
0E 00 02 00 04 00 00 00 00   DP0E entry
0F 00 02 00 04 00 00 00 00   DP0F entry
10 00 01 00 01 00   DP10 entry
13 00 01 00 01 00   DP13 entry
14 00 01 00 01 00   DP14 entry
15 00 04 00 01 00   DP15 entry
16 00 04 00 01 02   DP16 entry
49   checksum


    For example

    Bytes | Meaning | Value
    01 | DP ID | DP01
    00 | report marker | status/report
    01 | type| bool / 1-byte simple value
    00 01 | length | 1
    00 | value | 0x00
  • #23 21856387
    markusdd
    Level 2  
    >>21856376

    do you mean wifi pairing?
    If you just mean startup out of reset thesere is a capture LSB_plugging_mains in a bit further up.

    Added after 1 [minutes]:

    >>21856379

    Nice!

    Here is what grok said about the capture, a lot of that lines up (not 100% accurate from it I think but we're getting there).

    Code: Text
    Log in, to see the code
  • #25 21856404
    markusdd
    Level 2  
    OK, more stuff. The app also has provisions for display on/off, beep on/off, child lock, window-open detection, and ambient temperature compensation.

    See file name for the order in which I toggled them. Ambient temperature was 22 °C all the time. (note that window open is on/off instead of off/on like the others)

    The heater was already on in Eco20 mode; there is no on or off in this capture.

    EDIT: Forgot one setting: you can change device display from °C to °F and back to °C. So I did that as well.

    EDIT: Also added pictures of the app controls.
    Attachments:
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU Screenshot_20260307-121109.png (1.06 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU Screenshot_20260307-121055.png (1.02 MB) You must be logged in to download this attachment.
    • Cloud Cutting Dreo 517s Wall Mount Heater using an approach similar to TuyaMCU Screenshot_20260307-121047.png (985.59 KB) You must be logged in to download this attachment.
    • LSB_inEco20Mode_displayfromCtoF_displayfromFtoC.zip (4.83 KB) You must be logged in to download this attachment.
    • LSB_inEco20Mode_displayfromCtoF_displayfromFtoC.csv (16.12 KB) You must be logged in to download this attachment.
    • LSB_inEco20mode_displayoffon_beepoffon_childlockoffon_windowopenonoff_tempcomp-1_tempcomp+1_tempcomp0.csv (85.79 KB) You must be logged in to download this attachment.
    • LSB_inEco20mode_displayoffon_beepoffon_childlockoffon_windowopenonoff_tempcomp-1_tempcomp+1_tempcomp0.zip (16.65 KB) You must be logged in to download this attachment.
  • #26 21856431
    divadiow
    Level 38  
    does the unit have physical buttons? I see only rx/tx to the BL2028N module, so I guess any buttons are to gpios on the DreoMCU? Did you already capture the effect of single-push, long-push etc on buttons?
  • #27 21856436
    markusdd
    Level 2  
    >>21856431

    Yes, if you check the pictures, you see a capacitive button line at the front. This one has a single-wire comms line and is going to the MCU (so it does not seem to be classic UART — or maybe just TX?). In the disassembled pic, it's the board with the springs on it. There is no connection directly to the Beken module. Also, for the other TuyaMCU heater, the button presses and IR remote just kept working normally, as they just interacted with the MCU.

    I will test if maybe presses there trigger status updates or something.

    EDIT: Indeed, pressing the buttons triggers messages from the MCU to the Wi-Fi module. I played around with on/off, cycling through modes, using /- to set temperature, and also the timer button, where you can cycle through how many hours it should be on. I guess the effect when using the IR remote is the same. Attached the PDF manual in the first post
    Attachments:
    • LSB_buttonpanel_onoff_modes_temp_countdowntimer.zip (49.92 KB) You must be logged in to download this attachment.
    • LSB_buttonpanel_onoff_modes_temp_countdowntimer.csv (307.65 KB) You must be logged in to download this attachment.
  • #28 21856475
    p.kaczmarek2
    Moderator Smart Home  
    Are the variable types here matching TuyaMCU? I mean IDs of boolean, number, enum, etc...

    Probably we could reuse TuyaMCU code just use a different main function for parsing packets so we can handle sequence ids.
    Helpful post? Buy me a coffee.
  • #29 21856478
    DeDaMrAz
    Level 22  
    p.kaczmarek2 wrote:
    Are the variable types here matching TuyaMCU? I mean IDs of boolean, number, enum, etc...


    Looks like they are matching from the quick glance I had at them, see below.

    Code: text Expand Select all Copy to clipboard
    DP 01 bool Main power / run enable
DP 02 enum Main operating mode
DP 03 enum Submode / context flag
DP 04 value Temperature / eco target byte
DP 07 value4 Constant here: 0x0000004A
DP 09 value4 Constant zero here
DP 0D value4 Constant zero here
DP 0E value4 Fanonly-specific value, 0x0000001E in this capture
DP 0F value4 Constant zero here
DP 11 value4 Constant zero here
DP 13 bool Usually 1 in heating states, 0 later
DP 14 bool 0/1 flag, changes with some modes
DP 15 raw4 constant-ish in this sample
DP 16 raw4 constant-ish in this sample
  • #30 21856491
    p.kaczmarek2
    Moderator Smart Home  
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_tuyaMCU.c
    Probably would need to split in TuyaMCU_RunFrame but still reuse code TuyaMCU_ParseStateMessage.

    Is this TuyaMCU flavour an official update, like a version 2026, or something, or is it Dreo-specific?
    Helpful post? Buy me a coffee.
Reply | New topic
Report a violation of the law

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.
Generated by the language model.
Today's popular

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]
Generated by the language model.
ADVERTISEMENT