logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

morgan_flint 17418 152
ADVERTISEMENT
Reply Cool? Ranking DIY | New topic
Notify about new articles
  • #61 20925335
    p.kaczmarek2
    Moderator Smart Home  
    I am very happy to hear that it works good for you. It indeed took some time to come up with it but I hope it will be a good solution for extending TuyaMCU devices support.

    As for MQTT, you can execute command again and it will publish this JSON under stat topic, see self test:
    Screenshot from Microsoft Visual Studio showing C code related to MQTT.
    Also remember that you can request only single dpID by doing command like:
    Code: text Expand Select all Copy to clipboard
    
DP23

    This will publish only dpID 23, not the full list.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #62 20925583
    Angel0fDeath
    Level 13  
    @p.kaczmarek2 Ok. I confirm this also works. And of course publishes all 3 fields of json array - id, type and data.
    Since dpId's are mapped it will be better if they are published as before, but taking into account current parsing, i.e. if raw - hex string, if string - string, if value - value. The same valid for device default web control page - if mapped to appear with the correct parsing. Not mandatory, but will be more clean.
    I think, if @morgan_flint confirms this version works on the other device too, you can release it.
  • ADVERTISEMENT
  • #63 20925618
    p.kaczmarek2
    Moderator Smart Home  
    In theory, even the self test on Windows Simulator should be enough to confirm that's working, but practice is always different. For example, here is what I fixed to get it working on BK (and not just on Windows):
    Screenshot showing code differences in the source file json_interface.c in the project.
    Normaly I'd have assumed that all sprintf's should behave in the same way, but somehow, that -1 was getting overwritten on BK even if there was no digits after "DP" string. It's most likely related to our lightweight sprintf replacement...
    Helpful post? Buy me a coffee.
  • #64 20929761
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    I think, if @morgan_flint confirms this version works on the other device too, you can release it.

    I'm trying to reproduce what you did but I'm not very sure of being doing things right...

    First, I followed the instructions here, and then flashed the device OTA with OpenBK7231T_1048_merge_83754a936f15.rbl

    Then, I tried to reproduce what @Angel0fDeath posted here, but got an empty screen:
    Screenshot of browser showing empty result for a URL command.

    What an I doing wrong?
  • #65 20930032
    p.kaczmarek2
    Moderator Smart Home  
    You must enable a flag for this functionality first.
    Helpful post? Buy me a coffee.
  • #66 20930067
    Angel0fDeath
    Level 13  
    @morgan_flint Yep. First enable flag 46, save and if necessary reboot. Then try to issue the command
    Also be sure all dpid's are mapped. OTA update will wipe autoexec.bat. It doesnt matter on which channels dpid's will be mapped. Just need to be mapped. It won't work without mapping. Well probably the type of the channel should also be correct :)

    EDIT: I think this is already included in official release 1.17.425, so you can try with this.

    Quote:
    Changes
    increase MQTT_MAX_QUEUE_SIZE to 32 to support 16 relay devices (1683343)
    Tuyamcu raw access (#1048) (55e2a66), closes #1048
    Assets


    I will try it ...
    Just be sure after flashing you enable corresponding flag and map dpid's via autoexec.bat

    EDIT2: Ok. It works by me. Upgrade to official release v. 1.17.425. Install your autoexec.bat. Enable Flag 46. Reboot.
    Then issue command and should work
  • #67 20931165
    morgan_flint
    Level 14  
    Ok, done on TOMPD-63 WIFI:
    Code: JSON
    Log in, to see the code


    Device view in Home Assistant:
    Screenshot of the OBK application interface displaying device information for BK7231T and switch statuses.

    I'll try on the other device and report here

    (EDIT: added Home Assistant)

    Added after 2 [hours] 49 [minutes]:

    Tested on the other device (TOMPD 63 - LW). Apparently, it works well also:
    Code: JSON
    Log in, to see the code


    The autoexec.bat, cloned from TOMPD63-WIFI except from the different DpIDs:
    Code: text Expand Select all Copy to clipboard
    // 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 LeakageCurrent_div1000
setChannelLabel 5 "Leakage Current"


// Fault - Dpid 9 "fault" - channel 9
linkTuyaMCUOutputToChannel 9 val 9
setChannelType 9 ReadOnly
setChannelLabel 9 "Fault"

// 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 Prepayment"

// Prepaid energy - Dpid 13 "balance_energy" - channel 13
linkTuyaMCUOutputToChannel 13 val 13
setChannelType 13 EnergyTotal_kWh_div100
setChannelLabel 13 "Total Prepaid Energy"

// Charge Prepayment - Dpid 14 "charge_energy" - channel 14
setChannelType 14 textfield
setChannelLabel 14 "Purchased Energy [kWh*100], i.e. 1kWh = 100"
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"

// Test Leakage - Dpid 21 "leakagecurr_test" - channel 21
linkTuyaMCUOutputToChannel 21 bool 21
setChannelType 21 toggle
setChannelLabel 21 "Test Leakage"

// Clear all energy - Dpid 101 "clr_all_energy" - channel 23
linkTuyaMCUOutputToChannel 101 bool 23
setChannelType 23 toggle
setChannelLabel 23 "Clear all energy counters"

// Power factor - Dpid 104 "power_factor" - channel 24
linkTuyaMCUOutputToChannel 104 val 24
setChannelType 24 PowerFactor_div1000
setChannelLabel 24 "Power Factor"

// Grid frequency - Dpid 105 "supply_frequency" - channel 25
linkTuyaMCUOutputToChannel 105 val 25
setChannelType 25 Frequency_div10
setChannelLabel 25 "Frequency"

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

    (uncommented "addRepeatingEvent 5 -1 tuyaMcu_sendQueryState " because it refreshed data less frequently than the TOMPD63-WIFI)

    And the screenshot of OBKs main page:
    Screenshot of the OpenBK7231N interface homepage showing various settings and readings.
  • #68 20931493
    p.kaczmarek2
    Moderator Smart Home  
    So now it's time to come up with some kind of better REST page for the device. Can I help somehow more with that?
    Helpful post? Buy me a coffee.
  • #69 20931905
    Angel0fDeath
    Level 13  
    @p.kaczmarek2 @morgan_flint Better REST page - I'm working on that. Already can read all dpID's and set some of them. I would like to make the REST page independent of channels mapping although dpids should be mapped. Currently dpid 17 & 18 set correct.
    Actually all dpids can be set correct, but some of them are set via SetChannel (so still depending on channel mapping). Will rework this tomorrow...
    Attached are current autoexec.bat and Breaker REST (page rev. 4)
    Changes in autoexec.bat
    1. I rearranged again some channels in order to appear more or less as alternative control page. Original page also shows them in order - from 0 to xxx.
    2. DpID18 remapped on channel6 (to be shown before settings which we can set). The channel is RAW and ReadOnly.
    3. Relay remapped on channel10 to be show before other tolgles, as it is already shown on alternative web page
    4. Dpid17 - remains on channel 17 but map definition changed. Channel is VAL instead of RAW. This way it is possible to change (set) Leakage current protection settings from main page also. Well you will need calculator, but now this is possible.

    Breaker alternative control page:
    1. All dpid's are read by new implemented command Dp and correspondingly the values are set in web page
    2. DpID 17&18 - set via raw uart send command.
    3. All other dpids, which can be set are as before - via SetChannel command.

    IMPORTANT: In order html script to work all dpId's should be mapped and the correct type of channel should be given (for instance I changed dpid17 from RAW to VAL). It doesn't matter on which channels dpid's will be mapped (full support will come tomorrow) but for this release please check Channels mapping in html script. In general I suggest to use attached autoexec.bat.

    @morgan_flint Please give some feedback if something doesn't work correct
    @p.kaczmarek2 As I promised when I finish this REST page will submit it as PR to your repository with full comments inside. Currently comments are just for me and to keep filesize lower... Script is already about 23KB....

    EDIT: In general with attached files everything should work. I just would like to make REST page more independent by setting everything by uart send command.
    Attachments:
  • ADVERTISEMENT
  • #70 20931965
    Angel0fDeath
    Level 13  
    Quote:
    And the screenshot of OBKs main page:
    [BK7231N ] Teardown and flashing of Tomzn TOMPD-63 WIFI (not to be confounded with TOMPD-63LW)


    Probably is good idea to add clearIO command in the beginning of the script. This will clear all previous definitions. Or set these channels manually to Default in web app -> config

    EDIT: Also just tested - dpID19 - Breaker ID - I was not able to change it via uart raw command, so it seems this is read only on my device. However you can try to set this in the other device you have.
  • #71 20932137
    p.kaczmarek2
    Moderator Smart Home  
    That's good to hear, please submit a screenshots from this page as well, and maybe a photo of the device. We could make a separate topic in "Teardowns" section for that, so it's not lost on the fourth page of discussion.
    Helpful post? Buy me a coffee.
  • #72 20932186
    Angel0fDeath
    Level 13  
    @p.kaczmarek2 Photo of the device we already have in post No. 1 in this topic. Photo sent by @morgan_flint

    Here is picture of REST screen:

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

    The above is with all settings ON.
    Usually user don't need settings each time. This is normal load of the page:

    Screenshot of a user interface for a Breaker device.

    But as I said, I would like to make this REST page independent as much as possible from autoexec.bat.
    Will replace tomorrow setting of the rest things which are currently set by SetChannel via raw uart hex string. This way the script will be dependent from autoexec.bat only on mapping and correct type of channels :)

    Added after 11 [minutes]:

    Quote:
    We could make a separate topic in "Teardowns" section for that, so it's not lost on the fourth page of discussion.


    Definitely it is better to make separate topic on that in order not to disappear. We all lost a lot of time working on this issue - me, you, morgan_flint. If you need more info/photos - let me know. As I said, after I finish REST page there will be PR. Tutorial will be inside the code as comments :)

    Added after 8 [minutes]:

    @morgan_flint I'm playing with faults. It looks like there is some internal recovery time in tuyaMCU before next fault can be discovered - i.e. when you simulate fault - wait about 10-15 sec. before simulating next fault. Obviously in real life you cannot have faults so fast and probably this is the reason they don't read the inputs so often.... Don't really sure, but please check and confirm.
    Also on this device, if protection is OFF the device even didn't break the line. In general - now you can set and test everything. Please make full tests.

    Added after 8 [minutes]:

    @p.kaczmarek2 Taking a look at status command answer:
    Code: text Expand Select all Copy to clipboard
     "Status": {
        "Module": 0,
        "DeviceName": "Breaker",
        "FriendlyName": [
            "Main Breaker"
        ],


    According to me DeviceName should return what FriendlyName returns, i.e. they are swapped, but not mandatory since I know this :).
    Should change this also in REST page... Currently I'm working with DeviceName.
    I also don't know why FriendlyName is an array - there are []. Is this really necessary?

    Added after 1 [hours] 3 [minutes]:

    Quote:
    @morgan_flint I'm playing with faults. It looks like there is some internal recovery time in tuyaMCU before next fault can be discovered - i.e. when you simulate fault - wait about 10-15 sec. before simulating next fault. Obviously in real life you cannot have faults so fast and probably this is the reason they don't read the inputs so often.... Don't really sure, but please check and confirm.
    Also on this device, if protection is OFF the device even didn't break the line. In general - now you can set and test everything. Please make full tests.


    @morgan_flint Ok. I've got it. In order to process correct the event when tuyaMCU changes from 1 byte report up to 4 bytes report for dpID9 (fault) this dpID should be of type RAW. Then, at least by me everything is processed ok.

    I'm attaching the corresponding autoexec.bat and Breaker.html rev.5

    Nevertheless please check again with your devices and report.
    Attachments:
  • #73 20932557
    p.kaczmarek2
    Moderator Smart Home  
    I'm not sure about that swap, I will check this out, but it may be late to change now.
    Angel0fDeath wrote:

    Code: text Expand Select all Copy to clipboard
     "Status": {
        "Module": 0,
        "DeviceName": "Breaker",
        "FriendlyName": [
            "Main Breaker"
        ],


    (...)
    I also don't know why FriendlyName is an array - there are []. Is this really necessary?

    This is a good question but I also have a good reply for that. This JSON format was not designed by me, it's just made to mimic Tasmota standard. That's why Tasmota Control/Tasmotrol/Tasmota Remota etc apps are working with OBK:


    Helpful post? Buy me a coffee.
  • #74 20932569
    Angel0fDeath
    Level 13  
    Quote:
    I'm not sure about that swap, I will check this out, but it may be late to change now.


    It is not late to change, if you are asking me - will be more clear.

    About array - probably you are correct, but I don't see any reason DeviceName to be just a string and FriendlyName to be an array. Not so familiar with Tasmota, but can check when have some time...
    Nevertheless I already changed this in my REST page, but I can quickly return to previous

    Main breaker screen (rev. 6) showing device status and information.

    Even added version number... but this (rev 6) will be published tomorrow after everything is ok :)

    Quote:
    This JSON format was not designed by me, it's just made to mimic Tasmota standard. That's why Tasmota Control/Tasmotrol/Tasmota Remota etc apps are working with OBK:


    Is it possible when somebody adapted this to had make a mistake?
    Ok... It doesn't matter if it will be array or not. But I think full name (DeviceName) and short name (FriendlyName) should be swapped. And according to me it is not late - excluding last few revisions of the firmware they were the same (identical)

    Added after 55 [minutes]:

    @p.kaczmarek2

    It looks like you are correct:

    Code: text Expand Select all Copy to clipboard
     "Status": {
        "Module": 0,
        "DeviceName": "IR_TH1",
        "FriendlyName": [],
        "Topic": "IR_TH1",
        "ButtonTopic": "0",


    This device is running version 1.17.379. FriendlyName is again array, but empty. And since Topic is connected with DeviceName - don't change anything
  • #75 20932809
    morgan_flint
    Level 14  
    Wow! I've been away for a while and see I've got some homework pending...
    In the meantime:
    Angel0fDeath wrote:
    Probably is good idea to add clearIO command in the beginning of the script. This will clear all previous definitions. Or set these channels manually to Default in web app -> config

    I've also had that problem (some channels incorrectly set by a previous autoexec, for example), so I created a "resetchannles.bat" with 32 lines like "setChannelType n default". Now I see there was a much more efficient way to do that with just one command... Anyway, it could be a good idea to have a button for that in the web application, for example as in the following picture, to clear all pins or set all channels to default... What do you think?
    Screenshot of a web application form with dropdown lists for channels and a Save Types button.
  • #76 20933390
    Angel0fDeath
    Level 13  
    @morgan_flint Yes it will be better with buttons, but you can always issue clearIO command in logs page or this to be the first command in all your scripts.
    clearIO clears both - pins and channels.

    And yes - you have some homework to do :)
    Sorry, was busy today with other errands and didnt had time to finish html script...
  • #77 20933658
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    @morgan_flint Ok. I've got it. In order to process correct the event when tuyaMCU changes from 1 byte report up to 4 bytes report for dpID9 (fault) this dpID should be of type RAW. Then, at least by me everything is processed ok.

    I'm attaching the corresponding autoexec.bat and Breaker.html rev.5

    Nevertheless please check again with your devices and report.


    Tested and works OK, and apparently I can apply all faults in a brief period without problems in detecting them. This is an screenshot with 3 faults simultaneously:
    Screenshot of ETU9-IOT-WIFI device configuration showing settings and current electrical network values.

    I also could check that Overvoltage Recovery Time does not only affect overvoltage, but also the other protections (couldn't check it with undervoltage, but I imagine it's like that)

    For example, if Overvoltage Recovery Time is set to 5 and an overcurrent or over leakage current condition appears, it waits 5 seconds before reconnecting the switch (three tries and then stays off unless the condition disappears first). For overvoltage, as expected, it'll wait 5 seconds before reconnecting once the overvoltage condition disappears. So, for voltage protection, is effectively a "recovery time", but for leakage and overcurrent it is a "retry delay time".

    On the other hand, Overvoltage Reaction Time doesn't seem to affect the leakage current protection (it trips immediately, regardless of this setting), but it also affects overcurrent, as it waits for the settled reaction time before tripping (same as with overvoltage and, presumably, with undervoltage).

    Regarding the Home Assistant integration, it seems to have still some problems when DpID 09 is longer than one byte, as it shows correctly a value of 8 with leakage current but turns to 0 if I apply simultaneously overvoltage and/or overcurrent. Could this be because of the way this DpID is sent with MQTT?
    Screenshot of an energy management system control panel with device information, controls, and sensor data.

    I also did some experiments with the other device. As DpIDs 104 and 105 have another meaning, I commented out the corresponding lines in your autoexec. The Breaker_rev5.html didn't seem to work well, the measurements were not shown and, regarding protections' settings, it seemed to have a random behavior. I'll make some more tests and report after a second look at the autoexec
  • #78 20933777
    Angel0fDeath
    Level 13  
    @morgan_flint Thanks for your experiments. About Recovery Time - yes it looks like this is applied for all events (at least in this device). Will change the name to just Recovery time.

    About faults - yes no problem, after I changed definition in autoexec.bat from val to raw everything seems to be ok.
    Now about integration in home automation server... All dpIDs with type raw or string should be requested manually, one by one, with command Dp# (# is dpid number). This command will return json which contains dp, type, data. You need only data field for this dpid. You can request only 1 dpid with a single command....

    @p.kaczmarek2 I tried with test device to set everything from autoexec.bat. I wanted to test how command 'flags 0' and command 'SetFlag 46 1' are working (some can forget to set the correct flag, but autoexec can do it). So I set all 46 flags on, saved and rebooted the device. The device now is not responsible and cannot connect to the wifi. I have performed about 10 short reboots to force the device in safemode, I also have implementation of hardware button for long press the device to start in safe mode, but no success.... I have even implementation on double click of hardware button the device to reboot, but no reboot occurs. I think something wrong with the flags is going... And the fault is before autoexec.bat is executed. It is not like someone will set all flags available, but it is possible and I think this is a bug (big one)

    Added after 24 [minutes]:

    Ok. I recovered the device - one of the web pages with web app was still open and responsible although device was not (really don't know how this is possible)... Was able to issue flags 0 command. This command reset all flags except 35, 36, 37, 39, 40, 41, 43, 44, 45, 46. After issuing flags 0 command, the device immediately connected to wifi, ntp server and become responsible (obviously was connected before, but was not able to reach it via device ip address... don't know)...
    After that I cleaned all remaining flags manually. After that I issued command SetFlag 46 1 and it works correct.
    However it looks like there is some problem with these flags.

    Btw - a question a little bit out of the topic, but since Im going to do everything via autoexec.bat - important (not for this device, but in general): If I set pin6 (for instance) via autoexec.bat with SetPinRole 6 Btn, how can I map after that this pin to Channel x?
    Of course I can do this via config page, but if somebody else will use the same autoexec.bat and not familiar with details - autoexec can do for him everything.

    Added after 30 [minutes]:

    Quote:
    I also did some experiments with the other device. As DpIDs 104 and 105 have another meaning, I commented out the corresponding lines in your autoexec. The Breaker_rev5.html didn't seem to work well, the measurements were not shown and, regarding protections' settings, it seemed to have a random behavior. I'll make some more tests and report after a second look at the autoexec


    I will rework the html script for the other device, after everything is ok with this device

    Added after 1 [hours] 32 [minutes]:

    @p.kaczmarek2 About flags: I'm issuing in autoexec.bat flags 0 and then SetFlag 15 1 (these are IR devices; type T are with temp/humidity, type N are just IR)
    Observations:
    On type T devices - flags 36, 37, 39, 41, 42, 43, 46 are always on after manual cleaning, save, reboot and flags 0 in autoexec.bat
    On type N devices - flags 37, 44, 45, 46 are always on after manual cleaning, save, reboot and flags 0 in autoexec.bat

    So it looks like command 'flags' is doing whatever it wants... this week... it is possible next week to do something else...

    EDIT: Tested without issuing command 'flags 0' and manual cleaning of all flags, then save and reboot - everything is ok. The problem is really (according to me) in 'flags' command

    EDIT2: It is very easy to reproduce this error. Clear all flags and save then issue in Logs tab of web app 'flags 0'. Then go again to flags page and check what happened....
  • #79 20943418
    Angel0fDeath
    Level 13  
    @morgan_flint Sorry for the delay with issuing a new version, but I found some errors while testing:
    1. When you set purchased energy in the device, the device remembers this value (dpid 14). After that if you want to use the same value - not possible - you need to change it. Since setting this dpid ADDS the value to dpid 13, I found work around - first set the value of dpid 14 with user input, then reset the value with 0 (automatically) for dpid 14. Can you please test it is the same for you on your both devices
    2. @p.kaczmarek2 - The second thing I encountered is with the web page of the device - when I define 3 toggles (3 buttons) on channels 0, 1, 2 there is a problem with interface - it looks like table in html cannot resolve 3 columns. If these 3 toggles are defined on channels 1, 2, 3 - there is no problem everything looks ok in web page.

    This is a screenshot with 3 toggles on channels 1, 2, 3. On channel 0 is Breaker ID and everything is ok.
    [BK7231N ] Teardown and flashing of Tomzn TOMPD-63 WIFI (not to be confounded with TOMPD-63LW)

    And this is a screenshot with 3 toggles on channels 0, 1, 2 and Breaker ID on channel 3
    [BK7231N ] Teardown and flashing of Tomzn TOMPD-63 WIFI (not to be confounded with TOMPD-63LW)

    Nothing else changed. Just mapping of channels.
  • #80 20944727
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    1. When you set purchased energy in the device, the device remembers this value (dpid 14). After that if you want to use the same value - not possible - you need to change it. Since setting this dpid ADDS the value to dpid 13, I found work around - first set the value of dpid 14 with user input, then reset the value with 0 (automatically) for dpid 14. Can you please test it is the same for you on your both devices

    Yes, I had already noticed that: if you hit "Set!" more than once without changing the value, the prepaid energy counter doesn't change, even if the message "Changed channel Purchased Energy [kWh*100], i.e. 1kWh = 100 to xx!" appears in the screen. But you don't need to set it to 0 before trying again, just changing it for another value works OK; for example, if you load 10 (0,1 kWh) and then 20 (.0,2 kWh), the prepaid energy counter increases accordingly. Only if you want to repeat the same value twice, then you need to set it to 0 before repeating.
  • ADVERTISEMENT
  • #81 20944803
    Angel0fDeath
    Level 13  
    @morgan_flint My idea was after you set it, web control page first set this dpid then automatically reset it to 0. Should I do it?
  • #82 20944976
    morgan_flint
    Level 14  
    Yes, I think it's a good idea, so you don't have to remember the last value you sent in order to send a different one.
  • #83 20945034
    Angel0fDeath
    Level 13  
    In general you don't need to remember last value you used, since it is still present in dpid 14 when you ask for status, but according to me and obviously to you will be better just to reset (set to 0) this dpid after setting dpid13.
    Ok. Will do this.
  • #84 20954679
    Angel0fDeath
    Level 13  
    @morgan_flint Ok. I think this will be the final revision of html script.
    Now the script is fully independent from channels and depends only on dpID's, however dpID's should be mapped. It doesn't matter on which channel, but should be mapped and data type should be correct.
    I'm attaching also my autoexec.bat file - again some rearrangements, but you can use only channel type. Of course I added ClearIO command and even if you use this file everything should work :)
    The script works with dpID's, however the driver functions which script uses are functioning with mapped channels only.

    After a lot of testing, I found out that actually you can use the same value to set dpID14. If there is no prepaid energy set, this command is executed immediately. If some energy is already set, I don't know why, but execution of this command takes few seconds (actually between 3 and 5 seconds). Clear prepaid energy and set for instance 100 (1 kWh). Then use the same value and wait about 5 sec - you will see it works. Now clear again prepaid energy and use the same value - again it works, but immediately. Really don't know what is going, but this is from the device, since I'm setting everything the same way. Finally, I left it as before (without zeroing the input line as we spoke above).
    Please test and give some feedback.
    If everything is ok - will rework the script for your other device.

    Thank you all for the support.
    Attachments:
  • #85 20954945
    morgan_flint
    Level 14  
    I just tested it; everything seems to work ok.

    I think we've commented on this before: When the prepayment is turned off, the device doesn't respond to the "Change channel Purchased Energy" (original OBK web interface).

    As I can see, this field disappears from the web interface in your script when prepayment is turned off, which makes sense as it wouldn't work in that case:
    User interface of the OpenBK7231T device with various current settings and values. OpenBK web interface displaying energy information and settings.
  • #86 20954984
    Angel0fDeath
    Level 13  
    @morgan_flint Yep. Correct. All the logic and limitations implemented in the script (or at least I tried). For instance threshold bars - ranges as per specifications. Prepaid energy hidden if not set etc. Please test again everything. I want to be sure everything is ok, not just by me...

    EDIT: If you have suggestions about design (how page looks) - you are welcome, but such changes... I really hate to design pages, so propose your design in such case (in html format of course) :)

    EDIT1: Probably "prepaid energy" fields is better to be moved at the end of the web page. This can be done easily without you to submit anything :) See attached file. This way there will be no gap, if prepaid is OFF
    Attachments:
  • #87 20955378
    Angel0fDeath
    Level 13  
    @morgan_flint According to me, the last file, I sent, looks better. But you can chose what will be the final version - either 6.0 or 6.1
  • #88 20955709
    morgan_flint
    Level 14  
    Tested version 6.1 and all seems to go OK. I like this one better, but 6.0 is also fully functional.

    Something not related to the script: I see changes in power (DpID6) are only refreshed every 10 seconds (approx). In general, that could be enough, but some applications may require a higher refresh rate in this DpID. Looking at the logs, I see a batch of 7 DpIDs (9-1-6-15-13-12-9, the last one repeated) are effectively sent every 10 seconds, with some "heartbeats" in between. On the other hand, if you force a fault (e.g., leakage), then DpID 9 is sent immediately, which is logical as it's an important issue that may need immediate action (in an automation, for example). Also, turning the relay on or off manually in the device or via web interface triggers this "batch", adding DpID16 twice in this case.

    I understand adding "addRepeatingEvent X -1 tuyaMcu_sendQueryState" forces sending all DpIDs every X seconds, confirmed in the logs, but this might be overkill...

    Is there an instruction to force a more frequent update of just DpID6?

    I tried "addRepeatingEvent 5 -1 tuyaMcu_sendState 6", but it asks for two more args, so I guess this command is to set a DpID, not to ask for its value to be sent, and the documentation also states: "Manually send set state command. Do not use it. Use mapping, so communication is bidirectional and automatic."
  • #89 20955797
    Angel0fDeath
    Level 13  
    @morgan_flint There is no command to ask for just 1 dpID state. Moreover it seems channels are published only if there is a change.
    However you can force channel publishing via MQTT with:
    addRepeatingEvent 5 -1 backlog publishChannel 6; publishChannel 9; etc.

    From your pc or application you can ask for Dp6 only with IP/cm?cmnd=Dp6
    html script uses also the same command, but for all dpID's - IP/cm?cmnd=Dp. html script updates each 1 sec. -> setInterval(getDPIDs,1000)

    EDIT: Although html script updates each 1 sec, it receives current state of the dpID's (just checked). The script doesn't force dpID update, although I can implement this feature (@pkaczmarek2 posted the command below, but I know it), but after that it will be difficult to decide when exactly to start reading updated values, since we never know when TuyaMCU finished with the updates. Sometimes is immediately, sometimes takes few seconds... I also really cannot imagine which application, you are speaking for, can require such refresh rates you are asking for... Is it really necessary to know the state of dpID 6 each second or half second? And if you know this value what actions you will perform? The device is designed to perform all necessary actions and the output information is just... well information, or at least this is my understanding. In general the device will take the necessary actions, if set accordingly, before you even receive the information, regardless updates which you can request even each second or even half second. The script (html) updates each second to be relevant - nobody wants to set the relay and to receive feedback after 5 seconds (for instance)...
    Probably if you share your idea, why you need such high refreshments we can think something...
    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
    The conclusion is: You are not controlling the device. Device informs you what happened. You can only adjust device's settings in order to achieve the best performance from the device. Everything else is just monitoring of the values or device data and logs are helping in issues resolving, if any
  • #90 20955906
    p.kaczmarek2
    Moderator Smart Home  
    Angel0fDeath wrote:
    @morgan_flint There is no command to ask for just 1 dpID state.

    OpenBeken command tuyaMcu_sendQueryState uses Query DP status Tuya packet which is defined in the following way:
    Screenshot of documentation about Tuya DP status query. Table showing the structure of a command sent by the module.
    It queries update of all dpIDs, it is not possible to query a single dp.
    It's just a simple packet without argument:
    Code: text Expand Select all Copy to clipboard
    
55 aa 00 08 00 00 07

    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
    Helpful post? Buy me a coffee.
Reply Cool? Ranking DIY | New topic
Notify about new articles
Report a violation of the law

Topic summary

The discussion focuses on the teardown, firmware flashing, and integration of the TOMPD-63 WIFI smart breaker, distinguishing it from the similar TOMPD-63LW model. Users share experiences with device internals, including LED backlight control, DpID mappings, and firmware behavior. Key technical challenges addressed include parsing and handling of TuyaMCU raw data (notably DpIDs 9, 17, 18, and 19), bidirectional setting of configuration parameters, and fault detection reporting. Solutions involve custom parsing implementations in OpenBK7231T firmware, development of alternative web control pages independent of channel mappings, and enhanced MQTT and REST API support for raw and string data types. The community collaboratively refines autoexec.bat scripts for channel mapping and control, improves fault status decoding, and optimizes prepayment energy counter handling. Firmware updates introduce features like hex string representation of raw data, JSON-formatted DpID queries, and flexible REST commands. Practical aspects such as LittleFS storage limitations for hosting HTML control pages, OTA flashing procedures, and device-specific quirks (e.g., reaction and recovery times for protections) are also discussed. The final outcome includes stable firmware builds, comprehensive control interfaces, and shared resources for both TOMPD-63 WIFI and TOMPD-63LW devices, facilitating advanced home automation integration and device customization.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT