logo elektroda
logo elektroda
X
logo elektroda

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

XJ_ 3387 118
ADVERTISEMENT
  • Helpful post
    #1 21298953
    XJ_
    Level 11  
    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
    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 11  
    >>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
  • #4 21299065
    p.kaczmarek2
    Moderator Smart Home
    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.
  • ADVERTISEMENT
  • Helpful post
    #5 21299078
    XJ_
    Level 11  
    >>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.

    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
    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
    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
    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 11  
    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 !!

    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
          Warn:EnergyMeter:rc 0
          Warn:EnergyMeter:bl0942 uart bytes 00
    

    #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.
  • ADVERTISEMENT
  • #8 21299630
    p.kaczmarek2
    Moderator Smart Home
    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 11  
    >>21299630
    User @LucaArena sent me this info already, I'll check it.
  • #10 21300789
    p.kaczmarek2
    Moderator Smart Home
    Good to hear. So, did you try the polling approach?
    Helpful post? Buy me a coffee.
  • #11 21300816
    XJ_
    Level 11  
    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 11  
    >>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.

    #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
    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 11  
    >>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
    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 11  
    >>21305391 >>21305391
    Are you sure that nobody is using UART2 on Beken in actual state somehow?
  • #18 21310895
    p.kaczmarek2
    Moderator Smart Home
    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 11  
    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
    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 11  
    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
    @divadiow @DeDaMrAz any BK7231T boards at hand? If you want...
    Helpful post? Buy me a coffee.
  • #24 21313538
    XJ_
    Level 11  
    >>21313514
    Yes, only the SDK was changed.
  • #25 21315831
    divadiow
    Level 34  
    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 11  
    >>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 34  
    OK. Cool. I don't have equipment with me to test until probably tomorrow now or Monday :)
  • #28 21316626
    XJ_
    Level 11  
    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 11  
    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:
    logtype none
    MovingAvgSet 20
    startDriver NTP
    ntp_timeZoneOfs  01:00
    BL0942opts 3
    startDriver BL0942
    ConsumptionThreshold 200
    

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.
Summary generated by the language model.
ADVERTISEMENT