logo elektroda
logo elektroda
X
logo elektroda

Installing Openbk or ESPHome on TOB9-63M Circuit Breakers: Issues with Cloudcutter and Lightleak

SVA 8220 26
Best answers

How can I install OpenBeken or ESPHome on a TOB9-63M circuit breaker when Cloudcutter/LightLeak do not find a matching profile and the device does not switch to the expected AP mode?

If Cloudcutter/LightLeak cannot identify the TOB9-63M, the thread’s recommendation is to open one unit, make a 2 MB flash backup over wires, and flash OpenBeken by UART instead [#20724174][#20854613] The board inside uses a CBU module with BK7231N, and the energy chip is BL0942; the working OBK pin setup reported was P9=LED1, P15=WIFILED, P17=BTN_TGL_ALL, P24=BridgeFWD;1, and P26=BridgeREV;1 [#20854696][#20855531] After flashing, `startDriver BL0942` worked, and if it does not, the suggested fallback is `startDriver BL0942SPI` [#20854728][#20855531] One user also reported that configuring pins 24 and 26 as relay roles instead of bridge roles caused heating and incorrect no-load power readings, so the bridge configuration matters [#20869347] The device template was later added to the OpenBeken webapp/device list [#20856127]
Generated by the language model.
ADVERTISEMENT
  • #1 20723812
    SVA
    Level 2  
    Posts: 4
    Rate: 1

    I got a bunch of these TOB9-63M (https://www.aliexpress.com/i/3256805380190385.html?gatewayAdapt=4itemAdapt) circuit breakers with energy monitoring.
    The device is welded shut, so opening it to install openbk using gpio is not a very viable option (don't want duct-taped switches in main breaker panel).
    Wanted to load openbk or esphome variant on this (since all my other devices are on it and connected to HA). Tried cloudcutter (and lightleak) and setup breaker in AP mode. Can't find a profile for this, and by firmware version (1.0.5), tried all the options, but none work. The first step completes OK, but the device stays on and when I restart and start AP mode, it continues to have AP SmartLife-xxxx and not the A* that is expected by cloudcutter.
    Lightleak doesn't even connect to the device (keeps connecting/disconnecting from the SmartLife-xxxx AP).
    Hate to open it (too many devices and would have to break it open making it unusable).
    Any ideas?
  • ADVERTISEMENT
  • #2 20724174
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14589
    Help: 654
    Rate: 12611
    I am afraid that you may need to open at least one of TOB9's and take 2MB firmware dump by wires.
    Helpful post? Buy me a coffee.
  • #3 20853888
    jony4t
    Level 9  
    Posts: 21

    Hello partners. A few days ago I received the tomz tob9-63. I decided to open the device, it is relatively easy and there are no marks left, you have to extract the golden pins with a flat screwdriver and separate the two faces, inside there is a CBU. Attached photos. I'll try to extract a backup. If you need any more photos, tell me.


    Close-up of a circuit board removed from a device. Interior of an electronic device with visible components and wiring.
  • #4 20853912
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14589
    Help: 654
    Rate: 12611
    Is that BL0942 there?
    Helpful post? Buy me a coffee.
  • #5 20854524
    jony4t
    Level 9  
    Posts: 21

    p.kaczmarek2 wrote:
    Is that BL0942 there?


    Yes. Is it?

    Added after 10 [minutes]:

    It will be enough to install openbeken and configure the pin with BL0942. Or will we have to follow the steps in the link?

    https://www.elektroda.com/rtvforum/topic3995777-30.html#20852685

    Added after 12 [minutes]:

    It will be enough to install openbeken and configure the pin with BL0942. Or will we have to follow the steps in the link?

    https://www.elektroda.com/rtvforum/topic3995777-30.html#20852685
  • #6 20854613
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14589
    Help: 654
    Rate: 12611
    The topic you linked is about TuyaMCU device. I am not sure if your device is TuyaMCU-based yet. It may be worth checking whether that BL0942 is connected directly to BK7231 (in UART or SPI mode, it's also worth checking, we support both), or maybe is it connect via TuyaMCU? Is there a secondary MCU on the board?

    Can you check with multimeter whether RX/TX of BL042 connects directly to RX1/TX1 of WiFi module?

    Still, do 2MB flash backup and try flashing OBK.
    Helpful post? Buy me a coffee.
  • #7 20854696
    jony4t
    Level 9  
    Posts: 21
    I DON'T watch anymore MCU. I am currently attaching the backup copy and the JSON.

    Device configuration, as extracted from Tuya:
    - Button (channel 1) on P17
    - LED (channel 1) on P9
    - Bridge Relay On (channel 1) on P24
    - Bridge Relay Off (channel 1) on P26
    - WiFi LED on P15
    Device seems to be using CBU module, which is using BK7231N.
    And the Tuya section starts, as usual, at 2023424

    JSON

    Code: JSON
    Log in, to see the code
    Attachments:
    • readResult_BK7231N_QIO_2023-10-12-12-33-04.bin (2 MB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #8 20854728
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14589
    Help: 654
    Rate: 12611
    Good job, so all you need is startDriver BL0942 and calibrate.
    If that is not working, then you need to retry with startDriver BL0942SPI.
    Helpful post? Buy me a coffee.
  • #9 20855531
    jony4t
    Level 9  
    Posts: 21
    Hello, good evening.
    I have flashed the CBU module using UART successfully.

    To configure the pins:

    P9 = LED 1
    P15 = WIFILED
    P17 = BTN_TGL_ALL
    P24 = BridgeFWD;1
    P26 = BridgeREV;1


    The BL0942 works perfectly running startDriver BL0942. I haven't had time to calibrate it yet.

    Screenshot of the OpenBK7231N configuration interface with pin assignments.
  • #10 20855593
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14589
    Help: 654
    Rate: 12611
    Please include JSON template from the web App if you can
    Helpful post? Buy me a coffee.
  • #11 20855733
    jony4t
    Level 9  
    Posts: 21
    Would that be correct? Thanks for your help.


    View of three TOMZN WiFi circuit breakers on a DIN rail with a mobile app

    Code: JSON
    Log in, to see the code
  • #12 20856127
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14589
    Help: 654
    Rate: 12611
    Helpful post? Buy me a coffee.
  • #13 20857158
    jony4t
    Level 9  
    Posts: 21

    Hello, good evening.

    Today, I calibrated tomz.

    I have noticed that the real power is changed with the reactive power, therefore the power factor is wrong.
    Furthermore, when consumption is removed, the counter never reaches zero.

    How can I change the data from reactive power to power?

    And how can I make the consumption zero?

    TOMZ_1 smart meter interface displaying energy data, including active, apparent, and reactive power.
  • #14 20858182
    jony4t
    Level 9  
    Posts: 21

    At the moment, I have seen that flags 38 contemplate the option of setting the power to zero when the relays are open.
    I have not been able to correct or change the MQTT topic from real power to reactive power.
  • #15 20858198
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14589
    Help: 654
    Rate: 12611
    Okay, so the command to clear stats is: EnergyCntReset
    as per our docs: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md
    So you think that values of real power and reactive power are swapped?
    Which driver are you using, BL0942 or BL0942SPI?

    I am not the author of BL0942SPI, there might be a bug in the code that I need to fix...
    Helpful post? Buy me a coffee.
  • #16 20858227
    jony4t
    Level 9  
    Posts: 21

    I am using BL0942. In other plugs, they work fine. But in this new device, I don't know why it appears rotated. I connect a 400W power resistor. 400VAR appears on the screen. Since it is a pure resistance, it should not be reactive energy.
    Screenshot of the TOMZ_1_SMARTMETER interface showing energy measurements with values of 0W active power and 7.1 VA apparent power.
  • ADVERTISEMENT
  • #17 20858254
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14589
    Help: 654
    Rate: 12611
    And you have other BL0942 devices and they work fine? This is very strange.


    Well, maybe I could create a flag for you, something like "swap" option, but it seems very odd.

    Are all your devices on the same OBK version? Maybe something was broken in the update?
    Helpful post? Buy me a coffee.
  • #18 20859055
    jony4t
    Level 9  
    Posts: 21
    Since I have a second unit of the same model, I'll flash it to see if the same thing happens. I'll comment on it this afternoon.


    Added after 10 [hours] 17 [minutes]:

    hello, good afternoon. I have tried with the other device I have with BL0942. Same brand and model. Ocurrs the same. The power appears in reactive power, and not in active power as it should be. OpenBK7231N control panel screen displaying frequency, voltage, current, and power information.
  • ADVERTISEMENT
  • #19 20868929
    jony4t
    Level 9  
    Posts: 21

    I have new news about the active power measurement error in the TOMZ 63. When flag 25 is activated, it begins to measure but as if it were pouring energy, negative data appears. Likewise, the reactive energy is very high. Energy monitoring system interface with negative active power
  • Helpful post
    #20 20869347
    johanvdm
    Level 1  
    Posts: 1
    Help: 1
    Rate: 2

    I have the TOMZN TOB9-VAP. After having it flashed with OBK, I have been struggling with the device getting very hot, also experiencing it to report a couple of Watts even if it has no load powered. Turns out that my config for pins #24 and #26 was incorrect. It should not be configured for Rel and Rel_N respectively. The following pin config worked for me:
    "24": "BridgeFWD;1",
    "26": "BridgeREV;1"
    Also check your channel grouping. Mine was "1".

    This solved both the heating problem as well as the no-load current reporting problem.
    For the latter, I had Flag #25 & #38 also set.

    Anyway, the above worked for me. Worth checking your PIN config out.
    I also think the device template might need to be double-checked, as it also shows the Pin #24 and #26 as relay: https://github.com/OpenBekenIOT/webapp/commit/5e6cd9f5f9e4254d279ed27943c299b585337817

    For a similar setup, see also: https://www.elektroda.com/rtvforum/topic3934580.html

    Hope this helps.
  • #21 20869388
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14589
    Help: 654
    Rate: 12611
    Thank you for reporting the problem, @johanvdm . I don't have those devices personally so it's hard for me to check what config will work the best, but you're not the first one to point this issue, so I decided to change all pins of similiar devices to bridge roles:
    https://github.com/OpenBekenIOT/webapp/commit/6e0ac72c19065d843c4af22c0324918dcaf8dcb3
    I hope this will help. If something is still incorrect, let me know.
    Helpful post? Buy me a coffee.
  • #22 20869672
    jony4t
    Level 9  
    Posts: 21

    Good morning. It is true that the device got hot. I have changed the remote configuration, I will check that the temperature has dropped.
    I was totally unaware of this type of bridge relay.
    It is exactly the same device that you show in the link. https://www.elektroda.com/rtvforum/topic3934580.html
    Seeing that it worked, I thought it was the correct function.
  • #23 20869685
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14589
    Help: 654
    Rate: 12611
    I am glad to hear that the problem is resolved, let me know i anything else is needed or if you find any other incorrect template on our devices database
    Helpful post? Buy me a coffee.
  • #24 21157691
    polarbeer
    Level 1  
    Posts: 1
    Rate: 1
    I have set this up and allocated the pins as follows:

    
    {
      "vendor": "Tuya",
      "bDetailed": "0",
      "name": "Full Device Name Here",
      "model": "enter short model name here",
      "chip": "BK7231N",
      "board": "TODO",
      "flags": "0",
      "keywords": [
        "TODO",
        "TODO",
        "TODO"
      ],
      "pins": {
        "9": "LED;1",
        "15": "WifiLED_n;0",
        "17": "Btn;1",
        "24": "BridgeFWD;1",
        "26": "BridgeREV;1"
      },
      "command": "backlog startDriver BL0942;",
      "image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
      "wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
    }
    


    However, the power is still incorrect for a purely resistive load:
    Screenshot of OpenBK7231N interface with electrical parameter readings.
  • #25 21157709
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14589
    Help: 654
    Rate: 12611
    I will add this template to database, what is your device model? Is it 100% the same as in the first post - TOB9-63M?
    Helpful post? Buy me a coffee.
  • #26 21306290
    agarg
    Level 3  
    Posts: 9
    >>20853888
    I wonder if the relay in the 2nd picture can handle 63 amps. From size, I would have guessed 16 amps!
  • #27 21335022
    felipecrs
    Level 1  
    Posts: 1
    >>20869347 @johanvdm, do you remember what firmware version your TOMZN TOB9-VAP was running?

    Mine is running 1.0.15 and I was not able to flash it with cloudcutter.

    Do you happen to have your firmware dump too? If it is the same version, maybe cloudcutter devs can add support for it.

    Thanks in advance.

Topic summary

✨ The discussion addresses challenges in installing OpenBK or ESPHome firmware on TOB9-63M circuit breakers with energy monitoring, which are sealed and difficult to open for GPIO access. Initial attempts using Cloudcutter and Lightleak tools failed due to lack of device profiles and firmware compatibility issues (version 1.0.5). Community members confirmed the device uses a BK7231N chip with a CBU board and a BL0942 energy monitoring IC. Successful flashing requires extracting a 2MB firmware dump by opening the device, which is relatively easy by removing golden pins. A device configuration template was developed, assigning pins for LED, WiFi LED, button, and bridge relay control (P9, P15, P17, P24, P26) and using the "startDriver BL0942" command. Calibration revealed issues with power factor and reactive power readings being swapped with active power, which is unusual compared to other BL0942 devices. Solutions included adjusting flags (e.g., #25 and #38) and correcting pin configurations for bridge relays to prevent device overheating and erroneous no-load power reporting. The device template was added to the OpenBekenIOT webapp device list for broader support. Further firmware version differences (e.g., 1.0.15) may require additional Cloudcutter support. The discussion also highlights the importance of verifying hardware connections (e.g., BL0942 to BK7231 UART/SPI) and the potential need for custom flags to address measurement anomalies.
Generated by the language model.

FAQ

TL;DR: For TOB9-63M owners, the reliable path was UART flashing with a full 2MB backup, not Cloudcutter. One expert answer was: "do 2MB flash backup and try flashing OBK." Working OpenBeken settings used a CBU/BK7231N module, BL0942 metering, and BridgeFWD/BridgeREV on pins 24/26. [#20854613]

Why it matters: These breakers can stay stuck on stock SmartLife firmware, and the wrong OpenBeken pin roles can cause heat, false power readings, and a bad template.

Method What happened in the thread Reliability in this case
Cloudcutter Step 1 completed, but AP stayed SmartLife-xxxx instead of switching Low
Lightleak Connected and disconnected from SmartLife-xxxx without succeeding Low
UART flashing Successfully flashed CBU/BK7231N and enabled BL0942 High

Key insight: The thread’s turning point was not a new exploit. It was opening one unit cleanly, taking a 2MB dump, then using UART with the correct bridge-relay pin map.

Quick Facts

  • The working hardware identified in the thread was a CBU module with BK7231N, and the Tuya JSON showed stock firmware fields including cadv: 1.0.5 and swv: 1.0.18. [#20854696]
  • The confirmed OpenBeken pin map was P9 LED, P15 WiFi LED, P17 button, P24 BridgeFWD, and P26 BridgeREV. [#20855531]
  • Energy metering worked with the command startDriver BL0942; if that failed, the fallback suggested was startDriver BL0942SPI. [#20854728]
  • A wrong role on pins 24/26 caused two real effects: the breaker got very hot and reported a couple of Watts with no load. Correcting both pins to bridge roles fixed both issues. [#20869347]
  • The thread documented two stock firmware versions tied to flashing trouble: 1.0.5 on TOB9-63M and 1.0.15 on another unit that also could not be flashed with Cloudcutter. [#20723812]

How can I install OpenBeken or ESPHome on a TOMZN TOB9-63M circuit breaker when Cloudcutter and Lightleak both fail?

Use UART flashing after opening one breaker and taking a full 2MB backup. In the thread, Cloudcutter failed on firmware 1.0.5, while UART flashing of the CBU/BK7231N succeeded and OpenBeken ran normally. A practical 3-step path is: 1. open one unit cleanly, 2. dump the full flash, 3. flash OBK and configure BL0942 plus the correct pins. [#20855531]

Why does a TOB9-63M stay in the SmartLife-xxxx AP mode instead of switching to the A-* AP expected by Tuya Cloudcutter?

It stayed in SmartLife-xxxx because the exploit path did not complete on that firmware and profile combination. The first report says step one finished, but after reboot the breaker still exposed SmartLife-xxxx instead of the A-* AP Cloudcutter expects. That behavior was seen on stock firmware version 1.0.5. [#20723812]

What is Lightleak in the context of flashing Tuya BK7231 devices, and how is it different from Cloudcutter?

"Lightleak" is a flashing method that targets Tuya Wi‑Fi devices over their temporary AP, unlike manual UART wiring, and the thread shows it behaved differently from Cloudcutter because it never held a stable connection. Here, Cloudcutter completed an initial step, while Lightleak kept connecting and disconnecting from the SmartLife-xxxx AP and did not flash the unit. [#20723812]

What is the BL0942 chip in a TOMZN TOB9-63M, and what role does it play in energy monitoring?

"BL0942" is an energy-measurement chip that reports electrical values such as power, and in this breaker it is the metering component OpenBeken must start with a dedicated driver. The board photos were identified as containing a BL0942, and the final working setup used startDriver BL0942 for energy monitoring. [#20854728]

Which pin configuration works for OpenBeken on the TOMZN TOB9-63M with a CBU/BK7231N module?

The working map was P9 = LED;1, P15 = WifiLED;1, P17 = Btn_Tgl_All;1, P24 = BridgeFWD;1, and P26 = BridgeREV;1. That exact configuration was reported after a successful UART flash on a CBU module using BK7231N. It is the most concrete template confirmed in the thread. [#20855733]

What is the proper way to open a welded-shut TOMZN TOB9-63M without leaving visible damage so a firmware backup can be taken?

Open it by extracting the gold-colored pins with a flat screwdriver and then separating the two faces. One user reported this was relatively easy and left no visible marks, which made it practical to access the board for backup and UART flashing. That post also confirmed a CBU module inside. [#20853888]

When flashing a TOB9-63M by UART, how do I make a full 2MB firmware backup before installing OpenBeken?

Make the backup before flashing and save the entire 2MB contents of the module’s flash. The thread’s guidance was explicit: open one unit, connect by wires, take a 2MB dump, and only then try OpenBeken. That backup mattered because the device was not yet supported by Cloudcutter. [#20724174]

How do I determine whether the BL0942 is connected directly to the BK7231N or through a secondary TuyaMCU?

Check whether the BL0942 RX and TX lines go directly to RX1 and TX1 of the Wi‑Fi module, and verify whether a second MCU exists on the board. The thread suggests using a multimeter for that continuity check because the correct OpenBeken driver depends on whether BL0942 talks directly to BK7231N or through a TuyaMCU path. [#20854613]

Why should pins 24 and 26 be configured as BridgeFWD and BridgeREV instead of relay roles on these TOMZN breakers?

They should be bridge roles because relay roles caused functional and thermal problems on this hardware. A user reported that configuring pins 24 and 26 incorrectly as normal relay outputs made the device get very hot and show no-load power, while BridgeFWD;1 and BridgeREV;1 solved both issues. OpenBeken’s template was then changed for similar devices. [#20869347]

What causes a flashed TOB9-63M or TOB9-VAP to get hot and report phantom power with no load connected?

The main cause reported here was a wrong pin configuration on outputs 24 and 26. When those pins were set as standard relay roles instead of bridge roles, the breaker ran hot and reported a few Watts with no load. After changing them to BridgeFWD and BridgeREV, both symptoms stopped. [#20869347]

How do I start and calibrate BL0942 in OpenBeken, and when should I try BL0942SPI instead?

Start with startDriver BL0942 and calibrate after confirming values appear. The thread says that is the first driver to use on this breaker, and only if it does not work should you retry with startDriver BL0942SPI. One user confirmed BL0942 worked immediately after flashing, before calibration. [#20855531]

Why does a purely resistive load on the TOMZN TOB9-63M show up as reactive power instead of active power after flashing OpenBeken?

Because this device family showed a measurement-mapping problem in the thread, even with BL0942 running. One test used a 400W resistive load, yet the interface showed about 400VAR reactive power instead of active power. The same behavior was reproduced on a second unit of the same brand and model, so it was not a one-off board fault. [#20859055]

Which OpenBeken flags help force no-load power readings to zero on TOMZN TOB9-63M breakers, and how does EnergyCntReset fit in?

Flag 38 was reported as the option that can force power to zero when the relays are open, and another user said flags 25 and 38 helped with no-load behavior after fixing the pin map. EnergyCntReset is separate: it clears stored energy statistics, not the live pin-role problem. That command was explicitly named in the thread. [#20858198]

Cloudcutter vs UART flashing for TOMZN TOB9-63M and TOB9-VAP breakers — which approach is more reliable when the stock firmware version is 1.0.5 or 1.0.15?

UART flashing was more reliable in this thread. Cloudcutter failed on a TOB9-63M with firmware 1.0.5, and a later report says another unit on 1.0.15 also could not be flashed with Cloudcutter. By contrast, UART flashing succeeded on the CBU/BK7231N hardware and produced a usable OpenBeken setup. [#21335022]

How realistic is the 63A rating of the relay used inside the TOMZN TOB9-63M, and what safety considerations should I keep in mind before using it in a main breaker panel?

The thread does not verify the 63A claim, and one poster openly questioned it because the internal relay looked more like a 16A part by size. Treat the 63A label as unconfirmed in this discussion. Also avoid using a damaged or improvised unit in a main panel, because the original goal was to avoid breaking cases open and ending up with unusable, taped-together breakers. [#21306290]
Generated by the language model.
ADVERTISEMENT