logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Smart cube with power metering, 2 phase with clamps, 2x BL0942, CBU module, BK7231N

XJ_ 8205 118
Best answers

How can I get the second BL0942 working on UART2 on a BK7231N CBU device?

The zero readings on UART2 were not caused by the BL0942 address; the real problem was UART2 receive on the Beken SDK, which XJ_ traced to an SDK bug and first worked around with polling before finding a proper fix [#21299065][#21304930][#21310881] After the patch, UART2 BL0942 reading was confirmed working on BK7231N and also on BK7231T, with a test showing normal packet reception and the expected BL0942 buffer messages [#21324450][#213130130?]. For dual-sensor devices, the merged solution is to use `BL0942opts 3` plus `startDriver BL0942` in `autoexec.bat`, with `flag 26` disabled; UART1 stays the main sensor with energy calculation, and UART2 is informational only [#21432573] When both UARTs are used, `logtype none` is recommended to avoid serial logging interference [#21432573] For Home Assistant/MQTT, the second sensor reports with the `_b` suffix [#21432573]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • Helpful post
    #1 21298953
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    I have new device energy power meter with 2 BL0942 chips - one over UART 1 and the other over UART 2.

    There is no Tuya Chip.

    BL0942 on UART1 working good.
    But, I only get zeros on the second uart {with flag 26 set to 1}

    Has anyone working BL0942 on UART2 ?

    The module is a CBU (BKT7231N)
    LED on P9
    Button on P24

    Flashing is done without desoldering (GND, 3V3, RX1, TX1), no need for CEN, just simple turning on the device for flashing routine.

    Close-up of an electronic circuit board with various components, including capacitors and a module labeled CBU. Close-up of an electronic module with installed capacitors, resistors, and a chip. Top view of an electronic board with various components, including a CBU module. Circuit board of an energy measurement module with electrical components. Printed circuit board with two visible BL0942 integrated circuits and electronic components.

    I found another user with a similar device: https://www.elektroda.com/rtvforum/topic3946128-90.html#21050660.
  • ADVERTISEMENT
  • #2 21298984
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14589
    Help: 654
    Rate: 12611
    So basically... we want to first measure through first BL0942, then toggle UART, and then use second BL0942?

    Would such solution work for you? How often do you need to sample? Every two second (first second first BL0942, second second second BL0942?)

    Still... our current/voltage/power variables are global...
    Helpful post? Buy me a coffee.
  • #3 21298994
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    >>21298984
    As first step, I need to get working BL0942 on UART2
    Meaning, I can then manually switch between 1 and 2 [using same variables]

    Added after 23 [minutes]:

    I've tried to change BL0942 address @drv_bl0942.c

    #define BL0942_UART_ADDR 0 // 0 - 3

    BL0942 on UART1 only working if BL0942_UART_ADDR 0 is set (default)

    BL0942 on UART2 does not work - I've tested BL0942_UART_ADDR with values 0,1,2,3
  • ADVERTISEMENT
  • #4 21299065
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14589
    Help: 654
    Rate: 12611
    This is BL0942 code:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_bl0942.c#L18
    UART is set by UART_InitUART call in UART_InitUART.

    Added after 3 [minutes]:

    XJ_ wrote:

    I've tried to change BL0942 address @drv_bl0942.c

    #define BL0942_UART_ADDR 0 // 0 - 3

    BL0942 on UART1 only working if BL0942_UART_ADDR 0 is set (default)

    BL0942 on UART2 does not working - I've tested BL0942_UART_ADDR with values 0,1,2,3

    I do not think it's UART address.
    If you search for BL0942_UART_ADDR ...
    you can see it's used here:
    Code: C / C++
    Log in, to see the code

    This is something else, not UART port index, but a packet index....

    I think you need to rather look at UART_InitUART, but....

    Actually it seems it's called every frame?

    Code: C / C++
    Log in, to see the code

    It may require futher investigation...
    Helpful post? Buy me a coffee.
  • Helpful post
    #5 21299078
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    >>21299065
    I know, I've also tried to stop and start bl0942, but no success.

    How can I disable logging on comport (by default)?

    Added after 3 [minutes]:

    p.kaczmarek2 wrote:
    I do not think it's UART address.

    I know this is the BL0942's internal address - I tried that to see if Tuya changed the address for the other BL0942.

    Added after 2 [hours] 20 [minutes]:

    I added the received bytes log to the bl0942.c code.

    Code: text Expand Select all Copy to clipboard
    static int BL0942_UART_TryToGetNextPacket(void) {
   int cs;
   int i;
   int c_garbage_consumed = 0;
   byte checksum;

   cs = UART_GetDataSize();

   ADDLOG_WARN(LOG_FEATURE_ENERGYMETER,
                    "bl0942 uart bytes %02X",
                    cs);


    I tested it with an RS232 to USB PC converter connected at the same time on individual pins:

    If UART 1 is set
    request goes to TX1 2byte - also verified in PC
    response on RX1 comes with 17 bytes - also verified on the PC
    Code: text Expand Select all Copy to clipboard
    Warn:EnergyMeter:bl0942 uart bytes 17


    If UART 2 is set
    request goes to TX2 2byte - also verified in PC
    response on RX2 in comes with 0 bytes - but the PC receives 17 bytes
    Code: text Expand Select all Copy to clipboard
    Warn:EnergyMeter:bl0942 uart bytes 00


    That is the problem is somewhere in the reception of data on UART2 - even if the data arrives on the pin, the routine in the bl0942.c code will not receive anything.

    I will keep searching.
  • #6 21299291
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14589
    Help: 654
    Rate: 12611
    I see, that's interesting. Now that I think about it, I don't remember ever trying to receive data on UART2...

    But do you mean that UART2 receive never works? Or does it work, if you enable it directly after reboot? And only runtime change is broken?

    This function is used to set receive callback:
    https://github.com/search?q=repo%3Aopenshwpro...OpenBK7231N+bk_uart_set_rx_callback&type=code
    Tuya seems to be using it with:
    Code: C / C++
    Log in, to see the code

    They don't seem to use UART2 much:
    https://github.com/search?q=repo%3Aopenshwprojects%2FOpenBK7231N%20BK_UART_2&type=code
    Here is UART ISR:
    https://github.com/openshwprojects/OpenBK7231...k7231n_os/beken378/driver/uart/uart_bk.c#L772

    I'm not able to check myself now, but I'd try to narrow the case in order to determine what may be going wrong...
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • Helpful post
    #7 21299299
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    p.kaczmarek2 wrote:
    But do you mean that UART2 receive never works?

    Yes, I've found, that:

    bk_uart_set_rx_callback >> uart_read_byte >> UART_READ_BYTE on UART2 return count 0 {if SetFlag 26 1}

    And if I physically connect pins RX1 to RX2 {if SetFlag 26 1} the RX1 is receivíng the data {and BL0942 show results} WHEN SetFlag 26 1 !!

    Code: text Expand Select all Copy to clipboard
    Info:MAIN:Time 1515, idle 187931/s, free 66168, MQTT 1(1), bWifi 1, secondsWithNoPing 1445, socks 3/38 
Warn:EnergyMeter:rc 0  <<<<<<  nothing on RX2
Warn:EnergyMeter:rc 23 <<<<<<  data received on RX1
Warn:EnergyMeter:bl0942 uart bytes 17  <<<<<<  data accepted from RX1
Info:MAIN:Time 1516, idle 194056/s, free 62992, MQTT 1(1), bWifi 1, secondsWithNoPing 1446, socks 3/38 


    Its too late, I'll continue today in the evening

    Added after 3 [minutes]:

    If UART2 set, code below is returning 0
    Code: text Expand Select all Copy to clipboard
          Warn:EnergyMeter:rc 0
      Warn:EnergyMeter:bl0942 uart bytes 00

    Code: text Expand Select all Copy to clipboard
    #if PLATFORM_BK7231T | PLATFORM_BK7231N
void test_ty_read_uart_data_to_buffer(int port, void* param)
{
    int rc = 0;
    int cnt = 0;

    while((rc = uart_read_byte(port)) != -1) {
      cnt++;
      UART_AppendByteToReceiveRingBuffer(rc);
   }
   ADDLOG_WARN(LOG_FEATURE_ENERGYMETER,
                    "rc %d",
                    cnt);
}
#endif


    Added after 4 [minutes]:

    p.kaczmarek2 wrote:
    Or does it work, if you enable it directly after reboot? And only runtime change is broken?

    No, it does not work independent on state. I've tried to force UART2 and force to disable logging without success. But, I'll keep investigating.
  • #8 21299630
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14589
    Help: 654
    Rate: 12611
    I've seen a Github comment saying that UART2 IRQ is broken on SDK level and that they solved this issue by periodically polling the UART2 RX themselves.
    Helpful post? Buy me a coffee.
  • #9 21299865
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    >>21299630
    User @LucaArena sent me this info already, I'll check it.
  • #10 21300789
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14589
    Help: 654
    Rate: 12611
    Good to hear. So, did you try the polling approach?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #11 21300816
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    p.kaczmarek2 wrote:
    Good to hear. So, did you try the polling approach?

    I am currently working on it. So far I am not able to receive any damn byte from UART2.
  • #12 21304930
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    >>21300816

    Finally, working UART2 solution found. It must be done using (*runQuickTick)() @ drv_main.c by calling new void BL0942_UART_RunEveryTick() - but only if UART2
    choosen.

    I'm working on it. When tests done (and successful), I'll make a test branch.

    Code: text Expand Select all Copy to clipboard
    #if PLATFORM_BK7231T | PLATFORM_BK7231N
void BL0942_UART_RunEveryTick(void) {
  if (helper_usinguart2) {
    test_ty_read_uart_data_to_buffer(1, 0); //BK_UART_2
  }
}
#endif
  • #13 21305255
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14589
    Help: 654
    Rate: 12611
    That's how I would imagine it too, however, maybe it would be better to call test_ty_read_uart_data_to_buffer in drv_uart.c and not in BL0942? That way the fix will also work for other drivers using uart, like TuyaMCU. Maybe.
    Helpful post? Buy me a coffee.
  • #14 21305353
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    >>21305255

    Of course I'm planning to make it global. But for backward compatibility I also want to add a new flag to enable "Beken UART2 polling mode". The question is, should that flag be Beken only? Is the UART2 problem Beken only?
  • #15 21305391
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14589
    Help: 654
    Rate: 12611
    I think that you don't need to add a flag. Just hardcode mechanism for UART2 in #ifdef PLATFORM_BEKEN block. This way it will only run on Beken.
    Helpful post? Buy me a coffee.
  • #16 21305451
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    >>21305391 >>21305391
    Are you sure that nobody is using UART2 on Beken in actual state somehow?
  • #18 21310895
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14589
    Help: 654
    Rate: 12611
    Screenshot showing a code change related to UART2 interrupt reading repair in an open-source project.
    Nice finding, what exactly is get_ate_mode_state()?

    I don't remember using UART2 for reading in any way on Beken. We're using UART1 for TuyaMCU, for BL0942 and for commandline, but not UART2. Still, you can just check the source code to be sure.

    But anyway, now that you've found the problem in the SDK, the workaround is no longer needed...
    Helpful post? Buy me a coffee.
  • #19 21310909
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    p.kaczmarek2 wrote:
    exactly is get_ate_mode_state()

    Well, I don't know for sure, probably something for testing.
    However, the main one is the test ATE_APP_FUN which is CFG_ENABLE_ATE_FEATURE
    And that is in platforms/bk7231n/bk7231n_os/beken378/app/config/sys_config.h set to 0

    #define CFG_ENABLE_ATE_FEATURE 0

    Same test is on UART1

    Added after 2 [minutes]:

    p.kaczmarek2 wrote:
    But anyway, now that you've found the problem in the SDK, the workaround is no longer needed...

    Sure, that's why I preferred to look for the cause of the problem, not just a workaround.

    Added after 3 [minutes]:

    p.kaczmarek2 wrote:
    We're using UART1 for TuyaMCU, for BL0942 and for commandline, but not UART2.

    So you don't have the opportunity to test this SDK patch somehow?
  • #20 21310959
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14589
    Help: 654
    Rate: 12611
    I will merge this if you confirm it fixes UART2 for you, it should be enough. However, isnt' the same problem present also in the BK7231T SDK?
    Helpful post? Buy me a coffee.
  • #21 21310979
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    p.kaczmarek2 wrote:
    However, isn't the same problem present also in the BK7231T SDK?

    Exactly the same, but I cannot test it, I do not have any BK7231T yet.
    But, there is a simple test possible, just enable BL0942 driver, set flag 26=1 and send anything from PC to BK7231T RX2 (UART2) using baudrate 4800. If UART2 is receiving OK, there should be in log "consumed %i unwanted non-header byte in BL0942 buffer".

    Added after 6 [minutes]:

    p.kaczmarek2 wrote:
    I will merge this if you confirm it fixes UART2 for you

    I'd rather test it in the "real" world for a few more days directly on the measuring device (to avoid memory overflow, etc.). Then I'll let you know.
  • #22 21312630
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14589
    Help: 654
    Rate: 12611
    @divadiow @DeDaMrAz any BK7231T boards at hand? If you want...
    Helpful post? Buy me a coffee.
  • #24 21313538
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    >>21313514
    Yes, only the SDK was changed.
  • #25 21315831
    divadiow
    Level 38  
    Posts: 5038
    Help: 438
    Rate: 891
    so I have a WB3S in an ESP universal adaptor, which means GPIO0 and GPIO2 labels translate to TX2/RX2 on Beken.

    Diagram showing pin configuration with GPIO labels and function assignments.

    with https://github.com/openshwprojects/OpenBK7231T_App/pull/1436 build OpenBK7231T_App_1436_merge_0f77912a3305 and flag 26 set I'm afraid I'm not getting the expected output in the logs. Logs are set to full verbosity. Realterm at 4800bps and I'm sending some random stuff. Same with flag 26 unset.

    With flag 26 NOT set on UART1 I do get the BL0942 buffer return

    Screenshot showing PowerShell and RealTerm used for UART data analysis.

    maybe it's something I've not got right?
  • #26 21315899
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    >>21315831 after setting the flag 26 to 1 there must be a reboot

    Added after 3 [minutes]:

    >>21315831 after setting the flag 26 to 1 there must be a reboot
    divadiow wrote:
    OpenBK7231T_App_1436_merge_0f77912a3305

    OpenBK7231T_App_1436_merge_0f77912a3305 is what?

    Added after 7 [minutes]:

    divadiow wrote:
    I'm not getting the expected output

    The test on BKT must be done with the same changes on platform SDK BK7231T as is done for BKN here: https://github.com/openshwprojects/OpenBK7231N/pull/21

    This patch is not needed for testing this UART2 fix on SDK:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1436 is not necessary to use

    Added after 2 [minutes]:

    >>21315831
    I'll prepare BKT SDK PR for testing, just a moment - too much opened pending projects... :)

    Added after 9 [minutes]:

    XJ_ wrote:
    I'll prepare BKT SDK PR for test,

    Here BK7231T SDK with UART2 patch [untested]
    https://github.com/openshwprojects/OpenBK7231T/pull/20

    Added after 26 [minutes]:

    Just to clarify:

    The SDK uart2 patch solves reading from the UART2 port globally via an interrupt on Beken.
    - BK7231N - I tried that one (tested, working)
    https://github.com/openshwprojects/OpenBK7231N/pull/21

    - BK7231T - I don't have that one and this is that, what should be tested (using main release of OpenBK7231T_App)
    https://github.com/openshwprojects/OpenBK7231T/pull/20


    ----------------

    Then there's the OpenBK7231T_App ring buffer fix (which is not directly related to the SDK fix):
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1436
  • #27 21316326
    divadiow
    Level 38  
    Posts: 5038
    Help: 438
    Rate: 891
    OK. Cool. I don't have equipment with me to test until probably tomorrow now or Monday :)
  • #28 21316626
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    Another step further:
    I added new routines to enable simultaneous use of both UARTs on Beken. Each UART has its own Ring Buffer.
    Currently only for the Beken platform.
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1437

    Next step to do:
    Extend drv_bl0942 output to some available channels with values ​​from the second channel /I'm already working on it/

    Added after 32 [minutes]:

    XJ_ wrote:
    I'd rather test it in the "real" world for a few more days directly on the measuring device (to avoid memory overflow, etc.). Then I'll let you know.

    @p.kaczmarek2 After few days without any problems I can say that uart2 on BK7231N is fine. From my part, you can merge it (BK7321N).
    BK7231T still untested, but @divadiow promises to test it soon.
  • #29 21318432
    XJ_
    Level 12  
    Posts: 141
    Help: 13
    Rate: 39
    Twin BL0942 mod - (beta) - for anyone who wants to check it out, here it is (I'm currently testing it in practice, it looks great so far.)
    There are "huge for some" changes in bl_share.c, but necessary. (All changes are designed to maintain backward compatibility.)

    https://github.com/xjikka/OpenBK7231T_App/tree/twinbl0942mod

    Note: This mod will not work on standard SDK, SDK mod uart2 is required https://github.com/openshwprojects/OpenBK7231N/pull/21

    UI output:
    Screenshot of the Twin BL0942 module user interface showing energy parameters.

    autoexec.bat:
    Code: text Expand Select all Copy to clipboard
    logtype none
MovingAvgSet 20
startDriver NTP
ntp_timeZoneOfs  01:00
BL0942opts 3
startDriver BL0942
ConsumptionThreshold 200
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion focuses on integrating and troubleshooting a smart energy power meter device featuring two BL0942 power metering chips connected via UART1 and UART2 on a Beken BK7231N module (CBU). The primary issue was that the BL0942 on UART1 functioned correctly, while UART2 returned zero values with flag 26 enabled. Investigation revealed that UART2 receive interrupts were broken at the SDK level, requiring a workaround by polling UART2 RX manually. A patch was developed and tested, enabling stable UART2 communication and simultaneous operation of both BL0942 chips. Firmware modifications introduced a new command, BL0942opts, to support dual BL0942 operation with energy calculation from UART1 and informative data from UART2, using MQTT suffix "_b" for the second sensor. Home Assistant (HASS) MQTT discovery was extended to support dual sensors while maintaining backward compatibility. The patch increased firmware size, leading to the introduction of a compile-time flag (ENABLE_BL_TWIN) to enable or disable dual BL0942 support. Testing confirmed stable operation on BK7231N and BK7231T platforms. Additional features such as frequency measurement publication and moving average filtering were added. Users reported calibration and polarity issues with clamps, resolved by reversing clamp polarity and enabling specific flags. The final solution includes firmware branches and pull requests on GitHub, with detailed configuration instructions and community-shared binaries. The discussion also covers logging behavior on UART ports, flashing procedures without desoldering, and troubleshooting steps for consistent sensor data reading.
Generated by the language model.
Today's popular

FAQ

TL;DR: 2 BL0942 chips can now run together on BK7231N and BK7231T in OpenBK using BL0942opts 3; the flash-size overhead was cut to about +90 bytes, and the maintainer confirmed: "I've merged this PR." This FAQ is for users modding dual-channel clamp meters who need stable UART1+UART2 metering, MQTT, and Home Assistant behavior. [#21456787]

Dlaczego to ma znaczenie: Ten wątek turns a half-working dual-UART power meter into a repeatable OpenBK setup with known firmware settings, SDK fixes, and Home Assistant limits.

Opcja Co robi Kiedy używać Ograniczenia
Flag 26 = 0 BL0942 na UART1 Pojedynczy licznik na głównym porcie Brak drugiego kanału
Flag 26 = 1 BL0942 na UART2 Test lub pojedynczy licznik na UART2 Wymaga poprawki UART2 w Beken SDK
BL0942opts 3 Dwa BL0942 na UART1 + UART2 Licznik 2-kanałowy na Beken Energia liczona tylko z kanału A
logtype none Wyłącza log na UART Zawsze przy trybie dual BL0942 Startup log może pojawić się przed autoexec

Najważniejszy wniosek: Problem nie leżał w adresie BL0942 ani w samym driverze, tylko w obsłudze odbioru UART2 w Beken SDK. Po poprawce SDK i właściwym autoexec dwa BL0942 działają równocześnie na BK7231N i BK7231T. [#21324542]

Quick Facts

  • Dual BL0942 support was finally merged on 2025-02-26, after tests on BK7231N and BK7231T plus size optimization from about +423 bytes down to roughly +90 bytes in the default-disabled build path. [#21455568]
  • BL0942 packets are treated as 23-byte frames in the debugging discussion, and corrupted UART2 traffic showed extra bytes and desynchronization when hardware or UART handling was wrong. [#21407663]
  • The standard BL0942 driver runs at 4800 baud, and startDriver BL0942 switches the UART speed to that value, which matters when you sniff traffic or mix logging with metering. [#21407285]
  • For flashing the CBU/BK7231N module without desoldering, the reported working connection was GND, 3V3, RX1, TX1, with no CEN required; the board just needed a normal power-on during the flashing routine. [#21298953]
  • In dual mode, Home Assistant kept backward compatibility by treating channel A as the main channel; channel B was added with _b suffixes, while total energy initially stayed tied to the first BL0942 only. [#21432573]

How do I get two BL0942 energy metering chips working on UART1 and UART2 at the same time on a BK7231N or BK7231T device with OpenBK7231T_App?

Use a build that includes twin BL0942 support and the Beken UART2 fix, then enable dual mode in autoexec. 1. Put logtype none, BL0942opts 3, and startDriver BL0942 into autoexec.bat. 2. Keep Flag 26 disabled in dual mode. 3. Reboot and verify that UART1 is the main channel and UART2 appears as channel B. The merged implementation supports BK7231N and BK7231T, but energy is initially counted only from the first BL0942. [#21432573]

Why does BL0942 on UART2 return only zeros on a CBU/BK7231N device even though the chip responds on the RX2 pin?

Because the chip can answer electrically on RX2 while the SDK still fails to deliver those bytes to the OpenBK receive path. In the thread, TX2 sent the 2-byte request, a PC sniffer saw a 17-byte BL0942 response on RX2, yet the firmware logged bl0942 uart bytes 00. Looping RX2 into RX1 made the first UART receive data immediately, which isolated the fault to UART2 reception, not BL0942 addressing. [#21299078]

What was the actual UART2 bug in the Beken SDK, and how was it fixed for BK7231N and BK7231T?

The real bug was in the Beken SDK UART2 receive handling, not in BL0942 commands. A temporary workaround polled UART2 RX manually from a quick-tick function, but the final fix patched the SDK so UART2 interrupt-driven reading worked normally again. The BK7231N patch was confirmed first, then BK7231T was tested with the matching SDK change and verified to receive UART2 data correctly using the stock app plus the patched SDK. [#21315899]

Which autoexec.bat settings are needed to enable dual BL0942 mode in OpenBK, including BL0942opts 3 and logtype none?

Use exactly the three-line autoexec shown by the developer for dual mode on Beken. It is:
  1. logtype none
  2. BL0942opts 3
  3. startDriver BL0942 This setup disables serial logging after boot, enables the two-chip mode, and starts the BL0942 driver on both UART1 and UART2. The author explicitly recommended disabling UART logging when both ports are active. [#21432573]

When should I use Flag 26 for BL0942, and how does that differ from using BL0942opts 3 on Beken devices?

Use Flag 26 only for single-chip BL0942 selection, not for true dual-chip mode. With Flag 26 = 0, OpenBK reads one BL0942 on UART1. With Flag 26 = 1, it reads one BL0942 on UART2. With BL0942opts 3, OpenBK reads two BL0942 chips at once on UART1 and UART2, and the developer specifically said Flag 26 should be disabled in that mode. [#21404961]

What is a BL0942 chip, and what measurements does it provide in OpenBK-based power meters?

"BL0942 is an energy-metering chip that reads mains-related electrical values over UART, reports packetized measurements, and is used in OpenBK smart meters for live power data." In this thread, OpenBK exposed voltage, current, power, frequency, and energy-related values from BL0942 devices. In dual mode, the second chip first provided informative values only, while total energy stayed tied to the first BL0942 until later experimental work expanded that behavior. [#21486900]

What is a CBU module with BK7231N, and how does it differ from WB2S or WB3S in these smart energy meters?

"CBU is a Beken-based Wi-Fi module that uses the BK7231N SoC, serves as the main controller in some smart meters, and exposes UART and GPIO needed for flashing and metering integration." In this thread, the original device used a CBU with BK7231N, LED on P9, and button on P24. Later tests also used WB2S on BK7231T and WB3S hardware, mainly to validate the same UART2 and BL0942 behavior on other Beken module families. [#21298953]

How can I flash a CBU/BK7231N smart cube without desoldering, and which pins need to be connected?

You can flash it in-circuit through the first UART. The reported working method used four wires: GND, 3V3, RX1, and TX1. The author stated there was no need to use CEN; a normal power-on during the flashing routine was enough. On that same CBU board, the LED was on P9 and the button was on P24, which helps when bringing the module up after flashing. [#21298953]

Why does Home Assistant MQTT discovery work for channel A but not fully for channel B in twin BL0942 builds?

Because channel B discovery was unfinished in the early twin-BL0942 branches. The developer said channel A remained the backward-compatible main channel, while channel B initially only published MQTT values and had not yet been fully added to Home Assistant discovery. Later test builds added basic channel B discovery, but the developer warned the unique IDs for channel B were still provisional and could change. [#21405934]

How are MQTT topics and Home Assistant entities named for dual BL0942 devices, and how is backward compatibility preserved for the main channel?

The main channel keeps the original names such as voltage, current, and power, while the second BL0942 uses _b suffixes such as voltage_b and current_b. That naming preserves existing Home Assistant and MQTT setups for channel A. The maintainer pushed to avoid renaming the main topic to _a, because old HA discovery and configuration.yaml users already expect the original unsuffixed topic names. [#21321740]

What is get_ate_mode_state() in the Beken SDK, and how does ATE mode affect UART handling?

It appears to be an SDK test-related hook, not an OpenBK metering feature. The thread linked UART2 behavior to checks around ATE mode and noted that the key compile-time test symbol was ATE_APP_FUN, tied to CFG_ENABLE_ATE_FEATURE. On BK7231N, that flag was shown as #define CFG_ENABLE_ATE_FEATURE 0, which helped explain why the developer treated the UART2 issue as an SDK logic problem rather than a BL0942 driver bug. [#21310909]

Which approach is better for UART2 on Beken: polling the RX path in software or patching the SDK interrupt handling?

Patching the SDK interrupt handling is better. Polling via a quick-tick function did work as a stopgap, and it proved UART2 bytes could be recovered in software, but the author explicitly preferred finding and fixing the root cause in the SDK. Once the SDK bug was fixed, the workaround was no longer needed, and UART2 worked globally instead of only through BL0942-specific polling logic. [#21310909]

How do I troubleshoot intermittent or corrupted BL0942 readings on UART2 when the log shows messages like 'Consumed unwanted non-header byte in BL0942 buffer'?

Treat that message as a framing or data-integrity warning. 1. Test each BL0942 alone with stock firmware: Flag 26 off for UART1, then on for UART2. 2. Run each path for a long soak test, even 2 days, before re-enabling dual mode. 3. If corruption persists, inspect UART captures for malformed 23-byte packets or extra bytes, because one user’s UART2 stream was described as “crap” while UART1 was clean. [#21407571]

What causes current and power to stay at 0 or go negative on BL0942 clamp-based meters, and how do clamp polarity, Flag 25, and Flag 48 affect that?

Wrong clamp polarity is the first thing to check. One user saw voltage and frequency look normal while current and power stayed at 0.00; enabling Flag 25 allowed negative power readings, which strongly suggested reversed current-sense direction. The recommended fix was to swap the clamp polarity, described as red-to-black reversal, then recalibrate. The same report said Flag 48 had no effect there, and the developer noted he could not find code actually using that AC-invert flag. [#21500108]

Where does OpenBK currently publish frequency for BL0942 devices, and what steps are needed to make frequency appear in MQTT and Home Assistant discovery?

Frequency was later added to MQTT and Home Assistant through a new static channel named SPECIAL_CHANNEL_OBK_FREQUENCY 138. To make it appear, update to a build that includes the frequency change, reboot, and rerun Home Assistant discovery. The author stated that discovery must be rerun after the update, otherwise HA will not create the new frequency entity even if the firmware already publishes it. [#21486900]
Generated by the language model.
ADVERTISEMENT