logo elektroda
logo elektroda
X
logo elektroda

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

crash1912 21057 128
ADVERTISEMENT
  • #91 20990133
    ElektrodaBot
    AI OpenAI ChatGPT4
    p.kaczmarek2 wrote:
    How to change this javascript:

    r = data.find(t => t.id == leak_test).data

    to work even if given data point is not found? Handle all possible NULL variables correctly.
    It seems like you're dealing with a situation where you're trying to find an object within an array that matches a specific condition based on the object's `id` property. Your current approach works fine when the object is found, but you're looking to handle cases where the object is not found in a graceful manner.

    Let's analyze the code line you've posted and then discuss how to modify it to handle null variables or cases where the data point is not found.

    Your current line of JavaScript:
    Code: Javascript
    Log in, to see the code

    This line searches through the `data` array for an object where the `id` matches the `leak_test` variable. Once found, it attempts to access the `data` property of that object. There are two potential issues here:

    1. The `find` method returns `undefined` if no matching element is found. Trying to access a property (`.data`) on `undefined` will result in a TypeError.
    2. Assuming the object is found, but its `data` property is undefined or null. You might want to handle this case too.

    To handle these cases, let's break down the solution:

    ### Step 1: Safely Finding the Object

    First, let's safely find the object without immediately accessing its `data` property.

    Code: Javascript
    Log in, to see the code


    ### Step 2: Handling the Case Where the Object is Not Found

    Now, let's handle the case where `foundObject` is `undefined`.

    Code: Javascript
    Log in, to see the code


    ### Step 3: Handling Possible Null `data` Property

    If there's a possibility that the `data` property itself could be `null` or `undefined`, and you want to handle that specifically, you can extend the previous step:

    Code: Javascript
    Log in, to see the code


    ### Putting It All Together

    Combining everything, you get a robust way to handle the potential issues:

    Code: Javascript
    Log in, to see the code


    This approach ensures that you handle cases where the object isn't found in the array, as well as cases where the object's `data` property is null or undefined.

    Do you have any specific conditions or further details about what you'd like to do in each of these error-handling cases? This could help tailor the solution more precisely to your needs.
    You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
  • ADVERTISEMENT
  • #92 20990164
    Angel0fDeath
    Level 13  
    >>20990124

    Hehe... Will try it :)

    Thanks...
    And how can I use this bot in private?

    Added after 15 [minutes]:

    @morgan_flint rev7 works for me perfect. The only change from rev. 6.1 is the script grabs device type and revision number from the file name. Rev7 from the tutorial differs only by more comments inside the file. No code changes. So rev7 should work for 63-WIFI device.
    For 63-LW device - I was able to test up to changing dpID 104 and 105 purpose, since these are presented in my device. I was not able to test what happens with dpID 21 and 101. This is the reason I left r=0 in the script. If searching in dpID array is without result - the script will crash. You can try by uncommenting both r=0 lines and commenting the previous lines. This should work without status of dpID 21 and 101. Then you can try to return dpID 101 and after that dpID 21. As I said the problem according to me is there is no report for dpID 21 in your logs.
    And actually not finding dpID21 in response array was our discussion with @p.kaczmarek2 above... It seems the bot makes perfect analyses :) . Now I must learn how to use this feature :)
  • #93 20990219
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    @morgan_flint rev7 works for me perfect

    Sory, I deleted that post but I'm afraid I was late; after comparing things, I found a type mismatch in the URL (had added "/" at the end :-(). Rev 7 for the other device works perfectly and there were no changes in the autoexec.

    I've just checked that I committed the same error also for this device (I copied the URL from the browser to avoid errors but doing so includes "/" at the end...). So, I repeated the tests with LW and it shows values correctly and toggles the relay ok. I will test the rest of the features and report back
  • #94 20990272
    Angel0fDeath
    Level 13  
    ok. I'm glad there is movement forward :).
    Don't worry about deleted post. I saw it accidentally while I was writing an answer. And after that until I respond you, you deleted it. But don't worry. I'm trying to help.
  • #95 21000410
    Angel0fDeath
    Level 13  
    @morgan_flint Any news on testing?
  • #96 21001731
    njhuiz
    Level 5  
    Close-up of a circuit board with electronic components, including capacitors and an integrated circuit.

    I've just got a brand new device with a colored display. It seems to be the same like the other one on page 2 from November 2023.
  • #97 21001993
    p.kaczmarek2
    Moderator Smart Home
    How is the readability of the display at angles and from the distance?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #98 21002417
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    @morgan_flint Any news on testing?

    Hello and sorry for the delay!

    In general, everything seems to go well, but there are some label/scale errors, as you can see in the following images with the comparison between the standard OBK and the improved one :
    Screenshot of the OpenBK7231N interface with marked areas needing label and scale corrections. Screenshot of the OpenBK7231N user interface with errors in displayed data.
    1: The power factor is wrong by a factor of 10 and should have no units (shows 10 W and should be 1.000 (in the device's display it has 3 decimals, so that must be the real resolution, although 2 decimals could be good enough)
    2: The button labeled "Clr All Counters" in the improved one only clears prepaid energy, so it should be "Clr Prepaid Energy" (the one labeled "Clr All Energy" clears both, so this label is Ok but could also be "Clr All Counters")
    3: Breaker ID in the app was only 1234 (see here). Also, 825373492 that shows in the OBK for that DpID translates to 31 32 33 34 hex so 1234 in ASCII. This must be because this field in this device is half the size of the same one for the other device.
    4: The total energy counter is out by a factor of 10, as it shows 0.015 kWh while in the display is 0.1, and in OBK it shows 0.15. From the DpID value, I think the real resolution is 2 decimals

    Also, OBK interface shows SSID; if it's not too complicated, it would be good to have this also in the improved one, possibly only if "Show settings" is activated. I also see a temperature shown in OBK's interface... @p.kaczmarek2 : Where does it come from? Maybe an internal sensor in BK7231? Because it's not between the DpIDs and, although the Tuya App had a page with 4 temperatures, all of them showed NaN

    Added after 8 [minutes]:

    njhuiz wrote:
    It seems to be the same like the other one on page 2 from November 2023

    Yes, the PCB is exactly the same as mine

    p.kaczmarek2 wrote:
    How is the readability of the display at angles and from the distance?

    In my case, no problems with angles or distance, but a bit difficult to read under direct sunlight (not a common situation, anyway). What I've noticed is some dimming when using the device's buttons, probably because the case presses on the display when pressing them. A bit annoying as this is the situation when you need it more!. I've tried reseating the board into the case with no luck, maybe adding some more length to the buttons by glueing a shim of plastic on top could help, as you won't need to press the buttons so hard.

    In any case, I think the original LCD is better for this application than the colored one, as it's more readable an colors don't add value in this case
  • ADVERTISEMENT
  • #99 21004367
    Angel0fDeath
    Level 13  
    @morgan_flint Ok. Will make the corrections. What about dpID 21. Did you isolated it or now everything is ok?
    Breaker ID - your response (DP command) for this dpid returns "1234("B" (see your previous post). However from raw answer (in the same post) I can see tuyaMCU sends only 31 32 33 34 and then makes integer. This means we have again wrong parsing or maybe not zeroing the array. @p.kaczmarek2 Can you please check this issue?
  • #100 21005072
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    What about dpID 21. Did you isolated it or now everything is ok?

    DpID 21 (test leakage) works well, and also DpID 12 (clear prepaid energy counter).

    However, there is something I don't understand with the behavior of some bool DpIDs with "toggle" type. These are:
    LabelDpIDChannel
    Relay161
    Prepayment112
    Clr Prepaid Energy123
    Test Leakage2121
    Clr All Counters10122

    In OBK's original web interface, all of them, except for the last one, seem to work as expected (change status when clicked). In the case of DpIDs 12 and 21, they only perform the associated action when changing from 0 (red) to 1 (green) and nothing happens in the opposite transition, as we could expect. In the case of the last one (DpID 101), after resetting the device it appears in red but, once clicked, it stays at green forever, but even in this case, clicking on it clears counters as it should.

    In the improved web interface, there's a difference on DpIDs 12 and 21 (Clr prepaid and test leakage), as clicking on them performs the corresponding action but they stay red. I think We commented on this before and it is intentional, as it avoids having to toggle back them to 0 manually. It would be nice a nice feature if they "blinked" to green momentarily, to have visual feedback when clicked, but it's not mandatory.

    DpID 101 "strange" behavior is a bit perplexing; I don't think it's a problem neither in OBK nor in the improved web, but probably a bug in the device's FW... What do you think?
  • #101 21005116
    p.kaczmarek2
    Moderator Smart Home
    morgan_flint wrote:

    I also see a temperature shown in OBK's interface... @p.kaczmarek2 : Where does it come from? Maybe an internal sensor in BK7231? Because it's not between the DpIDs and, although the Tuya App had a page with 4 temperatures, all of them showed NaN

    This is BK7231 internal sensor and it's available on all BK7231 devices.


    Angel0fDeath wrote:
    @morgan_flint Ok. Will make the corrections. What about dpID 21. Did you isolated it or now everything is ok?
    Breaker ID - your response (DP command) for this dpid returns "1234("B" (see your previous post). However from raw answer (in the same post) I can see tuyaMCU sends only 31 32 33 34 and then makes integer. This means we have again wrong parsing or maybe not zeroing the array. @p.kaczmarek2 Can you please check this issue?

    Can you provide more information on the issue or at least tell me which dpType I should investigate?

    Maybe TuyaMCU sends a string without NULL terminating character so I need to add that manually?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #102 21006284
    Angel0fDeath
    Level 13  
    @p.kaczmarek2

    This is part of the answer of Dp command:
    {"id":19,"type":3,"data":"1234("B"}]


    And this is raw tuyaMCU:

    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


    Both taken from earlier post of @morgan_flint
    Definitely tuya sends only the string without termination. The strange is this is ok on the other device, but with this device definitely something wrong
  • #103 21006655
    p.kaczmarek2
    Moderator Smart Home
    Ok, I have added extra NULL terminating character to the buffer:
    https://github.com/openshwprojects/OpenBK7231...mmit/4cfdd1893d01dfc39509bbc648c0928f5121a4e3
    Can you update and recheck?
    Helpful post? Buy me a coffee.
  • #104 21006694
    Angel0fDeath
    Level 13  
    @p.kaczmarek2 I cannot check - don't have such device. By me with 63 WIFI device everything is ok, but the string is longer...

    @morgan_flint must check this!
  • #105 21006715
    p.kaczmarek2
    Moderator Smart Home
    The following problem will appear randomly, depending on the RAM content when the buffer is allocated. The string length does not matter in this case. If the RAM happens to be zeroed just after the allocated string buffer, then string will be displayed correctly. Otherwise some extra random characters will be displayed at the end of the string until the target buffer size runs out or until a NULL byte is hit.
    Helpful post? Buy me a coffee.
  • #106 21006810
    Angel0fDeath
    Level 13  
    @p.kaczmarek2 This is the reason, after dynamic definition of the buffer, one would like to zero it... Something like setmem(buffer, 0). After dynamic definition there could be everything in the buffer.
    The other way is to add after the string #0 after parsing
  • #107 21006997
    p.kaczmarek2
    Moderator Smart Home
    Actually not, doing a memset 0 or in Windows slang ZeroMemory on that buffer would not help in most cases because the old code was allocating only the reported byte length from the TuyaMCU, so there was no space for extra NULL terminating character. In the revised version I posted above, I am manually adding one byte to the buffer length and I am setting that extra byte to 0 to make sure that string is terminated.
    Helpful post? Buy me a coffee.
  • #108 21007021
    Angel0fDeath
    Level 13  
    Understood.
    But still I cannot test it. @morgan_flint should do this, because he has such device...
  • #109 21007376
    morgan_flint
    Level 14  
    Just tested with the latest compiled version of OBK (1.17.509) and the problem is solved:
    Screenshot of the OpenBK7231N user interface with energy settings and values.

    >>21004367
    @angelofdeath, another suggestion for the improved web page, if you consider it right: The box to add purchased energy disappears when "Prepayment" is off:
    Screenshot of the OpenBK7231N interface with visible settings and buttons.
    I understand you did this on purpose, as loading prepaid energy only makes sense if you're using the prepayment function, but I find it interesting to be able to load this counter before switching prepayment on. For example, if you have cleared counters and then switch prepayment on, the relay switches off until you load prepaid energy. In the same situation, with the standard OBK interface, you can load prepaid energy before switching prepayment on, thus avoiding the momentary blackout:
    Screenshot of the OpenBK interface regarding prepaid energy functionality.
  • #110 21007451
    Angel0fDeath
    Level 13  
    @morgan_flint I think, I have read somewhere you cannot set prepaid energy, if Prepaid function is off. Or at least that was the case with the other device. This is the reason the box disappears. Will check this with my device again. But if you are sure with this device you can set prepaid energy I will remove disappearing in this version of the script only.
    Will have time at some point in the afternoon to make all changes.
  • #111 21007466
    morgan_flint
    Level 14  
    Just checked it again and it's possible. I also remember what you said, maybe it's not the case in the other device. I'll connect it and try

    EDIT: Connected the other device (TOMPD63-WIFI) and it's like you say: in OBK's web, with prepayment off the prepaid energy counter won't change even if you send something to DpID 14 (channel 12 stays at 0, while if you send something with prepayment on, this channel would reflect the figure).

    So this modification would be only for TOMPD63-LW. Thanks!!
  • #112 21007508
    Angel0fDeath
    Level 13  
    ok. Will do it for this device only.
  • #113 21045967
    morgan_flint
    Level 14  
    Angel0fDeath wrote:
    ok. Will do it for this device only.

    Hi, @Angel0fDeath
    Some time ago, I was able to correct the scale/label issues, but the visibility seemed more difficult, as I don't know HTML or Javascript...

    But today I decided to give it a try, and I think now it works as I intended. Just modified the condition at the beginning of function Settings_Prepaid_visibility(vis).

    Maybe there's a more efficient way of doing this, but this seemed easier for me...

    I'm attaching it as "rev3prov(isional)", until you give your OK. Thanks again for your work!
  • #114 21100924
    stefanbratu74
    Level 3  
    >>21045967>>21045967
    Can anyone pls post the setup for this module....
  • #115 21101033
    p.kaczmarek2
    Moderator Smart Home
    Hello @stefanbratu74 ! Which module do you have exactly? Have you managed to get 2MB backup and flash OBK there? Have you seen autoexec.bat text on the previous page of this topic?

    Btw, check also our docs: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
    Helpful post? Buy me a coffee.
  • #116 21101080
    stefanbratu74
    Level 3  
    Ok, I start to understand how it works, I just OTA Flash the module and didn't find the settings for it. In the web app if i select the module and press Copy device settings nothing happened. I found the autoexec.bat file https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecs/TOMPD-63-WIFI.bat and after restart it seems to work...
    Thank you for your help
  • #117 21101089
    p.kaczmarek2
    Moderator Smart Home
    So your device is working out of the box with out autoexec.bat? Whoa, that's very nice! Tuya tends to change things often so I expected that we will have to do some adjustments.

    Have you tried our custom HTML page as well?
    Helpful post? Buy me a coffee.
  • #118 21104444
    stefanbratu74
    Level 3  
    Not quite. The device is few years old, I use it until now with localtuya and blocked internet access in router firewall. Recently I found that some resourceful guy(s) managed to break tuya protocol and I tought to give it a try (I'm glad i did). I use it now in HA and it works just fine.
    Thank you and keep up the good work
  • #119 21110386
    sakki143
    Level 2  
    I am looking for the "downloaded data file" (a csv maybe) of Tomzn TOMPD 63-LW. The purpose is to see how frequently the data (voltage, amp, and kwh) is logged.
    It would be much appreciated if someone could update that file here.
    Thanks
  • #120 21110395
    p.kaczmarek2
    Moderator Smart Home
    Hey @sakki143 , are you referring to OBK version? We have raw dpIDs http interface: https://www.elektroda.com/rtvforum/topic4049908.html
    Helpful post? Buy me a coffee.

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