TOMZN TOMPD-63-LW Wifi Multi Function (DIN) WB3S (BK7231T)

Well, since you have a 2MB backup, maybe we can skip the UART capture process which is risky and requires isolation for USB to UART converter, and just try to flash OBK? In worst case you can always restore the backup.

p.kaczmarek2 wrote:

maybe we can skip the UART capture process which is risky and requires isolation for USB to UART converter, and just try to flash OBK?

Hello again after an "intense" long weekend... Yes, that's probably the better option and I will do it as soon as possible, but I wanted to explore all the Tuya-related capabilities before flashing OBK.

morgan_flint wrote:

The rest of the hardware seems to be the same (I will add photos later on)

Here are the photos:


And some screenshots of the App:


I've also done a little bit of "reverse engineering" of the schematic; just for the sake of doing it, as it doesn't add much to making it work with OBK, but once I clean it up a bit I'll post it here.

That's a lot of dpIDs. Have you tried to look up the full list of datapoints at Tuya developer website?

p.kaczmarek2 wrote:

Have you tried to look up the full list of datapoints at Tuya developer website?

Is it the attached listing (pdf)?

If not, Where do I have to look?

EDIT: I also copied the contents under "Standard Instruction Set" and "Standard Status Set" of this screenshot in another attachment (zip)

I am not sure but it doesn't look right, there are no dpId numbers there?

Maybe try this method?
https://www.zigbee2mqtt.io/advanced/support-new-devices/03_find_tuya_data_points.html

Curiously, I was looking at the device logs, where you can find a dropdown menu called "Select DP ID":

(the first Chinese text translates as "Refresh report" and the second one as "Active Power")

Of course, I would have never imagined a procedure like the one you found!! I followed the instructions you posted and got this:

20 DP IDs, if I'm counting well

This would be the correspondence with the list of my previous post (pdf file), with also 20 entries (two first columns), and the new info (the other two)

DP Instruction	Standard Instruction	DP ID	Description
total_forward_energy	total_forward_energy	1	Total forward energy
phase_a	phase_a	6	Phase A
fault	fault	9	Fault
switch_prepayment	switch_prepayment	11	Switch prepayment
clear_energy	energy_reset	12	Clear energy
balance_energy	balance_energy	13	Balance energy
charge_energy	charge_energy	14	charge energy
leakage_current	leakage_current	15	Leakage current
switch	switch	16	Switch
alarm_set_1	alarm_set_1	17	Alarm set1
alarm_set_2	alarm_set_2	18	Alarm set2
breaker_id	breaker_number	19	Breaker id
leakagecurr_test	leakagecurr_test	21	Leakage current test
clr_all_energy	-	101	Clear Energy
power_factor	-	104	Power Factor
supply_frequency	supply_frequency	105	Grid Frequency
refresh	-	106	刷新上报 (Refresh report)
output_voltage	-	116	Voltage
output_current	-	117	Current
output_power	-	118	有功功率 (Active Power)

Also, in case it's of some help, I'm attaching some of the device log contents (TOMPD-63LW_logs.pdf)

I think we may also need to know the variable types, altough in most cases it should be very easy to guess them. Ok, so we are ready to flash OBK?

p.kaczmarek2 wrote:

I think we may also need to know the variable types

Maybe this can be (at least, partially) extracted from the information in the first attachment here.

It contains information for 14 of the 20 variables (all of those that have info in the second column (Standard instruction) of the table in my previous post, and the listing is in the same order, so easy to match.

I'm transcribing it here so it's easier to read. This first table is for "Standard Status Set":

DP ID	Code	Type	Values
1	total_forward_energy	Integer	{ "unit": "kW·h", "min": 0, "max": 99999999, "scale": 2, "step": 1 }
6	phase_a	Raw	{}
9	fault	Bitmap	{ "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" ] }
11	switch_prepayment	Boolean	"{true,false}"
12	energy_reset	Enum	{ "range": [ "empty" ] }
13	balance_energy	Integer	{ "unit": "kW·h", "min": 0, "max": 999999, "scale": 1, "step": 1 }
14	charge_energy	Integer	{ "unit": "kW·h", "min": 0, "max": 99999, "scale": 1, "step": 1 }
15	leakage_current	Integer	{ "unit": "mA", "min": 0, "max": 1000, "scale": 0, "step": 1 }
16	switch	Boolean	"{true,false}"
17	alarm_set_1	Raw	{}
18	alarm_set_2	Raw	{}
19	breaker_number	String	{ "maxlen": 255 }
21	leakagecurr_test	Boolean	"{true,false}"
105	supply_frequency	Integer	{ "unit": "Hz", "min": 0, "max": 1000, "scale": 1, "step": 1 }

And the second one for "Standard Instruction Set":

DP ID	Code	Type	Values
11	switch_prepayment	Boolean	"{true,false}"
12	clear_energy	Boolean	"{true,false}"
14	charge_energy	Integer	{ "unit": "kW·h", "min": 0, "max": 99999, "scale": 1, "step": 1 }
16	switch	Boolean	"{true,false}"
17	alarm_set_1	Raw	{}
18	alarm_set_2	Raw	{}
21	leakagecurr_test	Boolean	"{true,false}"

This looks somewhat complete, altough I am not sure why dpID 9 is marked as bitmap and not as raw bytes data.

It's strange, so I checked it again:


I'm not very sure of the reliability of Tuya info; for example, there's one of the screenshots I posted from the App, acceded after clicking "Temperature" on the main screen for the device, that shows no info and makes no sense, as there aren't any temperature sensors in the hardware. I'm afraid product developers just customize some general kind of information without paying too much attention

Do you need all of these data supported, or only the basic information like voltage, etc?

Of course (and abusing your patience...), it would be ideal if we could support as many as possible, as the main appeal of this device is the amount of functions it performs...

Maybe we could leave to the local keyboard the adjustment of the different protection thresholds, as these are values rarely changed but, for example, it would be interesting to know remotely which of the protections has acted.

I'll flash OBK now to see what we can do with that, but I've just ordered the isolators to be able to capture traffic and, once they arrive, I could flash the original FW again if we need to see something there...

BTW, I've also ordered one of the devices similar to this one but with just one relay (I found it at a very good price and couldn't resist...). I see coincidences in some of the DP IDs in that device's thread, so maybe between both devices, we will be able to decipher all of them.

I've also compiled in the attached .pdf all the info on the previous tables, to make it easier to see all at a glance. I'm also attaching the "diagnostics" from the Tuya integration in Home Assistant, in case they can give new information. It seems to have contents relative to all the functions, although the device's page only shows a few of them:


Thank you for all your help; I'm sorry I'm so noob on this subject

p.kaczmarek2 wrote:

This looks somewhat complete, altough I am not sure why dpID 9 is marked as bitmap and not as raw bytes data.

Regarding this, and looking at the combined table, maybe "bitmap" just means the DP reports the number of the alarm in the list:


If this is true, "0" in the reports would be no alarm, and "8" would be "self_test_alarm", which is the 8th in the list (I made some self-tests of the leakage current with the device by pressing the button labeled "T")

Yes, I also think we can now try flashing OBK and see how it goes.

morgan_flint wrote:

If this is true, "0" in the reports would be no alarm, and "8" would be "self_test_alarm", which is the 8th in the list (I made some self-tests of the leakage current with the device by pressing the button labeled "T")

I'm afraid I was wrong; I provoked 3 different alarms (overcurrent, leakage, and low credit, individually, not simultaneously) and got these values for this DP ID: 4,8 and 32768 (2², 2⁴ and 2¹⁵)
So now "bitmap" makes sense: the activated alarms of the list of possible values are those that correspond with the "1" bits of the binary conversion of the decimal value of this DP ID:


I still have to figure out the meaning of the cryptic values of "Phase A", "Alarm set 1", and "Alarm set 2"

Ah, sorry, now I understand! I may have been working too much. By Bitmap, they do not mean Bitmap as in "an image", but they mean what I usually call flags, where each bit (1 or 0) is a flag describing a state. Silly me. Now everything is clear. Thanks for pointing that to me!

morgan_flint wrote:

I still have to figure out the meaning of the cryptic values of "Phase A", "Alarm set 1", and "Alarm set 2"

Following the ideas in this post (specifically, base64 to hex conversion), I think the meaning of "Phase A" is now clear:



08 F0 hex = 2288 dec = 228.8V
00 1F FE hex = 8190 dec = 8.190 mA = 8,190A
00 07 53 hex = 1875 dec = 1.868 W = 1,868 kW

These coincide with the values I noted down at that time during tests I did yesterday with a heater connected as a load.

I imagine the values for "Alarm set 1", and "Alarm set 2" are also base 64, but I'm afraid they are going to be more difficult to decode

Finally flashed OBK and used the autoexec.bat from this post. These are the results:


I also copied all the "TUYAMCU received" strings from the attached file "TOMPD-63LW_OBK_LOG.txt" to the also attached "TUYAMCU received.txt", and analyzed them with TuyaMCUAnalyzer:


It shows up to 10 DP IDs in the brief time covered by the log, including those of Power Factor (104), Grid Frequency (105), Leakage Current (15), and the cryptic Alarm set 1 (17).

Also, DP ID 13 (Balance energy), that must correspond with the remaining prepaid energy in 1/10 kWh (It shows 8, I programmed this with the minimum, 1 kWh, and have expended 0.2, ):
55 AA 03 07 00 08 0D 02 00 04 00000008 2C
HEADER VER=03 State LEN dpId=13 Val V=8 CHK

BTW, there's a string in the logs (55 AA 03 07 00 10 12 00 00 0C 01 01 00 13 03 01 00 FA 04 01 00 D2 21) that gives an error in TuyaMCUAnalyzer:

morgan_flint wrote:

Following the ideas in this post (specifically, base64 to hex conversion), I think the meaning of "Phase A" is now clear:

😥 Supid of me... I see the contents of this DP were already known and are well-decoded


EDIT: Adding a screenshot from the device's page in Home Assitant:


EDIT 2: Analyzing the link posted by @fakuivan here, in the last post there's a detailed description of "Alarm set 1":


Unfortunately, "abilityId" (must be the same as DP ID) 104 and 105 have different meaning there.

Good job! For a start, I can see you have numbers like "4" and "5" on your HA panel.
Can you try to use:

to get better names on UI? Try it out and let me know if it works

See more info on our command docs page: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md

Ok, thanks!

Some progress here:


(BTW: ¿Why is NTP driver needed?)

I could add power factor (correct) and frequency (shows 5.00 Hz and channel value is 500.00, but there's only "Frequency_div100" option for this type). I'm afraid the real resolution for this variable is 1-2 decimal at most; it's very difficult that the real frequency is 50,000 Hz

Also, the Home Assistant screenshot:


Some of the labels seem to be different to those in autoexec.bat and RSSI says "Desconocido" (Unknown)

I will continue trying to add more things, but I'm afraid the Alarm Set 1 and 2 are beyond my possibilities 😢

EDIT: Deleting previous edit about leakage current; there must be some error, I'll add later

Added after 2 [hours] 17 [minutes]:

Regarding leakage current, ff I add to autoexec.bat the following:

But leave as "Default" or "Custom" the channel type, I get the following:


Channel shows the same value as on the device's screen but nothing in the listing above (I imagine this is normal behavior). Then, if I change channel type to "Current_div100" I get:


Correct value for the channel again and something coherent (apart from the rounding) shows in the listing. It should be 0,060 A or 60 mA, but I choose div100, so my fault...

BUT, if I choose change channel type to "Current_div1000" then I get:


An invalid value, both in the channel and in the listing, that are now cloning the values for Current on channel 4. I imagine this is because you can't use the same channel type for 2 different channels. Is this intended or is a bug?

Thank you for your patience, again!

I will add Frequency_div10 for you, but in general, we may consider something more flexible in the future, of course, with backwards-compatibility included.

NTP is just for current time, maybe previous config author used that.

I think you need a leakage current channel type for leakage current.

p.kaczmarek2 wrote:

I will add Frequency_div10 for you, but in general, we may consider something more flexible in the future, of course, with backwards-compatibility included

Thank you! A possibility would be to separate the type and the scale (multiplier or divisor), but you'll know better what would be easier to implement

p.kaczmarek2 wrote:

I think you need a leakage current channel type for leakage current.

But it doesn't exist yet, does it?

On the other hand, if we had more than one current measurement (in a three-phase meter, for example), would it work well if you assigned the same type to more than one channel?

Hello again!

I did a deeper analysis of DPIDs 17 and 18. I started rewriting the JSON on EDIT2 here in a more legible way:


(I pasted it like an image because the tabulations get distorted if I publish it like code, but I'm also attaching the file, remove ".txt" after downloading)

So, for example, for DPID 17:

55 AA	03	07		00 08	11	00	00 04	0401001E	49
HEADER	VER=03	State		LEN	dpId=17	Raw	LEN=4	V=67174430	CHK

The "payload" 04010050 translates to:
1st byte (indicating the presence of the alarm): 04
2nd byte (when this alarm occurs, the circuit breaker control mode (0X01 trip, 0X00 no action, only alarm)): 01 (trips)
3rd and 4th bytes: setting alarm threshold: 001E (HEX translates to DEC 30; corresponding to the 30mA which coincides with my setting of the leakage current threshold).

For DPID 18 the analysis would be, for example:

55 AA	03	07		00 10	12	00	00 0C	01010013 030100FA 040100D2	21
HEADER	VER=03	State		LEN	dpId=17	Raw	LEN=12	Values	CHK

The "payload" 01010013 030100FA 040100D2 translates to:
01010013
1st byte (indicating the presence of the alarm): 01 Could be the code for overcurrent 1st byte (indicating the presence of the alarm): 03 Could be the code for overvoltage (see 3rd and 4th bytes)
2nd byte (when this alarm occurs, the circuit breaker control mode (0X01 trip, 0X00 no action, only alarm)): 01 (trips)
3rd and 4th bytes: setting alarm threshold: 00FA (HEX translates to DEC 250; corresponding to the 19A which coincides with my setting of the overvoltage threshold).(see 3rd and 4th bytes)
2nd byte (when this alarm occurs, the circuit breaker control mode (0X01 trip, 0X00 no action, only alarm)): 01 (trips)
3rd and 4th bytes: setting alarm threshold: 0013 (HEX translates to DEC 19; corresponding to the 19A which coincides with my setting of the overcurrent threshold).

030100FA
1st byte (indicating the presence of the alarm): 03 Could be the code for overvoltage 1st byte (indicating the presence of the alarm): 03 Could be the code for overvoltage (see 3rd and 4th bytes)
2nd byte (when this alarm occurs, the circuit breaker control mode (0X01 trip, 0X00 no action, only alarm)): 01 (trips)
3rd and 4th bytes: setting alarm threshold: 00FA (HEX translates to DEC 250; corresponding to the 19A which coincides with my setting of the overvoltage threshold).(see 3rd and 4th bytes)
2nd byte (when this alarm occurs, the circuit breaker control mode (0X01 trip, 0X00 no action, only alarm)): 01 (trips)
3rd and 4th bytes: setting alarm threshold: 00FA (HEX translates to DEC 250; corresponding to the 19A which coincides with my setting of the overvoltage threshold).

040100D2
1st byte (indicating the presence of the alarm): 04 Could be the code for undervoltage in this DP(see 3rd and 4th bytes)
2nd byte (when this alarm occurs, the circuit breaker control mode (0X01 trip, 0X00 no action, only alarm)): 01 (trips)
3rd and 4th bytes: setting alarm threshold: 00D2 (HEX translates to DEC 210; corresponding to the 19A which coincides with my setting of the undervoltage threshold).

So, more or less, everything is clear; the only thing that puzzles me is the different meaning of the alarm code in both DPs, but could be normal as can be deducted from the examples in the JSON

Anyway, these DP IDs seem to be useful only for reading and setting the thresholds for alarms which, like I said before, can be done from the local interface and doesn't change frequently, so could be skipped in OBK (apart from the sake of completion...). More interesting would be to include DP ID 9, which is the alarm status, that is very interesting to have reported remotelly.

morgan_flint wrote:

BTW, there's a string in the logs (55 AA 03 07 00 10 12 00 00 0C 01 01 00 13 03 01 00 FA 04 01 00 D2 21) that gives an error in TuyaMCUAnalyzer:

I opened an issue in Github related to this; I checked the string against Tuya specs for this command and the string seems correct, including checksum

Hello again!
I have changed/completed the autoexec.bat so now almost all DPIDs of interest are shown:



In red/green I've added the channel numbers. Some comments:

All channels show correct values except for:

- Channel 6: shows 0.28 kWh and the value in the display is 2.8 kWh. I'm using channel type "EnergyTotal_kWh_div100", so could be corrected if "EnergyTotal_kWh_div10" existed (or an alternative for divisors)

- Channel 11: shows 5.00 Hz and the value in the display is 50 Hz. I'm using channel type "Frequency_div100", so could be corrected if "Frequency_div10" existed (or an alternative for divisors)

- Channel 9 (power factor) shows the correct value but doesn't seem to recognize the label set in autoexec.bat. Am I doing something wrong?

Other comments regarding channels:

- I've set Channels 8 and 14 ("Clear Prepayment" and "Test Leakage") as "Toggle", and they work as intended, i.e., when "pushed", channel 6 sets to 0 (first case) and leakage alarm appears and switch trips (second case). The "problem" is that they stay green (0) and don't go back to red (0) by themselves, as could be expected. In these cases, a "momentary" button type would be a possible solution (or maybe include something in the autoexec for these channels that made them return to 0 a few seconds after toggling to 1?)

- Channel 15 (Alarm set 1) shows in the textfield the correct decimal value for the expected hex value, according to the analysis in my previous post but, surprisingly, the value shown below for the same channels is different (67174490 vs 67174488.00). At that moment, I had the setting of the leakage current threshold in 90mA, which coincides with the last two digits in the textfield and, if I changed it to 30 in the device, the textfield would react accordingly. What doesn't work is the opposite: if I change the value in the textfield to 67174430 and hit "Set!", the value changes momentarily to this one but returns to 67174490 in a few seconds (and the value in the device's screen doesn't change). So, unfortunately, this isn't a way to set the thresholds from the web interface.

- I tried a similar approach with "Alarm set 2", but it doesn't show any values (stays at 0). I'm afraid it's due to its length (similar to the exception in TuyaMCUAnalyzer).

- Finally, channel 17 ("Fault") shows the correct decimal value for a given alarm, according to the analysis in this post. For example, 4 if I force an overcurrent or 8 during the leakage test. I don't know if there is a better way to treat these "bitmaps" in OBK

Here are some more screenshots in different situations:


And the screenshot from Home Assistant:


The textfields are ignored, and the label for power is not the same; curiously, the label for power factor is correct here

Apart from some details, all the interesting DPs are covered; the only thing I consider interesting that is missing is a better treatment for "Fault" signaling (knowing remotely what has been the protection that has acted: overload, overvoltage, undervoltage or leakage)

Good progress, keep it on! I will try to add required channel types tomorrow.

p.kaczmarek2 wrote:

Good progress, keep it on! I will try to add required channel types tomorrow.

Thank you!

Another curious fact about this device: It can detect negative (export) power:


To check this I simply inverted input and output. The problem is, as the device feeds itself from the input and the relay is open, it doesn't start, but if you temporarily bridge the input and the output (N to N and L to L, of course...) then the device starts and, once it closes the relay, you can remove the bridges and do the test.

Unfortunately, it doesn't report the negative sign to the module, so it doesn't reflect on the web page. Also, despite power being negative, the energy counters continue to increase...

>>20719315
I'm also interested in this subject, as the third listing posted by @crash1912 here was the most informative for identifying the DP IDs of the device, and I have a different one in it's way home, so using this method could be the simplest way.

I have tried accessing https://openapi.tuyaeu.com/v2.0/cloud/thing/xxxxxxxxxxxxxxx/model, replacing xxxxxxxxxxxxxxx with the "device id" that appears on Tuya platform for developers, but I get an error:


It seems like a "token" is missing...

I've asked @crash1912 privately, as I see he hasn't been around for a while but, just in case @fakuivan or somebody else knows the answer: What am I doing wrong? Is the "device id" the correct replacement for xxxxxxxxxxxxxxx?

Thanks!

EDIT: I continued searching on my own and I think I'm on the right way now. The link to look is this one:
https://iot.tuya.com/cloud/explorer

You have to have a Tuya Developer account and create a project (same as for this method).

Still have to find there the query that includes /model, that gives the most complete info

EDIT 2: Found. In https://eu.iot.tuya.com/cloud/device/, copy the "device_id":


Then, in the previous link, select Device Control -> Query Things Data Model:


Then, hit "Copy" in the "response" and you get this:

The interesting part is the one enclosed between quotation marks after "model": :


The problem is that is all in one line (no carriage returns), so not very legible. This, joined to the fact that the word "model" didn't show well in the previous screenshot is what made it difficult to locate. To make it more legible, I pasted it into notepad++ and made the following substitutions:

With "extended" selected in search mode. Here's an example for the first substitution:

(I recorded a macro for that)

Then, after installing "JSON Viewer" plugin, select "JSON format":


The results are like this:


Much easier to read!!

After that, a little bit of translation from Chinese and manual formatting is still needed to get what I attached here

If @p.kaczmarek2 finds it interesting, I could open a thread with a tutorial for this

Yes, please do, we can send you an Elektroda gadget for doing such tutorial. A guide from start to finish, how to get dpIDs.
Still, keep in mind that it may be also possible to use online JSON formatters/beautifiers

Hello again! I was away for a long time, sorry.
I am very impressed with the great progress!
@morgan_flint Congratulations on your great work, you've worked hard!
@p.kaczmarek2 As always, your help is amazing.

I arrive very late and I see that they have solved practically everything, I don't know if I can contribute anything now... I can only repeat, wow! your work is incredible!

p.kaczmarek2 wrote:

Yes, please do, we can send you an Elektroda gadget for doing such tutorial. A guide from start to finish, how to get dpIDs.
Still, keep in mind that it may be also possible to use online JSON formatters/beautifiers

Done!

A bit long, but I hope it's useful. Anyway, please make any suggestions you may have to improve it. Thanks!