logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

crash1912 21057 128
ADVERTISEMENT
Reply Cool? Ranking DIY | New topic
Notify about new articles
  • #61 20864317
    morgan_flint
    Level 14  
    Today I updated to 1.17.356 and I see I have now channel type frequency_div10, so now the displayed frequency is correct:
    Screenshot of an electrical data management interface showing frequency and current channels.

    But leakage current (channel 11) is still bad by a factor of 10, and this is because I have channel type Current_div100 instead of Current_div1000, as it should be. The problem is that if I set that channel as Current_div1000, then it copies the value of channel 4 (which corresponds to the total current and comes from linking Dpid 6 "phase_a" to channel RAW_TAC2121C_VCP):
    Screenshot of an interface displaying voltage, current, energy, and frequency values with a noted issue in leakage current.

    I think this is an issue with RAW_TAC2121C_VCP that, apparently, "hijacks" channel types "Voltage_div10", "Power", and "Current_div1000" for its exclusive use. I had already commented this problem at the end of this post.

    I have seen that there's already a pull request related to this problem, but still not merged.

    Another solution would be to create a new channel type for leakage current, for example, Current_milliamps, but it would be better to solve this "hijacking", as there may be devices that need more than one channel of these types (for example, a three-phase meter, as I said in this post).
  • ADVERTISEMENT
  • #62 20866354
    p.kaczmarek2
    Moderator Smart Home  
    Ok, you have conviced me, I will merge that PR.

    Still, I've also added LeakageCurrent_div1000, in case that's needed

    I will also check this on my side, and then let me know what next is needed
    Helpful post? Buy me a coffee.
  • #63 20867049
    morgan_flint
    Level 14  
    Thank you very much!

    I tested it on the second device I was waiting for (pending its own thread) and it works well, showing the real value for leakage current both with the new type "LeakageCurrent_div1000" and with "Current_div1000" shared with channel 4 but now without "hijacking", as you can see in the following image:
    Screenshot of a software interface for monitoring current and other parameters.

    But when I tested it in the old one, the new type worked OK, but with "Current_div1000" I still have the same problem:
    Screenshot of a user interface for BK7231N device showing current, voltage, power, and frequency values. Screenshot of OpenBK7231N interface displaying various electrical parameters.

    I'm a bit puzzled about it... Could it be because the new device is BK7231T (the old one is N) and the last changes were not included for BK7231N? Or maybe because of the order the channels are set in the autoexec.bat?
  • #64 20869153
    morgan_flint
    Level 14  
    morgan_flint wrote:
    (pending its own thread)

    Done! In case somebody here is interested, here's the link
  • #65 20869241
    p.kaczmarek2
    Moderator Smart Home  
    This is very strange behaviour and there should be no differences between T and N versions. The Current Leakage channel type should work. Can you retry?

    Maybe use the tuyaMcu_sendQueryState command to force-refresh the state?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #66 20869783
    morgan_flint
    Level 14  
    p.kaczmarek2 wrote:
    Maybe use the tuyaMcu_sendQueryState command to force-refresh the state?

    Tried it and still the same...

    To discard any other possibilities, I reset all the types to default, then copied the autoexec.bat from the other device in this one, just adapting the two DpIDs that are different (104 and 105):
    Code: Java
    Log in, to see the code


    But, after rebooting, no luck:
    User interface showing current and voltage values. A widget displaying data on various electrical parameters such as current, frequency, leakage current, power, and more.

    Then, if I change channel 15 type to "LeakageCurrent_div1000"
    Screenshot of a configuration panel with current, voltage, and power readings. Measurement data list from a device showing values like current, frequency, power.

    Then it shows correct values (except for RSSI in Home Assistant, that worked OK in the other device 🤔)

    EDIT: I did another experiment: setting power factor and frequency channels to Current_div1000 shows coherent values (apart from the scale) and their channels (24 and 25) are not overwritten by channel 4, while channel 15 does as soon as I set it to Current_div1000 (2nd image):
    Screenshot of an interface showing electrical parameter readings with values like total energy, voltage, and current. Screenshot of an interface with energy management settings and channels.
  • #67 20869897
    p.kaczmarek2
    Moderator Smart Home  
    It seems we have misunderstood each other. This currently works as expected. This is because you are supposed to use Leakage_Current channel type for leakage...

    Still, if you are referring to this:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/863
    I can accept this pull request, it's just not what I expected users to do.

    And the behaviour should be the same on T and N
    Helpful post? Buy me a coffee.
  • #68 20871101
    morgan_flint
    Level 14  
    p.kaczmarek2 wrote:
    It seems we have misunderstood each other. This currently works as expected. This is because you are supposed to use Leakage_Current channel type for leakage...

    That's OK, I understand LeakageCurrent_div1000 is best suited for leakage but, as is a"val" type DpID (and it's a current, anyway) it should also be possible to use Current_div1000 without interference from another channel (in this case, channel 4 that came from RAW_TAC2121C_VCP). In fact, as per the "experiment" of the last two images in my former post, it seems it's possible to use Current_div1000 with other DpIDs of the "val" type, just the label before the value won't be correct (and the scale, if the divXXX is not what it should be) but, apart from that, the numbers reflect the value of the channel.

    It's just when I try it in the BK7231N device that channel 4 overwrites channel 15, but not others sharing Current_div1000. I've cheched again in the BK7231T device and, in this case, works well (no overwriting):
    User interface screen of OpenBK7231T showing various current and energy parameters. User interface displaying electrical energy data and device configuration options.

    Effectively, it's a very strange behavior, but it doesn't seem to happen only to me, as the author of PR863 seems to have the same problem. If you don't see any collateral effects of accepting it, I could try the result on both devices and see what happens.

    Just made a new experiment with the BK7231T device, changing the last two DpIDs to Current_div1000 with even more puzzling results: They should show 1 and 10 (divided by 1000), but now, sometimes, both copy the value of channel 4 and other times the first one shows the correct value, oscillating between both 😮:
    Screenshot showing a user interface with channel values and set buttons. Screenshot of a device interface showing settings and channel values with incorrect labels.

    I remember seeing the value changing also in the other device, but as I wasn't able to capture it I thought it was my imagination...

    Excuse me for being so fussy with this; both devices can go well without changes just using LeakageCurrent_div1000, but I think it is good for the project to emerge these strange things, just in case they affect more negatively to other devices. Thank you very much!
  • #69 20871205
    p.kaczmarek2
    Moderator Smart Home  
    This is 100% normal because the order of dpIDs sent is not deterministic, so there is a race condition and the winner sets the second current field.

    Still, I've accepted and merged the pull request you linked. Starting from the next release, the VCP special packet will only set the first current channel, i.e. the one with the lowest index.
    Helpful post? Buy me a coffee.
  • #70 20872396
    morgan_flint
    Level 14  
    p.kaczmarek2 wrote:
    This is 100% normal because the order of dpIDs sent is not deterministic, so there is a race condition and the winner sets the second current field

    Ok, I understand now. I thought that, once a DpID was linked to a channel, that was the only possible value for the channel, but I imagine that, in the case of VCP, as no channels are assigned for the three magnitudes, this can't be the case so it relays on the channel type instead.

    p.kaczmarek2 wrote:
    Starting from the next release, the VCP special packet will only set the first current channel, i.e. the one with the lowest index

    I´ll test it as soon as I see it in Github and report here, thanks!
  • #71 20872518
    p.kaczmarek2
    Moderator Smart Home  
    Please backup your autoexec.bat on T platform before you update. We're working to solve the autoexec.bat removed by OTA issue soon, but it's not fixed yet
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #72 20874487
    morgan_flint
    Level 14  
    Tested and works OK on both devices, regarding the overwriting problem when using Current_div1000 in more than one channel. Thanks!

    Effectively, the autoexec.bat was removed after OTA flashing in the T device, but I had the backup ready.
  • #73 20874490
    p.kaczmarek2
    Moderator Smart Home  
    I know that autoexec.bat gets removed, I will fix it later and also maybe add auto-download of LittleFS on OTA?

    I was hesitant to change that Current_Div1000 behaviour because our initial assumption was that "current_smth" channel type is always for current - just current, not leakage, but if it works for you, then I'm happy

    Okay, so remind me please, what's the next step here? What else can I add for you?
    Helpful post? Buy me a coffee.
  • #74 20874558
    morgan_flint
    Level 14  
    p.kaczmarek2 wrote:
    Okay, so remind me please, what's the next step here? What else can I add for you?

    Thank you! I have some suggestions, but I wasn't too sure about putting them out there because I feel like I'm being a bit abusive...

    Anyway, let's start with some of them; they are not things that prevent the device from working correctly, but just possible improvements, so consider them only if you think the same.

    The first one is related to DpID 18 (Alarm set 2), which doesn't show any value in the corresponding channel despite being very similar to DpID 17 (Alarm set 1) which works OK. This is the autoexec.bat section related to both of them:
    Code: Java
    Log in, to see the code


    This is the screenshot for both:

    Screenshot showing incorrect display of values in the Alarm set 2 channel.

    And these are the logs for both DpIDs:
    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 11 00 00 04 04 01 00 5A 85 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 17, dataType 0-DP_TYPE_RAW and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 67174490
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 10 12 00 00 0C 01 01 00 0A 03 01 00 FA 04 01 00 D2 18 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 23 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 18, dataType 0-DP_TYPE_RAW and 12 data bytes
Info:TuyaMCU:TUYAMCU received: 55 AA 03 07 00 08 01 02 00 04 00 00 00 6C 84 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=3]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 1, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 108


    DpID 17 is correctly detected and processed and the "payload" 04 01 00 5A is translated from hex to dec and shown in the web interface as 67174490. DpID 18 is detected but the payload (01 01 00 0A 03 01 00 FA 04 01 00 D2) is not processed, maybe because it's too long. It also gives an error in TuyaMCUAnalyzer, as I reported here.

    The meaning of these DpIDs was explained here.

    Enough for now ;-) ... Will write about the other suggestions in following posts.

    Again, thank you very much for your hard work with OBK!
  • ADVERTISEMENT
  • #75 20874613
    p.kaczmarek2
    Moderator Smart Home  
    So basically you need a dedicated channel type (or driver) that can parse and display this:
    Screenshot showing a data table for DPID 17 and a description of the payload translation.
    (following screenshot is from the post you linked)

    Futhermore, you also need to be able to send the same data to the MCU?
    Helpful post? Buy me a coffee.
  • #76 20874670
    morgan_flint
    Level 14  
    p.kaczmarek2 wrote:
    So basically you need a dedicated channel type (or driver) that can parse and display this:

    That would be ideal, especially for DpID 18 which contains 3 "alarms" and does not give any info now. But if it's too complicated, I could do with the decimal or hex values in both DpIds

    p.kaczmarek2 wrote:
    Futhermore, you also need to be able to send the same data to the MCU?

    This would allow us to set remotely the corresponding protection on or off by toggling the 2nd byte of each protection, and also changing the protection threshold by modifying the last two bytes. I understand the 1st byte, which defines the type of protection (overcurrent, overvoltage, or undervoltage) should not be changed.

    Alarm sets 1 and 2, despite their names, are related to setting protection thresholds (that can be changed in the device) but, when one or more of the thresholds are surpassed, the information comes through DpId 9 (fault), as analyzed here. A driver or channel type for dealing with this would be very interesting!
  • #77 20955698
    Angel0fDeath
    Level 13  
    @morgan_flint Since alternative html control page for the other device TOMPD 63 WIFI is finished and works perfectly, as I promised, will rework it for this device also.
    Can you please post raw answer of tuyaMcu_sendQueryState for dpID 21, 101, 104 and 105. Since I set everything via uartSendHex command, it is much more easier if I have the raw package.
    Also will need the answer of Dp command (IP/cm?cmnd=Dp)
  • #78 20955894
    p.kaczmarek2
    Moderator Smart Home  
    Angel0fDeath wrote:

    Also will need the answer of Dp command (IP/cm?cmnd=Dp)

    Remember that you need to enable a flag for that first:
    Configuration options list with Flag 46 for storing raw data highlighted.
    Helpful post? Buy me a coffee.
  • #79 20956136
    Angel0fDeath
    Level 13  
    I added setflag 46 1 to autoexec.bat in order not to have mistakes :). He is probably using the same autoexec (with minor modifications) for this device since data types should be as on the other device.
  • #80 20956562
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    He is probably using the same autoexec

    Indeed! ;-)

    To avoid different autoexecs causing uncontrolled differences, I adapted your autoexec for the other module to this one. This is what I'm using:
    Code: JSON
    Log in, to see the code


    A slight modification (just the label) on DpID 12, some more on 104 and 105, and added DpID 22 and 101, mapped to channels 21 and 22, respectively. Maybe later I'll reorder the channels to group all "toggles" at the beginning, as you did but, for now, I think it's enough.

    Angel0fDeath wrote:
    Can you please post raw answer of tuyaMcu_sendQueryState for dpID 21, 101, 104 and 105. Since I set everything via uartSendHex command, it is much more easier if I have the raw package.
    Also will need the answer of Dp command (IP/cm?cmnd=Dp)

    Let's start with the second request, as I had some problems with the first; I'm attaching three different outputs, just in case:
    Code: text Expand Select all Copy to clipboard
    [{"id":101,"type":1,"data":0"},{"id":21,"type":1,"data":0"},{"id":105,"type":2,"data":500},{"id":104,"type":2,"data":1000},{"id":17,"type":2,"data":67174490},{"id":14,"type":2,"data":0"},{"id":13,"type":2,"data":400},{"id":18,"type":0,"data":"01010004030100F504000000"},{"id":9,"type":0,"data":0"},{"id":15,"type":2,"data":0},{"id":6,"type":201,"data":"0939000046000000"},{"id":1,"type":2,"data":0},{"id":12,"type":1,"data":0"},{"id":11,"type":1,"data":0},{"id":16,"type":1,"data":1},{"id":19,"type":3,"data":"1234("B"}]

[{"id":101,"type":1,"data":1},{"id":21,"type":1,"data":0"},{"id":105,"type":2,"data":500},{"id":104,"type":2,"data":1000},{"id":17,"type":2,"data":67174490},{"id":14,"type":2,"data":0"},{"id":13,"type":2,"data":0},{"id":18,"type":0,"data":"01010004030100F504000000"},{"id":9,"type":0,"data":0"},{"id":15,"type":2,"data":0},{"id":6,"type":201,"data":"09010010900003D2"},{"id":1,"type":2,"data":0},{"id":12,"type":1,"data":0"},{"id":11,"type":1,"data":0},{"id":16,"type":1,"data":1},{"id":19,"type":3,"data":"1234("B"}]

[{"id":101,"type":1,"data":1},{"id":21,"type":1,"data":0"},{"id":105,"type":2,"data":500},{"id":104,"type":2,"data":1000},{"id":17,"type":2,"data":67174490},{"id":14,"type":2,"data":0"},{"id":13,"type":2,"data":0},{"id":18,"type":0,"data":"01010004030100F504000000"},{"id":9,"type":0,"data":"00000008"},{"id":15,"type":2,"data":0},{"id":6,"type":201,"data":"0929000046000000"},{"id":1,"type":2,"data":2},{"id":12,"type":1,"data":0"},{"id":11,"type":1,"data":0},{"id":16,"type":1,"data":0},{"id":19,"type":3,"data":"1234("B"}]


    Regarding the first request, when I issue "tuyaMcu_sendQueryState", not all the DpIDs appear in the log, 5 (DpIDs 9, 12, 14, 21, and 101) out of 16 are missing. This is an example of what I get with that command:
    Code: text Expand Select all Copy to clipboard
    Info:CMD:[WebApp Cmd 'tuyaMcu_sendQueryState' Result] OK
Info:TuyaMCU:Received: 55 AA 03 07 00 05 10 01 00 01 01 21 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:ParseState: id 16 type 1-bool len 1
Info:TuyaMCU:ParseState: byte 1
Info:TuyaMCU:Received: 55 AA 03 07 00 08 13 03 00 04 31 32 33 34 F5 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:ParseState: id 19 type 3-str len 4
Info:TuyaMCU:ParseState: int32 825373492
Info:TuyaMCU:Received: 55 AA 03 07 00 08 11 00 00 04 04 01 00 5A 85 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:ParseState: id 17 type 0-raw len 4
Info:TuyaMCU:ParseState: int32 67174490
Info:TuyaMCU:Received: 55 AA 03 07 00 10 12 00 00 0C 01 01 00 04 03 01 00 F5 04 00 00 00 3A 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 23
Info:TuyaMCU:ParseState: id 18 type 0-raw len 12
Info:TuyaMCU:Received: 55 AA 03 07 00 08 01 02 00 04 00 00 00 02 1A 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:ParseState: id 1 type 2-val len 4
Info:TuyaMCU:ParseState: int32 2
Info:TuyaMCU:Received: 55 AA 03 07 00 08 0F 02 00 04 00 00 00 00 26 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:ParseState: id 15 type 2-val len 4
Info:TuyaMCU:ParseState: int32 0
Info:TuyaMCU:Received: 55 AA 03 07 00 0C 06 00 00 08 09 23 00 00 46 00 00 00 95 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 19
Info:TuyaMCU:ParseState: id 6 type 0-raw len 8
Info:TuyaMCU:Received: 55 AA 03 07 00 08 68 02 00 04 00 00 03 E8 6A 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:ParseState: id 104 type 2-val len 4
Info:TuyaMCU:ParseState: int32 1000
Info:TuyaMCU:Received: 55 AA 03 07 00 08 69 02 00 04 00 00 01 F4 75 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:ParseState: id 105 type 2-val len 4
Info:TuyaMCU:ParseState: int32 500
Info:TuyaMCU:Received: 55 AA 03 07 00 05 0B 01 00 01 00 1B 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:ParseState: id 11 type 1-bool len 1
Info:TuyaMCU:ParseState: byte 0
Info:TuyaMCU:Received: 55 AA 03 07 00 08 0D 02 00 04 00 00 00 00 24 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:ParseState: id 13 type 2-val len 4
Info:TuyaMCU:ParseState: int32 0
Info:TuyaMCU:Received: 55 AA 03 00 00 01 01 04 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 0 (Hearbeat) len 8
Info:TuyaMCU:Received: 55 AA 03 00 00 01 01 04 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 0 (Hearbeat) len 8
Info:TuyaMCU:Received: 55 AA 03 00 00 01 01 04 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 0 (Hearbeat) len 8


    From the missing DpIDs, I managed to get two in the logs by forcing certain situations; 9 after a fault, and 101 after togging the corresponding channel:
    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:Received: 55 AA 03 07 00 08 09 05 00 04 00 01 00 00 24 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:ParseState: id 9 type 5-bitmap len 4
Info:TuyaMCU:ParseState: int32 65536

Info:TuyaMCU:Received: 55 AA 03 07 00 05 65 01 00 01 01 76 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:ParseState: id 101 type 1-bool len 1
Info:TuyaMCU:ParseState: byte 1 


    Following the same logic as with 101, I tried toggling DpID 12 (clear prepaid energy), setting a value for DpID 14 (charge prepaid energy), and toggling DpID 21 (test leakage). All of them worked as expected, but no info appeared in the logs.

    So, to answer your question, here are the extracted logs for dpID 101, 104 and 105, as I couldn't get anything for 21:
    Code: text Expand Select all Copy to clipboard
    
Info:TuyaMCU:Received: 55 AA 03 07 00 05 65 01 00 01 01 76 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 12
Info:TuyaMCU:ParseState: id 101 type 1-bool len 1
Info:TuyaMCU:ParseState: byte 1

Info:TuyaMCU:Received: 55 AA 03 07 00 08 68 02 00 04 00 00 03 E8 6A 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:ParseState: id 104 type 2-val len 4
Info:TuyaMCU:ParseState: int32 1000

Info:TuyaMCU:Received: 55 AA 03 07 00 08 69 02 00 04 00 00 01 F4 75 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 7 (State) len 15
Info:TuyaMCU:ParseState: id 105 type 2-val len 4
Info:TuyaMCU:ParseState: int32 500


    To end this long post, three curious facts about this device.

    First, as I had mentioned elsewhere, the update period is very long: Every 5 minutes it reports DpIDs 6, 15, 104, and 105, and every 10 minutes, the previous ones and 1, 11, and 13. SO, activating "addRepeatingEvent 5 -1 tuyaMcu_sendQueryState" or something similar is going to be needed.

    Second, once I toggle "clear all energy counters", it changes automatically to "1", even if I try to set it to 0 (channel type toggle or textfield is the same). It's not a problem as it only clears the counters in the transition from 0 to 1, so the counters work well even if DpID 101 is high. This doesn't happen with DpID 12 that performs the same function but only for prepaid energy.

    And third, I managed to capture the following in the logs:
    Code: text Expand Select all Copy to clipboard
    Info:TuyaMCU:Received: 55 AA 03 01 00 40 7B 22 50 22 3A 22 75 30 63 78 6F 78 74 66 65 6C 79 73 33 75 66 78 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 2C 22 6D 22 3A 31 2C 22 6D 74 22 3A 31 30 2C 22 6E 22 3A 30 2C 22 6C 6F 77 22 3A 30 7D CA 
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 1 (QueryProductInformation) len 71
Info:TuyaMCU:ParseQueryProductInformation: received {"P":"u0cxoxtfelys3ufx","v":"1.0.0","m":1,"mt":10,"n":0,"low":0}

    It looks like the same info I had captured on other devices with TuyaMCUAnalyzer, but I don't remember seeing it in the logs, maybe it's simply because it's rarely broadcasted or maybe because it was introduced in a newer version
  • #81 20956599
    Angel0fDeath
    Level 13  
    @morgan_flint Ok. Thanks. I think this is enough. Don't worry about dpID21. We have dpID101:
    101: 55 AA 03 07 00 05 65 01 00 01 01 76
    So I assume 21 will be something like;
    21: 55 AA 03 07 00 05 15 01 00 01 ST CS
    ST- state
    CS - check sum
    It is enough to start reworking the script... of course not right now - it is Sunday evening :)
    I think we will clear everything about dpID21 during testing

    About product information - I don't think this is important. I have seen this to be broadcasted in other device also. The string after 'P' is unicode (UTF-16 probably) and eventually code table is Chinese. However don't know which of them - mandarin, etc.. If you are really interested - you can find it out - you have the capture from tuya developer website, now you need to compare the pictures :) . But really I don't think this is mandatory
    Quote:
    Second, once I toggle "clear all energy counters", it changes automatically to "1", even if I try to set it to 0 (channel type toggle or textfield is the same). It's not a problem as it only clears the counters in the transition from 0 to 1, so the counters work well even if DpID 101 is high. This doesn't happen with DpID 12 that performs the same function but only for prepaid energy.

    In the other device dpID12 as in this device returns back to 0 after set it high. Probably dpID101 makes the same but more time is needed. Don't know.
    Let me rework the script, which is more reliable than native control page and then we ca disscuss
  • #82 20956636
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    It is enough to start reworking the script... of course not right now - it is Sunday evening
    I think we will clear everything about dpID21 during testing

    Perfect!

    Angel0fDeath wrote:
    About product information - I don't think this is important. I have seen this to be broadcasted in other device also. The string after 'P' is unicode (UTF-16 probably) and eventually code table is Chinese. However don't know which of them - mandarin, etc.. If you are really interested - you can find it out - you have the capture from tuya developer website, now you need to compare the pictures . But really I don't think this is mandatory

    I agree, not really needed but, just out of curiosity, the meaning is explained here.

    EDIT: You added this while I was writing:
    Angel0fDeath wrote:
    In the other device dpID12 as in this device returns back to 0 after set it high. Probably dpID101 makes the same but more time is needed. Don't know.

    In this case, it goes to 1 instead of 0 😳. But when it reboots, it's value is 0

    The only difference I see between both in the information extracted from Tuya developer's website (copied at the end of this post) is that DpID 12 indicates "accessMode": "rw", while 101 has "accessMode": "wr"...
    Code: JSON
    Log in, to see the code
  • #83 20956643
    Angel0fDeath
    Level 13  
    One more thing - will use Breaker rev6.1 for this device since you and I like it more :)
  • #84 20988137
    Angel0fDeath
    Level 13  
    @morgan_flint Sorry, for the delay, but was really busy.
    Attached is updated script for this device. The script is based on Breaker_rev.6.1.
    By me everything was ok, until I added dpID 21 and 101.
    Please test and send feedback. If necessary will update the script.

    EDIT: I found small mistake in showing settings. In rev 1 this is corrected. 104 and 105 showing correct because they exist (as per new script - 105 - 10 sec. is shown as 1 Hz; 104 - 120 sec - shown as 1.2 which should be correct for this device). But of course I cannot test dpID 21 and 101
    Attachments:
  • #86 20989793
    morgan_flint
    Level 14  
    Hello, @Angel0fDeath !

    Thank you very much for the updates!

    Unfortunately, I tested both files and none of them works for me :-(

    I'm running it from the HDD, not the device (of course, I changed IP in baseURL)

    I also updated OBK to 1.17.492, just in case, and I'm using the same autoexec posted here

    I'll test now the new version for the other device and report there
  • #87 20989891
    Angel0fDeath
    Level 13  
    @morgan_flint According to me the problem is dpID21 is missing from data which we receive. As per above - you didn't captured status for this dpID.
    However there is a work around in the script.
    Go to line 355 where we try to find the value of dpID21 (leak_test) and comment it. The row is 'r = data.find(t => t.id == leak_test).data;'
    Then uncomment the next line (r=0).
    Then the script should work... without dpID21

    EDIT: If the problem still exists then probably we have a problem with dpID101. The same work around in the script few rows later. Thats how I tested it by me. If I search for something which doesn't exist script fails and almost everywhere I receive values "?". Which should be the case by you

    EDIT1: Even you comment any line as per above recommendations, you should be still able to change dpID 21 or 101. We just will not know the initial status, but we can find some work around :)
  • #88 20990068
    p.kaczmarek2
    Moderator Smart Home  
    Angel0fDeath wrote:
    @morgan_flint According to me the problem is dpID21 is missing from data which we receive. As per above - you didn't captured status for this dpID.
    However there is a work around in the script.
    Go to line 355 where we try to find the value of dpID21 (leak_test) and comment it. The row is 'r = data.find(t => t.id == leak_test).data;'
    Then uncomment the next line (r=0).
    Then the script should work... without dpID21

    I am not sure if I understand correctly, but maybe would it be possible to just check for NULL entry and skip the operation if the data is missing? This would make the script more foolproof.
    Helpful post? Buy me a coffee.
  • #89 20990121
    Angel0fDeath
    Level 13  
    Probably yes, but since this is not my favorite program language must check. I don't have an idea what .find method returns if element not found... And actually up to now everything was clear defined and there was always response. But you are correct. Must put some checks... :)
  • #90 20990124
    p.kaczmarek2
    Moderator Smart Home  
    This may also help with using the script on futher devices.

    @ElektrodaBot
    How to change this javascript:
    Code: Javascript
    Log in, to see the code

    to work even if given data point is not found? Handle all possible NULL variables correctly.
    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 revolves around the TOMZN TOMPD-63-LW Wifi Multi Function power meter, focusing on the integration of OpenBK firmware. Users share experiences with flashing the device, performing UART data capture, and configuring the device for optimal performance. Key features include remote control capabilities, voltage and current monitoring, and customizable protection settings. Users discuss challenges with data extraction, dpID configurations, and the functionality of the device's web interface. Solutions are proposed for issues related to data logging, channel types, and the visibility of certain features in the user interface. The conversation highlights the importance of proper firmware and configuration for achieving desired functionality.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT