logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Tongou TO-Q-SA1 WiFi Smart Energy Meter – Anyone tried flashing it?

casiopeia80 1311 52
ADVERTISEMENT
Reply | New topic
  • #31 21576770
    p.kaczmarek2
    Moderator Smart Home  
    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.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 21577273
    casiopeia80
    Level 2  
    p.kaczmarek2 wrote:
    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.

    Printed circuit board (PCB) with electronic components and a blue wire.

    Screenshot of the Home Assistant dashboard showing energy consumption charts for an apartment.

    Screenshot of an EnergyCounter monitoring panel displaying detailed electricity usage data.

    Screenshot of the EnergyCounter configuration panel with a startup commands input field.

    Graphs showing monitoring of voltage, current, and power over time in a Russian interface.
  • ADVERTISEMENT
  • #33 21577379
    p.kaczmarek2
    Moderator Smart Home  
    Good job. Did you also calibrate?

    casiopeia80 wrote:

    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.
    Helpful post? Buy me a coffee.
  • #34 21577386
    casiopeia80
    Level 2  
    p.kaczmarek2 wrote:
    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?

    Current chart showing periodic current spikes in amperes and a current value gauge.

    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.
  • #35 21577830
    p.kaczmarek2
    Moderator Smart Home  
    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.
    Helpful post? Buy me a coffee.
  • Helpful post
    #37 21578003
    p.kaczmarek2
    Moderator Smart Home  
    Interesting, but I checked current code and we have:
    Code: C / C++
    Log in, to see the code

    So it indeed checks for BL0937 and skips MCU sleep if found.
    Helpful post? Buy me a coffee.
  • #38 21578016
    divadiow
    Level 34  
    p.kaczmarek2 wrote:
    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.

    Screenshot of documentation with the word PowerSave highlighted multiple times in different colors.
  • #39 21580204
    p.kaczmarek2
    Moderator Smart Home  
    We need to update docs to reflect that, feel free to help if you have some spare time
    Helpful post? Buy me a coffee.
  • #40 21581992
    kymlalu
    Level 10  
    >>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
    Code: text Expand Select all Copy to clipboard
    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.

    from here Link

    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.
  • #41 21582025
    p.kaczmarek2
    Moderator Smart Home  
    Here is bigger part of the quote:
    Quote:


    {
    "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.

    Sure, no problem, I've added it, should be in release soon:
    https://github.com/openshwprojects/OpenBK7231...mmit/e663cf5d30ddac60deec04ab8c54da2301d876fa
    Syntax now:
    Code: text Expand Select all Copy to clipboard
    linkTuyaMCUOutputToChannel [dpId] [varType] [channelID] [bDPCache-Optional] [mult-optional] [bInverse-Optional] [delta-Optional] [delta2-Optional] [delta3-Optional]

    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)
    Helpful post? Buy me a coffee.
  • #42 21582112
    kymlalu
    Level 10  
    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
  • ADVERTISEMENT
  • #43 21585026
    casiopeia80
    Level 2  
    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%.

    Screenshot comparing two sets of electricity readings: Graphana data on the left, certified energy meter on the right.
  • #44 21605353
    kymlalu
    Level 10  
    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:
  • #46 21611552
    max4elektroda
    Level 20  
    divadiow wrote:
    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
    Tongou TO-Q-SA1 WiFi Smart Energy Meter – Anyone tried flashing it?
    Code: text Expand Select all Copy to clipboard
    
Info:MAIN:Time 94, idle 0/s, free 97304, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 0/0 
Info:MAIN:Module reboot in 2...
Info:MAIN:Time 95, idle 0/s, free 88792, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 0/0 
Info:MAIN:Module reboot in 1...
Info:MAIN:Main_Init_Before_Delay
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 19 changes count.
Error:CMD:lfs is absent
Info:GEN:PIN_SetupPins pins have been set up.
Info:MAIN:Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay
Info:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:Using SSID []
Info:MAIN:Using Pass []
Error:HTTP:Created HTTP SV thread with (stack=2048)
Info:MQTT:MQTT_RegisterCallback called for bT ln882hC23CC0FA/ subT ln882hC23CC0FA/+/set
Info:MQTT:MQTT_RegisterCallback called for bT obks/ subT obks/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/ln882hC23CC0FA/ subT cmnd/ln882hC23CC0FA/+
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obks/ subT cmnd/obks/+
Info:MQTT:MQTT_RegisterCallback called for bT ln882hC23CC0FA/ subT ln882hC23CC0FA/+/get
Info:CMD:CMD_StartScript: started @startup at the beginning
Info:CMD:CMD_PowerSave: will set to 1 after WiFi is connected
Error:CMD:LFS_ReadFile: lfs is absent
Info:CMD:CMD_StartScript: failed to get file autoexec.bat
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Time 1, idle 0/s, free 99464, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 0/0 POWERSAVE
Info:MAIN:Time 2, idle 0/s, free 99464, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 0/0 POWERSAVE
Info:MAIN:Time 3, idle 0/s, free 99464, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 0/0 POWERSAVE
Info:MAIN:Time 4, idle 0/s, free 99464, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 0/0 POWERSAVE
Info:MAIN:Time 5, idle 0/s, free 99464, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 0/0 POWERSAVE
Info:MAIN:Time 6, idle 0/s, free 97400, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 0/0 POWERSAVE
Info:MAIN:Boot complete time reached (5 seconds)
  • ADVERTISEMENT
  • #48 21611799
    p.kaczmarek2
    Moderator Smart Home  
    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
    Helpful post? Buy me a coffee.
  • #52 21611843
    insmod
    Level 25  
    >>21611840
    From what i see, there is no powersave 2. It only check if BL0937 pin is configured, and skips MCU sleep if true.
  • #53 21611861
    divadiow
    Level 34  
    Oh dear. That's so obvious too. Dunno where I got powersave 2 from. K
Reply | New topic
Report a violation of the law

Topic summary

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