Disassembly & Insights on TO-Q-SYS-JWT DIN Rail kWh Meter with Display

Selfdrivers 8751 52

TL;DR

TO-Q-SYS-JWT DIN rail kWh meter with display was disassembled and examined, including its relay, WiFi board, display controller, and energy-measurement circuitry.
The unit uses a BK7231N WiFi board connected to an HC32F460 microcontroller on the display board, while the WiFi module mainly relays commands and data.
The internal power switch appears to be a 60A 250V relay, and the energy-measurement side includes an HT7017? chip.
OpenBeken can be flashed onto the BK7231N without breaking the display, buttons, or stored fuse settings because those peripherals are handled by the HC32F460.
Configuration for full MCB control and energy metering remains unresolved, and the device is kept on a dummy load for safe access and calibration.

Generated by the language model.

Treść została przetłumaczona

Zobacz oryginalną wersję tematu

Report a violation of the law

Reply Cool? Ranking DIY | New topic

Notify about new articles

📢 Listen (AI):

#31 20943015 03 Feb 2024 17:28

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14622

Help: 655

Rate: 12638
» | Helpful post? (0)

Post #31
20943015 03 Feb 2024 17:28

Do you have a Github account, do you know how to do PR? Maybe it would be easiest if you could comment/delete fragments of the log yourself? You don`t even need to download anything, everything is compiled online.

Or maybe increase the log buffer size?
Here is PR with this buffer increased from 1024 to 8192:
https://github.com/openshwprojects/OpenBK7231T_App/pull/1059
You can download the binary from it once it compiles.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT
#32 20943018 03 Feb 2024 18:00

Selfdrivers Selfdrivers

Level 8

Posts: 35

Rate: 12
» | Topic author Helpful post? (0)

Post #32
20943018 03 Feb 2024 18:00

>>20943011

Now it`s completely visible how it "cuts", it`s probably a matter of the amount of data, hence I want to reduce the number of lines that are sent to the logo.

Added after 1 [minute]:

p.kaczmarek2 wrote:
Do you have a Github account, do you know how to do PR? Maybe it would be easiest if you could comment/delete fragments of the log yourself? You don`t even need to download anything, everything is compiled online.

Ok, I`ll try. When I write something. I will also check the increased buffer (although it seems to me that it is the amount of data that causes the cutting).

Added after 28 [minutes]:

Increasing the buffer seems to have solved the problem, now (I think) all dpIDs are displayed correctly:

Quote:
Info:TuyaMCU:Received: 55 AA 03 07 00 08 01 02 00 04 00 00 00 06 1E
Info:TuyaMCU rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU arseState: id 1 type 2-val len 4
Info:TuyaMCU arseState: int32 6
Info:TuyaMCU:Received: 55 AA 03 07 00 08 7D 02 00 04 00 00 00 06 9A
Info:TuyaMCU rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU arseState: id 125 type 2-val len 4
Info:TuyaMCU arseState: int32 6
Info:TuyaMCU:Received: 55 AA 03 07 00 0C 06 00 00 08 09 0C 00 00 00 00 00 00 38
Info:TuyaMCU rocessIncoming[v=3]: cmd 7 (State) len 19
Info:TuyaMCU arseState: id 6 type 0-raw len 8
Info:TuyaMCU:Received: 55 AA 03 07 00 05 0B 01 00 01 00 1B
Info:TuyaMCU rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU arseState: id 11 type 1-bool len 1
Info:TuyaMCU arseState: byte 0
Info:TuyaMCU:Received: 55 AA 03 07 00 08 0D 02 00 04 00 00 00 00 24
Info:TuyaMCU rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU arseState: id 13 type 2-val len 4
Info:TuyaMCU arseState: int32 0
Info:TuyaMCU:Received: 55 AA 03 07 00 05 10 01 00 01 00 20
Info:TuyaMCU rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU arseState: id 16 type 1-bool len 1
Info:TuyaMCU arseState: byte 0
Info:TuyaMCU:Received: 55 AA 03 07 00 05 65 04 00 01 00 78
Info:TuyaMCU rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU arseState: id 101 type 4-enum len 1
Info:TuyaMCU:P arseState: byte 0
Info:TuyaMCU:Received: 55 AA 03 07 00 05 66 04 00 01 02 7B
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:P arseState: id 102 type 4-enum len 1
Info:TuyaMCU:P arseState: byte 2
Info:TuyaMCU:Received: 55 AA 03 07 00 05 67 04 00 01 01 7B
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:P arseState: id 103 type 4-enum len 1
Info:TuyaMCU:P arseState: byte 1
Info:TuyaMCU:Received: 55 AA 03 07 00 05 68 04 00 01 02 7D
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:P arseState: id 104 type 4-enum len 1
Info:TuyaMCU:P arseState: byte 2
Info:TuyaMCU:Received: 55 AA 03 07 00 05 69 04 00 01 00 7C
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:P arseState: id 105 type 4-enum len 1
Info:TuyaMCU:P arseState: byte 0
Info:TuyaMCU:Received: 55 AA 03 07 00 05 6B 04 00 01 02 80
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:P arseState: id 107 type 4-enum len 1
Info:TuyaMCU:P arseState: byte 2
Info:TuyaMCU:Received: 55 AA 03 07 00 05 6D 04 00 01 00 80
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:P arseState: id 109 type 4-enum len 1
Info:TuyaMCU:P arseState: byte 0
Info:TuyaMCU:Received: 55 AA 03 07 00 05 6E 04 00 01 00 81
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:P arseState: id 110 type 4-enum len 1
Info:TuyaMCU:P arseState: byte 0
Info:TuyaMCU:Received: 55 AA 03 07 00 05 70 01 00 01 00 80
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:P arseState: id 112 type 1-bool len 1
Info:TuyaMCU:P arseState: byte 0
Info:TuyaMCU:Received: 55 AA 03 07 00 08 72 02 00 04 00 00 00 1E A7
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:P arseState: id 114 type 2-val len 4
Info:TuyaMCU:P arseState: int32 30
Info:TuyaMCU:Received: 55 AA 03 07 00 08 73 02 00 04 00 00 00 F5 7F
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:P arseState: id 115 type 2-val len 4
Info:TuyaMCU:P arseState: int32 245
Info:TuyaMCU:Received: 55 AA 03 07 00 08 74 02 00 04 00 00 00 DB 66
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:P arseState: id 116 type 2-val len 4
Info:TuyaMCU:P arseState: int32 219
Info:TuyaMCU:Received: 55 AA 03 07 00 08 76 02 00 04 00 00 02 26 B5
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:P arseState: id 118 type 2-val len 4
Info:TuyaMCU:P arseState: int32 550
Info:TuyaMCU:Received: 55 AA 03 07 00 08 77 02 00 04 00 00 08 4B E1
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:P arseState: id 119 type 2-val len 4
Info:TuyaMCU:P arseState: int32 2123
Info:TuyaMCU:Received: 55 AA 03 07 00 08 78 02 00 04 00 00 00 0A 99
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:P arseState: id 120 type 2-val len 4
Info:TuyaMCU:P arseState: int32 10
Info:TuyaMCU:Received: 55 AA 03 07 00 08 83 02 00 04 00 00 01 54 EF
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:P arseState: id 131 type 2-val len 4
Info:TuyaMCU:P arseState: int32 340
Info:TuyaMCU:Received: 55 AA 03 07 00 08 89 02 00 04 00 00 02 58 FA
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:P arseState: id 137 type 2-val len 4
Info:TuyaMCU:P arseState: int32 600
Info:TuyaMCU:Received: 55 AA 03 07 00 05 6F 01 00 01 00 7F
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:P arseState: id 111 type 1-bool len 1
Info:TuyaMCU:P arseState: byte 0
Info:TuyaMCU:Received: 55 AA 03 07 00 05 8D 01 00 01 00 9D
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:P arseState: id 141 type 1-bool len 1
Info:TuyaMCU:P arseState: byte 0
Info:TuyaMCU:Received: 55 AA 03 07 00 08 8C 02 00 04 00 00 00 05 A8
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:P arseState: id 140 type 2-val len 4
Info:TuyaMCU:P arseState: int32 5
Info:TuyaMCU:Received: 55 AA 03 07 00 05 8E 04 00 01 02 A3
Info:TuyaMCU:P rocessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU arseState: id 142 type 4-enum len 1
Info:TuyaMCU arseState: byte 2
Info:TuyaMCU:Received: 55 AA 03 07 00 04 8A 03 00 00 9A
Info:TuyaMCU rocessIncoming[v=3]: cmd 7 (State) len 11
Info:TuyaMCU arseState: id 138 type 3-str len 0
Info:TuyaMCU:Received: 55 AA 03 00 00 01 01 04
Info:TuyaMCU rocessIncoming[v=3]: cmd 0 (Hearbeat) len 8

However, I`m looking for the value 13 (my load and I don`t see it) unfortunately.
ADVERTISEMENT
#33 20943117 03 Feb 2024 18:19

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14622

Help: 655

Rate: 12638
» | Helpful post? (0)

Post #33
20943117 03 Feb 2024 18:19

Have you checked that?

Code: text Expand Select all Copy to clipboard
Info:TuyaMCU:Received: 55 AA 03 07 00 0C 06 00 00 08 09 0C 00 00 00 00 00 00 38 Info:TuyaMCU:ParseState: id 6 type 0-raw len 8

Package: 55 AA 03 07 00 0C 06 00 00 08 09 0C 00 00 00 00 00 00 38
Let`s remove the checksum and header: 09 0C 00 00 00 00 00 00

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#34 20943222 03 Feb 2024 19:29

Selfdrivers Selfdrivers

Level 8

Posts: 35

Rate: 12
» | Topic author Helpful post? (0)

Post #34
20943222 03 Feb 2024 19:29

p.kaczmarek2 wrote:
Have you checked that?

Code: text Expand Select all Copy to clipboard
Info:TuyaMCU:Received: 55 AA 03 07 00 0C 06 00 00 08 09 0C 00 00 00 00 00 00 38 Info:TuyaMCU:ParseState: id 6 type 0-raw len 8

Package: 55 AA 03 07 00 0C 06 00 00 08 09 0C 00 00 00 00 00 00 38
Let`s remove the checksum and header: 09 0C 00 00 00 00 00 00

There is actually something here, but I don`t quite know how to read it, the measurements are as follows:

Quote:
09 09 00 00 44 00 00 0D 86 - load 13/14W
09 07 00 00 11 00 00 04 48 - load 4W

you can see that the penultimate value represents the number of watts (however, I don`t know which way to read the whole thing or, for example, to read that the load is:

00 00 0D - 13W
00 00 04 - 4W

or maybe:

00 0D 86 - 13W
00 04 48 - 4W

I am leaning towards the first option (because then it will turn out that the last HEX value is the checksum (86 and 48) and then it goes like this:
09 09 - tension
00 00 44 - amperage
00 00 0D - watts
86 - checksum

Do I think right?

Can I somehow convert values on the fly in OpenBeken according to the formula I presented?

Can I somehow filter out only id = 6?
#35 20943234 03 Feb 2024 19:39

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14622

Help: 655

Rate: 12638
» | Helpful post? (0)

Post #35
20943234 03 Feb 2024 19:39

The presence of an entire packet checksum at the end of this packet is not in dispute. Look what I wrote earlier:

Quote:

Package: 55 AA 03 07 00 0C 06 00 00 08 09 0C 00 00 00 00 00 00 38
Let`s remove the checksum and header: 09 0C 00 00 00 00 00 00

To see 8 bytes of data, I remove the header and one byte at the end - the checksum.

The only question is what these 8 bytes mean.

Only now I don`t know, these 86 are the checksum that you didn`t remove?

Or in other words - in the Tuya application, watts were as an integer?

Quote:

Can I somehow filter out only id = 6

We plan to add search filters to the log panel but it is not done.

Quote:

Can I somehow convert values on the fly in OpenBeken according to the formula I presented?

At the moment, we do it as simply as possible, i.e. we simply add a special enumerator value via PR and in it:

Wait a minute, doesn`t the above type of package from the screenshot match what you have? Voltage (times 10, as a total), current (times 1000, as a total), and power?

I guess that`s it. Even the dpID from the comment is correct - dpID 6. Add to autoexec.bat:

Set the type channels ChType_Voltage_div10 ChType_Current_div1000 ChType_Power and OBK itself will parse it in the current firmware version.

PS: I know it would be better to have some more scriptable format parsing raw but as you can see, at least the VCP (Voltage/Current/Power) frame is repeated between devices and its format from TAC2121C also fits your device.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#36 20943248 03 Feb 2024 19:50

Selfdrivers Selfdrivers

Level 8

Posts: 35

Rate: 12
» | Topic author Helpful post? (0)

Post #36
20943248 03 Feb 2024 19:50

p.kaczmarek2 wrote:
I guess that`s it. Even the dpID from the comment is correct - dpID 6. Add to autoexec.bat:

Set the type channels ChType_Voltage_div10 ChType_Current_div1000 ChType_Power and OBK itself will parse it in the current firmware version.

I guess I didn`t fully understand what I should put into autoexec. I tried to set it up but I think I`m doing something wrong.
ADVERTISEMENT
#37 20943257 03 Feb 2024 19:57

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14622

Help: 655

Rate: 12638
» | Helpful post? (0)

Post #37
20943257 03 Feb 2024 19:57

If you use this line:

Code: text Expand Select all Copy to clipboard
linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP

It will automatically set channels of the following types:
- Voltage_div10
- Current_div1000
-Power
on the values from this package. Channel types maintain the integer convention to maintain compatibility with TuyaMCU.

Look:
https://www.elektroda.com/rtvforum/find.php?q=RAW_TAC2121C_VCP
Screenshot from the search engine:

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#38 20943305 03 Feb 2024 20:25

Selfdrivers Selfdrivers

Level 8

Posts: 35

Rate: 12
» | Topic author Helpful post? (0)

Post #38
20943305 03 Feb 2024 20:25

Hurray, managed to get some energy readings. The current autoexec looks like this:

Quote:
startDriver TuyaMCU
tuyaMcu_setBaudRate 115200
tuyaMcu_defWiFiState 4
setChannelType 1 toggle
setChannelType 2 TextField
setChannelType 3 TextField
setChannelType 4 TextField
setChannelType 5 TextField
setChannelType 6 TextField
setChannelType 7 temperature_div10
setChannelType 8 Current_div1000
setChannelType 9 Voltage_div10
setChannelType 10 Power
setChannelLabel 2 "OverCurrentProtection (A)"
setChannelLabel 3 "OverVoltageProtection (V)"
setChannelLabel 4 "UnderVoltageProtection (V)"
setChannelLabel 5 "OverTempProtection (C)"
setChannelLabel 6 "OverPowerProtection (W)"
setChannelLabel 7 "ProcessorTemperature (C)"
setChannelLabel 8 "Current (A)"
setChannelLabel 9 "Voltage (V)"
setChannelLabel 10 "Power (W)"
linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP
linkTuyaMCUOutputToChannel 16 bool 1
linkTuyaMCUOutputToChannel 114 2 2
linkTuyaMCUOutputToChannel 115 2 3
linkTuyaMCUOutputToChannel 116 2 4
linkTuyaMCUOutputToChannel 118 2 5
linkTuyaMCUOutputToChannel 119 2 6
linkTuyaMCUOutputToChannel 131 2 7
tuyaMcu_sendQueryState

The other things you might want to figure out are:

Times after which the device should respond to OverVoltage/Power/Current/Temp etc.
What events should it respond to and how, e.g. ALARM, TRIP, OFF
Total power consumption (what`s on the display - probably dpID 137 but I`m still verifying it.
Turning off the display - it seems that dpID 141 in the true (1) state turns off the display and this is important because This saves almost 0.6W during operation which is not much in the short term, but over time this value begins to add up quickly.

I will keep you updated on the progress of the work and inform you so that someone in the future can easily modify the entire device so that it is compact and ready for operation without unnecessary games and combinations.

As for the LOG buffer, I think I would leave it enlarged because in the future there will certainly be other devices that will have such a large number of dpIDs and this LOG size ensures that all available dpIDs will be displayed. The whole thing in the control panel currently looks like this:

If anyone sees channels that may be responsible for the above-mentioned functionalities, feel free to write to me, it will make my task easier.

Added after 5 [minutes]:

Now there is another problem, the values are not updated continuously only when the relay is switched. This is strange because previously it updated itself every few seconds.
#39 20943331 03 Feb 2024 20:32

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14622

Help: 655

Rate: 12638
» | Helpful post? (0)

Post #39
20943331 03 Feb 2024 20:32

Selfdrivers wrote:

As for the LOG buffer, I think I would leave it enlarged because in the future there will certainly be other devices that will have such a large number of dpIDs and this LOG size ensures that all available dpIDs will be displayed. Everything in the control panel currently looks like this

There is a small problem with this, because at the moment the firmware is available on the following platforms:

Code: text Expand Select all Copy to clipboard
BK7231T (WB3S, WB2S, WB2L, etc) BK7231N (CB2S, CB2L, WB2L_M1, etc) T34 (T34 is based on BK7231N) BL2028N (BL2028N is a Belon version of BK7231N) XR809 (XR3, etc) BL602 (SM-028_V1.3 etc) LF686 (flash it as BL602) W800 (W800-C400, WinnerMicro WiFi & Bluetooth), W801 W600 (WinnerMicro chip), W601 (WIS600, ESP-01W, TW-02, TW-03, etc) LN882H WIP platform, see sample device teardown and flashing

And the logger is the main module, so I would have to test on all these platforms whether it still works after the changes, because I don`t want to, as they say, "brick" dozens of devices for users.

At most, I could increase the size of the log on Beken, but then I would have to test how much to increase it, because in this PR I increased the buffer quite generously as a test.

Maybe when you finish the autoexec.bat of this device, you could spare a moment (at least by PM) and I will send you a build with, for example, a buffer only twice as large and check if it is enough?

Selfdrivers wrote:

If anyone sees channels that may be responsible for the above-mentioned functionalities, feel free to write to me, it will make my task easier.

Search all other topics about this type of devices on TuyaMCU, maybe something matches, because this dpID 6 is not the first time that it contains the VCP package.

Selfdrivers wrote:

Now there is another problem, the values are not updated continuously only when the relay is switched. This is strange because previously it updated itself every few seconds.

You can request regular updates:

Code: text Expand Select all Copy to clipboard
// every 10 seconds, request update from TuyaMCU addRepeatingEvent 10 -1 tuyaMcu_sendQueryState

See: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md

You may also need to enable the TuyaMCU queue in the flags.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#40 20943360 03 Feb 2024 20:46

Selfdrivers Selfdrivers

Level 8

Posts: 35

Rate: 12
» | Topic author Helpful post? (0)

Post #40
20943360 03 Feb 2024 20:46

p.kaczmarek2 wrote:
And the logger is the main module, so I would have to test on all these platforms whether it still works after the changes, because I don`t want to, as they say, "brick" dozens of devices for users.

I actually didn`t think this through.

p.kaczmarek2 wrote:
At most, I could increase the size of the log on Beken, but then I would have to test how much to increase it, because in this PR I increased the buffer quite generously as a test.

Maybe when you finish the autoexec.bat of this device, you could spare a moment (at least by PM) and I will send you a build with, for example, a buffer only twice as large and check if it is enough?

Sure, I`m in favor, finally an open source project to which I will start contributing, I deal with web applications on a daily basis (so I can generally understand OpenBeken interfaces if there is something) but I also like to dig into IoT as a hobby, despite not having much experience . Currently, I am preparing to defend my engineering thesis, but after the defense I will probably be able to devote even more time (at least until I start pursuing my master`s degree haha).

p.kaczmarek2 wrote:
You can request regular updates:

I also thought about it and checked it, and yes it works, the current autoexec.bat:

Quote:

startDriver TuyaMCU
tuyaMcu_setBaudRate 115200
tuyaMcu_defWiFiState 4
setChannelType 1 toggle
setChannelType 2 TextField
setChannelType 3 TextField
setChannelType 4 TextField
setChannelType 5 TextField
setChannelType 6 TextField
setChannelType 7 temperature_div10
setChannelType 8 Current_div1000
setChannelType 9 Voltage_div10
setChannelType 10 Power
setChannelLabel 1 "MainRelay"
setChannelLabel 2 "OverCurrentProtection (A)"
setChannelLabel 3 "OverVoltageProtection (V)"
setChannelLabel 4 "UnderVoltageProtection (V)"
setChannelLabel 5 "OverTempProtection (C)"
setChannelLabel 6 "OverPowerProtection (W)"
setChannelLabel 7 "ProcessorTemperature (C)"
setChannelLabel 8 "Current (A)"
setChannelLabel 9 "Voltage (V)"
setChannelLabel 10 "Power (W)"
linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP
linkTuyaMCUOutputToChannel 16 bool 1
linkTuyaMCUOutputToChannel 114 2 2
linkTuyaMCUOutputToChannel 115 2 3
linkTuyaMCUOutputToChannel 116 2 4
linkTuyaMCUOutputToChannel 118 2 5
linkTuyaMCUOutputToChannel 119 2 6
linkTuyaMCUOutputToChannel 131 2 7
addRepeatingEvent 2 -1 tuyaMcu_sendQueryState

Personally, what I would add is to the command tuyaMcu_sendQueryState gave the opportunity to provide parameters (e.g. to update id = 6 and not everything possible), of course I don`t know if this is possible when it comes to hardware and software (communication interface), but if there was such an option, it would certainly enable more efficient updating data.
#41 20943824 04 Feb 2024 08:44

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14622

Help: 655

Rate: 12638
» | Helpful post? (0)

Post #41
20943824 04 Feb 2024 08:44

Selfdrivers wrote:

Sure, I`m in favor, finally an open source project to which I`ll start contributing, I deal with web applications on a daily basis (so I can understand OpenBeken interfaces if there`s anything)

It`s very nice of you, create a separate topic and I`ll give you suggestions on what could be improved on the website.

Selfdrivers wrote:

I also thought about it and checked it, and yes it works, the current autoexec.bat:

Every 2 seconds is quite often, in case of problems, enable TuyaMCU queue in the flags, it improves stability and will probably be enabled by default soon.

Selfdrivers wrote:

Personally, what I would add is to the command tuyaMcu_sendQueryState gave the opportunity to provide parameters (e.g. to update id = 6 and not everything possible), of course I don`t know if this is possible when it comes to hardware and software (communication interface), but if there was such an option, it would certainly enable more efficient updating data.

I`m afraid this is not possible, according to the documentation:

but documentation is documentation, if you want, you can send the command 0x08 with one payload byte being dpID and see what happens.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT
#42 20945445 04 Feb 2024 23:46

Selfdrivers Selfdrivers

Level 8

Posts: 35

Rate: 12
» | Topic author Helpful post? (0)

Post #42
20945445 04 Feb 2024 23:46

p.kaczmarek2 wrote:
Every 2 seconds is quite often, in case of problems, enable TuyaMCU queue in the flags, it improves stability and will probably be enabled by default soon.

Where can I find a list of flags? Because I understand that flags are set using SetFlag .

p.kaczmarek2 wrote:
It`s very nice of you, create a separate topic and I`ll give you suggestions on what could be improved on the website.

Also in the IoT part of the forum, right?

p.kaczmarek2 wrote:
but documentation is documentation, if you want, you can send the command 0x08 with one payload byte being dpID and see what happens.

is this also using uartSendHex?

Added after 17 [minutes]:

Is there maybe a channel type textField_div10? I need it for textField because there is an option to set OverTempProtection, but currently you have to enter values in hundreds (750 for 75C). I must admit, it`s not very comfortable.
#43 20945519 05 Feb 2024 04:31

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14622

Help: 655

Rate: 12638
» | Helpful post? (0)

Post #43
20945519 05 Feb 2024 04:31

Selfdrivers wrote:

Where can I find a list of flags? Because I understand that flags are set using SetFlag .

You can also use the gui in options. List:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/flags.md

Selfdrivers wrote:

Also in the IoT part of the forum, right?

Yes, it`s about IoT

Selfdrivers wrote:

is this also using uartSendHex?

Probably yes, but now I think that then you would have to calculate the checksum yourself, I have to check if there is another function better for this

Selfdrivers wrote:

Is there maybe a channel type textField_div10? I need it for textField because there is an option to set OverTempProtection, but currently you have to enter values in hundreds (750 for 75C). I must admit, it`s not very comfortable.

It`s not there at the moment, but I might consider adding it. But generally, for more advanced panels, we recommend simply creating your own skin in HTML + JS:
https://www.elektroda.pl/rtvforum/topic3971355.html
Example of a user-generated dashboard:
https://www.elektroda.com/rtvforum/topic4022907-60.html#20933658

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#44 20951149 08 Feb 2024 12:01

morgan_flint morgan_flint

Level 14

Posts: 251

Help: 4

Rate: 60
Helpful post? (0)

Post #44
20951149 08 Feb 2024 12:01

Hello!
I see this device has some things in common with the two I have:
https://www.elektroda.com/rtvforum/topic3995777.html
https://www.elektroda.com/rtvforum/topic4022907.html

So, here are some comments, in case they're useful:

Selfdrivers wrote:
In order to upload the OpenBeken software, I had to unsolder the white board from the blue board, which actually only connects the E469716 board with the rest of the MCB. Everything after desoldering looks like this:

Probably, it's not needed to unsolder the module; it seems like the signals needed (TX1, RX1, Vcc, and GND) are not interfered by Tuya MCU, thanks to the fact that the blue board can be unplugged from the rest. You even may not need to solder anything, as you can plug the necessary cables to the connector. TX1 and RX1 are connected to the header with resistors, but this shouldn't be a problem.

Selfdrivers wrote:
https://a.aliexpress.com/_EyCIK5X I bought this auction on Aliexpress.

I see in that advertisement that the display shows date and time so, probably, you'll need to add NTP driver to your autoexec:
Code: Javascript
Log in, to see the code

BTW, this device seems a bit expensive (42€!) compared to similar ones.

Selfdrivers wrote:
I managed to determine that the relay has dpID 16, (but e.g. dpID 11 turns off the relay without the possibility of turning it on again, it looks a bit like it is a "safety" signal)

In my devices, DpID16 is also for the relay, and DpID 11 is for resetting prepaid energy, which is a counter that allows to set a certain amount of kWh that, once consumed, sets the relay off until some more "prepaid energy" is loaded or the prepaid function is turned off (via two additional DpIDs). So this is probably the cause that it turns off the relay without the possibility of turning it on again.

Selfdrivers wrote:
One more thing, I read that there are custom manufacturer`s devices above dpID 100, everything below 100 is designed by Tuya, but unfortunately they like to change dpID values very often (I looked in Tasmota`s default list and no dpID from their list works).

This seems to be confirmed by the similarities between the aforementioned DpID's and also DpID 6, commented in other posts.

p.kaczmarek2 wrote:
2. You can try to get dpIDs from Tuya: Extracting DpIDs for TUYA MCU devices
Extracting DpIDs for TUYA MCU devices

If you have a backup of the original FW, you could try that method (tutorial written by me, BTW ). It's a bit tedious, as you need to create an account in Tuya developers website, but it's worth it, as you can get a lot of information about the DpIDs

p.kaczmarek2 wrote:
Example of a user-generated dashboard: https://www.elektroda.com/rtvforum/topic4022907-60.html#20933658

Finally, if you browse through this thread, you can see the great work done by @p.kaczmarek2 and @Angel0fDeath about decoding and setting the DpIDs related to the alarms (DpID 9) and some of the protection thresholds (17 and 18), that might be the same in this device (including the dashboard quoted before)... Have you seen these DpIDs in any of your logs?
#45 20954276 10 Feb 2024 11:30

Angel0fDeath Angel0fDeath

Level 13

Posts: 118

Help: 2

Rate: 33
Helpful post? (0)

Post #45
20954276 10 Feb 2024 11:30

@Selfdrivers The fastest and best way to extract all dpID's is to use original firmware and Tuya developers website. I always do that prior flashing new device. This way you have all dpID's, their meaning (description) and data format as well as min and max values for each dID. After flashing the device with openBeken it is very easy to understand data format even if this format is still not supported by TuyaMCU driver.
So I would recommend to revert to original firmware, extract dpID's and then flash again openBeken. Then from response to tuyaMcu_sendQueryState you can very fast understand everything, taking into account you know settings of the device and you already checked what could be set with original firmware in Smart Life app.

Once you know everything you can download my html script as @morgan_flint mentioned above and modify it to your needs.
#46 20956696 11 Feb 2024 19:20

Selfdrivers Selfdrivers

Level 8

Posts: 35

Rate: 12
» | Topic author Helpful post? (0)

Post #46
20956696 11 Feb 2024 19:20

Thank you all for your feedback, soon I`m planning to investigate the dpID`s more, I think I will change the software to original one so it will be easier to extract data.

morgan_flint wrote:
Hi! I see that this device has a few features in common with the two I have: https://www.elektroda.com/rtvforum/topic3995777.html https://www.elektroda.com/rtvforum/topic4022907.html Here are some comments if will prove useful:
Selfdrivers wrote:
To upload the OpenBeken software, I had to unsolder the white board from the blue one, which actually only connects the E469716 board to the rest of the MCB. Everything after desoldering looks like this:
There is probably no need to desolder the module; it looks like the needed signals (TX1, RX1, Vcc and GND) are not interfered with by the Tuya MCU, thanks to the blue board being detachable from the rest. You may not need to solder anything because you can connect the necessary cables to the connector. TX1 and RX1 are connected to the header with resistors, but this should not be a problem.
Selfdrivers wrote:
https://a.aliexpress.com/_EyCIK5X I bought this listing on Aliexpress.
I see in this ad that the display shows the date and time, so you will probably need to add the NTP driver to your autoexec: Code: javascript Expand Select all Copy to clipboardstartDriver NTP
ntp_setServer 150.214.94.5 //or whatever you like
ntp_timeZoneOfs 1 //adapt to your zone By the way, this device seems a bit more expensive (42€!) compared to similar ones.
Selfdrivers wrote:
I managed to determine that the relay has dpID 16 (but e.g. dpID 11 turns off the relay without the possibility of turning it on again, it looks a bit like a "safety" signal)
In my devices, DpID16 is also used for the relay, and DpID 11 is used to reset the prepaid energy, which is a counter that allows you to set a certain amount of kWh which, when used, turns off the relay until more "prepaid energy" appears loaded or the prepaid function is disabled (via two additional DpIDs). So this is probably the reason that it turns off the relay without being able to turn it on again.
Selfdrivers wrote:
One more thing, I read that there are custom devices from manufacturers above dpID 100, everything below 100 is designed by Tuya, but unfortunately they like to change dpID values very often (I looked at Tasmota`s default list and there is no dpID from their list that works).
This seems to confirm the similarities between the DpIDs mentioned, as well as DpID 6, commented on in other posts.
p.kaczmarek2 wrote:
2. You can try to get dpID from Tuya: Extracting DpIDs for TUYA MCU Devices Extracting DpIDs for TUYA MCU Devices
If you have a backup of your original firmware, you can try this method (tutorial written by me, BTW). It`s a bit tedious because you have to create an account on the Tuya developer site, but it`s worth it because you can get a lot of information about DpIDclass="notranslate">
p.kaczmarek2 wrote:
Example of a user-created dashboard: https://www.elektroda.com/rtvforum/topic4022907-60.html#20933658

Finally, if you browse this thread, you can see the great work done by @p.kaczmarek2 and @Angel0fDeath in decoding and setting DpIDs related to alarms (DpID 9) and some security thresholds (17 and 18) which may be the same in this device (m. incl. dashboard cited earlier)... Have you seen these DpIDs in any of your logs?

Unfortunately I was trying without desoldering the module and without success and it worked only when i desoldered the module.
#47 21080150 13 May 2024 02:45

onkel11 onkel11

Level 5

Posts: 10

Help: 1

Rate: 1
Helpful post? (0)

Post #47
21080150 13 May 2024 02:45

Hi,

so what is actual state for that device ?

Does it fully work including display ?

Thanks
#48 21088459 19 May 2024 19:27

onkel11 onkel11

Level 5

Posts: 10

Help: 1

Rate: 1
Helpful post? (0)

Post #48
21088459 19 May 2024 19:27

No one ?
#49 21088469 19 May 2024 19:35

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14622

Help: 655

Rate: 12638
Helpful post? (0)

Post #49
21088469 19 May 2024 19:35

This is TuyaMCU device. The screen is controlled via MCU. It will still work after flashing. Configuring dpIDs as in the topic can also give you data in Home Assistant.

If you are unsure, make a 2MB flash backup first.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#50 21089661 20 May 2024 18:07

onkel11 onkel11

Level 5

Posts: 10

Help: 1

Rate: 1
Helpful post? (0)

Post #50
21089661 20 May 2024 18:07

Hi,

ok I can confirm that I was not able to read or write when the BK7231N was soldered.

After desoldering read and write works with baudrate 115200 like a charm

I keep you informed.

Edit:

- I doublechecked the baudrate - even 1500000 is working read / write after desoldering.
#51 21089674 20 May 2024 18:13

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14622

Help: 655

Rate: 12638
Helpful post? (+1)

Post #51
21089674 20 May 2024 18:13

Ok, I will help you if any futher issue arise.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#52 21089722 20 May 2024 19:02

onkel11 onkel11

Level 5

Posts: 10

Help: 1

Rate: 1
Helpful post? (0)

Post #52
21089722 20 May 2024 19:02

Thanks for your help offer.

So there is no template so far ?

How do I edit the autoexec.bat file ?

Edit found it: [Youtube] OpenBeken LittleFS - autoexec.bat creation, scripts, HTML+Javascript page hosting tutorial

Thanks for the Video

So all works so far.

what about the couter for energy today/yesterday/total ?
#53 21094715 24 May 2024 18:31

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14622

Help: 655

Rate: 12638
Helpful post? (0)

Post #53
21094715 24 May 2024 18:31

Are those counters available as TuyaMCU dpIDs, or do we have to calculate them on our own?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Reply Cool? Ranking DIY | New topic

Notify about new articles

📢 Listen (AI):

Report a violation of the law

Topic summary

✨ The discussion revolves around the TO-Q-SYS-JWT DIN Rail kWh meter, which features a built-in display for monitoring energy consumption and adjusting settings such as undervoltage and overvoltage protection. Users share insights on disassembling the device, with specific instructions on removing metal pins to access internal components. Concerns are raised regarding the device's documentation and safety, with some users questioning its classification as a fuse. The conversation also delves into the device's compatibility with TuyaMCU, firmware modifications, and the extraction of dpIDs for energy measurement. Participants discuss the challenges of obtaining accurate energy consumption readings and the potential for integrating the device with home automation systems. Various technical solutions and commands for configuring the device are shared, along with troubleshooting tips for communication issues and data extraction.
Generated by the language model.

Home page
/
Forum
/
Smart Home
/
Smart Home IoT
/
Smart Home Devices
/
Disassembly & Insights on TO-Q-SYS-JWT DIN Rail kWh Meter with Display

FAQ

TL;DR: With a 115200 baud TuyaMCU link and 6 housing pins removed, this teardown shows that “the screen is controlled via MCU,” so OpenBeken can replace the cloud Wi‑Fi side while the local display still works. It helps tinkerers who want relay control, kWh-related telemetry, and protection settings on the TO-Q-SYS-JWT without losing core front-panel functions. [#21088469]

Why it matters: This thread turns an undocumented DIN-rail Wi‑Fi meter-switch into a repeatable OpenBeken workflow, including disassembly, dpID discovery, and safe limits.

Feature	TO-Q-SYS-JWT	TO-Q-SY1-JWT
Front display	Yes, built-in display with local settings	Mentioned as similar version; no display noted here
Main Wi‑Fi module	BK7231N	Same family/device line discussed as comparable
Relay behavior	Suspected bistable, MCU-controlled	Reported as also using bistable relay
OpenBeken path	TuyaMCU mapping needed	Existing related topic/driver experience available

Key insight: The BK7231N does not directly run the relay, buttons, or display here. It mainly bridges Wi‑Fi to a separate MCU, so successful conversion depends on decoding TuyaMCU dpIDs, not on simple GPIO remapping. [#20938300]

Quick Facts

The housing is held by 6 metal pins, and the first visible power part was described as a 60A 250V relay inside a 3-PCB stack, which matters for careful teardown planning and reassembly. [#20937367]
After desoldering the BK7231N module, users reported reliable flashing at 115200 baud, and one later confirmed even 1500000 baud read/write worked. [#21089661]
A working raw measurement frame was mapped from dpID 6 using RAW_TAC2121C_VCP, exposing Voltage_div10, Current_div1000, and Power channels in OpenBeken. [#20943257]
Confirmed protection-related values included 245 V overvoltage, 219 V undervoltage, 550 for overtemperature as 55.0°C, and 2123 W overpower threshold. [#20943018]
One buyer cited an online price of about 42€, while other posters criticized the weak documentation, missing installation-category details, and sparse safety markings. [#20951149]

How do you disassemble the TO-Q-SYS-JWT DIN rail kWh meter and remove the housing pins without damaging the case?

You open it by removing the 6 metal rods first, not by forcing the plastic shell. 1. Bend the visible edge of each gold-colored pin inward. 2. Gently tap each rod out; the starting side does not matter. 3. After all 6 rods are out, release the top latches and lift the housing apart. The author called this step out because standard MCB-style cases hide the pins well, and prying first risks breaking the clips. [#20937367]

Why does flashing the BK7231N on the TO-Q-SYS-JWT seem to require desoldering the module, and what baud rates were reported to work afterward?

Flashing worked reliably only after desoldering the BK7231N from the carrier board. The original poster said in-circuit flashing failed, while later confirmation showed read and write worked “like a charm” once the module was removed. Reported working speeds were 115200 baud and even 1500000 baud after desoldering. That makes this device a poor candidate for casual pogo-pin flashing unless you verify the board does not load TX/RX lines. [#21089661]

What is TuyaMCU, and how does it differ from a setup where the BK7231N directly controls the relay and display?

TuyaMCU here means the Wi‑Fi chip exchanges serialized commands with a separate controller instead of driving hardware directly. "TuyaMCU is a UART-based device architecture that sends dpID state packets between a Wi‑Fi module and a main MCU, rather than exposing direct relay or display GPIO control." In this meter-switch, the HC32F460 handles the display, buttons, and relay logic, while the BK7231N mainly handles Wi‑Fi transport. That is why the display still works after flashing OpenBeken. [#20937367]

What does dpID mean in TuyaMCU devices, and how do you figure out which dpIDs control relay, protection settings, and measurements on the TO-Q-SYS-JWT?

A dpID is the device-property identifier that labels each TuyaMCU state or command field. The thread identified dpID 16 as relay control, 114 as overcurrent, 115 as overvoltage, 116 as undervoltage, 118 as overtemperature, 119 as overpower, and 131 as processor temperature. Users found them by sending tuyaMcu_sendQueryState, toggling settings, and comparing returned values like 245, 219, 550, and 2123 to what the display or UI showed. The fallback method is restoring stock firmware and extracting full dpIDs from Tuya’s developer portal. [#20942478]

Which OpenBeken autoexec.bat lines were used to get the TO-Q-SYS-JWT relay control, voltage, current, power, and protection thresholds working?

The working setup used TuyaMCU at 115200 baud, mapped dpID 16 to a toggle, dpID 6 to raw V/I/P decoding, and linked threshold dpIDs 114, 115, 116, 118, 119, and 131 to channels. The final script also labeled channels and added addRepeatingEvent 2 -1 tuyaMcu_sendQueryState for periodic refresh. Key lines included startDriver TuyaMCU, tuyaMcu_defWiFiState 4, linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP, and linkTuyaMCUOutputToChannel 16 bool 1. That combination exposed relay, voltage, current, power, and protection values in the panel. [#20943360]

How can you identify whether dpID 6 on this device is the raw voltage-current-power packet and map it with RAW_TAC2121C_VCP in OpenBeken?

You identify it by matching the raw 8-byte payload against known VCP packet structure and real load changes. A 13–14 W load produced bytes ending with 00 00 0D, while a 4 W load produced 00 00 04, which aligned with power. The developer then matched dpID 6 to the existing TAC2121C-style raw frame and recommended linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP. That automatically created channels for voltage divided by 10, current divided by 1000, and power. [#20943234]

Why were the TuyaMCU logs getting cut off during tuyaMcu_sendQueryState, and how was the larger log buffer used to reveal all dpIDs?

The logs were getting truncated because the returned state list was larger than the visible or buffered log path could hold. Once the buffer was enlarged from 1024 to 8192 bytes in a test build, full dpID output appeared, including ids 1, 6, 11, 13, 16, 101–120, 131, 137, 140, 141, and 142. The thread also checked for another failure case: two browser tabs can split WebApp logs between tabs. In this case, only one WebApp instance was open, so the larger buffer exposed the missing entries. [#20943018]

What is command 0x34 in TuyaMCU communication, and why did replying with "55 aa 00 34 00 02 04 00 39" stop the repeated unknown query messages?

Command 0x34 is an extended Tuya module service packet that OpenBeken initially logged as unknown. The repeating frame 55 AA 03 34 00 01 04 3B kept appearing after Wi‑Fi state was set to 4, and replying with 55 aa 00 34 00 02 04 00 39 stopped the spam immediately. The developer linked 0x34 to Tuya’s extended module functions and then added support so the main firmware would answer it automatically. That calmed the logs, although it did not directly reveal energy measurements. [#20942168]

How can you capture original Tuya UART traffic safely on a mains-powered device like this if the power supply may be non-isolated?

You should revert to the original firmware, then capture UART only with isolation in place. The thread explicitly warned that the internal converter may be non-isolated, so a plain USB-UART hookup is risky on a live mains device. The recommended path was to restore the saved 2 MB flash backup, power the unit safely, and use a UART isolator while recording packets during normal app and button actions. That method avoids guesswork and recovers hidden dpIDs cleanly. [#20942614]

TO-Q-SYS-JWT vs TO-Q-SY1-JWT: what similarities and differences were noted in hardware layout, relay behavior, and TuyaMCU mapping?

They look closely related, but the TO-Q-SYS-JWT adds a built-in display and local settings menu. The original poster described it as a version similar to TO-Q-SY1-JWT, and another developer said both device families had seen bistable relay behavior. Both were treated as TuyaMCU-style designs with BK7231-based Wi‑Fi modules and MCU-side relay control, which means dpID mapping matters more than GPIO templates. The practical difference in this thread was the display board and HC32F460 controller in the TO-Q-SYS-JWT. [#20938495]

What is a bistable relay, and why did users suspect this meter-switch uses one instead of a standard continuously powered relay?

A bistable relay is a latching relay that changes state with a pulse and then holds that state without continuous coil power. "A bistable relay is an electromechanical switch that stays open or closed after a short drive pulse, reducing standby consumption because the coil is not energized continuously." Users suspected one here because they saw a full-bridge relay drive stage in SOT23-6 and noted similar hardware in related Tuya rail devices. That would fit a design focused on low static power. [#20938473]

Where can you find the TO-Q-SYS-JWT online, what price was mentioned, and what concerns were raised about documentation and safety markings?

The device was linked to an AliExpress listing, and one poster later remarked that the advertisement showed a price around 42€. Several replies criticized the product page and paperwork, saying the documentation was “pathetic,” the installation category was missing, and required markings were sparse. Another poster argued it should not be called a fuse at all, but rather a smart Wi‑Fi switch with metering and trip-style control behavior. Those concerns matter if you plan to use it as a protective device. [#20938044]

How do you edit autoexec.bat in OpenBeken for this device, including adding repeating TuyaMCU queries and channel labels?

You edit autoexec.bat in OpenBeken’s LittleFS-backed web interface or by following the project’s tutorial workflow. A working example in the thread used setChannelLabel for names like MainRelay, Voltage (V), and Power (W), then added addRepeatingEvent 2 -1 tuyaMcu_sendQueryState for automatic updates every 2 seconds. One later user explicitly asked how to edit autoexec.bat, found the video tutorial, and confirmed the setup worked. That makes the web UI the practical path for this device. [#21089722]

What’s the best way to recover the full list of Tuya dpIDs for the TO-Q-SYS-JWT using the original firmware and the Tuya developer website?

The best method is to restore the stock firmware first, then extract the dpID definitions through Tuya’s developer platform. Two experienced contributors recommended this because it returns the dpID list, meaning, type, and often min/max ranges, which is faster than guessing from live packets. The suggested workflow was: make a flash backup, revert to original firmware, pair it with Tuya, and then query the developer portal before flashing OpenBeken again. That is the fastest route to complete mapping. [#20954276]

How can energy counters like today, yesterday, and total consumption be obtained on this device, and are they exposed as TuyaMCU dpIDs or something OpenBeken would need to calculate?

The thread did not confirm those counters yet. A later user asked about today, yesterday, and total energy, and the answer was a direct technical question: are those values available as TuyaMCU dpIDs, or must OpenBeken calculate them itself? The only partly identified candidate earlier was dpID 137, mentioned as “probably” total energy, but it was still under verification. So, for this device, daily and total counters remain unresolved until stock-firmware dpID extraction confirms whether Tuya exposes them. [#21094715]

Generated by the language model.