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_ 7473 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
  • #61 21405842
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    randomalias324 wrote:
    Yep, cant get dual measurement back by restarting, toggling BL0942opts, so far whatever I try

    To make both working, BL0942opts must be 3 and flag 26 disabled

    Maybe you should first test if both BL0942s work with standard firmware https://github.com/openshwprojects/OpenBK7231T_App
    BL0942 on UART 1 should work with flag26 0
    BL0942 on UART 2 should work with flag26 1

    If it is ok, the You can try this:

    Reset pins and other things using commands:
    Code: text Expand Select all Copy to clipboard
    ClearIO
StartupCommand ""
Flags 1028


    autoexec.bat with BL things only
    Code: text Expand Select all Copy to clipboard
    
BL0942opts 3
startDriver BL0942


    If You want to try HASS discovery, here binary (BK7231N) with hass discovery test (OpenBK7231N_App_1.18.23-twinbl0942mod_3.zip) (it is twnbl0942mod + added hass channel B discovery)

    And screens from test device and HASS using this FW :

    Screenshot of CP03BKNP device interface displaying electrical energy data.

    User interface panel of software for BK7231N device with power measurement data and diagnostic information.

    Anyway, in the log there is watchdog reboot (wdt reboot), Do You have ping watchodog active or something like this?
    Attachments:
    • OpenBK7231N_App_1.18.23-twinbl0942mod_3.zip (487.77 KB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #62 21405854
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    XJ_ wrote:
    Maybe you should first test if both BL0942s work with standard firmware https://github.com/openshwprojects/OpenBK7231T_App
    BL0942 on UART 1 should work with flag26 0
    BL0942 on UART 2 should work with flag26 1


    I did - UART2 is no longer reading.
  • ADVERTISEMENT
  • #63 21405860
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    >>21405854
    randomalias324 wrote:
    I did - UART2 is no longer reading.

    Maybe there is something in GPIO set, try reseting it using ClearGPIO
  • #64 21405861
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    I'll plug it back in and try the other commands you've listed
    I can also try the firmware you posted
  • #65 21405886
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    randomalias324 wrote:
    I did - UART2 is no longer reading.

    If the BL0942 on UART2 doesn't work with the standard firmware, it won't work with this one either.

    Did you compile it with the new SDK, don't you still have the old one that didn't support UART2?

    This is how I compile it

    Code: text Expand Select all Copy to clipboard
    #download 

export wrkd="bk7231n-bl"
cd ~
mkdir $wrkd
cd ~
git clone https://github.com/openshwprojects/OpenBK7231N ./$wrkd
git clone https://github.com/xjikka/OpenBK7231T_App -b twinbl0942mod_2movavg ./$wrkd/apps/OpenBK7231N_App

#compile
cd ~/$wrkd
./build_app.sh apps/OpenBK7231N_App OpenBK7231N_App 1.18.23-twinbl0942mod_2movavg
  • #66 21405907
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    >>21405842
    Must have been the flags. I ran
    Code: text Expand Select all Copy to clipboard
    ClearIO
StartupCommand ""
Flags 1028

    in order, line by line, in the 'Execute Custom Command' screen of the UI

    I set autoexec.bat to
    Code: text Expand Select all Copy to clipboard
    logtype none
BL0942opts 3
startDriver BL0942


    And now I've got data :D
    Solar_Production user interface showing frequency, voltage, and power data.

    I was about to ask if some of those settings were persistent. Sounds like the answer is yes

    I'll flash up your binary and try MQTT/auto discovery

    If it fails, is there a way to configure MQTT/homeassistant manually?

    Added after 3 [minutes]:

    XJ_ wrote:
    Did you compile it with the new SDK, don't you still have the old one that didn't support UART2?


    Yeah I compiled it using the latest master commit of the SDK for the Cygwin attempt, and I also tried the docker build process. Both worked in the end. Currently I'm running the binary I compiled in Cygwin. I used the build instructions included in the GitHub README
  • #67 21405924
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    randomalias324 wrote:
    I was about to ask if some of those settings were persistent. Sounds like the answer is yes

    StartupCommand, Flags and ClearIO are persistent
    logtype, BL0942opts and startdriver are not, settings must be done in autoexec.bat
  • #68 21405930
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    @XJ_ What a legend
    Flashed your binary, deleted the old device and re-ran discovery
    Homeassistant is sorted!
    Screenshot of the BK7231N device info panel in Home Assistant.

    We're now about to find out how calibrating goes
  • #69 21405934
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    randomalias324 wrote:
    If it fails, is there a way to configure MQTT/homeassistant manually?


    HASS discovery must work even in normal firmware (Channel A).
    I just added channel B (base, without power) to HASS discovery.
    To maintain backward compatibility, channel A is the main one, and energy is calculated from it (A only). Channel B is therefore not included in the energy and only show voltage, current and power.

    To start HASS discovery, you must use the button on the website in the config
    Device configuration interface with buttons to start Home Assistant discovery and configure MQTT.

    Added after 4 [minutes]:

    randomalias324 wrote:
    We're now about to find out how calibrating goes

    Screenshot of a device configuration panel with tabs and tools for LED drivers and power metering.

    Added after 2 [minutes]:

    randomalias324 wrote:
    Homeassistant is sorted!

    Be careful, I will definitely change the unique IDs of channel B entities, for now it's just for testing!
  • #70 21405999
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    Something is wrong.

    Voltage and frequency are showing plausible values, but current and power remain at 0.00 on both channels.

    I have the loops set up on a heater.

    Electric heater with visible wires and a connector.

    On previous software versions we were getting only one channel, and wildly incorrect values, but at least it showed something.

    Trying a few configs to try and find the cause
  • #71 21406040
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    randomalias324 wrote:
    I have the loops setup on a heater.

    First, I would recommend you try a simple classic light bulb (NOT LED)
  • ADVERTISEMENT
  • #72 21406045
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    >>21406040
    It's not reading anything. With anything plugged into it

    Added after 1 [hours] 29 [minutes]:

    OK fixed it.

    Soldered on the FTDI UART board again and erased the whole chip with the flashing tool
    Screenshot of the BK7231 Easy UART Flasher tool for firmware flashing.

    Then I flashed official OpenBK. Setup WiFi, resoldered the UART track and booted with the normal BL0942 driver.

    Calibrated the unit on one channel using the heater, a halogen flood light and a couple of calibrated power meters. Because its using those clamps, it was quite off.

    Flashed the modified firmware, added BL0942opts 3 to autoexec.bat and its now running.

    Screenshot of OpenBK7231N user interface displaying energy measurement data and configuration buttons.

    I think repeatedly flashing and setting flags did something
  • #73 21406699
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    randomalias324 wrote:
    Flashed the modified firmware, added BL0942opts 3 to autoexec.bat and its now running

    Great!
  • #74 21407161
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    OK. The sensor seems to frequently stop logging, and upon restart often does not find both sensors.

    Screenshot of Solar_Production_FuseBox_Sensor data showing voltage, current, power, apparent power, and other technical statistics.

    User interface displaying Solar_Production_FuseBox sensor data.

    Added after 25 [minutes]:


    Editing autoexec.bat file with configuration commands.

    Adding clearIO to autoexec might have fixed it? It was a fairly random thing to try, but it got both sensors back on reset

    Added after 2 [minutes]:

    Logging often stops on ch2. I think logging spam is still being output on UART2, as shown in my UART logs. Some of it must be hardcoded

    Added after 17 [minutes]:

    Yep, can't achieve consistent logging on Ch B.

    Screenshot showing data from the Solar_Production_FuseBox_Sensor, displaying various electrical values.

    With this autoexec
    Screenshot of the edited autoexec.bat file with configuration code.

    Setting logport to an invalid UART port doesn't seem to change anything
  • #75 21407285
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    randomalias324 wrote:
    logging spam is still being output on UART2, as shown in my UART logs. Some of it must be hardcoded

    There is always a startup log on UART2, until you turn it off via logtype none. This cannot be turned off in the standard way.

    logtype none will turn off the OBK log on serial port

    Code: text Expand Select all Copy to clipboard
    if (!stricmp(cmd, "logtype")) {
      if (!stricmp(args, "none")) {
         direct_serial_log = LOGTYPE_NONE;
      }
...


    logport 1 will set logport to UART1
    logport 2 will set logport to UART2
    any other value is ignored, nothing is changed

    Code: text Expand Select all Copy to clipboard
    idx = Tokenizer_GetArgInteger(0);
switch (idx) {
case 1:
   UART_PORT = UART1_PORT;
   UART_PORT_INDEX = 0;
   break;
case 2:
   UART_PORT = UART2_PORT;
   UART_PORT_INDEX = 1;
   break;
}

    Added after 3 [minutes]:

    randomalias324 wrote:
    Yep, can't achieve consistent logging on Ch B

    Note, that startdriver BL0942 affect the log, it switches the UART speed to 4800
    static unsigned short bl0942_baudRate = 4800;

    Added after 4 [minutes]:

    randomalias324 wrote:
    Yep, can't achieve consistent logging on Ch B.

    Do you mean the OBK log, or reading values ​​from BL0942?
  • #76 21407521
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    >>21407285
    XJ_ wrote:
    There is always a startup log on UART2, until you turn it off via logtype none.

    XJ_ wrote:
    Log via UART affects the BL0942 startdriver - it switches the speed to 4800
    static unsigned short bl0942_baudRate = 4800;

    Oh the small amount of logging is just what you get during boot until the logtype none is hit in auto exec?
    I don't fully understand that, because the logging messages are output at 4800 baud and there are BL0942 polling characters in between them. This seems to imply that the BL0942 driver has been started? startDriver bl0942 is further down in autoexec than logtype none.

    XJ_ wrote:
    any other value is ignored, nothing is changed

    OK yep

    XJ_ wrote:
    randomalias324 wrote:
    Yep, can't achieve consistent logging on Ch B

    Do you mean the OBK log, or reading values ​​from BL0942?

    Oh, I meant reading values from the BL0942. I can't get consistent 'logging', by that I meant reading of values, of the ChB BL0942 chip; Data from the BL0942 doesn't seem like its being read properly.

    randomalias324 wrote:
    Yep, can't achieve consistent logging on Ch B.

    Screenshot showing data from the Solar_Production_FuseBox_Sensor, displaying various electrical values.


    When sniffing the UART lines I can see the regular polling coming out of the beken chip and the response of the BL0942. But on the OBK web page ChB doesn't seem to be updating regularly. I can see the Ch A values changing and the sent/skipped counters incrementing. But Ch B signals update sporadically and often stop. The sent/skipped counters start lagging, maybe averaging 1/3rd of the 'normal' channels

    After a while, Ch A started dropping out completely. Only ChB was being displayed on the OBK web page, and nothing for ChA was being sent over MQTT. Following another couple of restarts, ChB dropped out as well. ClearIO was in the autoexec, so clearly (no pun) it isn't fixing the issue
  • #77 21407571
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    >>21407521
    is in the log something like this?
    Consumed %i unwanted non-header byte in BL0942 buffer

    I recommend to test both BL0942 on the original firmware first (using flag 26).

    https://github.com/openshwprojects/OpenBK7231T_App/releases/tag/1.18.24

    First UART1 - and let it run for e.g. 2 days, if it is OK
    and then UART2 - and let it run again for e.g. 2 days, if it is OK

    Then if both worked on the original firmware without a problem I could add some logs to the source code for you to investigate.
  • #78 21407585
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    >>21407571
    XJ_ wrote:
    Consumed %i unwanted non-header byte in BL0942 buffer

    I do recall seeing those messages in the JavaScript webapp logs. Not 100% sure which configuration that was
  • #79 21407593
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    randomalias324 wrote:
    I do recall seeing those messages in the javascript webapp logs. Not 100% sure which configuration that was

    Well, these shouldn't be there, it means there's data there that wasn't expected.
  • #80 21407598
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    >>21407593
    Your device never logs those errors?
  • #81 21407603
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    >>21407598
    No, as far as I remember, I only saw them when I was testing and programming it. They might appear after boot, when there is something vague on the port. But, never say never.
  • #82 21407622
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    >>21407603
    I should be able to check the UART logs I posted to see if the data is correct.
    I haven't stuck a scope on it when it's plugged in, so no idea if the signal is clean when it's actually running off the mains.
    Hopefully one day I'll get a differential probe
  • ADVERTISEMENT
  • #83 21407663
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    >>21407622
    there is some problem with your bl0942 on uart2, here are the logs of what you sent divided into packets /BL0942 has a packet length of 23 bytes)
    UART1 is OK, UART2 is crap


    Two UART logs showing transmission issues with BL0942.
    Attachments:
    • bl0942logsplitted.zip (3.46 KB) You must be logged in to download this attachment.
  • #84 21411897
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    Very nice progress, I will want to merge it within few days if possible, however, first I want to merge RTL support: https://github.com/openshwprojects/OpenBK7231T_App/pull/1501 and it may require futher adjustments for new UART changes, but we will see when I merge it.
    Helpful post? Buy me a coffee.
  • #85 21413024
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    >>21411897
    I updated uart2bufmod using new version (1.18.28) and fortunately no changes were needed.
    Then I tested UART1 and UART2 on BK7231N with BL0942 - switching via flag26, and everything OK.

    Then I also tested UART1 and UART2 on BK7231N with BL0942 in twinbl0942mod (that with twin BL support) branch, and it's also OK.
  • #86 21413876
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    >>21407663
    Good find! I wonder what is causing that. Seems like it gets 2 more bytes per message on average. Noise maybe? Could that cause a byte of zeros to be read? My particular device could be junk

    Funny thing is, more often than not UART 2 was the one actually reading 🤷‍♂️
  • #87 21413923
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    randomalias324 wrote:
    Good find! I wonder what is causing that. Seems like it gets 2 more bytes per message on average. Noise maybe? Could that cause a byte of zeros to be read? My particular device could be junk

    Normally it should work even with the zeros. But that's why it shows "Consumed %i unwanted..." in the log

    The question is whether there really is a problem with the HW. I probably can't help you with that anymore, sorry.
  • #88 21414913
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    Hey @XJ_, is MovingAvgSet a new command? It's not in the docs. Interested in using for some other devices
  • #89 21415080
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    randomalias324 wrote:
    is MovingAvgSet a new command?

    It's my private non-public command. I don't plan to use it in PR. It does a simple "moving average" of power, current and voltage. I use a special proportional power control for the heater and the power consumption changes radically in a matter of seconds.. I compensate this using MovingAvg.
    You can safely ignore it, the function is inactive by default.

    Added after 3 [minutes]:

    randomalias324 wrote:
    Interested in using for some other devices


    It would be better to wait for the official implementation twinbl0942.
    BTW, where did you found the MovingAvg command?
  • #90 21422204
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    >>21411897
    @p.kaczmarek2 uartbuf mod still ok with the 1.18.33

    some checks failed due to download errorr

    Screenshot of a build process with download errors and process completion with exit code 1.

    I've triggered rerun checks and now it's fine
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