Retry later and if ok, then I can merge. But didn't @insmod include a TCP to UART bridge in his PR? I would suspect that this bridge will also require update for new UART handling?
Helpful post? Buy me a coffee.
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
extern int g_uart_init_counter;int get_g_uart_init_counter();p.kaczmarek2 wrote:Retry later and if ok, then I can merge.
p.kaczmarek2 wrote:Retry later and if ok, then I can merge
logtype none
BL0942opts 3
startDriver BL0942
p.kaczmarek2 wrote:@divadiow do you have BL0942 device or BL0937 device to double-check if OBK behaviour is still the same after this PR?
divadiow wrote:do these code changes only affect BK7231N? I have this for T/BL0942
p.kaczmarek2 wrote:Which parts have grown so much in flash usage?
p.kaczmarek2 wrote:To anyone reading this topic - let me know if you have dual BL0942 device! How many of you are there?
Consumption History enabled
Sample Count: %d
Sample Interval: %d
Consumption History disabled
ConsumptionThreshold: %1.1f
Read ENERGYMETER status values. sizeof(ENERGY_METERING_DATA)=%d\n
Read ENERGYMETER status values. sizeof(ENERGY_METERING_DATA)
Consumed %i unwanted non-header byte in BL0942 buffer\n
Skipping packet with bad checksum %02X wanted %02X
Failed to read reg %02X: bad checksum %02X wanted %02X
Failed to write reg %02X val %02X: read %02X
p.kaczmarek2 wrote:TuyaMCU has separate power mechanisms right now, sadly... they don't go through bl_shared
p.kaczmarek2 wrote:Also on RBL?
p.kaczmarek2 wrote:TuyaMCU has separate power mechanisms right now, sadly... they don't go through bl_shared
p.kaczmarek2 wrote:So it's just +110 bytes now?
p.kaczmarek2 wrote:separate teardown/guide topic so people don't have to read through all 4 pages?
maxim2002 wrote:Can we also have frequency published to mqtt.
maxim2002 wrote:Just a feature request: Can we also have frequency published to mqtt.
XJ_ wrote:Added frequency.
maxim2002 wrote:Did I mess around something with cables?
maxim2002 wrote:"Flag 48 - [PWR] Invert AC dir" has no effect.
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]
startDriver BL0942 switches the UART speed to that value, which matters when you sniff traffic or mix logging with metering. [#21407285]_b suffixes, while total energy initially stayed tied to the first BL0942 only. [#21432573]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]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]logtype noneBL0942opts 3startDriver 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]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]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]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]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]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]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]