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
  • #31 21321489
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    Whoa, @XJ_ , very good job on checking UART code! There was indeed a bug:
    Screenshot of Visual Studio IDE with UART test code and output console showing test failure results.
    Screenshot of C language program code showing the Test_UART() function.
    I've added a self-test:
    https://github.com/openshwprojects/OpenBK7231...mmit/a2f3b020686633c643ab8790875e00173bb9d354
    and merged your PR:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1436
    The test should now pass correctly.

    That was indeed a very good job, keep it on, we need more fixes like that.

    Let me know what's the state of full double BL0942 support, can I help with it somehow? Do you have a list of things changed or a quick summary, how does it maintain compatibility with older versions?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 21321593
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    p.kaczmarek2 wrote:
    Let me know what's the state of full double BL0942 support, can I help with it somehow? Do you have a list of things changed or a quick summary, how does it maintain compatibility with older versions?

    I'm testing it in my own "junction box", it works like a charm. The only thing that needs to be done to make it available to others on BK7231N is to merge https://github.com/openshwprojects/OpenBK7231N/pull/21 .

    For BK7231T I have to wait for the module and try to find a bug in BK7231T SDK as well as BK7231N.

    Added after 42 [seconds]:

    p.kaczmarek2 wrote:
    That was indeed a very good job, keep it on, we need more fixes like that.

    Thank you

    Added after 2 [minutes]:

    p.kaczmarek2 wrote:
    I've added a self-test:

    Great 👍
  • #33 21321672
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    So I see you've added index here:
    Code: C / C++
    Log in, to see the code

    but now, how does HA Discovery works? What is the MQTT name of first and second BL0942 readouts values?
    Helpful post? Buy me a coffee.
  • #34 21321681
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    p.kaczmarek2 wrote:
    but now, how does HA Discovery work? What is the MQTT name of first and second BL0942 readout values?

    @Src/driver/drv_bl_shared.c
    Code: text Expand Select all Copy to clipboard
    typedef struct energysensor energysensor_t;
typedef struct {
  energysensor_t sensors[OBK__NUM_SENSORS];
} energysensdataset_t;

energysensdataset_t datasetlist[BL_SENSDATASETS_COUNT] = {
  { {      //.hass_dev_class,    .units,      .name_friendly,         .name_mqtt,       .hass_uniq_id_suffix, .rounding_decimals, .changeSendThreshold      
      {{"voltage",      "V",      "Voltage",            "voltage",               "0",      },  1,         (float)0.25,      },   // OBK_VOLTAGE
      {{"current",      "A",      "Current",            "current",               "1",      },   
...

    } }
,
   { {
       //.hass_dev_class,    .units,      .name_friendly,         .name_mqtt,       .hass_uniq_id_suffix, .rounding_decimals, .changeSendThreshold      
       {{"voltage",      "V",      "Voltage B",            "voltage_b",               "0",      },  1,         (float)0.25,      },   // OBK_VOLTAGE
       {{"current",      "A",      "Current B",            "current_b",               "1",      },   3,   

    Fragment of C code defining structures related to energy sensors.
  • ADVERTISEMENT
  • #35 21321701
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    If the "voltage" MQTT name has changed to "voltage_b", then it will break compatibility with existing HASS configurations.

    Most likely the preferred (but a bit dirty) solution is to introduce voltages as "voltage" (no name change) and "voltage2", I guess?
    Helpful post? Buy me a coffee.
  • #36 21321705
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    p.kaczmarek2 wrote:
    What is the MQTT name of first and second BL0942 readouts values

    At this time, the energy calculation is performed as before only for channel 0, channel 1 is only voltage, current and power with the suffix _b

    Added after 2 [minutes]:

    p.kaczmarek2 wrote:
    then it will break compatibility with existing HASS configurations

    How? Tuya driver uses _a and _b.

    Added after 6 [minutes]:

    XJ_ wrote:
    How? Tuya driver uses _a and _b.

    By the way, the _a suffix was not a good decision, I always delete it on Tuya.

    Added after 4 [minutes]:

    @>>21321672
    I suggest you to look at this PR first
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1437
    and then at
    https://github.com/xjikka/OpenBK7231T_App/tree/twinbl0942mod
  • #37 21321729
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    XJ_ wrote:

    p.kaczmarek2 wrote:
    then it will break compatibility with existing HASS configurations

    How? Tuya driver uses _a and _b.


    Maybe I misunderstood the code, but as far as I know, the Home Assistant Discovery mechanism works by telling HA which topics are used for stuff like relays, voltage, power, energy, etc. So, once you do this process:



    the Home Assistant begins to remember that it should listen to, specifically, "voltage" MQTT topic (with device name prefix, etc etc) and show it on panel.
    If you then update OBK, to publish voltage on "voltage_a" instead of "voltage", it will break HA connectivity. HA will no longer receive voltage data under expected topic.

    So, here are my two current concerns:
    1. Does the current solution maintain compatibility with older HASS configurations (either via Discovery or configuration.yaml)
    2. Did you also include your changes in the HASS Discovery code, so Home Assistant "can see" both measuring chips?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #38 21321740
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    p.kaczmarek2 wrote:
    "voltage_a" instead of "voltage", it will break HA connectivity.

    Maybe I wrote it wrong, I don't want to use the suffix _a in any case. On the contrary, for the TuyaMCU driver (I have also one cube meter with TuyaMCU), I delete it (suffix _a) in HASS so that it works properly in HASS.

    Added after 9 [minutes]:

    p.kaczmarek2 wrote:
    So, here are my two current concerns:
    1. Does the current solution maintain compatibility with older HASS configurations (either via Discovery or configuration.yaml)
    2. Did you also include your changes in the HASS Discovery code, so Home Assistant "can see" both measuring chips?


    - ad 1 Yes - but only channel 0 as before
    - ad 2 Not yet, it only sends MQTT messages, which is enough for my needs at the moment. Once I have verified that it is ok this way, I will add discovery.

    That is why I have not made a PR for this modification yet.

    Added after 6 [minutes]:

    p.kaczmarek2 wrote:
    specifically, "voltage" MQTT topic

    I think it's based on dev_class and unit_of_measurement and state_topic topic has no effect on it, however when I do discovery I'll check it.

    Code: text Expand Select all Copy to clipboard
    state_topic: pwr_main_2nd/voltage_b/get
unit_of_measurement: V
name: Voltage
unique_id: bkn_pwr_main_2nd_sensor_10
state_class: measurement
device_class: voltage


    Anyway, thanks for the suggestion, I'll check it out and change it if necessary before I make a PR. I'm doing it for HASS after all, so why would I complicate it for myself ;-)
  • #39 21321794
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    In a meantime, I will check if we already have a self-test for BL0942/BL0937/etc MQTT topics and if not, I will add it. This will help us to make sure that all topics stayed compatible with previous versions.

    Probably I will have to extend this:
    https://github.com/openshwprojects/OpenBK7231...blob/main/src/selftest/selftest_energyMeter.c
    Helpful post? Buy me a coffee.
  • #40 21321819
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    p.kaczmarek2 wrote:
    This will help us to make sure that all topics stayed compatible with previous versions

    👍

    Added after 50 [minutes]:

    p.kaczmarek2 wrote:
    stayed compatible with previous versions.

    It wouldn't be bad to at least check device_class state_class and unit_of_measurement - that would reveal, for example, my typo here https://github.com/openshwprojects/OpenBK7231T_App/pull/1433.
  • #41 21321989
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    I've double checked and it seems that selftest_energyMeter.c already checks for:
    Code: C / C++
    Log in, to see the code

    We also have Test_HassDiscovery_BL0942 in selftest_hass_discover.c:
    Code: C / C++
    Log in, to see the code

    The main drawback of current approach is that the tests don't check for keyword presence in given publish, but they check all publishes, but I will try to improve it as well. Still, they should detect missing MQTT topics well.

    Added after 8 [minutes]:

    Ok I am improving it:
    Code: C / C++
    Log in, to see the code


    Added after 12 [minutes]:

    Much better? Almost..
    Test code in Visual Studio editor regarding MQTT tests.
    Helpful post? Buy me a coffee.
  • #42 21322078
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    p.kaczmarek2 wrote:
    Much better? Almost..

    Wow, 3key, impressive!

    So you'll add a check according to drv_bl_shared.c, right?

    Screenshot of a text editor showing a fragment of C code related to sensor definitions.
  • #43 21322110
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    More or less, I guess, but I need to do without using the C table you mentioned, otherwise it would defeat the purpose... if I were to use exactly the data from table, then I wouldn't be able to catch typo in it anyway.
    Helpful post? Buy me a coffee.
  • #44 21322141
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    p.kaczmarek2 wrote:
    but I need to do without using the C table you mentioned, otherwise it would defeat the purpose

    Of course, I didn't even mean to use a structure, that wouldn't make sense (as you wrote)
  • #45 21324450
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    >>21321593
    I got some WB2S today. I compiled it using PR https://github.com/openshwprojects/OpenBK7231T/pull/20 and the stock app using:

    Code: text Expand Select all Copy to clipboard
        git clone https://github.com/xjikka/OpenBK7231T -b uart2 ./bk7231t
    git clone https://github.com/openshwprojects/OpenBK7231T_App ./bk7231t/apps/OpenBK7231T_App
    cd bk7231t
    ./build_app.sh apps/OpenBK7231T_App OpenBK7231T_App 1.17.777-uart2sdk

    And BL0942 on UART2 works without any problems with this autoexec.bat:

    Code: text Expand Select all Copy to clipboard
       logtype none
   setflag 26 1
   startDriver BL0942


    Also, when I send some dummy bytes to UART2, I get as expected:

    Code: text Expand Select all Copy to clipboard
       Warn:EnergyMeter:Consumed 30 unwanted non-header byte in BL0942 buffer 


    So I can confirm that this UART2 patch is also ok for the BK7231T chip and it is mergeable from my side.

    As a bonus I checked the twinbl0942mod branch and both channels on both UARTs working with this PR.

    And as an added bonus, here's my test build. Just so you know how not to do it ;-)

    Prototype setup with electronic components on breadboards with wires and a power adapter.
  • #46 21324542
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    Nice, I see you're using the same variable power supply that I did once a teardown of:
    https://www.elektroda.pl/rtvforum/topic3919579.html
    As for the protoboard power supply, well, I have my own version:
    https://www.elektroda.pl/rtvforum/topic3752773.html

    Today I extended the self test a bit:
    https://github.com/openshwprojects/OpenBK7231...mmit/a6dcddb6a533901c38a0d1b03939e4cf449babc2
    ... but for some reasons now, self test fails on Github but not on my PC? I need to investigate... maybe it times out on the cloud build. I can't see anything wrong in Github logs.

    I've merged the BK7231T PR.
    Helpful post? Buy me a coffee.
  • #47 21324642
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    p.kaczmarek2 wrote:
    As for the protoboard power supply,

    The red wire is there to make it hot and spicy, right? |;)

    Breadboard with a red wire connected to a blue electronic board.

    Added after 17 [minutes]:

    p.kaczmarek2 wrote:
    I extended the self test a bit:

    ANY_4KEY – You are unstoppable

    Added after 11 [minutes]:

    p.kaczmarek2 wrote:
    I've merged the BK7231T PR.

    👌

    Added after 1 [minutes]:

    p.kaczmarek2 wrote:
    self test fails on Github but not on my PC?

    Can I help You somehow with that?

    Added after 25 [minutes]:

    p.kaczmarek2 wrote:
    well, I have my own version:


    Nice work and Powerfull - up to 1,2A !
    The version from Ali is really weak (current) and the stabilizers get hot even at low load. However, it is enough for me for testing.

    Power module with USB output and power connector, polarity marked with arrows.

    I have also another version, and it almost blew up my processor.
    !!! plus and minus are reversed !!!

    Electronic module with highlighted reversed power supply polarity.

    Fortunately, I noticed it in time!
  • #48 21324728
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    XJ_ wrote:
    p.kaczmarek2 wrote:
    As for the protoboard power supply,

    The red wire is there to make it hot and spicy, right? |;)
    [/quote]
    Exactly! This protoboard power supply is shortcircuit-proof, it just lights up a LED when there is a short.

    XJ_ wrote:

    ANY_4KEY – You are unstoppable

    When something is stupid but works, then it's not stupid :D

    XJ_ wrote:

    p.kaczmarek2 wrote:
    self test fails on Github but not on my PC?

    Can I help You somehow with that?

    For now, I am investigating myself, it seems that two of self tests fail on Github but not on my machine:
    Code: text Expand Select all Copy to clipboard
    
ERROR: SelfTest failed for SIM_HasMQTTHistoryStringWithJSONPayload("homeassistant", 1, 0, 0, "dev_cla", "energy", "stat_t", "~/energycounter/get", "unit_of_meas", "Wh", "stat_cla", "measurement")
Check D:\a\OpenBK7231T_App\OpenBK7231T_App\src\selftest\selftest_hass_discovery.c - Test_VerifyForCommonPowerMeteringStuff - line 339
Total SelfTest errors so far: 3
ERROR: SelfTest failed for SIM_HasMQTTHistoryStringWithJSONPayload("homeassistant", 1, 0, 0, "dev_cla", "energy", "stat_t", "~/energycounter_last_hour/get", "unit_of_meas", "Wh", "stat_cla", "measurement")
Check D:\a\OpenBK7231T_App\OpenBK7231T_App\src\selftest\selftest_hass_discovery.c - Test_VerifyForCommonPowerMeteringStuff - line 345
Total SelfTest errors so far: 4
Info:MAIN:Drv BL0937 stopped.

    I've added SIM_DumpMQTTHistory and if it does not lead to the solution I will investigate in the separate branch (to avoid spamming main releases).


    XJ_ wrote:

    !!! plus and minus are reversed !!!

    Electronic module with highlighted reversed power supply polarity.

    Fortunately, I noticed it in time!

    So seller is so greedy that he actually tries to sell the product with obvious flaw instead of scrapping it? Well, maybe it's not that bad, assuming that he sells it under special discount price..

    Added after 5 [minutes]:

    EDIT - regarding my issue:
    Screenshot of a build simulator with several entries related to Home Assistant sensor configurations.
    ahhh it has stat_cla total_increasing and not measurement. But it does not explain why it didn't fail on my machine! Did Visual Studio again failed on full rebuild?!

    Added after 6 [minutes]:

    Wait, it fails after rebuild... and by fail, I mean it works correctly... so it was the "rebuild" problem, after all, Visual Studio did not refresh all .o files.
    Helpful post? Buy me a coffee.
  • #49 21324754
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    p.kaczmarek2 wrote:
    it has total_increasing and not measurement

    Super, is it solved then, right?

    Maybe in the future it would help to add a log where the difference is

    Code: text Expand Select all Copy to clipboard
    bool CheckForKeyVal(cJSON *tmp, const char *key, const char *value) {
...
if (!strcmp(ret, value)) {
return true;
 } else {
 printf("CheckForKeyVar error '%s'<>'%s'",ret, value))   just typed, not tested
}
...
    and so on

    Added after 1 [minutes]:

    p.kaczmarek2 wrote:
    correctly... so it was the "rebuild" problem, after all, Visual Studio did n

    I've come across it a few times too
  • #50 21324851
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    Your generic idea is good, but the following code snippet will not work correctly - it would print lots of data. I think it's better to just do once a SIM_DumpMQTTHistory call when the MQTT publish check fails.

    I've added some more checks and pushed changes to github
    Helpful post? Buy me a coffee.
  • #51 21324965
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    p.kaczmarek2 wrote:
    it would print lots of data

    I meant printf if not matching (strcmpi } else { ) - means only in case of error. i.e total_increasing <> measurement
  • #52 21325850
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    As I said, the mechanism is checking every entry in MQTT publish history until it finds a match, so if entry, I don't know, 10 of 12 is a match, then it would print info for all 9 entries before that.

    The better solution is to just dump whole MQTT history once MQTT assert/test fails....

    PS: Of course this "mqtt history" is cleared per each asserts, so there are no older entries polluting the tests
    Helpful post? Buy me a coffee.
  • #53 21325939
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    p.kaczmarek2 wrote:
    10 of 12 is a match, then it would print info for all 9 entries before that.

    Ah. I understand now. Thanks for the explanation.
  • ADVERTISEMENT
  • #54 21327444
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14394
    Help: 650
    Rate: 12314
    This whole Windows/Simulator build is indeed a bit wild, especially that MQTT library from LWIP port to Windows that I did so that I can test HASS integration directly from my Windows PC. The MQTT self tests are similiar, they are injected at publish call level and store whatever was published so I can externally check later if all functionality is within expectations.

    Added after 19 [seconds]:

    Btw, are you able to compile and run the simulator on your machine?
    Helpful post? Buy me a coffee.
  • #55 21327691
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    >>21327444
    p.kaczmarek2 wrote:
    Btw, are you able to compile and run the simulator on your machine?

    Sure, I use it often, I modify everything in it. Sometimes I have to "bend" it a bit, e.g. when I need to test early.bat, a lot of things are not clear - what is implemented there and what is not. However, I was weaned from assembler and machine code in the 80s, so I can always manage. It's still just a program for some processor ;-)
    But without the simulator I wouldn't actually do any of what I did - because I wouldn't even start ;-9
  • #57 21404961
    XJ_
    Level 12  
    Posts: 140
    Help: 13
    Rate: 38
    >>21404671
    https://github.com/openshwprojects/OpenBK7231N/pull/21 has been merged now?[/quote]
    It is merged already...

    Added after 1 [minutes]:

    >>21404671
    randomalias324 wrote:
    to a very similar device tomorrow.

    If it is a device with two BL0942, I suggest You to compile and try this:
    https://github.com/xjikka/OpenBK7231T_App/tree/twinbl0942mod

    Autoexec.bat
    Code: text Expand Select all Copy to clipboard
    logtype none
startDriver NTP
ntp_timeZoneOfs +01:00
BL0942opts 3
startDriver BL0942


    BL0942opts 3 is used to set options so that startDriver BL0942 starts the driver for two BL0942 on both UARTs (Beken)
    Flag 26 ([UART] Use alternate UART for BL0942) should be disabled
  • #58 21405654
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    >>21404961

    Yep that's what I attempted to build.

    Looks like my Cygwin build pipeline is broken, or I'm doing something wrong. Seems to complete, but the OTA won't flash and flashing over UART bricks it.

    Don't suppose you could share a binary?

    Added after 6 [hours] 33 [minutes]:

    Alright, got it working.

    Looks like Home Assistant self discovery doesn't work

    How do we add Voltage B and Current B?

    Added after 3 [minutes]:

    Now Voltage A and Voltage B don't display in the device page.

    Seems like the dual measurement is buggy, potentially triggered by calling self discovery

    Added after 4 [minutes]:

    Yep, cant get dual measurement back by restarting, toggling BL0942opts, so far whatever I try

    Added after 4 [minutes]:

    By playing around with SetFlag 26 it appears it has lost the ability to read UART2

    Added after 35 [minutes]:

    I have taken some logs from the UART ports
    I think despite logtype none being included in autoexec, UART2 is being spammed.

    I have attached some UART logs, where logging is started just prior or just after sending the reset command from the native UI page
    Attachments:
    • UART_Logs_After_Reset.zip (8.17 KB) You must be logged in to download this attachment.
  • #60 21405808
    randomalias324
    Level 8  
    Posts: 41
    Rate: 4
    >>21405788

    Reading off UART2 has failed altogether though, it won't show up on the UI page of the device itself now.

    Either with the autoexec line FlagSet 26 1 (and no BL0942opts 3) or with the line BL0942opts 3 (and no FlagSet 26 1)

    When I first had it working I could see both sets of voltages/currents, just like in your screen shots; The 'normal' voltage/currents on UART1, and voltage B Current B from UART 2 underneath
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