Alternative control html page for TOMPD-63-WIFI

Angel0fDeath 04 Mar 2024 13:41 8 4107 Cool? (+4)

📢 Listen (AI):

TL;DR

Alternative HTML control page for TOMPD-63-WIFI automatic circuit breaker/power meter flashed with OBK, aimed at TuyaMCU dpIDs that pack multiple settings into one field.
It uses the Dp command at http://IP/cm?cmnd=Dp to read mapped dpIDs in their correct data types, then drives them from JavaScript, MQTT, or curl.
65536 means the 16th bit is high (“Not enough purchased energy”), while 67174430 dec = 04 01 001E sets leakage protection ON at 30 mA.
The page runs from a PC after editing baseURL, or from http://IP/api/lfs/TOMPD-63-WIFI_rev7.html on the device, but it needs flag 46 and 32K LittleFS.
OTA updates on T devices wipe LFS, so keeping a PC backup of the HTML and autoexec.bat is recommended.

Generated by the language model.

Some TuyaMCU devices combine few settings on single dpID. This doesn't necessarily mean you cannot alter the state of such dpID from OBK web page, but in all cases you will need calculator.
One such device is TOMPD-63-WIFI. This is automatic circuit breaker with power meter capabilities, under- and over- voltage protection, max. current protection, some prepaid functions etc. Of course, the most important is, as the name of the device states, you can control it over WiFi.
I'm not going to explain here how to flash this device with OBK. You can find more info about that here:

https://www.elektroda.com/rtvforum/topic4022907.html

Now, I suppose, you already flashed your device and you have written the correct autoexec.bat file.
If you open device's web page you will land into something like this:

From the screenshot above one can conclude everything is ok. Toggles are responding and the device performs expected functions. If we take a closer look we will discover that not everything is ok. In this case protection reaction time, protection recovery time and purchased energy are shown correct and you can change them. But what should mean channel Fault = 65536, BreakerID = 0, Leakage current protection = 67174430. Undervoltage, overvoltage and max. current - you cannot even set them (in this example I intentionally set this dpID as read only, because in general you really cannot set it from this interface).
Now checking Fault channel and knowing the representation of the Fault we will discover everything is ok, since 65536 corresponds to 2^16, i.e. 16th bit is high and this should say 'Not enough purchased energy'. So everything is ok.
The same is valid for leakage current protection - 67174430 dec = 04 01 001E (hex); 01 - protection is ON; 001E = 30 mA leakage current is allowed. You can even change that - enter 67108896 (04 00 00 20 - protection is OFF and 32 mA leakage current is allowed). You can check settings in the device and you will see everything is ok.

Now comes the question - ok, should I each time calculate everything and more over how I can set the other protections?
The problem here is when more than 1 setting is mapped on a single dpID it is possible to have overflow. TuyaMCU devices are using 32 bit CPU, which means longint is 4 bytes. So if the data of dpID is up to 4 bytes (as we see this in Fault channel and leakage protection channel) you will receive it correct, but you will need calculator to understand and alter these dpID's. If data of certain dpID is more than 4 bytes (like BreakerID and the other protections - OV, UV etc.) - we receive 0 and we cannot alter this dpID.
There are 2 possibilities to solve this issue.
The first possibility is to forward all data to your home automation server. The second possibility is to create alternative control web page. Both ways are using Dp command, kindly implemented by @pkaczmarek2.
The format of the command is:

http:/IP/cm?cmnd=Dp

where IP is IP address of your device.

This will return the state of ALL MAPPED dpID's in the CORRECT DATA TYPE form they are mapped. So raw will return really array of bytes, string will return string etc.

You can issue Dp command via MQTT - home automation (HA) server will process the incoming data, via Javascript - web page or again HA server will process incoming data. You can issue Dp command even through 'curl'.

In this case, I created alternative web page to control this TOMPD-63-WIFI device. Initial purpose was quickly to access device's settings without writing additional modules for integration in my HA server (I'm using FHEM, which is written in Perl and definitely additional module was necessary). Now, I realise you can use this alternative page as an example to create your own module in whatever programming language your HA server understands.

To use this alternative page you need:
1. You successfully flashed your device
2. You have configured it correctly via autoexec.bat. I recommend to use the attached by me autoexec.bat. EDIT: If you are not using my autoexec.bat be sure to SET flag 46 in order Dp command to work!!!
3. To use the script, first open it with text editor (I would recommend Notepad++) from your PC and find baseURL= . Type the IP address of your device. Save, close and double click on the html file. It should open in your default web browser. You can test all functions. Once you have done everything correct, in your browser you should have something like this:

4. After you tested the script from your PC, you probably can consider in hosting the script in the device itself. To do this, first again open the script with text editor. Go to the line where you typed IP address, comment this line and uncomment the line where baseURL is empty, i.e. baseURL="". Now upload html file in device. Web page will be accessible on the following address:

http:/IP/api/lfs/TOMPD-63-WIFI_rev7.html

Please do NOT change filename since the script takes device type and script revision from the filename. Device type and script revision are displayed on the web page.
There are similar devices, so in order to make difference I adopted this concept.

Similar devices are:

TOMPD-63-LW - you can find my modified script for this device here:

https://www.elektroda.com/rtvforum/topic3995777-60.html

@morganflint modified my autoexec.bat to suit this device, so you can find it in the same topic. After he finishes the tests. Both files will be submitted to Github repository.

EAMPDW-TY63 - @njhuiz modified html file and autoexec.bat file for this device. Some tests are in progress. You can find corresponding files in this topic:

https://www.elektroda.com/rtvforum/topic3959907-60.html

Explanations on how autoexec.bat and html script are functioning you can find in the comments inside both files.
Both files will be submitted soon to Github repository to be included as an examples, since these are the most complex files

.

If you decide to host html file in device, take into account that default Little FS is 32K, so hosting html file and autoexec.bat will fill LFS of the device. If you need more space format properly LFS prior to upload the files. It is also recommended to keep backup of the files on your PC, since OTA update on 'T' devices will wipe LFS. Currently OTA updates do not wipe LFS on 'N' devices.

If you are so far to here reading - Thank you for reading and I hope this will be really helpful for you.

Regards

EDIT: If you decide to change html filename please follow the concept: DEVICE-TYPE_revX.html
Subrevisions will not be taken correct currently, so you will need to modify that in the code.
If you decide not to follow the concept - take care to adjust this part of the code or to remove it, if necessary.

Thank you

EDIT 1: I forgot to mention JavaScript is not my first and favorite programming language, so it is possible some experts in Java to find my code writings ridiculous, although I tried to do my best. Will be glad, if such experts can help and optimise the code, if they think it is necessary

Attachments:

TOMPD-63-WIFI_rev7.zip (6.46 KB) You must be logged in to download this attachment.
Breaker_autoexec_20240203.tar (10 KB) You must be logged in to download this attachment.

About Author

Angel0fDeath wrote 118 posts with rating 33 , helped 2 times. Been with us since 2023 year.

Comments

Add a comment

p.kaczmarek2 04 Mar 2024 14:09

Good job, that's a very advanced page. That way we can easily replicate and extend a lot of custom features of TuyaMCU devices without even changing OBK firmware itself. REST interface along with Javascript... [Read more]

Angel0fDeath 04 Mar 2024 14:30

@pkaczmarek2 First, Thank you for the good assessment, but I promised I will do this :) Second - you are correct about REST flexibility. For instance, I don't think it is good idea to create more channel... [Read more]

p.kaczmarek2 22 Mar 2024 10:17

@angel0fdeath is the version in the first post the latest update? Or do you have a newer version of page and autoexec.bat? [Read more]

Angel0fDeath 22 Mar 2024 14:37

@pkaczmarek2 For TOMPD-63WIFI these are the latest versions. There will be new release for TOMPD-63-LW. I will post here the final versions for that device when they are ready and tested. [Read more]

mr_crabs 12 Dec 2025 22:56

Hi everyone! I know it's been a while since the last post here and the device has been already discontinued, but for those still using TOMPD-63, I've created a modernized version of the web interface. What's... [Read more]

divadiow 13 Dec 2025 08:26

wow that looks slick. nice ✅ [Read more]

Angel0fDeath 13 Dec 2025 18:19

@mrcrabs Looks you've done very good work reworking my html script. Html and java script are not my favorits, but about 2 years ago I tried to make it functioning. Feel free to rework and the other... [Read more]

mr_crabs 14 Dec 2025 17:34

Thank you! I'll definitely take a look in my spare time 👍 Yeah, I made the initial skeleton MB a year ago or something but postponed it. Now I need to adjust some "tolerances" from time to time because... [Read more]

FAQ

TL;DR: With a 32K LittleFS limit and “correct data type” access via the Dp command, this FAQ helps OpenBeken users fix TOMPD-63-WIFI controls that OBK shows as raw decimals or 0 by using a custom HTML page or a home-automation parser. [#20989776]

Why it matters: Packed TuyaMCU data makes important breaker protections hard to read or edit unless you bypass the default OBK page.

Option	Where logic runs	Best for	Notable limit
Custom HTML page	Browser or device-hosted page	Fast local control of TOMPD-63-WIFI	LittleFS space is tight at 32K
Home automation server	FHEM, MQTT, or other HA stack	Deeper parsing and automation	Usually needs extra module or scripting
New TypeScript UI	Device-hosted modern web UI	Smaller maintained frontend	Posted for TOMPD-63 after discontinuation

Key insight: The Dp REST command is the practical workaround for packed dpIDs. It returns mapped values in their proper types, so you can decode multi-setting fields outside the firmware. [#20989776]

Quick Facts

OpenBeken receives up to 4 bytes correctly from packed TuyaMCU data because the device uses a 32-bit CPU; longer dpID payloads can appear as 0 in the standard page. [#20989776]
A real example from the thread: Fault = 65536 means 2^16, so the 16th bit is set and indicates “Not enough purchased energy.” [#20989776]
Leakage protection example: decimal 67174430 equals hex 04 01 001E, where 01 means protection ON and 001E means 30 mA. Changing to 67108896 sets protection OFF and 32 mA. [#20989776]
Default OpenBeken LittleFS is 32K, and the author warns that storing both the HTML page and autoexec.bat can fill it on the device. [#20989776]
A later TOMPD-63 web UI rewrite reported a build size of about 19KB, using TypeScript and Vite while preserving the original functions. [#21779258]

How do I create and use an alternative HTML control page for the TOMPD-63-WIFI running OpenBeken?

Create the page by using OpenBeken’s Dp REST output instead of relying on the default OBK widgets. The thread’s author flashed the TOMPD-63-WIFI, prepared a correct autoexec.bat, then built an HTML page that reads and writes packed settings through JavaScript. You can run the page from a PC first, then upload it to the device for local hosting. This approach exposes settings like protection thresholds and prepaid functions that the stock page cannot present cleanly. [#20989776]

Why do some TOMPD-63-WIFI settings show up as large decimal values like Fault = 65536 or Leakage current protection = 67174430 in the OBK web interface?

They appear as large decimals because several settings are packed into one TuyaMCU dpID and OBK shows the raw numeric value. In the thread, Fault = 65536 maps to 2^16, meaning the 16th bit is high. Leakage current protection = 67174430 is raw packed data that decodes to hex 04 01 001E, where 01 means ON and 001E means 30 mA. The value is correct, but it needs manual decoding or a custom parser. [#20989776]

What is a dpID in TuyaMCU devices, and why are multiple settings sometimes packed into a single dpID?

A dpID is the TuyaMCU data point identifier that carries one device state or command, and some devices pack several related settings into one dpID to save structure and transport overhead. “dpID” is a TuyaMCU data-point field that stores or reports device settings, often as raw bytes; on complex breakers, one dpID can bundle multiple protection parameters into a single packed value. That is why one field can contain status flags, thresholds, and enable bits together. [#20989776]

How does the OpenBeken Dp command work for reading mapped dpIDs in their correct data types?

The Dp command queries the device and returns all mapped dpIDs in the data types they were mapped as. The thread gives the format http:/IP/cm?cmnd=Dp. Raw mappings come back as byte arrays, strings come back as strings, and other mapped types keep their intended form. That makes Dp better than the standard page for packed TOMPD-63-WIFI values because your script or server can decode them correctly. [#20989776]

What steps are required to edit baseURL, test the TOMPD-63-WIFI HTML script on a PC, and then host it in LittleFS on the device itself?

Use this 3-step flow.

Open the HTML file in a text editor, find baseURL=, and enter the device IP address.
Save the file, open it in a browser on your PC, and verify that all controls work.
For device hosting, comment the IP-based baseURL line, enable baseURL="", then upload the HTML file so it is served from LittleFS at http:/IP/api/lfs/TOMPD-63-WIFI_rev7.html. [#20989776]

Why do BreakerID, overvoltage, undervoltage, or max current protections return 0 in OBK when their dpID data is longer than 4 bytes?

They return 0 because the packed dpID payload exceeds the 4-byte size that the standard OBK numeric handling can represent here. The author explains that TuyaMCU devices use a 32-bit CPU, so a longint is 4 bytes. Values up to 4 bytes arrive correctly, but longer fields such as BreakerID, overvoltage, undervoltage, and max current overflow the default interface path and show as 0. [#20989776]

What is LittleFS in OpenBeken, and how does its default 32K size affect hosting an HTML page and autoexec.bat on a BK7231 device?

LittleFS is the device file system that stores uploaded files such as HTML pages and autoexec.bat on OpenBeken hardware. “LittleFS” is an embedded flash file system that stores small local files on the device, with a default 32K allocation here that can be exhausted by one HTML control page plus configuration files. The author warns that the default 32K can fill up when you host both files, so you may need to format for more space first. [#20989776]

Which is better for handling complex TOMPD-63-WIFI dpIDs: sending Dp data to a home automation server like FHEM or building a custom JavaScript/HTML page?

Both work, but the better choice depends on where you want the decoding logic. A home automation server like FHEM is stronger for automation and long-term parsing, especially when you already use MQTT or server-side code. A custom JavaScript/HTML page is faster to deploy for local control and avoids writing a dedicated module. The author chose the HTML route first because FHEM is Perl-based and would have needed an extra module. [#20989776]

How should flag 46 be configured in OpenBeken so the Dp command works with the TOMPD-63-WIFI script?

Set flag 46 in OpenBeken if you are not using the author’s provided autoexec.bat. The thread includes an explicit edit: without that flag, the Dp command used by the HTML script will not work as intended. If you use the attached autoexec.bat, that requirement is already covered by the recommended configuration. [#20989776]

What filename format should be used for a TOMPD-63-WIFI custom page, and why does the script expect names like DEVICE-TYPE_revX.html?

Use the format DEVICE-TYPE_revX.html because the script parses the device type and script revision from the filename itself. The author specifically says not to change TOMPD-63-WIFI_rev7.html casually for that reason. Subrevisions are not handled correctly in the current code, so if you change the naming scheme, you must also modify or remove the filename-parsing logic. [#20989776]

How can I decode and modify packed protection values for TOMPD-63-WIFI, such as turning leakage current protection on or off and changing the mA threshold?

Decode the decimal as packed bytes, then change the relevant byte fields before writing the new value back. The thread’s example uses 67174430, which becomes hex 04 01 001E: 01 means leakage protection ON, and 001E means 30 mA. Changing the value to 67108896 gives 04 00 0020, which turns protection OFF and sets the threshold to 32 mA. A calculator or script makes this practical. [#20989776]

What differences between TOMPD-63-WIFI, TOMPD-63-LW, and EAMPDW-TY63 matter when adapting the HTML script and autoexec.bat?

The main difference is that each model needs its own adjusted HTML script and autoexec.bat, even though the devices are similar. The thread says TOMPD-63-LW has a modified script in a separate topic, and EAMPDW-TY63 also has modified HTML and autoexec.bat files with tests in progress. The author mentions three TOMPD-63 variants with small differences, so do not assume one file set fits all three. [#21779800]

How do OTA updates affect files stored in LittleFS on OpenBeken T devices versus N devices?

OTA updates wipe LittleFS on T devices, but the thread says they do not currently wipe LittleFS on N devices. That makes backups important if you host your custom page on the device itself. The author explicitly recommends keeping copies on your PC because an OTA on a T device can erase both the HTML page and autoexec.bat. [#20989776]

What improvements does the newer TypeScript and Vite-based TOMPD-63 web UI add compared with the original HTML/JavaScript version?

The newer UI modernizes the frontend without removing the original functionality. Its author says it is a complete rewrite in TypeScript with a Vite build system, a component-based architecture, and a build size of about 19KB. It preserves real-time monitoring, protection settings, and prepayment mode control, then packages the result for LittleFS deployment from a GitHub release archive. [#21779258]

How can I use REST, MQTT, JavaScript, or curl with OpenBeken to build a custom control panel for TuyaMCU devices without changing the firmware itself?

Use the Dp command as the data source and process the returned values outside the firmware. The thread says you can call Dp over REST, MQTT, JavaScript, or even curl, then decode packed fields in a browser page or home automation server. As one OpenBeken maintainer put it, “REST interface along with Javascript and HTML provides a lot of flexibility,” which is why this method can replicate device-specific features without modifying OBK itself. [#20989827]

Generated by the language model.