Can the Tongou TO-Q-SA1 WiFi smart energy meter be identified and flashed with custom firmware, and what chips or UART wiring does it use inside?
Yes: the unit appears to use a Tuya CB2S Wi‑Fi module with a BK7231N, an STC8H3K64S2 secondary MCU, and a BL0942 energy-measurement chip [#21562880] That means it behaves like a TuyaMCU device, so in OpenBeken you can map the meter data via dpID 6 using `RAW_V2C3P3`, with voltage/current/power packed as 8 bytes big-endian; one user got it working with `startDriver TuyaMCU`, `tuyaMcu_setBaudRate 115200`, `tuyaMcu_defWiFiState 4`, and `linkTuyaMCUOutputToChannel 6 RAW_V2C3P3` [#21563065][#21569350][#21570955] However, several users found the readings stop after about 25–30 minutes or only resume briefly, and `tuyaMcu_sendQueryState` still did not bring back dpID 6 reliably [#21576465][#21576531][#21576703] The most reliable workaround reported was to remove the STC chip entirely and wire the BL0942 directly to the BK7231N UART (RX1/TX1), then use OBK’s BL0942 driver; after that, calibration with a known load was needed [#21577273][#21577386][#21576775]
That's because this device has non-isolated power supply. So it can have live wire potential on TuyaMCU RX/TX lines. If your machine, for example, has USB ground grounded (directly or indirectly) ,then you will get a live short.
I don't recommend testing with just 3.3V. You could try it, but then, how would you be able to tell that it's actually working?
Maybe it would be better to try feeding 12V DC (from isolated power supply) to the mains input of the device. Maybe it could work on voltage as low a 12V.
I don't recommend testing with just 3.3V. You could try it, but then, how would you be able to tell that it's actually working?
So, I spent a few minutes thinking about which path to choose — trying to reverse-engineer the Tuya protocol or resorting to surgical methods. Taking into account that such research carries the risk of fire and electric shock (and my apartment is not insured), and to make matters worse, the first guy who started investigating this device in the thread has vanished without a trace... I decided to take the path of least resistance :)
The 8H3K64S2 chip was removed as the root of the problem. The BL0942 and BK7231N chips were connected directly via UART (as shown in the photo). Nothing else needed to be done. In OBK, I simply enabled the BL0942 driver.
I believe that if someone is capable of flashing OBK onto this device, then soldering two wires shouldn't be a big challenge either.
Just a reminder: when installing the device on the wire, be mindful of the current direction. If you install it backwards, the current readings will be negative.
Just a reminder: when installing the device on the wire, be mindful of the current direction. If you install it backwards, the current readings will be negative.
True, but it's not a bug, it's a feature for PV guys.
True, but it's not a bug, it's a feature for PV guys.
Now I'm puzzled by something else. I'm seeing current spikes of about 1.2 amps on the graph, and I can't figure out where they're coming from. I've already tried turning off almost every device in the apartment — except a few that I currently can't access. I'm starting to suspect that maybe I ended up with some "special" version of the BL0942 😄 Has anyone seen this kind of behavior before?
Added after 25 [minutes]:
False alarm! 😄 I found the source of the current spikes — it's the floor heating near the balcony, installed by the developer. What’s strange is that it was supposed to be just a self-regulating heating cable, but this one clearly uses some kind of pulse-based control. Looks like the developer just embedded the control unit somewhere in the concrete — I couldn’t find it anywhere 😅 Sorry for the off-topic!
Added after 20 [minutes]:
p.kaczmarek2 wrote:
Good job. Did you also calibrate?
Yes, everything calibrated perfectly using a 60W OSRAM incandescent bulb.
I see, interesting. From my experience, BL0942 is more reliable than BL0937, so there should be no strange pulses. For BL0937, strange readouts may happen if you use MCU power save along with it, as it relies on GPIO interrupts. That's why we have option for RF-only powersave only in OBK, which is less efficient but BL0937-friendly.
So it indeed checks for BL0937 and skips MCU sleep if found.
oh this is good news. I guess Zanadar can close that PR.
I didn't see acknowledgment in commands list, so will maybe propose update unless you do first. Or maybe it doesn't matter now and it doesn't need special mention because it's automatic if BL0937.
>>21577273 Sorry, I didn't vanish but I said as much as I can. Unfortunately I didn't have much time to play with it (or put it in use) so that discovery about not sending data was on you . But I can confirm that also. Also I was suspicious from the beginning that second MCU could cause some issues, since I don't understand why it is here.
BTW @p.kaczmarek2 could it be possible that module thinks that he is in other mode so he is reporting only every hour? I mean this
2) The meter reports data based on a certain period. Suggestion: In WIFI mode, report once every 15 seconds. In NB mode, it is reported once every hour.
EDIT: Yes offset for all three (U, I, P) would be nice - if it makes sense. Because now with data every hour it doesn't I guess). But also more data how "accurate" measuring is will be also helpful.
{
"abilityId": 6,
"accessMode": "ro",
"code": "phase_a",
"description": "1，A相电压，电流及功率\n2，大端模式，HEX格式，共8个字节\n3，单位精度：电压，2字节，单位0.1V。电流，3字节，单位 0.001A 。A相有功功率，3字节，单位0.0001kW\n4，报文格式\n举例：08 80 00 03 E8 00 27 10 表示A相217.6V，A相电流1.000A，A相功率10.000KW\n5，通信逻辑：\n1）用户进面板，主动查询。用户进入面板，面板马上下发0x08到电表，电表上报数据到云平台，面板拿到数据，然后展示。 注：最新WIFI支持。 \n2）电表基于一定周期上报数据。建议：在WIFI模式时，15秒上报一次。NB模式时，1个小时上报一次。
1. Phase A voltage, current and power
2, big-endian mode, HEX format, 8 bytes in total
3. Unit accuracy: voltage, 2 bytes, unit 0.1V. Current, 3 bytes, unit 0.001A. Phase A active power, 3 bytes, unit 0.0001kW
4, message format
Example: 08 80 00 03 E8 00 27 10 means phase A 217.6V, phase A current 1.000A, phase A power 10.000KW
5, Communication logic:
1) Users enter the panel and actively query. When the user enters the panel, the panel immediately sends 0x08 to the meter. The meter reports the data to the cloud platform. The panel obtains the data and then displays it. Note: The latest WIFI support.
2) The meter reports data based on a certain period. Suggestion: In WIFI mode, report once every 15 seconds. In NB mode, it is reported once every hour.
",
It's in description of dpID 6 data, which is sent from MCU to WiFi module. I don't see how can WiFI module use it to alter reporting period. For now, it seems unclear or not implemented for me.
The best I can recommend is the already mentioned tuyaMcu_sendQueryState command. It seemed to work in the past, at least for some of TuyaMCU devices.
kymlalu wrote:
EDIT: Yes offset for all three ( U,I, P ) would be nice - if it make sense. Because now with data every hour it doesn't i guess ). But also more data how "accurate" measuring is will be also helpfull.
I'll add a self test for it in a moment.
PS: First delta is for voltage, second for current, third for power. Deltas are unscaled, as in Tuyamcu values. So, when TuyaMCU sends 2305 (as for 230.5), then you set delta to 10, and get 2305+10 = 2315 (231.5V)
I add that command but with same results as casiopeia80 had. Nothing has changed. I also noticed when I restart module from UI (red restart button in "tasmota" UI) I don't receive any dpID6 messages, only TUYA MCU transmit some data (signal strength, MCU temp, frequency, total kW/h and other IDs) but no dpID6
The accuracy of the device is surprisingly good. On the screenshot: on the right — the readings from the certified apartment energy meter, on the left — the energy calculation in Grafana using the integral of the power measured by the device. Over six days, the difference came out to just 0.012%.
So I finally had some time to hook up TTL serial to my unit, flash it with original FW, do makeshift extension cord and hook it to the RPi to log serial comm (I use CoolTerm - looks solid and can log into file, but if anyone have anything better and runs on RPI I can try) for longer time period. Also plugged in my refrigerator as load Aaand all I'm see from log is just heartbeat (based on what hex for heartbeat looks and what tuyaanalyzer showed).
I'm taped on RX/TX pins of TUYA module, when I switch something in TUYA app I can see command in log, but I don't see any power metering data (current, voltage, power..). But in TUYA app everything is displayed. So I don't know what's wrong or what.
Also I attached -overnight log
Attachments:
po.zip(292 Bytes)
You must be logged in to download this attachment.
In the case of LN882H PowerSave will not work as a startup command, so use in autoexec.
Hm, I'll have to check, but didn't we change that for LN882H to work in any case? Iirc the actual turning PowerSave on was delayed until WiFi is working. Didn't that count for startup, too? If no one is faster, I'll try in the afternoon.
Added after 3 [hours] 29 [minutes]:
Unbelievable, faster than @divadiow
In fact, "powersave" can be set in startup command of LN882H
If you want to adjust command descriptions, then you need to edit the source code of OBK - command descs are in the XML comments and getcommands.js parses them on every docs build
I don't. few posts back I posted logged data from unit with original FW but there wasn't much ( maybe I did something wrong? ). But at the end I ended up with removing STC microcontroller and added jumpers ( as posted by OP ) which I planned originally anyway. Now they are working just fine for some time.
✨ The Tongou TO-Q-SA1 is a compact WiFi-enabled smart energy meter based on the Tuya platform, featuring no internal relay and designed for inline monitoring. Internally, it uses an STC8H3K64S2 MCU, a Tuya WB2S WiFi module, and a BL0942 power measurement chip. The device communicates via TuyaMCU protocol at 115200 baud, with data including voltage, current, active power, energy, and temperature. Users encountered issues with the MCU ceasing to send measurement data (dpID 6) after approximately 30 minutes, likely due to the Tuya MCU firmware requiring a cloud handshake or timing out. Attempts to maintain data flow using repeated UART commands (e.g., tuyaMcu_sendQueryState and custom repeating events) were partially successful but did not fully resolve the issue. A practical solution involved physically removing the STC8 MCU and directly connecting the BL0942 chip to the BK7231N WiFi SoC via UART, enabling the use of OpenBK7231T firmware with the BL0942 driver for stable readings and calibration. Calibration was performed using a known load (60W incandescent bulb), achieving high accuracy with minimal error (~0.012% over six days). The device’s power-saving behavior and reporting intervals were discussed, with suggestions to use TuyaMCU analyzer tools and galvanic isolation for safe UART traffic capture. The BL0942 chip was noted as more reliable than alternatives like BL0937, which can have issues with MCU power-saving modes. Overall, flashing and modifying the device firmware with OpenBK7231T and bypassing the secondary MCU provided a robust method for stable, accurate energy monitoring. Generated by the language model.
TL;DR: Over 6 days, one user measured just 0.012% energy error after saying "It works fine with the chip removed." This FAQ is for TO-Q-SA1 owners who want stable OpenBeken flashing, dpID 6 decoding, and the proven hardware bypass when TuyaMCU stops live measurements after about 25–30 minutes. [#21585026]
Why it matters: The thread shows that software-only TuyaMCU integration can work briefly, but the most reliable long-term fix is a simple hardware reroute from the BL0942 metering IC directly to the Wi-Fi module.
Method
Live V/I/P data
Long-term stability
Difficulty
Notes
OpenBeken + TuyaMCU dpID 6
Yes, initially
Poor
Low
Often stops after about 25–30 minutes
OpenBeken + repeated UART queries
Sometimes
Poor
Medium
Did not fix the timeout in the thread
STC removed, BL0942 wired direct
Yes
Good
Medium
Confirmed stable by multiple users
Key insight: The TO-Q-SA1 hardware is usable with OpenBeken, but the stock STC TuyaMCU path throttles or suppresses dpID 6 over time. Direct BL0942-to-BK7231/WB2S wiring was the only confirmed stable solution in the thread.
Quick Facts
Internal parts identified from teardown photos were STC8H3K64S2 as the main MCU, a CB2S/WB2S-class Tuya Wi-Fi module, and BL0942 as the power-measurement chip. [#21562880]
The successful TuyaMCU mapping used dpID 6 as RAW_V2C3P3, decoding an 8-byte big-endian payload into voltage, current, and active power. [#21569184]
Users reported that live voltage/current/power updates worked at first, then stopped after about 25–30 minutes, later dropping to roughly one update per hour. [#21576587]
The direct-wire BL0942 mod was calibrated with a known 60 W incandescent bulb, and one six-day comparison against a certified apartment meter showed only 0.012% difference. [#21577386]
The board can run from about 26 V DC on the mains-input side during bench testing, but the power supply is non-isolated, so UART capture can put lethal mains potential onto signal ground. [#21570161]
How do you flash OpenBeken on the Tongou TO-Q-SA1 and configure TuyaMCU to read voltage, current, and power from dpID 6?
Flash OpenBeken to the Tuya Wi-Fi module first, then map dpID 6 as RAW_V2C3P3. 1. Install OBK on the WB2S/CB2S-class module. 2. Start the TuyaMCU driver at 115200 baud and force Wi-Fi state 4. 3. Link dpID 6 to channels for voltage, current, and power. This worked immediately for live readings before the later timeout issue appeared. [#21570955]
What chips are inside the Tongou TO-Q-SA1, and how are the STC8H3K64S2, WB2S/CB2S Wi-Fi module, and BL0942 connected?
The TO-Q-SA1 contains an STC8H3K64S2 MCU, a Tuya CB2S/WB2S-family Wi-Fi module, and a BL0942 metering IC. The STC MCU sits between the Wi-Fi module and the BL0942, so the Wi-Fi chip does not read the metering IC directly in the stock design. Only four pads were seen on the Wi-Fi module, which strongly suggested a TuyaMCU architecture. [#21563065]
Why does the Tongou TO-Q-SA1 stop sending dpID 6 voltage/current/power data after about 25–30 minutes when running OpenBeken?
It stops because the STC-based TuyaMCU path appears to suppress or change reporting of dpID 6 after about 25–30 minutes. Users still received heartbeats and other dpIDs, but dpID 6 disappeared. One user then observed a pattern of a single measurement report about once per hour. That behavior matches the thread’s suspicion that the MCU falls back to an NB-like reporting mode or requires a cloud-side trigger OBK does not reproduce. [#21576531]
What autoexec.bat commands are needed for the Tongou TO-Q-SA1 to map dpID 6 as RAW_V2C3P3 in OpenBeken?
Use the TuyaMCU driver, set 115200 baud, force Wi-Fi state 4, and map dpID 6 to RAW_V2C3P3. A working startup set was: startDriver TuyaMCU; tuyaMcu_setBaudRate 115200; tuyaMcu_defWiFiState 4; linkTuyaMCUOutputToChannel 6 RAW_V2C3P3; then assign channel 0 as Voltage_div10, channel 1 as Current_div1000, and channel 2 as Power. That configuration produced almost-correct readings right away. [#21570955]
How can you calibrate voltage, current, and power on the Tongou TO-Q-SA1 after switching to the BL0942 driver in OpenBeken?
Calibrate it in OpenBeken against a known load and a trusted reference meter. The thread recommends a load like a 60 W bulb, then using PowerSet, VoltageSet, and CurrentSet to match the expected values. One user reported that calibration worked cleanly with a 60 W OSRAM incandescent bulb after rewiring BL0942 directly to the Wi-Fi module. [#21576675]
What is TuyaMCU, and how does it affect flashing and configuration on devices like the Tongou TO-Q-SA1?
"TuyaMCU is a secondary microcontroller architecture that handles device logic and sensors, while the Wi-Fi module mainly relays serial datapoints to Tuya or custom firmware, usually over UART." On the TO-Q-SA1, that means flashing the Wi-Fi module alone does not replace the STC meter logic. You must decode dpIDs, not just assign GPIO roles, because voltage, current, and power arrive as TuyaMCU datapoints such as dpID 6. [#21569184]
What is dpID 6 on the Tongou TO-Q-SA1, and how is its RAW_V2C3P3 payload decoded into voltage, current, and power values?
dpID 6 is the Phase A voltage, current, and active-power report. It uses an 8-byte big-endian payload: 2 bytes for voltage at 0.1 V resolution, 3 bytes for current at 0.001 A, and 3 bytes for power. The thread’s example payload decodes to 217.6 V, 1.000 A, and 10.000 kW, which matches the RAW_V2C3P3 mapping used in OpenBeken. [#21569184]
What’s the difference between using the TO-Q-SA1 through TuyaMCU and bypassing the STC MCU to connect the BL0942 directly to the BK7231/WB2S module?
TuyaMCU mode is easier to try, but direct BL0942 wiring is the stable fix. Through TuyaMCU, users got live values without board surgery, yet dpID 6 often stopped after about 30 minutes. After removing the STC8H3K64S2 and wiring BL0942 straight to the Wi-Fi module UART, users reported normal continuous operation and full OpenBeken BL0942-driver support. [#21577273]
How do you safely capture UART traffic on a non-isolated mains-powered Tuya energy meter without risking damage to your PC?
Use galvanic isolation between the meter UART and your computer. The thread specifically recommends an ADuM1201-class isolator because the TO-Q-SA1 uses a non-isolated power supply, so RX/TX can sit at live mains potential. Directly connecting a USB-UART adapter can create a live short through grounded USB and may cause fire, explosion, or equipment damage. [#21576730]
Why do current readings become negative on the Tongou TO-Q-SA1 when the meter is installed in the opposite direction?
They go negative because the meter senses energy flow direction. After the BL0942 direct-wire mod, a user confirmed that reversing installation direction made current readings negative. Another expert replied that this is not a bug but a useful feature for photovoltaic systems, where reverse energy flow matters. [#21577379]
Which TuyaMCU commands or periodic UART queries can be tried to keep the TO-Q-SA1 reporting measurements instead of falling back to hourly updates?
Try tuyaMcu_sendQueryState and, if needed, periodic raw UART queries. The thread also tested this repeating command every 10 seconds: backlog uartSendHex 55AA000300010407; uartSendHex 55AA0008000007; uartSendHex 55AA00000000FF. It did not restore stable dpID 6 reporting on this device, but it is the main workaround explored before the hardware bypass. [#21576633]
How do OpenBeken and Tasmota differ when dealing with a TuyaMCU-based energy meter like the Tongou TO-Q-SA1?
OpenBeken handled this device better in the thread because it supports TuyaMCU dpID mapping and custom autoexec scripts. Tasmota was described as less straightforward here because the STC MCU hides the real metering path, so standard module dropdown configuration is not enough. OpenBeken users could map dpID 6 as RAW_V2C3P3 and later switch to the native BL0942 driver after hardware rewiring. [#21569073]
What is the purpose of the BL0942 energy metering chip, and why might it be more reliable than BL0937 for OpenBeken-based power monitoring?
"BL0942 is an energy-metering IC that measures voltage, current, power, and accumulated energy, using a direct serial interface that OpenBeken can read without GPIO pulse counting." In the thread, experts said BL0942 is generally more reliable than BL0937 and less prone to odd readings tied to MCU sleep behavior. That made BL0942 a strong candidate for direct wiring after the STC MCU was removed. [#21577830]
How accurate is the Tongou TO-Q-SA1 after the STC MCU is removed and the BL0942 is calibrated with a known load?
It was very accurate in the thread. After calibration with a 60 W incandescent bulb, one user compared the device against a certified apartment meter for 6 days and found only 0.012% difference in total energy. That is the strongest real-world accuracy data reported for the direct BL0942 setup. [#21585026]
What’s the best way to modify the Tongou TO-Q-SA1 hardware to remove the STC8H3K64S2 and wire the BL0942 directly to the Wi-Fi module for stable operation?
Remove the STC8H3K64S2, then jumper the BL0942 UART directly to the Wi-Fi module UART and enable the BL0942 driver in OpenBeken. One user said, “Nothing else needed to be done,” beyond the rewiring and driver selection. Multiple later posts confirmed that this direct-connect mod fixed the 25–30 minute dropout and stayed stable. [#21734387]
.
