logo elektroda
logo elektroda
X
logo elektroda

[OPL1000] Sonoff DW2 door/window opening sensor - teardown, firmware

p.kaczmarek2 11082 83

TL;DR

  • Sonoff DW2-WiFi door/window sensor uses an OPL1000 WiFi/Bluetooth microcontroller instead of RF433MHz, unlike the older DW1.
  • Inside the DW2-WiFi V1.2 board, a 6131 Hall sensor, Q1 transistor, and TH25Q80UA SPI flash sit alongside the separate WiFi module.
  • The flash was desoldered and read with a CH341 programmer; NeoProgrammer 2.2.0.3 recognized the chip with SPI ID EB6014.
  • Firmware strings suggested SDK traces, and the dumped firmware was published with links to OPL1000 SDK documentation and source.
  • The sensor pairs with eWeLink and works, but cloud cutoff is still difficult, and OpenBeken porting is only a possibility so far.
Generated by the language model.
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
📢 Listen (AI):
  • #61 21194827
    divadiow
    Level 38  
    Posts: 5021
    Help: 438
    Rate: 891
    p.kaczmarek2 wrote:
    Did this device support AP mode pairing for the app?

    no AP ever showed however many different ways I reset or pushed button with factory firmware.

    I'll try that demo with AP code change
  • ADVERTISEMENT
  • #62 21194829
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14576
    Help: 654
    Rate: 12602
    Which example are you using right now? I may need to double check it's code for all necessary AP changes.
    Helpful post? Buy me a coffee.
  • #63 21194834
    divadiow
    Level 38  
    Posts: 5021
    Help: 438
    Rate: 891
    >>21194829 I think this is currently flashed OPL1000A2-SDK-master\SDK\APS_PATCH\examples\system\ota_wifi

    but it's quick and easy to flash anything

    Added after 2 [minutes]:

    (I say "I think" because desk was tidied and everything disconnected. I'll reconnect now)

    Added after 13 [minutes]:

    divadiow wrote:
    I am no further forward with a working OTA demo.


    forgot to mention that although I do get a built binary, this is in the make output

    Code: Text
    Log in, to see the code


    I've not investigated this yet
  • ADVERTISEMENT
  • #64 21194882
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14576
    Help: 654
    Rate: 12602
    Regarding OTA sample - if you are getting "ota_prepare fail", then it fails there:
    Code: C / C++
    Log in, to see the code

    This could mean that MwOta_Prepare fails, MwOta_Prepare which is MwOta_Prepare_impl:
    https://github.com/Opulinks-Tech/OPL1000A2-SD...DK/APS/middleware/netlink/mw_ota/mw_ota.c#L81
    There are multiple conditionals in this function:
    Code: C / C++
    Log in, to see the code

    You can debug it by inserting printfs in each block.
    Helpful post? Buy me a coffee.
  • #65 21194948
    divadiow
    Level 38  
    Posts: 5021
    Help: 438
    Rate: 891
    I made some changes to the mw_ota.c file but nothing extra was printed to log. I saw "ota_abort error" in https://github.com/Opulinks-Tech/OPL1000A2-SDK/blob/49805f417c8d1fda258c146d2c8c7a8961fa57fc/SDK/APS_PATCH/examples/system/ota_wifi/http_ota_example.c#L364

    GPT gave me the attached revised for both. This is the boot log output now.

    Code: Text
    Log in, to see the code


    I think it's something to do with

    project_id = 1000
    chip_id = 2
    firmware_id = 1
    img_size = 160180
    img_sum = 14753094


    eg setting firmware ID to 20 here

    OPL1000 Download Tool user interface with OTA configurations.

    gives a 20 value in the log

    Code: Text
    Log in, to see the code
    Attachments:
    • mw_ota.c (37.4 KB) You must be logged in to download this attachment.
    • http_ota_example.c (15.09 KB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #66 21194994
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14576
    Help: 654
    Rate: 12602
    mw_ota.c you attached won't build, something has copied printfs twice there:
    Source code snippet in C with duplicated return statements.
    Here is the function with better printfs:
    Code: C / C++
    Log in, to see the code

    Also, make sure to make a full rebuild, so the changes are included.
    It is possible this file somehow is not getting build.


    Or just make a syntax error in it and check if it detects it.
    Helpful post? Buy me a coffee.
  • #67 21195405
    divadiow
    Level 38  
    Posts: 5021
    Help: 438
    Rate: 891
    p.kaczmarek2 wrote:
    Here is the function with better printfs:

    thank you. I have restored http_ota_example.c to default and then edited server IP where I am hosting opl1000_ota.bin.

    I then reset mwa_ota.c to default and changed that function to match above.

    It's definitely building fresh every time. Some of the changes chatgpt was giving me would fail and then subsequent changes would make a difference. If I add random junk to one line it fails the next build.

    With only the changes you've supplied, the output is back to no more information:

    Code: Text
    Log in, to see the code


    I think I only found changes to http_ota_example.c seemed to make a difference in my tinkering earlier.

    Added after 3 [minutes]:

    divadiow wrote:
    http server is serving opl1000_ota.bin file download for any other device on subnet but not the DW2 yet.

    I should elaborate on this. The https_server.exe Python single exe they supply never seems to start whatever switches I use. I'm running it on a Windows machine and there's an Opulinks-TEST-AP broadcasting but it never connects. I gave up on it and have been testing with simply python http, powershell http and then Synology hosted http. Chrome downloads .bin from all, just not the DW2.

    Code: Text
    Log in, to see the code


    Added after 11 [minutes]:

    I've tried to find a newer version of http_server.exe but no luck. There are only a couple of versions in the whole OPL github

    Added after 8 [minutes]:

    oh hang on. "make clean" is a thing.

    Added after 2 [minutes]:

    same after make clean

    Code: Text
    Log in, to see the code


    Added after 3 [minutes]:

    I wonder if it's anything to do with where it would be copying the image to on the device. Maybe the partition layout isn't correct or something.

    Added after 24 [minutes]:

    this is interesting https://github.com/Opulinks-Tech/OPL1000A2-Door-Sensor-Coolkit-Cloud-HTTPS

    looks like the source for the DW2 factory firmware.

    https://github.com/Opulinks-Tech/OPL1000A2-Do...ystem/blewifi/src/blewifi_configuration.h#L64
  • #68 21196234
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14576
    Help: 654
    Rate: 12602
    I still can't see this line being printed:
    Code: C / C++
    Log in, to see the code

    is this line even included in the built binary?


    Why do you suspect HTTP client? If the code we are checking is correct:
    Code: C / C++
    Log in, to see the code

    Then the error message:
    
            LOG_I(TAG, "ota_prepare fail\r\n");
    

    is after the:
    
    
                LOG_E(TAG, "http client recv response error, ret = %d \r\n", ret);
    

    which means the HTTP part is ok, just OTA file is problematic.
    Helpful post? Buy me a coffee.
  • #69 21196691
    divadiow
    Level 38  
    Posts: 5021
    Help: 438
    Rate: 891
    OK. So it helps if you use a version of the Opulinks Download Tool that packs the firmware correctly.

    v2.0.0.

    Using the same opl1000_m0, PatchData.txt as before and the ota_wifi firmware opl1000_app_m3.bin we create the opl1000.bin as normal

    Opulinks Download Tool window displaying settings and file paths.

    then we add the opl1000_ota_loader.bin because

    Code: Text
    Log in, to see the code
    - from OPL1000-Demo-ota-wifi-guide_ENG.pdf

    Burn opl1000_ota.bin to OPL1000
    Screenshot of the Opulinks Download Tool showing UART settings and download process logs, with a FLASH_ERASE_ERROR displayed.

    on reboot this in the output indicates the OTA loader is present
    Code: Text
    Log in, to see the code


    Code: Text
    Log in, to see the code
    -from OPL1000-Demo-ota-wifi-guide_ENG.pdf

    and if you've set the AP SSID and password correctly in http_ota_example.h and the http server and port in http_ota_example.c and opl1000_ota.bin is available on the your HTTP server
    Code snippet defining server IP, port, and URL for OTA download.

    then it will begin to download the OTA file and flash it. This is the complete process from first boot of ota_wifi demo fw, OTA file download and flash and finally boot of wifi_station_gpio where it connects to my wifi and the LED on the DW2 lights. (Note the wifi_station_gpio firmware on the HTTP server is the same opl1000_ota.bin created by the ota pack process in tool).

    Code: Text
    Log in, to see the code


    note how the new firmware boots with this in log

    Code: Text
    Log in, to see the code


    I did try to OTA the full 1024kb factory backup but of course it failed. it stops at around 167kb. Unknowns are how big each image area is, if these demos are even aware of the 1mb flash, how big could Openbeken OTA fw be?

    Added after 37 [minutes]:

    and if you serve up ota_wifi firmware so it OTA updates every reboot, then it alternates between MW_OTA [0] and MW_OTA [1]
  • #70 21203280
    divadiow
    Level 38  
    Posts: 5021
    Help: 438
    Rate: 891
    p.kaczmarek2 wrote:
    so I may need to get another one soon

    did you order one in the end @p.kaczmarek2 ?
  • #71 21204554
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14576
    Help: 654
    Rate: 12602
    Sorry, I haven't managed to get around that yet! Now I see you've got OTA working, is that correct? Very good!

    So what about creating AP?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #72 21204577
    divadiow
    Level 38  
    Posts: 5021
    Help: 438
    Rate: 891
    p.kaczmarek2 wrote:
    Now I see you've got OTA working, is that correct

    Yes

    p.kaczmarek2 wrote:
    what about creating AP?


    I started playing with other devices and haven't done anything OPL1000 since, but will see if I can get AP going

    Added after 5 [hours] 37 [minutes]:

    hmm

    https://github.com/Opulinks-Tech/OPL1000A2-SD...ware/netlink/wifi_controller_layer/wifi_api.h

    Screenshot of API documentation for OPL1000 regarding Wi-Fi configuration.

    Added after 4 [minutes]:

    but then there is this https://github.com/Opulinks-Tech/OPL1000A2-SD...tlink/wifi_controller_layer/wifi_types.h#L105

    Added after 9 [hours] 6 [minutes]:

    :(
    Screenshot of an email about the OPL1000 device, indicating it supports only STA mode, not soft AP.
  • #73 21205361
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14576
    Help: 654
    Rate: 12602
    Strange, I was sure barely some time ago that it just does not support config change, but still can run AP.

    If no AP, then how it pairs? Now seriously. Is it even possible? It would kinda require device to know the SSID upfront and phone would have to use AP mode so OPL is STA...
    Helpful post? Buy me a coffee.
  • #76 21360243
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14576
    Help: 654
    Rate: 12602
    If you manually edit the hex file to be flashed, add some bytes, does it still boot? Or is there some kind of checksum/encryption in hex that prevents editing it?
    Helpful post? Buy me a coffee.
  • #77 21360269
    divadiow
    Level 38  
    Posts: 5021
    Help: 438
    Rate: 891
    Unsure, I cannot check until 28th.

    The checksum box in the flash tool changes as you add each binary (or maybe just main binary) so I *think* maybe you can make any bin and checksum is sorted at flashing.
  • #78 21360271
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14576
    Help: 654
    Rate: 12602
    Another thing to try is to capture UART communication with, for example Salae logic analyzer.
    Alternatively, we can try to disassemble the flash tool.

    And of course we can just... check Github, maybe there actually is some source of the flash code.
    Helpful post? Buy me a coffee.
  • #80 21386430
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14576
    Help: 654
    Rate: 12602
    That's not good, it will not fit to NodeMCU.

    Maybe it will fit to ESP boards? ESP32 modules have also smaller pitch pins?
    Helpful post? Buy me a coffee.
  • #82 21405013
    divadiow
    Level 38  
    Posts: 5021
    Help: 438
    Rate: 891
    E103-W08A defrocked

    Close-up of a circuit board with two chips, one marked PQ80 92U T61 and the other OPL 1000 A2SA1938 PPMN 4207. Close-up of an electronic circuit with two visible chips on a circuit board. Close-up of a circuit board with two black integrated circuits.
    Electronic module with visible conductive elements

    looks like
    Code: Text
    Log in, to see the code


    Added after 3 [hours] 17 [minutes]:

    ah, is this the same USON package @DeDaMrAz has just encountered here: https://www.elektroda.com/rtvforum/topic4093142-150.html#21403323 how did you connect to it @DeDaMrAz ?

    Added after 6 [minutes]:

    divadiow wrote:
    ah, is this the same USON package @DeDaMrAz has just encountered here

    maybe not. this has legs

    GPIO3 TX 115200 boot
    Code: Text
    Log in, to see the code


    -11 Carriage return wrapping was not entered
  • #83 21407092
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14576
    Help: 654
    Rate: 12602
    I haven't seen that small flash memory used on such module yet, all ESP modules I saw had a larger flash footprint.
    Helpful post? Buy me a coffee.
📢 Listen (AI):

Topic summary

✨ The discussion centers on the Sonoff DW2 door/window opening sensor based on the OPL1000 WiFi microcontroller, focusing on hardware teardown, firmware backup, and potential firmware modification. The sensor is inexpensive (~30 PLN) and uses WiFi communication, unlike its predecessor DW1 which used RF433MHz. Users confirmed the sensor transmits signals on opening but not necessarily on closing, with no firmware modification currently possible. Efforts to develop OpenBeken (OBK) support for OPL1000 are ongoing but limited by the chip's low popularity and scarce documentation. The OPL1000 SDKs (A1, A2, A3) correspond to different chip revisions or related chips (OPL1000, OPL1200, OPL1600/1800), with the DW2 sensor marked as A2 and compatible with the OPL1000A2 SDK. Firmware dumping was performed by desoldering the TH25Q-80UA 8Mbit SPI flash chip and bit-banging with FTDI, revealing AliCloud firmware with OTA capabilities and AT command support. Flashing custom firmware using the Opulinks Download Tool and compiling SDK examples (e.g., wpa2_station_gpio) was successful, enabling WiFi connection and GPIO control (e.g., LED on GPIO21). However, soft-AP mode is not supported or unclear, with pairing likely done via BLE rather than WiFi AP mode. OTA update demos were tested but initially failed due to improper firmware packaging; using the correct OTA loader and build process resolved this. Challenges remain in understanding flash memory layout, patch data usage, and full SDK utilization. Additional hardware like the E103-W08A OPL1000 module was also examined. The community is progressing toward porting OBK firmware to OPL1000 devices, with ongoing exploration of SDK examples, build environments (MSYS2), and flashing tools. Key technical issues include UART bootloader access, flash dumping, firmware compilation, OTA implementation, GPIO control, and network modes (STA/AP/BLE). The discussion includes detailed logs, code snippets, and hardware photos to support development efforts.
Generated by the language model.

FAQ

TL;DR: For under 30 PLN, the Sonoff DW2-Wi-Fi is a cheap door sensor for reverse engineers, and the thread’s key result is that "A2 SDK works" on the module marked A2. The flash was dumped, UART flashing worked, and OTA updates worked only after correct Opulinks packaging with an OTA loader. [#21196691]

Why it matters: This FAQ helps hardware hackers and OpenBeken users decide whether the DW2 is worth buying, dumping, compiling for, and eventually de-clouding.

Option Radio / setup Firmware status from thread Practical takeaway
Sonoff DW1 RF433 MHz Older design referenced by sellers Different product family, not the Wi-Fi teardown target
Sonoff DW2-Wi-Fi Wi-Fi + BLE setup flow Flash dumped, UART flashing and OTA confirmed Best current OPL1000-family test target in the thread
OPL1000 A2 SDK Matches A2-marked module Boots and connects in tests Use this SDK path first
OPL1000 A3 SDK Different family mapping Did not boot on this hardware Avoid for DW2 A2 modules

Key insight: The breakthrough was not just compiling code. The breakthrough was proving the DW2 can boot custom A2 builds, accept UART flashes, and alternate between MW_OTA [0] and MW_OTA [1] once the OTA image is packaged correctly. [#21196691]

Quick Facts

  • Case label and seller data in the thread identify the unit as DW2-Wi-Fi, with quiescent current <=40 uA and emission current <=15 mA. [#20767159]
  • The teardown identifies three core parts: an Opulinks OPL1000-family module marked A2, a TH25Q80UA SPI flash, and a 6131 Hall sensor. [#20767159]
  • The original buyer paid less than 30 PLN, which is why the DW2 attracted interest as a low-cost battery Wi-Fi sensor. [#20767159]
  • A full external flash backup was read from the 8 Mbit / 1 MB TH25Q-80UA chip, and later the same dump was flashed back successfully over UART. [#21190525]
  • OTA testing succeeded with a correctly packed image of 118,300 bytes, and the boot log then switched from MW_OTA [0] to MW_OTA [1]. [#21196691]

How do I open the Sonoff DW2-Wi-Fi door/window sensor and identify its main components like the OPL1000, TH25Q80UA flash, and Hall sensor?

Open it by removing the battery cover first, then release the two PCB retaining hooks and lift the board out. The PCB is marked DW2-WiFi V1.2 with date 2021.01.13. The main identifiable parts are the Opulinks Wi-Fi/Bluetooth module marked A2, the TH25Q80UA SPI flash, and a Hall sensor marked 6131. "Hall sensor" is a magnetic sensor that detects the nearby magnet’s position, replacing a reed switch and enabling open/close sensing with low power. The thread also notes transistor Q1 near the sensor area. [#20767159]

What is the OPL1000 and how does it differ from the OPL1200, OPL1600, and OPL1800 mentioned in the Opulinks SDKs?

The OPL1000 is an Opulinks Wi-Fi and Bluetooth microcontroller family used here as the DW2’s radio SoC. In the thread, Opulinks support mapped SDK families this way: A1 = OPL1000, A2 = OPL1200, and A3 = OPL1600 & OPL1800. The confusion came from the module being discussed as “OPL1000,” while the chip marking also showed A2. Later testing confirmed the A2 SDK worked on the DW2 hardware, so that is the practical target for this sensor. "OPL1000 family" is a Wi-Fi/BLE MCU line that uses multiple SDK branches tied to chip revisions or related parts. [#21192899]

Why does the Sonoff DW2 show up in listings with RF433 keywords when the teardown says it only uses WiFi?

Because sellers mixed the DW2 with the older DW1 in marketplace titles. The thread states that auction listings included RF433 keywords even though the examined DW2-Wi-Fi had Wi-Fi only and no 433 MHz radio. The seller’s own description explained the mismatch: the earlier DW1 version used RF433 MHz, while the offered version used Wi-Fi. So the keyword is listing carryover, not a hardware feature of the teardown unit. [#20767159]

How can I dump the Sonoff DW2 TH25Q80UA flash chip with a CH341A or FTDI bit-banging method?

You can dump it by removing the flash and reading it externally. 1. Desolder the TH25Q80UA because the thread author did not trust clip reading. 2. Read it with a CH341A in NeoProgrammer, which detected SPI ID EB6014. 3. Save the full dump, or bit-bang SPI with an FTDI adapter if needed; later posts confirmed a successful bit-banged dump after desoldering the same 8 Mbit / 1 MB chip. The original dump also revealed SDK-related strings and a PEM certificate when inspected. [#21187912]

Which Opulinks SDK should be used for the Sonoff DW2 module marked A2, and why did the A2 SDK work while the A3 SDK did not boot?

Use the OPL1000A2-SDK for the DW2 module marked A2. In direct testing, an A2 build of wpa2_station_gpio booted and joined Wi-Fi, while the A3 build did not boot on the same device. The tested working combination used A2 PatchData.txt, A2 opl1000_m0.bin, and the A2 example output binary. The thread later clarified that the module photos showed A2 on the chip, matching the SDK choice. In practice, the A2 firmware path matched the hardware layout and packing files, while A3 did not. [#21192488]

What is MW_OTA in the OPL1000 boot log, and what do messages like "This image is from MW_OTA [0]" and "MW_OTA [1]" mean?

MW_OTA is the Opulinks dual-image OTA storage area used to switch between firmware slots. In the thread, the boot log printed "This image is from MW_OTA [0]" before an update and "This image is from MW_OTA [1]" after a successful OTA flash. That shows the new image was written to the alternate slot and then executed after reboot. The same post notes that if you keep serving the OTA demo again, the device alternates between [0] and [1] on successive reboots. "MW_OTA" is firmware storage logic that keeps two bootable images for rollback-style updates. [#21196691]

Why does the OPL1000 ota_wifi demo fail with "ota_prepare fail," and how do I package the firmware correctly for OTA updates?

It fails when the OTA file is built in the wrong format. The breakthrough post showed the fix: first build normal opl1000.bin, then use Opulinks Download Tool v2.0.0 to combine it with opl1000_ota_loader.bin and generate opl1000_ota.bin in the OTA tab. After that, the OTA demo downloaded and flashed a 118,300-byte image successfully. Before that correction, the log stopped at "ota_prepare fail" even though HTTP worked. The full 1,024 KB factory backup still failed as an OTA payload, stopping around 167 KB, so raw flash dumps are not valid OTA images. [#21196691]

What steps are needed to compile and flash an OPL1000A2-SDK example like wpa2_station_gpio on a Sonoff DW2 using MSYS2 and arm-none-eabi-gcc?

Use MSYS2, install the ARM GCC toolchain, build the A2 example, then pack and flash it. 1. In msys64, run pacman -Syu and install mingw-w64-x86_64-arm-none-eabi-gcc, then add /mingw64/bin to PATH. 2. Build OPL1000A2-SDK\SDK\APS_PATCH\examples\wifi\wpa2_station_gpio with make to generate opl1000_app_m3.bin. 3. Pack it with A2 PatchData.txt and A2 opl1000_m0.bin, flash it, and the DW2 should boot, scan APs, and obtain a DHCP address such as 192.168.0.251 when credentials are correct. [#21192439]

How do I use the Opulinks Download Tool to flash OPL1000 binaries over UART, and why do I need to power-cycle the device when the tool is waiting on the COM port?

Use the Opulinks Download Tool, select the COM port and binary, then reconnect power when the tool starts waiting. The thread reports that flash start on this platform is like Beken: the DW2 enters the loader when power is reapplied while the tool is already waiting. That timing is why a power cycle is required. Tests confirmed that official binaries, AT firmware, and even full flash-chip dumps could be written this way over UART. The same workflow was used successfully with Download Tool 3.9.3.7012 for basic flashing, though OTA packaging later depended on v2.0.0. [#21190297]

Where is the Sonoff DW2 UART boot output available, and what can GPIO0 versus GPIO8 logs tell me during reverse engineering?

The DW2 exposes useful UART output on both GPIO0 and GPIO8, but they show different things. The thread states that GPIO8 has a PCB pad and prints the richer application boot log, including Wi-Fi scan activity and cloud retries. GPIO0 prints a shorter low-level boot stream such as "", "SPI load patch", and "BootMode 10". That split helps reverse engineering: GPIO0 is better for bootloader and image-slot clues, while GPIO8 is better for application behavior and pairing flow. [#21186407]

How can I control the Sonoff DW2 status LED from custom OPL1000 firmware, including the PinMux and Hal_Vic_GpioDirection settings needed for GPIO21?

Control the LED on GPIO21 after changing its PinMux role from PIN_TYPE_ICE_M3_CLK to PIN_TYPE_GPIO_OUTPUT_HIGH in hal_pin_config_project.h. The thread confirms the LED trace and datasheet mapping point to GPIO21. After that, custom code can call Hal_Vic_GpioOutput(GPIO_IDX_21, GPIO_LEVEL_HIGH) when Wi-Fi connects and drive it low on disconnect. A key lesson from the thread was that pin direction matters; output mode must be configured, not just the output level. Once corrected, the DW2 LED lit reliably on Wi-Fi connection. [#21193315]

Sonoff DW1 vs Sonoff DW2 — what are the practical differences in radio technology, cloud dependence, and firmware modification potential?

The DW1 is the older RF433 MHz design, while the DW2 uses Wi-Fi and a BLE-assisted setup flow. In practice, that means the DW2 can pair with eWeLink directly, but the thread repeatedly notes it is still cloud-dependent and was not easily cut off from the cloud at the start of the investigation. Firmware modification also differs: the DW2 needed OPL1000-family reverse engineering, flash dumping, SDK builds, and custom OTA packaging. So DW2 offers more software potential than DW1, but it also creates a much harder de-clouding path. [#20767159]

Why does the Sonoff DW2 pair in eWeLink but sometimes stay offline while looping coolkit.cc connection errors in the UART log?

It pairs because local provisioning succeeds, but it can still stay offline if the cloud connection fails. In the thread, the device paired successfully, yet the UART log looped mbedtls_net_connect() failed, ret:-0x44, HTTP connected fail, and repeated attempts to reach https://eu-dispd.coolkit.cc:443/dispatch/device. That means BLE/Wi-Fi setup and app-side registration can complete, while the sensor still cannot finish its cloud session. The practical symptom is an eWeLink device that appears added but remains offline. [#21189210]

What pairing method does the Sonoff DW2 use if it does not seem to support soft-AP mode, and how is BLE involved in WiFi setup?

The DW2 appears to use BLE for provisioning and then joins Wi-Fi as a station, not as a soft-AP. The thread notes that repeated resets never exposed an AP, and later analysis pointed to Opulinks blewifi examples where BLE handles configuration of the device’s Wi-Fi connection. One poster summarized it as BLE being the setup channel while the device is configured to connect to a Wi-Fi AP, not act as one. That explains why pairing can work even when no temporary AP is visible. [#21205368]

Which other devices have been found with OPL1000-family chips, such as the Tuya outdoor siren or Ebyte E103-W08A module, and how useful are they for OpenBeken porting and testing?

The thread found at least two useful additional targets: a Tuya outdoor 95 dB siren with solar and USB power, and the Ebyte E103-W08A module. The siren used an OPL1000 A2SA2121 chip with PUYA P25Q80H flash, making it a strong OpenBeken port candidate because it adds another real product beyond the DW2. The E103-W08A is useful for AT-command and module-level testing, but the thread called its form factor awkward and noted its small flash package. More hardware targets matter because low OPL1000 popularity was the main reason porting stalled. [#21174018]
Generated by the language model.
ADVERTISEMENT