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_ 3399 118
ADVERTISEMENT
Reply | New topic
  • #61 21405842
    XJ_
    Level 11  
    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:
  • ADVERTISEMENT
  • #63 21405860
    XJ_
    Level 11  
    >>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  
    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 11  
    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
  • ADVERTISEMENT
  • #66 21405907
    randomalias324
    Level 8  
    >>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 11  
    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  
    @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 11  
    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  
    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 11  
    randomalias324 wrote:
    I have the loops setup on a heater.

    First, I would recommend you try a simple classic light bulb (NOT LED)
  • #72 21406045
    randomalias324
    Level 8  
    >>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
  • ADVERTISEMENT
  • #73 21406699
    XJ_
    Level 11  
    randomalias324 wrote:
    Flashed the modified firmware, added BL0942opts 3 to autoexec.bat and its now running

    Great!
  • #74 21407161
    randomalias324
    Level 8  
    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
  • ADVERTISEMENT
  • #75 21407285
    XJ_
    Level 11  
    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  
    >>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 11  
    >>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  
    >>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 11  
    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  
    >>21407593
    Your device never logs those errors?
  • #81 21407603
    XJ_
    Level 11  
    >>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  
    >>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
  • #84 21411897
    p.kaczmarek2
    Moderator Smart Home  
    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 11  
    >>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  
    >>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 11  
    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  
    Hey @XJ_, is MovingAvgSet a new command? It's not in the docs. Interested in using for some other devices
  • #89 21415080
    XJ_
    Level 11  
    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 11  
    >>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.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT