>>21763803 Hi josemr,
I've been working non-stop on this exact issue for the past 48 hours, and I can now confirm the root cause of the dual-channel problem.
Hardware Architecture Confirmation:
After carefully reading through this thread, I found the key information: the QS-wifi-S10-CT02 has two BL0942 chips communicating via a SINGLE shared UART port on the CB2S - NOT via separate UART1 and UART2 like other dual-meter designs. This specific hardware architecture is exactly what's causing our issues.
What I Tested:
I compiled a custom OpenBK7231N firmware with:
- ENABLE_BL_TWIN explicitly enabled in obk_config.h
- Both ENABLE_DRIVER_BL0942 and ENABLE_DRIVER_BL0942SPI active
- Firmware compiled and flashed successfully via OTA
Test Results (with 230V mains connected and loads on both clamps):
- Voltage/frequency readings display on the web interface (likely default/cached values: 240V, 50Hz)
- Zero current/power readings despite active loads connected to both clamps
- Persistent checksum errors flooding the logs:
Warn:EnergyMeter:Failed to read reg 03: bad checksum 00 wanted A4
Warn:EnergyMeter:Failed to read reg 04: bad checksum 00 wanted A3
Warn:EnergyMeter:Failed to read reg 06: bad checksum 00 wanted A1
Warn:EnergyMeter:Failed to read reg 07: bad checksum 00 wanted A0
Warn:EnergyMeter:Failed to read reg 08: bad checksum 00 wanted 9F
Analysis:
These errors prove that:
1. Both BL0942 chips ARE physically responding to queries
2. Their UART data frames collide and overlap when transmitted simultaneously on the shared bus
3. The driver receives corrupted data (checksum 00 = no valid data/collision)
4. Registers 03-08 (current, power, energy) cannot be read due to continuous frame corruption
Root Cause:
The ENABLE_BL_TWIN flag in OpenBK7231N was designed for hardware architectures where each BL0942 has its own dedicated UART (UART1 for chip 1, UART2 for chip 2).
Our QS-wifi-S10-CT02 has a fundamentally different design: both BL0942s share the SAME UART bus. Without a proper addressing/polling protocol, when the firmware queries a register, both chips respond simultaneously → collision → unreadable data.
The current OpenBK7231N driver lacks:
- Individual chip addressing mechanism
- Collision detection/avoidance
- Sequential polling for shared-UART configurations
Other Firmware Options:
I also investigated alternatives:
- ESPHome: Has an open GitHub issue (#10137) titled "bl0942 component doesn't work with multiple (2-3-4)" confirming the same limitation for multiple BL0942s on shared UART
- Tasmota: BL0942 support exists but only for single-chip configurations; no shared-UART multi-chip support found
Conclusion:
This appears to be a fundamental limitation across ALL current open-source firmware options (OpenBK7231N, ESPHome, Tasmota). The shared-UART dual-BL0942 architecture of the QS-wifi-S10-CT02 is not supported by any existing open-source drivers.
Available Options:
1. Hardware modification: Physically disable one BL0942 (desolder or cut VCC trace) to eliminate collisions and get one working channel
2. Wait for driver development: Submit feature requests to firmware projects for "twin BL0942 on shared UART" support (requires significant driver rewrite with addressing protocol)
3. Accept limitation: Use device with single clamp only
Question for the community: Has anyone successfully gotten both channels working simultaneously with this exact QS-wifi-S10-CT02 model using ANY firmware? If so, please share details!
I'm documenting all findings and will submit detailed feature requests to the relevant GitHub repositories.
QS-wifi-S10-CT02_4.png
(7.54 MB)
You must be logged in to download this attachment.
QS-wifi-S10-CT02_3.png
(2.94 MB)
You must be logged in to download this attachment.
QS-wifi-S10-CT02_2.png
(2.72 MB)
You must be logged in to download this attachment.
QS-wifi-S10-CT02_1.png
(2.33 MB)
You must be logged in to download this attachment.
