logo elektroda
logo elektroda
X
logo elektroda

[BK7231N ] Teardown and flashing of Tomzn TOMPD-63 WIFI (not to be confounded with TOMPD-63LW)

morgan_flint 17091 152
ADVERTISEMENT
  • A few days ago I received this device from Aliexpress Link:
    Advertisement of TUYA WiFi smart circuit breaker 63A on Aliexpress

    The device is similar to others already treated here, for example Tomzn TOML-VA 63A and Earu EAMPDW-TY63, and also TOMPD-63LW mentioned in the title, although the latter is more complete and cuts both line and neutral.

    But, despite the external similarities and in functionality, I see from the teardowns that they are different, so I think it's justified to create a new thread. Apart from this, is a good opportunity to put into practice the tutorial I wrote about extracting DpIDs and try to make it work with OBK starting from zero.

    So let's start with some photos from the advertisement in Aliexpress, just in case the previous link gets broken:
    A section of the user manual for a device from Aliexpress with technical specifications.
    Screenshots of the Tuya app showing electricity statistics and other parameters. Two screenshots from a device management app showing various settings. Screenshots of the Tuya app showing add schedule and device information. Multifunction automatic circuit breaker with surge protection. Device buttons and various display screens, including voltage and current measurements. TOMZN TOMP-63WIFI device with visible labels and buttons.

    Now the printed manual that came with the device:
    User manual for an energy meter with voltage protection function. User manual for WiFi Smart Meter and Energy Protector.

    You can already see some differences between the settings in the advertisement and those in the manual. The real thing also included another setting "t" (see next pictures), that can be set to "on" or to a number between 5 and 120.
    TOMZN TOMPD-63WIFI device with active display and lit indicators. TOMZN TOMPD-63WIFI device with display and buttons

    I haven't been able to deduct what is this setting for.

    Now, some photos of the teardown:
    View of a device from Aliexpress with visible holes and a latch. Electronic device with LCD screen and five buttons. Side view of an opened electronic device with visible components on PCB boards. Modular electronic device with a PCB and buttons. Close-up of a printed circuit board with various electronic components inside a device. Front panel of a device from Aliexpress with an LCD screen and buttons. WB3S WiFi module on a blue PCB. Close-up of a PCB from an electronic device purchased from AliExpress. Internal circuitry of a device from Aliexpress with visible capacitors and wiring. View of disassembled QY60F-C relay with PCB boards. Internal view of a disassembled electrical device.

    Opening the device is very easy: just unfasten the two screws in the holes of the first photo (after pushing apart the lower side lock). It's well constructed; there are two PCBs: the bigger one supports the relay (latching type, no need to keep the coil energized to set it on), the components for the power supply (12V output for the relay and two 3.3V outputs, one with a linear regulator from 12V and the other one with a switch mode one), and the energy metering chip BL0942 (attached English datasheet). The smaller PCB has the LCD screen, push buttons, the Tuya MCU (behind the LCD screen), and the WB3S WiFi module.

    Also, here are some screenshots of the Tuya App; you can see there are also differences with the ones from the advertisement:
    Tuya app screen displaying energy consumption and device status. Screenshot of an app showing a log of on and off operations with date and time. Screenshot from an app showing alarm record. App screen displaying overcurrent warning Screenshot of over-current alarm settings in a mobile app. Screenshot of a mobile app displaying current electrical data. Energy expense management app screen with prepayment options. Screenshot of an expense management app with an active energy top-up field in kWh. Screenshot of a mobile app with energy expense management settings. Screenshot of a mobile app displaying electricity consumption in kWh and a no balance alarm. Screenshot of leakage alarm in the Tuya mobile app. Leakage alarm threshold settings with a value of 80. Over-current alarm threshold settings menu with on-screen keyboard. Screenshot of Tuya app's under-voltage alarm settings. Smartphone app showing an over-voltage alarm screen with threshold settings and a control switch. Screenshot of an app showing over-voltage alarm settings with threshold options. App screen showing over-voltage alarm settings. Over-current alarm screen with threshold settings and control switch. Screenshot of alarm settings in the app. Screenshot of an app with leakage alarm settings Dialog box in an app asking for confirmation of power zero. Expense management app screen with energy top-up option. Screenshot of expense management app with prepayment settings options. Device update screen on a smartphone.

    Now, let's start with the DpID identification process, which should be done before flashing OBK, as we need to access the device from Tuya's developer website. Following the first process in the tutorial, we get this:
    {"1":"Total forward energy","6":"Phase A","9":"Fault","11":"Switch prepayment","12":"Clear energy","13":"Balance energy","14":"charge energy","15":"Leakage current","16":"Switch","17":"Alarm set1","18":"Alarm set2","19":"Breaker id","104":"Over Vol Protect Time","105":"Over Vol Recovery Time"}

    The same info, written as a list:
    "1":"Total forward energy",
    "6":"Phase A",
    "9":"Fault",
    "11":"Switch prepayment",
    "12":"Clear energy",
    "13":"Balance energy",
    "14":"charge energy",
    "15":"Leakage current",
    "16":"Switch",
    "17":"Alarm set1",
    "18":"Alarm set2",
    "19":"Breaker id",
    "104":"Over Vol Protect Time",
    "105":"Over Vol Recovery Time"

    We can see that there are a total of 13 DpIDs.

    Now, jumping to the last method in the tutorial (signaled with [*]) and, after processing the Json as instructed there, we get:
    Code: JSON
    Log in, to see the code

    Where, besides the DpID numbers, we have a more complete description of each of them. With this info in hand we will be able to configure OBK so now we can proceed with flashing.

    To flash it with OBK, after unplugging the smaller board from the bigger one, is enough to solder just two wires to the RX and TX pads, as Vcc and Gnd can be connected to the header:
    WB3S module on blue PCB with marked TX, RX, GND, and 3.3V pins

    I didn't need to cut any traces to flash OBK as the Tuya MCU doesn't seem to interfere with the process (in principle, it should be shut off, as it gets the power from a different pin in the header). To avoid problems, I only connect TX, RX, and GND to the serial to USB adapter, and connect Vcc just after hitting the corresponding key to start flashing in BK7231Flasher.

    Once flashed, we can connect our PC or phone to the access point provided by OBK and navigate to 192.168.4.1, where we configure SSID and password for our local WiFi. After rebooting, we have to find in our router the IP assigned to the device and access it with a browser to continue with the configuration. I first configured MQTT and then, by navigating "Launch web application" -> "Filesystem" -> "Create file" I created "autoexec.bat" with the following contents:
    Code: Java
    Log in, to see the code

    Let's explain briefly the contents: The first lines come from similar devices and are there to start the TuyaMCU driver and simulate the connection to the cloud. I commented out the NTP driver, as it doesn't seem to be necessary. The last line also comes from similar devices and, as I understand, is there to force the MCU to send the state periodically.

    The lines in between correspond to the previously identified DpIDs, linking them to a channel and setting the channel type accordingly. To make things clearer, I preferred to assign channels with the same number as the DpIDs where possible. I also wrote the following table in Excel to help keep things clear, but it's not really necessary:
    Table with DP instructions, IDs, and channel types for a device from Aliexpress.

    After saving the autoexec and rebooting the configuration is finished and we can start using the device with OBK:
    OpenBK7231T user interface with various settings and energy readings.

    In practice, it's not really needed to have so much info, so you can comment out or delete the corresponding lines in the autoexec.bat to eliminate the variables of less interest. Also, some of them don't work as expected (for example, Alarm set 2 doesn't show well, probably because it's too long), but I hope @p.kaczmarek2 will be correcting this in future versions.

    Also, after going to "Config" -> "Home Assistant configuration" and hitting "Start Home Assistant Discovery", we can also control the device from Home Assistant:
    MQTT interface with BK7231T device information

    And that's all for now! It's a long post and I hope I haven't bored you too much, but I think it is better to give as many details as possible for the most novices; the most experienced just can pass over them quickly ;-)

    EDIT: corrected label from "Clear Prepayment" to "Clear Energy Counters", as this is what DpID 12 does (thanks, @AngelOf Death)
    EDIT: Adding schematic:
    Circuit diagram of TOMPD-63 WiFi device

    Cool? Ranking DIY
    About Author
    morgan_flint
    Level 14  
    Offline 
    morgan_flint wrote 243 posts with rating 52, helped 4 times. Live in city Sevilla. Been with us since 2018 year.
  • ADVERTISEMENT
  • #2 20879436
    Angel0fDeath
    Level 13  
    I have exactly the same device. All DpIDs match exactly.
    About DpID 104 - From the device I'm able to change the values from 0.5s to 30s with step 0.5s. However with tuya-mqtt.js I always receive this as integer, i.e. 0.5 is 1 and 1 is also 1, 1.5 is 2 etc.

    About 't' setting of the device - according to users manual this should be light source. By me this do nothing. Probably for future use - light for LCD or something like that. Maybe some models have LCD light and this don't (in manual it is written it's optional)
  • #3 20879633
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    About 't' setting of the device - according to users manual this should be light source.

    Hello and thank you for your answer. Could be it's prepared for some present or future backlight version, as you say. Mine doesn't have any backlight also.

    From what you say, I understand your manual shows this setting, something that mine didn't (as you can see in the pictures I posted), so I guess I received an outdated manual...

    Could you post a picture of your manual? Thanks in advance!

    Added after 46 [minutes]:

    Angel0fDeath wrote:
    About DpID 104 - From the device I'm able to change the values from 0.5s to 30s with step 0.5s. However with tuya-mqtt.js I always receive this as integer, i.e. 0.5 is 1 and 1 is also 1, 1.5 is 2 etc.

    I've just checked that, with OBK, if I set it to 0.5 in the device, the corresponding channel shows 0:
    Display of TOMZN TOMPD-63WIFI device showing 0.5 Screenshot of channel settings and logs in the TuyaMCU panel.

    It must be a problem of Tuya MCU's firmware, as the logs effectively report 0:
    Logs of Tuya MCU communication showing transmitted and processed data.
  • #4 20879727
    Angel0fDeath
    Level 13  
    My manual is exactly the same as yours and actually you have this in your manual - 10th bullet on the first page (Light source).


    Well I just flashed openbeken on my device have some comments on your autoexec.bat
    Alarm set 1 and Alarm set 2 - it will be better if decoded and send as separate readings. Of course this could be done from home automation server also, but in this case is better to disable possibility to change them from web page.

    Id field shows 0 instead of name, which in my case is ETU9-IOT-WIFI

    And yes over voltage protection time shows only the integer part.
  • #5 20879734
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    10th bullet on the first page

    Ah, OK. I was missing it on the 2nd page, where it should appear between the last two screenshots, so I thought they might have corrected that
  • ADVERTISEMENT
  • #6 20880051
    Angel0fDeath
    Level 13  
    So after I spent a few hours with openbeken firmware, I have the following observations:

    dpID 104:
    for 1.0s -> 55 AA 03 07 00 08 68 02 00 04 00 00 00 01 80
    for 1.5s -> 55 AA 03 07 00 08 68 02 00 04 00 00 00 01 80

    Definitely wrong transmission from tuyaMCU. But usually you set this once, so it could bbe done from the device

    dpID 17: Leak protection

    received: 55 AA 03 07 00 08 11 00 00 04 04 00 00 1E 48
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 17, dataType 0-DP_TYPE_RAW and 4 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 67108894

    67108894 -> 0400 001E -> 30mA, do nothing (only alarm) - correct
    If not possible to decode in device HA server can do this.

    dpID 18: Always 0 here

    received: 55 AA 03 07 00 10 12 00 00 0C 01 01 00 3F 03 01 00 FA 04 01 00 AA 25
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 18, dataType 0-DP_TYPE_RAW and 12 data bytes
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 0E 02 00 04 00 00 00 64 89

    55 AA 03 07 00 10 12 00 00 0C 01 01 00 3F 03 01 00 FA 04 01 00 AA 25

    Data -> 01 01 00 3F 03 01 00 FA 04 01 00 AA - Data is correct - 63A(3F), OV=250V, UV=170V break the line for all 3 events

    Im prety sure if tuyaMCU driver tries to make integer from these 12 bytes (like for dpID 17) there will be overflow. Even longint will overflow, so this is a problem of tuyaMCU driver.


    9: Fault - this is better to be processed in HA server, since it is really a bitmap of this
    {
    "label": [
    "short_circuit_alarm",
    "surge_alarm",
    "overload_alarm",
    "leakagecurr_alarm",
    "temp_dif_fault",
    "fire_alarm",
    "high_power_alarm",
    "self_test_alarm",
    "ov_cr",
    "unbalance_alarm",
    "ov_vol",
    "undervoltage_alarm",
    "miss_phase_alarm",
    "outage_alarm",
    "magnetism_alarm",
    "credit_alarm",
    "no_balance_alarm"
    ]
    }

    which means error 1024 = 2^10 -> bit 10 (start counting from 0) -> 'ov_vol'


    dpID 19 - I never received such package. Probably some tuya function should be called to obtain this, but accordin to me this is not important, since in HA server there are different ways to make difference between devices

    Everything else seems to be ok.

    So as per the above the only thing which should be fixed is long data package for dpID 18 and correct transmission via MQTT.
  • #7 20880238
    p.kaczmarek2
    Moderator Smart Home
    @Angel0fDeath , while you are mostly correct, this is not a bug. We just don't have parsing for raw data, well, maybe except for one format. We have a work around for that in place but it requires writing a simple byte split in C code.
    We need to thing how to handle that, maybe we could just redirect it to MQTT directly, or just add a parser per each type when it becomes required.
    Take a look here:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_tuyaMCU.c
    Search for DP_TYPE_RAW_TAC2121C_VCP to see an example how we parse that.
    Helpful post? Buy me a coffee.
  • #8 20880387
    morgan_flint
    Level 14  
    @Angel0fDeath, thanks for your analysis; we had already bumped into these issues with the other device, TOMPD-63LW, in its thread, for example in this post and the following ones.

    Fortunately, we can deal with these DpIDs by setting them locally at the device, although it would be nice to be able to do the same remotely but, for me, the most interesting thing now would be to deal with DpID 9 (fault) as, if the device trips because of any of the possible causes (leakage, overcurrent, overvoltage or undervoltage), is good to know it before reconnecting remotely, for example, as I said in the last post (for now) of the other thread.

    You said this could also be done in HA server. If you are going to do it, could you please explain it here?
  • #9 20880451
    Angel0fDeath
    Level 13  
    I checked it and the idea is not bad, but since this is a setup channel we will not only need correct parsing to mqqt but backwards also.
    These are setup values and they have ranges. According to me it is better just to transmit them to HA server, if user wants to change them - he makes changes, server verifies ranges and if everything is ok then publish back the number. While this is applicable for dpID17, this is currently not applicable for dpID18.

    Let me explain - these are definitions of dpID 17 and 18, confirmed with real data:

    DpID 17 - Config - Leakage Current
    Example with real reading:
    DpID17 = 04 01 001e

    04 -> ???????? (probably ID or subchannel - never changes)
    01 -> Monitor Leakage Current (00 - Don't monitor) --> 01 - break the line + alarm; 00 - alarm only
    001e -> Leakage Current - 30 mA (range 10mA - 99mA, step 1, default 30 mA)

    DpID 18 - Config - Over Current, Over Voltage, Under Voltage
    Example with real reading:
    DpID18 = 01 01 003f 03 01 00fa 04 01 00aa

    01 -> ?????? (probably ID or subchannel - never changes)
    01 -> Monitor Over Current (00 - Don't monitor) --> 01 - break the line + alarm; 00 - alarm only
    003f -> Over Current - 63A (range 1A-63A, step 1A, default 50A)

    03 -> ?????? (probably ID or subchannel - never changes)
    01 -> Monitor Over Voltage (00 - Don't monitor) --> 01 - break the line + alarm; 00 - alarm only
    00fa -> Over Voltage - 250V (range 110V - 300V, step 1V, default 270V)

    04 -> ?????? (probably ID or subchannel - never changes)
    01 -> Monitor Under Voltage (00 - Don't monitor) --> 01 - break the line + alarm; 00 - alarm only
    00aa -> Under Voltage - 170V (range 85V - 220V, step 1V, default 170V)

    In general driver should do everything, unless we have limited memory. Due to this reason I suggest:

    For dpID17 the integer which driver obtains is enough. Can confirm it is transmitted correctly to MQTT Server. HA server can manipulate it and return it to tuyaMCU driver to set it into the device. Will try this tomorrow - manipulate the number and return it back to the device.

    For dpID18 - well more work is needed - the best will be the same approach - driver transmits the digits to the HA Server and manipulation is from the top level then return back to the device for setting. Because we have these unidentified bytes (marked with???) which in this device are one and the same but in other devices could be different, I would suggest the following:

    1. WB3S chip, I think is 32 bits, then longint = 4 bytes. If data is more than 4 bytes, then starting from right to left make few integers and transmit them to different channels. (I don't think this is the best idea, more over you need to reconstruct the byte array again if user change something)
    2. Just convert byte array to hex data string and transmit it in one channel (better) - HA server will return the correct hex string with changed settings
    3. Decode everything, send it in different channels and when user returns the values - reconstruct the correct data array and send it back to device - the best, but it is device dependent and additional memory for the firmware.

    Added after 19 [minutes]:

    >>20880387
    In HA server (Home Automation server) just make a function which reads the bit and returns the corresponding readable message

    something like:

    error - input for the function

    msg-string
    for (i=0; i<17; i++) {
    if (error && 1) { add to msg from enum values };
    error >>= 1;
    }
    return msg

    I'm using FHEM as HA server - it is in perl, but not so much difference with HASIO. Can do all the conversions tomorrow. Depending on how we will deal with dpiD 18
  • ADVERTISEMENT
  • #10 20880495
    p.kaczmarek2
    Moderator Smart Home
    Hey, your idea 1 is incorrect because we don't know what is the byte size of each variable, it could be 2, or 4, or maybe 1.

    I'd phrase it differntly, here are my 3 ideas:
    A. you can (or maybe even I could do that) hardcode simple parsing of it like we did for VCP, those packets seem to be standarized for Tuya
    B. we can make a flexible system on OBK that parses N bytes and puts it to channel by index, something like: [3,2,5] meaning offset 3, 2 bytes, are put to channel 5. Maybe just store this string in config and do parsing on the fly, but it's not perfect, also what if we need to specify whether given bytes are integer or a float?
    C. we can add a flag to OBK something like "publish raw dpIDs to HA" and publish this data as hex string to something like obk7623123/tuyaMCU/18/raw where 18 is dpID...

    we can also try to implement both or all of those solutions, what do you think? I can look into it tomorrow or soon

    Added after 1 [minutes]:

    I think I could do my C idea first (MQTT publish) and then we can also work on A or B, C is the most basic but flexible way
    Helpful post? Buy me a coffee.
  • #11 20880539
    Angel0fDeath
    Level 13  
    My idea 1 was just for splitting and nothing more. I know it is not good since everybody should read docs and to know how splitting works.
    Your suggestion about HEX string is good enough.
    I know it is difficult to decide right now, cause we don't have much experience with such devices. So the simplest solution will work... until new devices with the same things appear.
    So yes - simple HEX string transmission will be ok. But if it is a flag - not to publish all messages in HEX, just what is needed. Or maybe you can make channeltype HEX
  • #12 20881016
    p.kaczmarek2
    Moderator Smart Home
    I'm working on it, along with a self test, I hope this will suit your basic needs, then we will work on more advanced version:
    Screenshot displaying the debugger window in Microsoft Visual Studio with code related to MQTT tests.
    Is the following MQTT path okay for you?
    
    myTestDevice/tm/value/2
    

    NOTE: for raw, you will have 'raw' instead of 'value' in path

    Added after 1 [hours] 15 [minutes]:

    Angel0fDeath wrote:
    So after I spent a few hours with openbeken firmware, I have the following observations:

    dpID 104:
    for 1.0s -> 55 AA 03 07 00 08 68 02 00 04 00 00 00 01 80
    for 1.5s -> 55 AA 03 07 00 08 68 02 00 04 00 00 00 01 80

    Definitely wrong transmission from tuyaMCU. But usually you set this once, so it could bbe done from the device


    I don't think it's wrong. It's a value, number 1. They must be rounding seconds to full integer. What kind of dpID usage is this? Would user notice device using 1 second instead of 1.5 seconds?
    Helpful post? Buy me a coffee.
  • #13 20881211
    Angel0fDeath
    Level 13  
    The path doesn't matter, I hope it is for testing only.

    About reaction time - yes you are correct, the user will not notice the difference unless there are some fingers in some socket :).
    However this could be set from the device and once set you don't need to change it. Personally I prefer the fastest reactions otherwise the breaker of the electric company will break the line and I must call them to come to switch it on.
  • #14 20881264
    p.kaczmarek2
    Moderator Smart Home
    So what kind of path would you like? This is almost ready for use, so if you have any feedback, let me know.

    Once we have this feature tested, we will look into other, more specific solutions.
    Helpful post? Buy me a coffee.
  • #15 20881304
    Angel0fDeath
    Level 13  
    Leave the path as it is

    Just for information...
    It looks like the driver has also problems with string parsing:

    Info:GEN:No change in channel 10 (still set to 0) - ignoring

    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 12 13 03 00 0E 45 54 55 39 2D 49 4F 54 2D 57 49 46 49 00 DB
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 25 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 19, dataType 3-DP_TYPE_STRING and 14 data bytes
    Info:MAIN:Time 181, idle 121433/s, free 78680, MQTT 1(1), bWifi 1, secondsWithNoPing 2, socks 2/38
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 00 00 01 01 04
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 0 (Hearbeat) with 8 bytes
    Info:MAIN:Time 182, idle 256797/s, free 78680, MQTT 1(1), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:MAIN:Time 183, idle 252597/s, free 78680, MQTT 1(1), bWifi 1, secondsWithNoPing 1, socks 2/38
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 05 09 05 00 01 00 1D
    Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 12 bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 9, dataType 5-DP_TYPE_BITMAP and 1 data bytes
    Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 0
    Info:GEN:No change in channel 10 (still set to 0) - ignoring

    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 01 02 00 04 00 00 00 00 18

    dpID 19 - no parse
    Data -> 45 54 55 39 2D 49 4F 54 2D 57 49 46 49 00 -> 45h(E) 54h(T) 55h(O) 39h(9) 2Dh(-) 49h(I) 4Fh(O) 54h(T) 2Dh(-) 57h(W) 49h(I) 46h(F) 49h(I) 0(end of string) -> ETO9-IOT-WIFI - which is correct

    As I mentioned in my previous posts - this is not mandatory for me. Just for your information, because I think this is another bug...


    Forgot - The definition is:
    // Breaker Id - Dpid 19 "breaker_id" - channel 19
    linkTuyaMCUOutputToChannel 19 3 19
    setChannelType 19 textfield
    setChannelLabel 19 "Breaker ID"

    And the value is always 0. Probably another overflow...


    Btw, as you wrote in a post somewhere here, which I have read, channels don't know what is inside. How can I write string to channel? I tried for instance SetChannel 1 "asdasdasd". Value was 0. Channel1 was defined as textfield

    Added after 2 [hours] 35 [minutes]:

    @morgan_flint On my device when I set ClearPrepayment (dpID12) it clears prepaid energy counter (dpID13), but also clears TotalEnergy (dpID1). Can you confirm with your device is the same, ecause according to your explanations above it should clear only dpID13.
  • #16 20881929
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    @morgan_flint On my device when I set ClearPrepayment (dpID12) it clears prepaid energy counter (dpID13), but also clears TotalEnergy (dpID1). Can you confirm with your device is the same, ecause according to your explanations above it should clear only dpID13.

    Yes, the same in mine, it clears both counters. I should correct the label (EDIT: done in the first post), which is like that because there are two different DpIDs in the other device to clear both counters separately, so it's a copy-paste error from that. Sorry!

    Anyway, it's a bit strange that it allows you to clear the total energy counter so easily...

    Also, I have noticed that it doesn't allow you to recharge prepaid energy if prepayment is switched off, and if you switch prepayment on and the prepayment counter is 0, then it switches off the relay, so you must have a short blackout... nothing you can't live with, but I wouldn't have done it like that.
  • #17 20881979
    Angel0fDeath
    Level 13  
    About prepayment - yes correct you cannot change anything until prepayment switch is off, and yes you have blackout and alarm 65536 until you enter something where necessary. This is a poor user manual. I don't use prepayment, so I dont care, but the question here is in principle - when you make something - do it all others to use it, not only you...
    I think 'clear energy' switch is mainly for guys using prepayment services. This is the reason it clears total energy also. I dont think somebody in Europe can have this option, but probably in China is usual...
    Nevertheless tank you for your feed back.

    Btw: Im working on alarms (dpid9) on the server. I defined the following array:
    ("Short Circuit", "Surge Protection", "Overload", "Leakage Current", "temp_dif_fault", "fire_alarm", "High Power", "Self Test Failure", "Overcurrent", "unbalance_alarm", "Overvoltage", "Undervoltage", "Phase Is Missing", "Outage", "Magnetism", "Not Enough Credit", "No Prepaid Energy")

    More readable. I don't know what some of the messages should mean, so I left the original text. If you can help with the rest - appreciate. Of course this could be changed in the code later so it is not urgent. Will post the code when it is finished and tested (probably tomorrow, if my wife has no intentions about my day.... :) )


    This is my last autoexec file - you can try it. Still wondering should dpid9 to be resolved in device, but it seems we cannot write string to channel... Nevertheless try it and give some feedback

    // start TuyaMCU driver
    startDriver TuyaMCU
    tuyaMcu_setBaudRate 9600
    
    // This one is better than tuyaMcu_defWiFiState 4;  MQTTState 1 = WiFiState 4
    // issuing of tuyaMcu_defWiFiState 4 continues the script,
    // but doesnt report to MQTT since there is still no connection.
    // if you didn't setup MQTT connection then issue tuyaMcu_defWiFiState 4
    // and comment waitFor MQTTState 1
    
    waitFor MQTTState 1
    // tuyaMcu_defWiFiState 4
    
    
    // Breaker Id - Dpid 19 "breaker_id" - channel 0
    linkTuyaMCUOutputToChannel 19 3 0
    setChannelType 0 ReadOnly
    setChannelLabel 0 "Breaker ID"
    
    // Total energy - Dpid 1 "total_forward_energy" - channel 1
    linkTuyaMCUOutputToChannel 1 val 1
    setChannelType 1 EnergyTotal_kWh_div100
    setChannelLabel 1 "Total Energy"
    
    // Measurements - Dpid 6 "phase_a" - channel RAW_TAC2121C_VCP -> 2,3,4
    // TAC2121C VoltageCurrentPower Packet
    // This will automatically set voltage, power and current
    linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP
    setChannelType 2 Voltage_div10
    setChannelLabel 2 "Voltage"
    setChannelType 3 Power
    setChannelLabel 3 "Power"
    setChannelType 4 Current_div1000
    setChannelLabel 4 "Current"
    
    // Leakage current - Dpid 15 "leakage_current" - channel 15
    linkTuyaMCUOutputToChannel 15 val 5
    setChannelType 5 Current_div1000
    setChannelLabel 5 "Leakage Current"
    
    
    // Fault - Dpid 9 "fault" - channel 9
    // linkTuyaMCUOutputToChannel 9 bitmap 9
    setChannelType 9 ReadOnly
    setChannelLabel 9 "Fault"
    
    linkTuyaMCUOutputToChannel 9 val 10
    setChannelType 10 ReadOnly
    setChannelLabel 10 "Fault Numeric"
    
    AddChangeHandler Channel10 == 0 SetChannel 9 "No Alarm"
    // AddChangeHandler Channel10 != 0 
    
    // Prepayment on-off - Dpid 11 "switch_prepayment" - channel 11
    linkTuyaMCUOutputToChannel 11 bool 11
    setChannelType 11 toggle
    setChannelLabel 11 "Prepayment"
    
    // Clear Prepayment - Dpid 12 "clear_energy" - channel 12
    linkTuyaMCUOutputToChannel 12 bool 12
    setChannelType 12 toggle
    setChannelLabel 12 "Clear Energy Counters"
    
    // Prepaid energy - Dpid 13 "balance_energy" - channel 13
    linkTuyaMCUOutputToChannel 13 val 13
    setChannelType 13 EnergyTotal_kWh_div100
    setChannelLabel 13 "Prepaid Energy"
    
    // Charge Prepayment - Dpid 14 "charge_energy" - channel 14
    setChannelType 14 textfield
    setChannelLabel 14 "Charge Prepayment"
    linkTuyaMCUOutputToChannel 14 val 14
    
    // Main Relay - Dpid 16 "switch" - Channel 16
    linkTuyaMCUOutputToChannel 16 bool 16
    setChannelType 16 toggle
    setChannelLabel 16 "Relay"
    
    // Settings 1 - Dpid 17 "alarm_set_1" - channel 17
    linkTuyaMCUOutputToChannel 17 raw 17
    setChannelType 17 textfield
    setChannelLabel 17 "Leakage Current Protection Settings"
    
    // Settings 2 - Dpid 18 "alarm_set_2" - channel 18
    linkTuyaMCUOutputToChannel 18 raw 18
    setChannelType 18 textfield
    setChannelLabel 18 "UV, OV, Max. Current Protections Settings"
    
    // Over Voltage Protect Time - Dpid 104 "over_vol_protect_time" - channel 24
    linkTuyaMCUOutputToChannel 104 val 24
    setChannelType 24 textfield
    setChannelLabel 24 "Over Vol Protect Time"
    
    // Over Voltage Recovery Time - Dpid 105 "over_vol_recovery_time" - channel 25
    linkTuyaMCUOutputToChannel 105 val 25
    setChannelType 25 textfield
    setChannelLabel 25 "Over Vol Recovery Time"
    
    // NOTE: addRepeatingEvent [RepeatTime] [RepeatCount]
    // code below will forever Send query state command every 5 seconds
    // addRepeatingEvent 5 -1 tuyaMcu_sendQueryState 
    
    // AngelOfDeath - We don't need it forever, since TuyaMCU sends everything when necessary
    // we need it just first time to obtain initial status. Some dpIDs not reported without asking
    tuyaMcu_sendQueryState
    


    Added after 1 [hours] 37 [minutes]:

    I think I've got the logic about prepaiment: Turn prepayment on and have a blackout, then in the field prepaid energy enter the amount (kWh*100) and this becomes prepaid energy total (dpid13). When this prepaid energgy is over, the breaker will cut the line.... well issuing also some alarms.

    So this is the correction
    // Charge Prepayment - Dpid 14 "charge_energy" - channel 14
    setChannelType 14 textfield
    setChannelLabel 14 "Prepaid Energy (Enter prepaid energy as prepaid [kWh] *100)"
    linkTuyaMCUOutputToChannel 14 val 14

    I entered 1, which is 10Wh and after few minutes observed the all the action :)

    Again POOR MANUAL from manufacturers....


    PS: You can add energy to dpid14 before total energy expires. Then the device adds thee value of dpid14 to dpid13. If thee device cuts the line then you must clear all energies to start again. So this is the reason we have this function Clear all energies.
  • ADVERTISEMENT
  • #18 20883083
    Angel0fDeath
    Level 13  
    @morgan_flint Here is the code to process the fault in HA server It is in perl, but I think you can easily write it in any other language.
    Although I never received 2 faults at same time I left full processing in case we have more than 1 fault. I don't know is this possible.

    sub ProcessFault($) {
      my ($fault) = @_;
    
      my @errors = ("Short Circuit", "Surge Protection", "Overload", "Leakage Current", "temp_dif_fault",
                    "fire_alarm", "High Power", "Self Test Failure", "Overcurrent", "unbalance_alarm",
                    "Overvoltage", "Undervoltage", "Phase Is Missing", "Outage", "Magnetism",
                    "Not Enough Credit", "No Prepaid Energy");
    
      if ($fault == 0) { return "Everything ok"; }
      else {
        my $err = "";
        for (my $i = 0; $i < 17; $i++) {
          if ($fault & 1) {$err .= $errors[$i].". "; }
          $fault >>= 1;
        }
        $err = substr($err, 0, (length $err) - 1);
        return $err;
      }
    }


    This function triggers on change of Fault reading and returns the coresponding value to Error reading.
  • #19 20883189
    morgan_flint
    Level 14  
    I share your opinion about the device (and this kind of Chinese devices in general): it has some details that can be/should be improved and the manual is very poor. But, on the other hand, the hardware seems well-designed and they are dirt cheap, considering all they contain (I got mine for just 11.56€ and, although its regular price is about 19€, it's still very cheap), so I think they are a good platform for experimenting and hacking.

    I think the prepayment function is intended for landlords hiring apartments or people hiring rooms, for example, more than prepayment to utilities. So the way it works makes some sense, just it would be better to have the two reset counter DpIDs separated (as in TOMPD-63LW), as you may want to clear and reprogram the prepayment when a new occupant comes, but keep the record of the total energy spent, for example.

    Regarding DpID9, thank you for your work with the server option; let's wait to see if @p.kaczmarek2 finds a solution for treating it in the device; as I see it, a solution like the one in RAW_TAC2121C_VCP, to be future proof, could require reserving 17 output channels to show the status of the 17 possible alarms (of which this device only uses 4), and this could be overkill. Or limit it just to the 4 alarms, for the moment...

    The logic about charge prepayment is as you describe it, I had already tested it like that but is somewhat confusing because it takes some time to appear on the counter. In the beginning, I thought you had to write a 0 after writing the desired amount, but it was just because I hadn't waited enough.

    I tested your autoexec and also works well for me. Regarding removing addRepeatingEvent 5 -1 tuyaMcu_sendQueryState I had tried it, but included it again because it seemed like it took more time to refresh power and current. Probably wrong perception, but I see voltage updating more frequently than power and current; this could be also something related to TuyaMCU's FW.

    I see you have added the code to process the fault in HA server while I was writing this one! apart from the programming language, I'm afraid I'm going to need more help with how to integrate it into HA; I'm a novice using it...

    You did well considering the possibility of more than one alarm at the same time; I managed to get 3 of them on the other device, as you can see here
  • #20 20883595
    Angel0fDeath
    Level 13  
    Concerning dpID9 - it is not necessary to reserve 17 channels if you want to resolve this in device - 2 channels are enough - 1 channel for num value and 1 channel for text value - 2 changehandlers 1 i value is zero and 1 if value is not zero. If not zero to run script to check for all faults with a lot of if statements (I didn't saw we have for statement in the firmware). Just 1 new command will be needed to append string in the channel instead of setting it. As you can see in my autoexec file I started this implementation, but I discovered I cannot write string to channel. This is the reason I asked p.kaczmarek how exactly this is supposed to be done. If everything is ok, I can make this to be resolved in device in autoexec. Probably will be necessary to shorten explanations to fit into string channel, but first we must see this implemented.
    Today I discovered a new issue - although the value of dpID17 is correct, I was not able to set it. For instance value by me is 67108894 and is correct (in he 04 00 001e). So I would like to change it to 04 01 001e (dec 67174430). So I enter the dec number, press set and it seems everything is ok, but after request of status of all registers the value is as before setting. Probably another problem with the driver, but didn't have much time to analyze that, so this remains for the next year - my wife will kill me if tomorrow whole day Im again busy "with this stupid breaker" :)
    Concerning your autorepeat event - in general tuyaMCU reports dpids when there is a change except dpids with the current values which are reported each 15 or 30 sec. So I call this once to obtain initial status then tuya reports everythin we should know. Of course your statement will update all readings faster, because you call it each 5 seconds, but do you really need this info each 5 seconds?
  • #21 20883603
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    About 't' setting of the device - according to users manual this should be light source. By me this do nothing. Probably for future use - light for LCD or something like that. Maybe some models have LCD light and this don't (in manual it is written it's optional)

    I opened the device again and checked that there were two "suspicious" pads at one side of the smaller PCB: one of them was ground and the other went to a resistor and a transistor (difficult to see as it is behind the LCD), which looked very much like a LED driver. I soldered an LED to these pads, set the "t" setting to a low value and as expected, the LED turns on after pressing a key and goes back to off after the settled time. Now I have to guess how to attach the LED to the LCD in a way that illuminates it effectively and fits into the case
    Electronic circuit with buttons and an LCD display, with a soldered LED.

    Added after 1 [hours] 2 [minutes]:

    Sorry, when I posted this I hadn't refreshed the browser, so I hadn't seen your last post.
    Angel0fDeath wrote:
    2 channels are enough - 1 channel for num value and 1 channel for text value

    But, would this work with more than one alarm at the same time? Or the second channel (string) would contain all active alarms?

    Angel0fDeath wrote:
    Today I discovered a new issue - although the value of dpID17 is correct, I was not able to set it

    Same for me, in the other thread @p.kaczmarek2 asked about implementing the possibility of sending the info to the MCU, so I understand OBK doesn't allow it now.

    Angel0fDeath wrote:
    Of course your statement will update all readings faster, because you call it each 5 seconds, but do you really need this info each 5 seconds?

    In general, no, maybe only in some special applications
  • #22 20883782
    Angel0fDeath
    Level 13  
    1. Nice discovery about LED - this confirms this setting is or LCD backlight. If you have remote control, do you really need backlight? I'm not going to do anything, because I don't need it, more over it seems no way to oparete it remotely. Probably if t setting is with timer backlight should turn on by pressing any button and turn off after timer expires. But thank you for the feedback.
    2. If we have command in firmware to append string to the channel instead of setting it - it will have all alarms, but in order to fit in string definition of the channel probably text descriptions should be shortened.
    3. Yes we are awaiting implementation of this new raw format in the driver, then we can test and give feedback to p.kaczmarek
  • #23 20885440
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    do you really need backlight?

    Probably not, but just for the sake of it, I finally added it :-)
    Circuit board with buttons and LCD backlight. Backlight panel with clipped wire. DIY backlight panel and a sheet of paper with aluminum foil. Backlight panel from a trash bin with a trimmed paper sheet and a diode. Two rectangular backlight panels with wires and a piece of paper on a blue surface. Backlight panel installed behind an LCD display with buttons. Circuit board with mounted LCD display and additional electronic components. View of an electric energy meter with a backlit display showing various values.

    I used a backlight panel from my junk box, cut it to size, and installed it behind the LCD. The place where the diode is is brighter than the rest, but I've dimmed it a bit more with a piece of paper
  • #24 20886504
    Angel0fDeath
    Level 13  
    @morgan_flint First of all Happy New Year to everybody.
    Had some time today. I wrote alternative web page for controlling the breaker. In general the code makes everything which you want to do with device without HA server. This new web page does not replace the original one, so you can always go to main page. But this page is more compact, more understandable and processes all data we receive from breaker.
    You can run it either from PC or from breaker.
    To run it from PC first open html file with text editor (notepad++ for best view) and search for baseURL. Change the value in quotes with IP-address of breaker. Check the mapping of channels is the same as yours. Mapping is after baseURL. If necessary change channel numbers. Save the file and open it with browser.
    If everything is ok you probably would like to run the file from breaker.
    First open again html file and go again to baseURL. Comment the line with your IP-address and uncomment the next line where baseURL is blank. Open breaker's web application and create a new file for instance breaker.html. Open it and copy and paste all the content. Save it in breaker.
    Now html file will be accessible on the following address http://BreakerIP/api/lfs/breaker.html

    I will add the code for the rest things which we cannot currently read or set after we know how to do this.
    Enjoy :) .

    BTW nice work with the backlight

    PS: If you have more than 1 breaker it is not necessary to change the title, since the script will change it on load with device name you configured
  • #25 20887774
    morgan_flint
    Level 14  
    Tested both as a file and in the device, works like a charm!

    Thanks!
  • #26 20887865
    p.kaczmarek2
    Moderator Smart Home
    Good job @Angel0fDeath , please consider posting this file along with some guide and description how it works on our tutorials section: https://www.elektroda.com/rtvforum/forum517.html

    Added after 1 [minutes]:

    btw do you know that you can add a http panel button as a link to this page, while it's hosted on LittleFS?
    Helpful post? Buy me a coffee.
  • #27 20887927
    Angel0fDeath
    Level 13  
    @p.kaczmarek2 Yes I know. Since it is normal html file you can add whatever you want, just like normal web page.
    @morgan_flint Here is improved version of the html.
    Since you don't set the device each day and the most people are not using prepaid features, I made these hidden by default. Of course you can show them by clicking on corresponding checkbox. Added some colors (for instance fault - green if everything is ok and red if there is an error etc.)
    We still await correct raw parsing of the settings values and correct string parsing, although the last one is not mandatory. It could be parsed again as raw, and I can convert it in html.

    Regards
  • #28 20887948
    Angel0fDeath
    Level 13  
    @p.kaczmarek2 I don't think tutorial is needed. If somebody is familiar with html and javascript, can make it. I just reviewed your examples. Well of course I'm a little bit lazy and in general I hate to design forms I just saved your web page and modified it a little. This is the reason it looks like your page. Of course I needed to add some properties to the fields, rearrange them a little and definitely the java code, but when you know what to do it is definitely fast.
    Since this is the most complex html, you can consider to add the final version to your examples. If you want to do that will write some comments inside html file. Currently they are on min. The last revision of the file is almost 20k... The main reason is I don't want to use iterators, because I want the page to work without internet connection - just inside your internal (home) network.
    Actually, the last is valid for your web application also. When have some more time, will try to host it on my NAS. I didn't found any instructions about that, but I think I have an idea how to do this...


    PS: Just noticed something - when you issue status command to the device in the returning JSON we have DeviceName and FriendlyName, but both are set to Short (Friendly) device name. Is it possible DeviceName to return the full name and Friendly Name to remain as it is (i.e. with the short name)
  • #29 20888496
    p.kaczmarek2
    Moderator Smart Home
    Which endpoint exactly, can you be more specific?

    Ah wait, I see, you mean that?
    https://github.com/openshwprojects/OpenBK7231...mmit/bed281a890034965bccac63a8f04856567880434
    Nice spotting
    Helpful post? Buy me a coffee.

Topic summary

The discussion revolves around the teardown and flashing of the Tomzn TOMPD-63 WIFI device, focusing on its differences from similar models like TOMPD-63LW. Users share insights on the device's DpIDs, firmware issues, and the functionality of various settings, including alarm configurations and leakage current monitoring. The conversation highlights the challenges faced with TuyaMCU communication, particularly in parsing raw data and setting parameters through the OpenBeken firmware. Participants also discuss the implementation of a custom web interface for device control, troubleshooting methods, and the integration of the device with home automation systems. The need for improved documentation and user manuals is emphasized, along with suggestions for enhancing the device's features and usability.
Summary generated by the language model.
ADVERTISEMENT