logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Fiddling with my first Matter device - 10A 1CH switch [CB3S / BL2028N (BK7231N)]

divadiow 8754 93
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #91 21753895
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    yep yep OK.

    I had envisaged a new load of SBER and the UASCENT binaries in the BK7231N release zip, but maybe that's overkill, especially considering how rarely users post about them.
  • ADVERTISEMENT
  • #92 21849983
    ic3ek
    Level 15  
    Posts: 248
    Help: 3
    Rate: 30
    Hi , I have a question for you.

    Well, I have a Matter 4CH device , I wanted to upload OBK, but of course it is not so simple.
    The device is based on a BL2028 , and I have really uploaded the software many times , of course I have the ORI dump of the batch.

    But Uploading any version from the current REALSE 1.18.264 , the module does not issue an AP , RF restore does not work , Entering WIFI and password does not work.
    REALSE with the UA end does not work either, as I infer that this is the version intended for the UASENT device.
    Tried in options upload BK7231N (T2,T34) with skip keys, BK7231M, and BK7231N (T4), of course bootloader remains orginals from Matter device.

    The option that helped and the only one that works is to upload the file from this thread ENCRYPT_NEW_DOESBOOT_NOOTA_OpenBK7231N_UASCENT_QIO_bk7231m_qio_09b8b111cb80.bin
    But, of course, the OTA does not work here, but the module starts, you can set everything to your liking, and this is the only version I was able to upload correctly to UAM028.

    Can you, as experienced programmers, answer me why no other software will boot on this module?
    Of course, the electronics is not a problem for me, but the programming and reverse engineering is a bit of a problem.

    If someone needs the original batch of course I have it, and I can upload it here for review.

    And maybe one more thing, I have a PIN (GPIO) list for this device, maybe you can tell me how to put it into the device directory, because I saw that it does not exist, and I have it.

    Please help me to explain why only this one software works , others do not work with it ?
    Attachments:
    • readResult_BK7252N_QIO_4ch_n_t4_2026-24-2-17-01-53.bin (2 MB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #93 21850205
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    it takes a bit of fiddling because of the encryption key in efuse that Uascent devices have set.

    you need to load up your backup in the BK7231N Decryption tab in Easy Flasher, find keys, add default BK7231N partitions, encrypt bootloader - flash encrypted bootloader to 0x0. then encrypt the OpenBK7231M app partition only for burning to 0x11000. Ideally you'd then restore RF from your backup to correct location too.

    Screenshot of BK7231 Easy UART Flasher showing partition table and decryption log output

    A bit long-winded and I think it would still be better to have a Uascent QIO in artefacts, ready-built.

    I attach a file that has all that done. Do erase all on your device then flash this full dump from 0x0 under BK7231M mode or BK7231N with skip key check. This file includes the RF from your backup. Initial boot will unpack the ota rbl I put in at 0x12A000 and then boot into fresh OBK. OTA within OpenBeken works for me in testing.

    File is a 2mb dump of flash after this creation:
    Screenshot of BEKEN BKFIL showing BIN file list and a “Success” log message.

    To add template to device list, submit a PR for edit to this file https://github.com/OpenBekenIOT/webapp/blob/main/devices.json
    Attachments:
    • Uascent_1.0.1_4862379A_8612784B_85C5E258_75754528_OBK_1.18.264_RF.bin (2 MB) You must be logged in to download this attachment.
  • #94 21912588
    lesder1986
    Level 4  
    Posts: 7
    Good day to everyone. I'm sorry, as a rule, this device is from the manufacturer SBDV-00050. As soon as I haven't tried it, it doesn't start, the indicator doesn't light up, I can't even start it on backup anymore... in particular, he compiled the firmware, but it doesn't even stretch, he flashed it using programs like BKFIL, itchiptool, and Bk7231 Flasher. I understand that I'm doing something wrong. maybe I'm doing something wrong with the loader or the addresses... I don't even know anymore. Please help me figure it out. Thank you.

    [code]
    Code: YAML
    Log in, to see the code
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ The discussion centers on reverse engineering and firmware modification of a 10A 1CH Matter smart switch featuring a CB3S module with a BL2028N chip, initially thought to be BK7231N but later identified as BK7231M. Attempts to flash OpenBeken (OBK) firmware failed to produce a working access point or UART output, likely due to encryption key differences and firmware partition layout issues. The device uses uHome (Uascent) firmware rather than Tuya, with a unique coefficient key (4862379A 8612784B 85C5E258 75754528) that must be applied during encryption for successful booting. A newer encryption tool supporting CRC is required to generate a bootloader compatible with the device, as older tools produce non-booting images. Flashing the bootloader with correct keys and CRC enabled allows OBK to boot, but OTA functionality remains non-functional, possibly due to encrypted partition sections (e.g., 01PE) that differ from standard Tuya layouts. The community is working on integrating the new encryption method into OpenBK7231N build scripts to support these devices. Additional observations include the presence of ESP32-C3 based Matter devices with secure boot preventing flashing, and exploration of alternative modules (WB2S/CB2S, ESP32-C2) as replacements. Firmware dumps and boot logs have been collected and shared for further analysis. The challenges highlight the complexity of adapting open-source firmware to newer Matter devices with proprietary encryption and partition schemes.
Generated by the language model.
Today's popular

FAQ

TL;DR: For makers converting first-generation Uascent Matter switches, the reliable path is a 2MB dump-based workflow using custom encryption handling; as one expert put it, "both running" once the bootloader and app were rebuilt with the Uascent coeff key. This FAQ explains why stock OBK builds fail, how to recover AP/MAC, and which partitions matter on CB3S/BL2028N hardware. [#21466530]

Why it matters: These devices look like ordinary BK7231N hardware, but their non-Tuya bootloader, efuse keying, and partition layout break standard OpenBeken flashing assumptions.

Option Boots on Uascent BL2028N OTA status Typical use
Classic Tuya BK7231N QIO No N/A Standard Tuya-key BK7231N devices
Zero-keys / BK7231M-style build No on Uascent N/A Devices using zero-key or M-specific paths
ENCRYPT_NEW_DOESBOOT_NOOTA UASCENT QIO Yes No Early proof-of-concept boot on Uascent Matter hardware
Uascent-specific rebuilt bootloader + encrypted app Yes Yes in later testing Proper conversion path for Uascent devices

Key insight: The main blocker is not the BL2028N radio itself. The blocker is the Uascent efuse coeff key plus a matching bootloader and partition scheme; once those match, OpenBeken can boot and later OTA can work too. [#21753785]

Quick Facts

  • The original 10A 1CH Matter mini switch used a CB3S module, but shield removal showed a BL2028N chip, not a plain BK7231N marking match. [#20940846]
  • On these Uascent RT-Thread Matter devices, the observed OTA partition for manual RBL placement was 0x143000 during stock-bootloader experiments. [#21106354]
  • A standard OBK OTA session on converted hardware wrote from about 0x12A000 to 0x1A3400, then rebooted into the new app when the boot path was correct. [#21466523]
  • The recovered Uascent coeff key was 4862379A 8612784B 85C5E258 75754528; reading efuse often returned all zeros even when that key was actually active. [#21465033]
  • A different Matter relay examined later used an ESP32-C3, 4MB flash map, secure boot verification, and 0 plaintext flashes left, blocking normal Tasmota-style reflashing. [#20965795]

How do I flash OpenBeken onto a Uascent uHome Matter switch with a CB3S/BL2028N module and custom efuse encryption keys?

Use a dump-first, key-aware workflow. 1. Read the full backup and use Easy Flasher’s BK7231N Decryption tab to find keys and add default BK7231N partitions. 2. Encrypt a matching bootloader and flash it at 0x0. 3. Encrypt the OpenBeken app partition and burn it at 0x11000, then restore RF from backup if possible. A later working method packaged a full 2MB image so first boot unpacked an OTA RBL and entered fresh OBK. [#21850205]

Why does a BL2028N-based UAM028 Matter device fail to create an AP after flashing standard OpenBK7231N or BK7231M builds?

It fails because the device does not use the standard Tuya encryption and partition assumptions. Standard builds could boot partially, but logs showed mac=00:00:00:00:00:00 and no AP broadcast even after RF restore attempts. The thread tied this to Uascent-specific coeff keys, non-Tuya bootloader behavior, and different RF or OTA layout expectations. Until the bootloader and app were rebuilt for the correct key path, the device did not expose the expected OpenBK7231N access point. [#21115403]

What is the coeff key on BK7231N/BL2028N devices, and why does it matter when converting Uascent Matter hardware to OpenBeken?

The coeff key is the efuse-backed encryption key that the bootloader uses to validate or encrypt firmware on this hardware. "Coeff key" is an efuse-stored encryption parameter that binds firmware images to a device family, preventing ordinary Tuya-key or zero-key binaries from booting when the chip expects a different key set. For the Uascent devices in this thread, the working key was 4862379A 8612784B 85C5E258 75754528. Without that key, standard OBK builds booted poorly or not at all. [#21465033]

What does the 0x143000 OTA partition mean on these Uascent RT-Thread Matter devices, and how is it used during flashing?

It is the stock bootloader’s download area for OTA-style application updates. In early tests, flashing an unencrypted BK-N RBL directly to 0x143000 triggered the Uascent BK7231n_1.0.13 bootloader to inspect that partition on reboot. When the bootloader accepted the payload, logs showed the OTA start marker and then jumped into the app area at 0x10000. That is why direct RBL placement worked even before a fully standard OBK conversion existed. [#21106354]

Which steps are needed in Easy Flasher to restore stock firmware from a backup on a BK7231N or BL2028N module?

Use Easy Flasher’s restore mode and make the backup file recognizable. 1. Enable "allow backup restore". 2. Ensure the filename starts with readResult_BK7231N_QIO.. so it appears in the restore list. 3. Select the backup and flash it back to the device. That method successfully restored factory firmware after failed OBK tests on BL2028N hardware. [#20968329]

How can I tell whether a CB3S module is really BK7231N, BK7231M, or a BL2028N variant when the markings and behavior do not match?

Do not trust the module label alone; confirm by chip inspection and boot behavior. The CB3S module first looked like a normal BK7231N, but removing the shield revealed BL2028N on the die. Even then, boot signatures such as 0x00401C1C suggested an M-flavor or different keying path, which explained why ordinary N images failed. The safest identification method is: inspect the silicon, capture boot logs, and compare behavior after flashing known N or M test images. [#20940912]

What's the difference between classic Tuya BK7231N firmware, zero-keys BK7231M builds, and Uascent-specific QIO builds in OpenBeken?

They target three different encryption assumptions. Classic Tuya BK7231N builds use the normal Tuya key path and standard partition layout. Zero-keys or BK7231M-oriented builds target devices whose efuse path behaves like the all-zero or M-family workflow. Uascent-specific QIO builds use the recovered Uascent coeff key 4862379A 8612784B 85C5E258 75754528 and a matching bootloader build path. That is why a Uascent device could reject release binaries yet boot a Uascent-specific QIO image. [#21725546]

Why does the newer Beken cmake_encrypt_crc.exe tool with CRC produce a bootable Uascent bootloader when the older encrypt.exe does not?

Because the Uascent bootloader path needed the newer encryption flow plus CRC packaging. A direct test showed that encrypting bk7231n_bootloader.bin with cmake_encrypt_crc.exe -enc ... -crc finally booted BK7231N_1.0.1 on Uascent hardware, while the older no-CRC result did not. Later testing also showed that using -un-skip broke booting on Uascent. In short, the newer tool produced a bootloader format that the Uascent device would actually execute. [#21466119]

How do I recover Wi-Fi, MAC address, and AP broadcasting on an OpenBeken-flashed Uascent device when RF restore does not help?

Fix the bootloader and key path first, then revisit RF. In the failing state, OBK booted with SSID OpenBK7231N_8C000000 but logged mac=00:00:00:00:00:00 and still did not broadcast. After a corrected Uascent bootloader and app were used, the low-level log showed a real MAC like 38:1f:8d:d8:14:d7, and the AP path initialized normally. RF restore alone did not solve the issue when the core bootloader and partition assumptions were still wrong. [#21466523]

What is an RBL file in the BK7231/OpenBeken ecosystem, and how is it different from flashing a full 2MB QIO dump?

An RBL is the OTA-style application package, not a whole-flash image. "RBL" is an RT-Thread OTA firmware container that carries an app payload for the bootloader’s download partition, rather than a complete flash layout with bootloader, RF, and data regions. In this thread, users flashed RBL files to 0x143000 or 0x12A000 for OTA processing, while a 2MB QIO dump replaced the complete flash from 0x0. Use RBL for bootloader-managed updates and QIO for full-device recovery or conversion. [#21727545]

When OTA starts but the device reboots or bricks afterward, what should I check in the bootloader, partition table, and 01PE data?

Check whether the bootloader can still parse the partition metadata after encryption. The thread linked failed OTA to bootloaders where the 01PE partition area became scrambled by the newer encryption flow. One working theory was that the app could boot, but OTA failed because the download or app partition header became unreadable after repacking. Also verify that the bootloader’s partition table points to the expected download area, such as 0x12A000 or 0x143000, for that specific build path. [#21725675]

How does BKFIL compare with Easy Flasher and BK Writer for dumping, restoring, and custom-writing BK7231N/BL2028N firmware?

BKFIL was the most useful for staged custom writes, Easy Flasher was best for guided restore and decryption, and BK Writer was one tool among several in the workflow. The thread used BKFIL to queue multiple files, wipe from 0x0, and place bootloader plus OTA pieces exactly. Easy Flasher handled backup restore, RF restore attempts, and later key discovery in the decryption tab. BK Writer 1.7.5 appeared in the toolchain, but the successful Uascent conversion relied more on BKFIL and Easy Flasher. [#21115403]

What can I do with an ESP32-C3 Matter relay switch that has secure boot and flash encryption enabled, when Tasmota or custom firmware won't flash?

Treat it as a hardware-mod case, not a normal serial-flash target. The boot log showed secure boot v2, flash encryption enabled, 0 plaintext flashes left, and a 4MB layout on the ESP32-C3 module, so custom firmware flashing was effectively blocked. In the thread, the practical options were to leave it stock, transplant a different module, or replace the radio board with something pin-compatible like a WB2S, CB2S, or another small module. [#20965795]

Where should I submit GPIO mappings or a template for a new Matter switch so it appears in the OpenBeken device directory?

Submit a pull request that edits the OpenBeken webapp device template list. The thread’s direct guidance was to add the new switch mapping to devices.json in the OpenBeken webapp repository. That is the file used for the device directory entry, so a clean GPIO map and tested template belong there rather than only in a forum attachment. [#21850205]

Why does the ENCRYPT_NEW_DOESBOOT_NOOTA UASCENT QIO image boot on some BL2028 Matter devices while current OpenBeken release binaries and UA files do not?

Because that image was built with the Uascent-specific encryption path that matched the device’s efuse coeff, while normal release binaries used the wrong assumptions. A user with a Matter 4CH BL2028 device reported that release 1.18.264 binaries, UA files, BK7231N T2/T34, T4, and BK7231M options all failed to bring up AP or Wi-Fi. The only image that booted was ENCRYPT_NEW_DOESBOOT_NOOTA_OpenBK7231N_UASCENT_QIO..., which fits the thread’s earlier finding that Uascent hardware needed a custom bootloader and encryption flow. [#21849983]
Generated by the language model.
ADVERTISEMENT