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

Angel0fDeath wrote:

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.

Sure, please do, and maybe open a pull request?

Angel0fDeath wrote:

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...

You just need a HTML hosting, even a static one will work, and then in OBK change web app URL and it should work out of the box.

Quote:

Sure, please do, and maybe open a pull request?

For sure, but will do this with the final script version.
Currently awaiting correct data parsing to the channels, to finalize it.

@p.kaczmarek2 It looks like no development on this issue... I mean raw data parsing, of course

I apologize for the delay, we are currently working on new platform support, namely LN882H.

Regarding the parsing, would you like to get a flexible, scriptable parse system, or just a custom dpType that will fit your device?

The custom hardcoded dpType will be way faster. Here is an example of already existing custom dpType for TAC2121C:

How good is your C knowledge? Maybe we could add a required parser for you together?

@p.kaczmarek2 Parsing - for me it doesn't matter how exactly will be done as long as it works. The most important is that since these are settings after user modifies the values the driver must read them back and set them in device. so this parsing should work forth and back.
Regarding C knowledge - not the best but all my ESP8266 devices (about 10) are running with code written by me.

Hello all!

Angel0fDeath wrote:

The most important is that since these are settings after user modifies the values the driver must read them back and set them in device. so this parsing should work forth and back.

Regarding this, I've tried modifying DPId 17 (Alarm set1, which is shorter than DPId 18 - Alarm set2). The web interface says "Changed channel Alarm set 1 17 to 67174430!" (writing 67174430 on the textfield, with a previous value of 67174480) and, although the textfield stays at 67174430 even after refreshing the page, the settled value in the display stays at 80 mA and the protection doesn't trip with a leakage of 50 mA, so it's not really changing anything.

I tried the same in the other device with a slight difference: the value in the textfield returns to the previous value shortly after the attempt of changing it.

The Tuya App did allow to change the settings with the Tuya firmware, so there must be a way...

@morgan_flint This is because probably not correct set command is issued. To find correct set command for DpID 17 and 18 probably we will need to sniff communication between WB3S and tuyaMCU with original firmware.

Ok, I can do that; I bought the isolators to be able to sniff even if connected to AC, but I think it's not really needed, as that "sniffing" does not require real AC measurements, so it can be done just feeding the board with low voltage DC

@morgan_flint Don't do it. It is again parsing problem:
I was able to set DpID 17 via raw sent command

uartSendHex 55AA00060008110000040401002047 -> this will set DpId to protection on and 32mA leakage current.

EDIT:
The same is valid for DpID 18:

uartSendHex 55AA000600101200000C0101003F030100FA040100AA21 -> all protections on 63A 250V 170V

uartSendHex 55AA000600101200000C0100003203000104040000B426 -> all protections off 50A 260V 180V

You can try it if you want and check settings in the device, but it works

EDIT2:
The good thing is I can send these commands via url. Already tested. And this means I can implement them in alternative html control page.
The driver more or less reads correct DpID17. The only thing we need is to read correct DpID 18....

EDIT3:
@p.kaczmarek2 Is there any way to capture the output from tuyaMcu_sendQueryState via url?
I mean send command via IP/cm?cmnd=tuyaMcu_sendQueryState and to capture the whole output

Tested and also works in the other device, so everything developed here can also be applied to it. Thanks!

@morgan_flint At the moment I'm adding the above to breaker.html. Will post it later when ready.
In the other device DpID's are the same or not? I'm speakin for DpID 17 and 18. Currently I'm using a constant string for these 2 DpID's to set. Changing only the bytes necessary. If DpID's are different should think for somethin else...

Added after 1 [hours] 27 [minutes]:

@morgan_flint Ok. Setting DpID 17 & 18 added to alternative control page (attached).
Don't forget to change IP address, with IP address of your device.
Initial values for settings derived from DpID17 are correct.
Initial values for settings derived from DpID18 are NOT correct since we don't read this correct.

In general we can set all settings, but to verify some of them is possible in device only.
After we find a way to read correct dpID18 will add correct initial setting of these values.

PS: It is also possible to verify settings via web app issuing command tuyaMcu_sendQueryState and checking the raw answer for dpID18.
Enough for today. If you can find some work around to obtain dpID18 reading will incorporate it in html page

@p.kaczmarek2 Now since I am able to set all settings with raw send command, it is only needed to receive data from this channel. Probably the easiest way will be just to convert data array to hex string. Actually type 'raw' for me sounds exactly like this - either receive byte array with values or hex string.

Angel0fDeath wrote:

In the other device DpID's are the same or not? I'm speakin for DpID 17 and 18. Currently I'm using a constant string for these 2 DpID's to set. Changing only the bytes necessary. If DpID's are different should think for somethin else...

Yes, DpID 17 and 18 are the same.

This is a comparative table for both devices' DpIDs:


Until DpID 19 all DpIDs are the same, with a slight difference in DpID 12: on the other device it only clears the prepayment counter, while on this one it clears both energy counters (prepayment and total). Also, DpID 19 is 14 bytes long in this one and just 4 in the other one (content is 45 54 55 39 2D 49 4F 54 2D 57 49 46 49 00, translated to ASCII, "ETU9-IOT-WIFI " for this one and 31 32 33 34 "1234" for the other one). We could try to change these with uartSendHex to see what happens, although, supposedly, it's read-only.

DpID 21 and 101 only exist in the other device; the first one simulates a leakage current test (trips switch for the scheduled time, not very useful in my opinion as it doesn't really provoke a real leakage current, as the test in "hardware" RCDs) and the second one clears the main energy counter.

DpID 104 and 105 are completely different; in this device they set the parameters of overvoltage protection and in the other one they are for power factor and frequency, respectively.

DpID 106 doesn't appear in OBK's logs; in Tuya's logs it appeared occasionally with "app client" as source and "appName:Tuya Smart,ios-packageName:com.tuya.smart,android-packageName:com.tuya.smart,model:2201116SG,os_system:13,app_version:5.7.0. App uid: eu16778378437609KUvs" as content. Not very sure what it represents but not useful for us, I think

Finally, DpIDs 116 to 118 don't appear in any log, but were defined in one of the archives downloaded from Tuya developers page (like the one in the first post of this thread, for DpID descriptions). Probably something that wasn't finally implemented as is redundant with DpID 6 (or maybe not so redundant, as "output" could indicate "export" in this case, because the other device is capable of detecting reverse power in the display, but doesn't report it on DpID 6; in any case, it is not implemented)

@morgan_flint Since I have only this device, lets try first to get all features working, then I can easily adapt for the other device. Can easily change everything in JS script, but to know with which device we deal, I think it is good idea if we read dpID19 - braekerID and to identify with which breaker we are communicating.
At least you can test last version of breaker.html and give feedback. If there are some problems - let me know - will fix them. I can test this only on 1 device while you have a lot

So please test the last revision of breaker.html and give some feedback.

About missing dpID's - if you issue tuyaMcu_sendQueryState do you receive something for these channels (even not mapped in the log you should see something)
Also - Please send tuyaMCU package for the missing dpID's from the log - tuyaMcu_sendQueryState -> full answer, which means even what tuya driver tries to do.
Example:

Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 11 00 00 04 04 01 00 1E 49
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 17, dataType 0-raw and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 67174430
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 12 00 00 0C 01 01 00 3F 03 01 00 FA 04 01 00 B4 2F
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 18, dataType 0-raw and 12 data bytes
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 0E 02 00 04 00 00 13 88 C0
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes

From the above it is clear driver is doing something with dpID17, and it is also clear cannot manage dpID18

Angel0fDeath wrote:

I can test this only on 1 device while you have a lot

Well, just two

Angel0fDeath wrote:

So please test the last revision of breaker.html and give some feedback.

I've been doing some tests and here's some feedback:
- The units for power should be W instead of kW
- Setting the thresholds works perfectly
- Fault status always says "Everything is OK"., regardless of the fault. I've tested leakage, overvoltage, and overcurrent in all possible combinations. These are the results:

Something curious here is that the payload has one or two bytes length, depending on the alarms; they could have chosen a constant length even if the most significant byte was 00... Also, the result for channel 10 only depends on leakage (which belongs to the least significant byte), it doesn't seem to take the most significant one when it exists (overcurrent and/or overvoltage).

Angel0fDeath wrote:

About missing dpID's - if you issue tuyaMcu_sendQueryState do you receive something for these channels (even not mapped in the log you should see something)
Also - Please send tuyaMCU package for the missing dpID's from the log - tuyaMcu_sendQueryState -> full answer, which means even what tuya driver tries to do.

Tried that on the other device; DpIDs 116 to 118 didn't appear in the logs even after sending tuyaMcu_sendQueryState

@morgan_flint Open script with text editor. After IP address is mapping of channels. Check it is as yours in config. If necessary edit and save. Im using channel 9 for fault and not channel 10. Once mapping is corect you can repeat your tests

Done. I hadn't considered that because I had the autoexec.bat you posted some time ago, so I thought we had the same channel settings.

Now it detects correctly leakage, but not the other two alarms. Furthermore, if I provoke the three alarms and then retire leakage, channel 10 stays at 8 and leakage alarm is detected.

I'm afraid it's due to OBK not treating well DpID 9 when its payload changes from one to two bytes, something similar to DpID 17 vs. DpID 18

I see also "Breaker ID" shows as 0:


I have this for DpID 19 in autoexec.bat:

And also tried:

With the same results. This channel shows 0 in both cases, and I can't see its mapping in the script

I rearranged some channels in autoexec.bat depending on they are read only or read-write in order to show read only channels in device control page before read-write channels and without possibility to change them.
About fault - probably you are correct. I tested processing of the fault giving all possible combinations in random order, so I'm pretty sure in processing. However processing process what it reads from fault channel so the problem is probably with this reading...

Added after 1 [hours] 38 [minutes]:

@morgan_flint Breaker ID is always 0 because of the same parsing problem - a lot of bytes in data field of tuya package.
Otherwise mapping for this channel in script is this:
let breaker_id_ch = 0;

All other mappings are following this line.
Attached is my autoexec in order not to have mistakes.

Angel0fDeath wrote:

@p.kaczmarek2 Is there any way to capture the output from tuyaMcu_sendQueryState via url?
I mean send command via IP/cm?cmnd=tuyaMcu_sendQueryState and to capture the whole output

I understand what you're trying to do and it's a good idea in general, but sadly it would be very problematic. This is because TuyaMCU reports all data with delay and we can never ever be sure when it finishes the reporting.

From what I can understand, you're trying to extend the REST page, right?

Your idea is not viable but it gave me another idea. What about storing all TuyaMCU dpIDs as strings and giving the REST API access to them?

That way you would be able to query the OBK via REST page for, let's say, dpID 19 and retrieve it in a form of hex string like "FFAABBCC", etc.

That seems for me like a suprisingly good solution for the issue that have been discussed here for some time already.

I can try adding it for you tomorrow.

What do you think?

@p.kaczmarek2 I think this is a good idea, I mean hex string will do the trick

Here is a self test of this feature:

I think you can already infer the JSON structure from it. It will work both through HTTP and MQTT.

Added after 1 [hours] 12 [minutes]:

Raw type will be shown as hex string:


Added after 2 [hours] 45 [minutes]:

@Angel0fDeath here is a preview, can you check?
https://github.com/openshwprojects/OpenBK7231T_App/pull/1048
You need to enable a flag first.
Then, try executing "Dp" command via HTTP to get JSON

@p.kaczmarek2 I don't see the build on provided link

You need to click on one green ticks, to get build details, a page like this:
https://github.com/openshwprojects/OpenBK7231...tions/runs/7627074885/job/20775034317?pr=1048

Then you need to click "Summary" and scroll down:

Then you will get a zip file:

With all the builds:


Added after 47 [seconds]:

PS: I will add more self tests for this functionality soon

Aha... Thanks. Downloaded it.

@p.kaczmarek2 Hmm. Something wrong. Flag 46 -> enabled
command:
IP/cm?cmnd=Dp -> nothing happens

Web app -> Logs Dp
Info:CMD:[WebApp Cmd 'Dp' Result] Unknown command

MQTT - not tested, since obviously will not get result.

I tried it with my autoexec.bat and with empty autoexec.bat. Same results.

However I noticed even Flag 46 is enabled, in the beginning of flag config page always states;
Flags (Current value=0)

I don't know if this is the reason nothing to happen, but in general this is a bug. It seems you don't set corresponding bit in flags
... or you set it but you have overflow...

Ok, I'm on it, let me check

Added after 1 [minutes]:

BTW:

Angel0fDeath wrote:

I tried it with my autoexec.bat and with empty autoexec.bat. Same results.

I will only work for dpIDs with mappings, even dummy ones

Added after 2 [minutes]:

EDIT:
Hmmm

Yep, work with mappings. It will be easier.

The current flags display seems to be misleading, it reads only first 32 bits:

That's a thing to fix

Well thats definitelly longint overflow. But I don't know how you keep them...

I think I've got it. Wait

Added after 10 [minutes]:

@Angel0fDeath try latest build (please note that the just display of flag numbers is not fixed yet)

Now everything seems ok



Even string dpID 19 shown correct
I can read everything with javascript.

How it is supposed to obtain the same with MQTT?

EDIT: About flags - I don't think printing in web page some longint or 2 longints for flags status brings some important information even for you , unless you are able to perform bitwise operations without pc or calculator. Probably more suitable will be just to print
Current active (or enabled) flags - 1, 21, ..... (for instance)
No one uses all flags and this number in web page speaks nothing, while flag numbers (if printed) give more info and more understandable info.

@morgan_flint Please check on other device also. Will rework alternative html control page during the weekend. Will be out of the town for the next 2 days.