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

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.

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.

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.

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?



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.

p.kaczmarek2 wrote:

That's why we have option for RF-only powersave only in OBK, which is less efficient but BL0937-friendly.

I don't remember that getting merged, or did it happen in with some other code?
https://github.com/openshwprojects/OpenBK7231T_App/pull/1533

Interesting, but I checked current code and we have:

So it indeed checks for BL0937 and skips MCU sleep if found.

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.