logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

Selfdrivers 8409 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.
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #31 20943015
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    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.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 20943018
    Selfdrivers
    Level 8  
    Posts: 35
    Rate: 12
    >>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.

    Screenshot of a console logging data related to TuyaMCU communication.

    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 :P rocessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU :P arseState: id 1 type 2-val len 4
    Info:TuyaMCU :P arseState: int32 6
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 7D 02 00 04 00 00 00 06 9A
    Info:TuyaMCU :P rocessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU :P arseState: id 125 type 2-val len 4
    Info:TuyaMCU :P 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 :P rocessIncoming[v=3]: cmd 7 (State) len 19
    Info:TuyaMCU :P 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 :P rocessIncoming[v=3]: cmd 7 (State) len 12
    Info:TuyaMCU :P arseState: id 11 type 1-bool len 1
    Info:TuyaMCU :P arseState: byte 0
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 0D 02 00 04 00 00 00 00 24
    Info:TuyaMCU :P rocessIncoming[v=3]: cmd 7 (State) len 15
    Info:TuyaMCU :P arseState: id 13 type 2-val len 4
    Info:TuyaMCU :P arseState: int32 0
    Info:TuyaMCU:Received: 55 AA 03 07 00 05 10 01 00 01 00 20
    Info:TuyaMCU :P rocessIncoming[v=3]: cmd 7 (State) len 12
    Info:TuyaMCU :P arseState: id 16 type 1-bool len 1
    Info:TuyaMCU :P arseState: byte 0
    Info:TuyaMCU:Received: 55 AA 03 07 00 05 65 04 00 01 00 78
    Info:TuyaMCU :P rocessIncoming[v=3]: cmd 7 (State) len 12
    Info:TuyaMCU :P 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 :P arseState: id 142 type 4-enum len 1
    Info:TuyaMCU :P arseState: byte 2
    Info:TuyaMCU:Received: 55 AA 03 07 00 04 8A 03 00 00 9A
    Info:TuyaMCU :P rocessIncoming[v=3]: cmd 7 (State) len 11
    Info:TuyaMCU :P arseState: id 138 type 3-str len 0
    Info:TuyaMCU:Received: 55 AA 03 00 00 01 01 04
    Info:TuyaMCU :P 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.
  • #33 20943117
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    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
    Helpful post? Buy me a coffee.
  • #34 20943222
    Selfdrivers
    Level 8  
    Posts: 35
    Rate: 12
    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?
  • ADVERTISEMENT
  • #35 20943234
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    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:
    Program code showing the parsing of raw data in DP_TYPE_RAW_TAC2121C_VCP format.
    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:
    Screenshot of a code snippet with the expression DP_TYPE_RAW_TAC2121C_VCP highlighted.
    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.
    Helpful post? Buy me a coffee.
  • #36 20943248
    Selfdrivers
    Level 8  
    Posts: 35
    Rate: 12
    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
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    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:
    Screenshot of TuyaMCU configuration code with settings for voltage, current, and power measurements.
    Helpful post? Buy me a coffee.
  • #38 20943305
    Selfdrivers
    Level 8  
    Posts: 35
    Rate: 12
    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:

    Energy consumption monitoring device control panel with protection configuration options.

    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
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    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.
    Helpful post? Buy me a coffee.
  • #40 20943360
    Selfdrivers
    Level 8  
    Posts: 35
    Rate: 12
    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
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    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:
    Screenshot of documentation about querying DP status in a module.
    Table describing the structure of the command sent by the module.
    but documentation is documentation, if you want, you can send the command 0x08 with one payload byte being dpID and see what happens.
    Helpful post? Buy me a coffee.
  • #42 20945445
    Selfdrivers
    Level 8  
    Posts: 35
    Rate: 12
    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
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    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
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #44 20951149
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    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
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @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
    Selfdrivers
    Level 8  
    Posts: 35
    Rate: 12
    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
    onkel11
    Level 5  
    Posts: 10
    Help: 1
    Rate: 1
    Hi,

    so what is actual state for that device ?

    Does it fully work including display ?

    Thanks
  • #49 21088469
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    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.
    Helpful post? Buy me a coffee.
  • #50 21089661
    onkel11
    Level 5  
    Posts: 10
    Help: 1
    Rate: 1
    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
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    Ok, I will help you if any futher issue arise.
    Helpful post? Buy me a coffee.
  • #52 21089722
    onkel11
    Level 5  
    Posts: 10
    Help: 1
    Rate: 1
    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
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    Are those counters available as TuyaMCU dpIDs, or do we have to calculate them on our own?
    Helpful post? Buy me a coffee.
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.
Today's popular

FAQ

TL;DR: The TO-Q-SYS-JWT DIN-rail meter packs a 60 A / 250 V bistable relay, an HC32F460 MCU, and Wi-Fi via BK7231N; “Very interesting, fuse, current measurement and control/reading by applications in one.” [Elektroda, gulson, post #20937562] OpenBeken enables full local control, ditching Tuya cloud.

Why it matters: You get a sub-€45 smart breaker that can log kWh offline and integrate with Home Assistant.

Quick Facts

• Relay rating: 60 A, 250 V AC [Elektroda, Selfdrivers, post #20937367] • Main MCU: HC32F460 (STM32F103-compatible) [Elektroda, Selfdrivers, post #20937367] • Wi-Fi module: BK7231N, UART 115 200 bps default [Elektroda, p.kaczmarek2, post #20938300] • Flash backup size: 2 MB full image advised [Elektroda, p.kaczmarek2, post #21088469] • Street price: ≈ €42 on AliExpress [Elektroda, Selfdrivers, post #20941591]

What silicon is inside the TO-Q-SYS-JWT?

Three boards: a BK7231N Wi-Fi module, an HC32F460 32-bit Cortex-M3 MCU that drives the OLED, and a TAC2121C (HT7017 marking) for energy metering [Elektroda, Selfdrivers, post #20937367]

Is it really a fuse?

No. It is a smart switch with measurement. It offers no certified protective breaking; documents omit installation category and mandatory marks [Elektroda, CosteC, post #20938044]

How do I open the enclosure without damage?

  1. Bend inward and punch out the six gold locking rods.
  2. Unclip the top latches and split the housing.
  3. Unscrew the single PCB screw to free the Wi-Fi board [Elektroda, Selfdrivers, post #20937367]

Where do I connect for flashing?

After unplugging the blue Wi-Fi daughterboard you get VCC, GND, TX1, RX1 on its header. Desoldering eases access and eliminates MCU interference, enabling stable reads even at 1 500 000 bps [Elektroda, onkel11, post #21089661]

Which alternative firmware works and what survives?

OpenBeken 1.18+ installs via BK7231 GUI Flash Tool. The relay, buttons, and OLED keep working because the Tuya-side MCU, not the Wi-Fi module, drives them [Elektroda, p.kaczmarek2, post #21088469]

How do I map voltage, current and power in OpenBeken?

Set RAW_TAC2121C_VCP on dpID 6, then assign ChType_Voltage_div10, ChType_Current_div1000 and ChType_Power channels. Example autoexec lines are documented in the thread [Elektroda, p.kaczmarek2, post #20943257]

Does the display still refresh after flashing?

Yes. The HC32F460 continues to update the OLED. For live data in HA you must poll TuyaMCU every few seconds or enable the queue flag [Elektroda, Selfdrivers, post #20943360]

What is the safest flashing procedure?

  1. Backup the full 2 MB flash.
  2. Flash OpenBeken via UART at 115 200 bps.
  3. Restore original firmware if needed with the backup file [Elektroda, p.kaczmarek2, post #21088469]

Can I query only one dpID instead of all?

Tuya’s documented protocol lacks single-dpID query, but sending command 0x08 plus the target dpID over UART is being tested; checksum must be added manually [Elektroda, p.kaczmarek2, post #20943824]

What edge cases should I watch?

Issuing dpID 11 resets prepaid-energy, permanently opening the relay until reconfigured [Elektroda, Selfdrivers, post #20941591] Always back up settings before experimenting.

Are energy counters for today and yesterday exposed?

The thread hasn’t revealed dpIDs for daily counters yet; you may need to compute them in Home Assistant if TuyaMCU doesn’t expose them [Elektroda, p.kaczmarek2, post #21094715]
Generated by the language model.
ADVERTISEMENT