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

Angel0fDeath wrote:

Is it really necessary to know the state of dpID 6 each second or half second?

Not as fast, 5 or even 10 seconds, like this device does, is enough. But 5 minutes, as the other device has, seems too much even for "simple" applications, don't you think?

Angel0fDeath wrote:

Probably if you share your idea, why you need such high refreshments we can think something...

Well, one of my ideas is to implement a device that warns when something called "ICP" is going to trip, also indicating how long it will take to trip. "ICP" stands for "Interruptor de control de potencia" (Power control breaker) and is something implemented in Spanish's smart meters to avoid customers taking more power than they are paying for. But it's not a simple power or current limit, but it has a rather generous inverse time curve so it will trip faster the further you go over the limit. For example, it will allow you to drain 150% of your contracted power during 15 minutes, but if you go to 200% it'll trip in less than 5 min. So I'd like to have some kind of warning (sound, traffic light or the like) that allows to react and turn off something before the meter trips (and somebody start crying because he lost all his work in his computer...). I tink 5-10 seconds update time is enough for this application. I have 9 kW in my contract but have an instant electric water heater of 24 kW (it never reaches full power in normal conditions). Usually, I don't have problems during a shower (let's say 3-5 min), but if I have one or two HVAC units connected at the same time, I probably would have a blackout. A further improvement would be to turn off the air conditioning when power reaches a certain amount, taking into account the inverse time curve or not.

Angel0fDeath wrote:

And if you really need such quick update you can probably consider buying some professional devices... But speaking about professional devices - the only difference probably will be the price and reaction time of the protections. Well reliability also. You will always receive the info with delay... it is always 'post factum' - after event occurs

You're right, but I don't really need that (and less want to pay the price!). Another possibility I'm considering is simply using PZEM-004T module(s) (I have three phase at home) directly connected to an ESP module (already did some experiments with them). Or, maybe, something like this connected to the ESP module via MODBUS (I think OBK doesn't implement it). Of course, the poor documentation doesn't state refresh rate but, if it's like with the PZEM, you send a command and get a response quite fast (I tested them with 1 second and even less).

p.kaczmarek2 wrote:

So, as far as I know, it's not possible to request single DP update. That's a shame, they could very well just allow sending 0x08 command with a single payload byte as argument (dpID) and report only that, but as far as I know, there is nothing like that in Tuya specs

I agree, shouldn't have been very difficult for them to implement it like that, but we'll have to live with it ☹️

@morgan_flint Yep 5-10 sec. update time will be enough. If your heater is operating at full power (24kWh) this will be about 6.7 Ws. Updating each 10 sec will give about 67W difference which according to me is enough accuracy. Of course you can update each 5 sec. also. Even if you have 36 kW connected to the device it is still about 100 W difference for 10 sec. But I think your heater is 3 phases, so you need other device.
For this device - 220V * 63A = 13.86 kW (max), which is about 3.85Ws - update each 10 sec is enough. And this in case you use full power.... There will be no big difference if you make calculation with 240V...

A very cool addition to a device page would be a graph chart. It would have to be, of course, fully clientside, and it would most likely forget the data once you close the page (and it would store the data only as long as the page is open), but it still could be done relatively easily with all the freely available javascript chart libraries that are around here.

Angel0fDeath wrote:

@morgan_flint Yep 5-10 sec. update time will be enough. If your heater is operating at full power (24kWh) this will be about 6.7 Ws. Updating each 10 sec will give about 67W difference which according to me is enough accuracy. Of course you can update each 5 sec. also. Even if you have 36 kW connected to the device it is still about 100 W difference for 10 sec. But I think your heater is 3 phases, so you need other device.
For this device - 220V * 63A = 13.86 kW (max), which is about 3.85Ws - update each 10 sec is enough. And this in case you use full power.... There will be no big difference if you make calculation with 240V...

You are talking about using DpID1 (energy) for this application, but it's also possible to use DpID 6 (power).

For a three-phase system, I'd need something like the three-phase counter I linked in my previous post or, alternatively, three single-phase devices... better without the switch, to avoid unbalance in case of spurious tripping of one or two of them.

Yes, using dpID1 doesn't require very often updates, since changes are not so rapid. Using dpID6, since these are moment values, require more often updates. But you can always take actions at some safety level - for instance if you have moment power over 10kW (or 2 kW, if your heater is on) do something. In this case again 10 sec update should be enough.
You can even limit the breaker by max. current for some period (while your heater is on) and after that to remove limitation. In this case you even not need to know what happens... The device will automatically strip the line if max. current exceeded.

Added after 8 [hours] 46 [minutes]:

Quote:

A very cool addition to a device page would be a graph chart.

@p.kaczmarek2 In general - yes could be done. It is very easy to log the values in memory. However I probably cannot understand the practical reason for this. I can combine all data in lets say 2 graphs, but first you should wait a lot of time to see something on this graphs with incomming data only, and second this will involve loading of some packages from internet (if you dont have them on your pc) - something which I would like to avoid. And third the current idea is you can host this page in device. Im not sure it will be possible to host all graph libraries in the device, although we recently solved such issue.
The main purpose of this page (according to me) is everybody to be able to set the device with desired settings, since firmware currently cannot do it and after that just to monitor the moment values from home automation server where you can issue whatever graphs you want. The intention of this page is not to replace home automation server. Development of this page also shows some alternative ways (work around) to set everything from home automation server. I almost have finished this integration in perl for FHEM. Hassio is written in python and in general can do this also, but Im pretty sure here we have more hassio entusiast which can do this better than me.
You can even set the device from browser or linux command prompt (curl). My script shows how. The way somebody will do it - depends on the choice.
So for now - no graphs. Will finish reworking of the script for the other device. Then will add detail comments. Then you will have the honor to merge them in your Github repository. And then I can focus on other projects, which btw includes my LIST and RTOS delay.
All of us here lost a lot of time working on this device. It is time to say over - now we have all instruments to do whatever we want with the device. Of course if driver includes all these features we dont need alternative control page.
Yes... I know you are alone and this device has only 2M flash... Will try to help as much as I can, but this remainds me something - have you ever considered modular building - for this device we need only tuyamcu driver, ok some device from the same type probably will need ntp driver as well. Why we need the rest 29 drivers in this device? Everybody likes full builds, but when you have only 2M flash probably this should be reconsidered. I have ir blaster with CB2S chip. On this device I use only ir driver. I dont need the rest 30 drivers. Instead of them I preffer larger IR library... But the last comment is another story and probably another topic... Sorry

Angel0fDeath wrote:

Yes... I know you are alone and this device has only 2M flash... Will try to help as much as I can, but this remainds me something - have you ever considered modular building - for this device we need only tuyamcu driver, ok some device from the same type probably will need ntp driver as well. Why we need the rest 29 drivers in this device? Everybody likes full builds, but when you have only 2M flash probably this should be reconsidered. I have ir blaster with CB2S chip. On this device I use only ir driver. I dont need the rest 30 drivers. Instead of them I preffer larger IR library... But the last comment is another story and probably another topic... Sorry

Could a TASMOTA style compile time options be a solution to build only the required libraries?

@jkwim but there already is a TASMOTA style compile time options system:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/obk_config.h

It's just that all public builds are done with the same config.

@Angel0fDeath how's the progress on the page?

p.kaczmarek2 wrote:

@jkwim but there already is a TASMOTA style compile time options system:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/obk_config.h

You are missing ".h". This link works for me:

Quote:

@Angel0fDeath how's the progress on the page?

@p.kaczmarek2 The page for TOMPD-63-LW just posted in corresponding topic

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

For this device there will be no further development since everything is working fine.
Big delay, but was really busy with other errands... Remains only to add comments and to submit both pages on GH repository . Will try to do this tomorrow. For TOMPD-63-LW page must wait @morgan_flint to confirm everything is ok, since I don't have such device

I think a separate topic in Smart Home Tutorials with basic info how to setup it and and how it looks like (screenshots) would be also very useful. Good job.

@p.kaczmarek2 Ok. Will do it... and will try to do it tomorrow

Added after 1 [hours] 50 [minutes]:

@morgan_flint Last change in html file. The only change is I changed the name of the file according to device name. Now the script will take device name and revision number from the filename. It seems now we have a lot of devices which more or less can use this script, so it is mandatory to make a difference between devices... I made corresponding changes in the script for TOMPD-63-LW and EAMPDW-TY63 also. The latter scripts published in corresponding topics

@p.kaczmarek2 @morgan_flint I added comments to last rev7 of html. I would like to ask you, if possible, to review the comments and if something not clear to notify me. According to me everything is clear, but let's not forget I wrote the code, so for me everything is clear...

So, please review it. If necessary will add more comments and after that - ready to publish it in GH and Tutorial Page.
Thank you in advance.

This segment:

could be commented to say that (as I understand it) you can have URL blank when used on LittleFS and enter URL if you are testing on PC.

The rest looks good, however, it could be slightly improved with the new send function that allows for arbitrary payloads and packet types but still calculates the checksum:
https://github.com/openshwprojects/OpenBK7231...mmit/7a9d3df40d4c20cee56ed9bfe4d9927ce44c20c1

Quote:

I think a separate topic in Smart Home Tutorials with basic info how to setup it and and how it looks like (screenshots) would be also very useful. Good job.

@p.kaczmarek2 Done. You can find it here:

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

Added after 2 [hours] 40 [minutes]:

@p.kaczmarek2 Autoexec.bat for this device submitted on GH repository as PR. The folder is docs/autoexecs.

https://github.com/openshwprojects/OpenBK7231T_App/pull/1110

Can't find in which folder to make PR for html file. There is a folder docs/scripts but I find only .bat files there... Can you advise, please?

You are supposed to update the JSON source:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/json/autoexecExamples.json
Then the MD files will be built when I run node scripts/getcommands.js in the repository.

Added after 46 [seconds]:

PS: and autoexec sample should be in separate dir, not in the "docs", but here:
https://github.com/openshwprojects/OpenBK7231T_App/tree/main/docs/autoexecs

autoexec is exactly there, or at least I created it there. For html script - will check now. Thank you.

Hmm... The link with json's you've sent - it looks like it treats only different autoexec.bat files....
Please either write more detailed instructions on how to proceed or just include the attached files....

The linked PR adds autoexec.bat to the docs directory itself, and not to the "autoexecs" dir:

@p.kaczmarek2 Ok. Sorry for that. First time making PR on your site.... Please just add both files I have sent in previous post where necessary. Thank you.

Sure, let me add that for you.
Here's first commit:
https://github.com/openshwprojects/OpenBK7231...mmit/99c9d2a009c347a574e24a1be17802fe7da5a34d
And now here is docs build:
https://github.com/openshwprojects/OpenBK7231...mmit/7e59270362367a95e41796f069c6e1ef3436b0d9
I think it looks good! Can I also add something like "script by Angel0fDeath"? Your work deserves a credit.

@p.kaczmarek2 First - thank you. On your question - you can add whatever you want or you think is appropriate.
However, I think there is something wrong with addition - you added autoexec.bat but html file still not added (according to the links above.

EDIT: After check of GH repository again - autoexec is added to docs/autoexecs and to docs/autoexecExamples - 2 commits which is correct. I cannot find where html file is added...

Angel0fDeath wrote:

However, I think there is something wrong with addition - you added autoexec.bat but html file still not added (according to the links above)

We don't have currently a place for HTML files in that doc repo, that's why it's linked to your article there:
Alternative control html page for TOMPD-63-WIFI
I am not sure how to handle that, where would you suggest adding HTML?

Or maybe I should add that to this repo:
https://github.com/openshwprojects/OpenBekenRESTDemo/tree/main

I think docs/html or docs/htmlExamples will be clear enough.
EDIT: Or something like that... In general you can organise this folder as autoexxecs, but the name will be html. Currently I don't thing you need json for this folder... but who knows... After few weeks probably 2 more html files will be submitted - for the other similar devices, so up to you

hm but that would make this repository obsolete:
https://github.com/openshwprojects/OpenBekenRESTDemo/tree/main
wouldn't it?

Yep. Agree.
But in general what we post - these files this is not a demo - they are working files with the correct device. So I don't think it is correct to call them demo.
From the other point of view - everything could be called DEMO....

I'd like to report that I successfully flashed two TOMPD-63-WIFI smart breakers using the below command:



Both my breakers has the CB3S module instead of WB3S. They also have the backlight mounted under the display but it's disabled (the part with the LED connection to the board is filed down).

The autoexec.bat from the https://www.elektroda.com/rtvforum/topic4040354.html thread works OK. But I have a trouble coping the TOMPD-63-WIFI_rev7.html:



Will try to remove all comments from both files and try again but in the current form this file set seems to be too big.

I've also a problem with the drag-and-drop way to sending files to the device on Linux. Can an alternate way (select a file from disk) be added do the WebApp?

leśny_ziutek wrote:

Will try to remove all comments from both files and try again but in the current form this file set seems to be too big.

From this post and in the new thread opened to continue the discussion about hosting the web app on the device, you can find some considerations about LittleFS size, how to increase it, and how to adapt the block size to make better use of it.

Following the advice there, I was able to host the alternative control HTML page in the device, adapted to GR2PWS, even including an special 7-segment font:


I also removed all the comments from the HTML to save some space. The only problem I've had is the one mentioned here by @p.kaczmarek2 , related to OTA overwriting LittleFS space, but it was solved simply clearing all files and restoring them from a backup

leśny_ziutek wrote:

. Can an alternate way (select a file from disk) be added do the WebApp?

Sure, added:

After removing all comments, empty lines and indentation from both files they fit into standard LiteFS. The file sizes are as below:

/TOMPD-63-WIFI_rev7.html - 20316
/autoexec.bat - 1733

And I found the "Upload file" button that makes my life easier on Linux and also enables using Android phone/tablet to upload files (I couldn't find a way to drag-and-drop anything on Android). Is this button a new feature or somehow I didn't notice it before?

Dodano po 3 [minuty]:

p.kaczmarek2 wrote:

Sure, added:

I thought I hadn't noticed it! Thanks!

morgan_flint wrote:

leśny_ziutek wrote:

Will try to remove all comments from both files and try again but in the current form this file set seems to be too big.

From this post and in the new thread opened to continue the discussion about hosting the web app on the device, you can find some considerations about LittleFS size, how to increase it, and how to adapt the block size to make better use of it.

Following the advice there, I was able to host the alternative control HTML page in the device, adapted to GR2PWS, even including an special 7-segment font:


I also removed all the comments from the HTML to save some space. The only problem I've had is the one mentioned here by @p.kaczmarek2 , related to OTA overwriting LittleFS space, but it was solved simply clearing all files and restoring them from a backup

Neat!