>>21110395 I am referring to the default version of the device having data captured for a few days. I have seen a few videos of unboxing and showing the functionality of this device. I have attached screenshots of the app where this section is mentioned.
>>21358884 Hello, @paoliniluis, and Merry Christmas to all
I don't remember well (it was more than a year ago...), but I've opened it and see that there are remains of having soldered wires to CBU pins 13, 14, 15, and 16 (GND, 3.3V, TX1, and RX1, respectively), so I guess, I powered it from the USB to serial adapter used for flashing it.
I've checked that there are resistors between CBU's RX1 and TX1 and the MCU, so there's little risk of ruining the MCU's TX pin, which could happen if the programmer tries to output a different level than the MCU (it occurred to me with one of my TH08's...).
I'm attaching my actual autoexec.bat for this device:
Added after 17 [minutes]:
@p.kaczmarek2 :
I've found a misfunction in this device after upgrading OBK: voltage and current stopped working, and also the relay switched on by itself after switching off from the web interface.
I noticed this when updating to OpenBK7231N_1.17.808; then went back to previous versions I had in my HD and saw it worked again OK with OpenBK7231N_1.17.769.
Then, I started a dichotomic search to find out which was the version where the error started and found it was OpenBK7231N_1.17.796: with 795 everything went well but, after flashing 796, voltage and current values showed 0 while they were 230 V and 0.08 A with 795 (power was 0 for both, but probably it was because of its low value and/or resolution/rounding in 795).
In Github's releases page, changes for version 1.17.796 states: "support multiple RAW_TAC2121C_VCP channels for devices with 3 phases, etc (6e176a3)", so it seems the changes to RAW_TAC2121C_VCP don't go well for this single phase device... This doesn't directly explain the auto-resetting of the relay but could be a side effect.
This is the part of the autoexec.bat where I call RAW_TAC2121C_VCP, just in case the syntax should be changed to work with ver. 796:
// Measurements - Dpid 6 "phase_a" - channel RAW_TAC2121C_VCP -> 5,6,7
// TAC2121C VoltageCurrentPower Packet
// This will automatically set voltage, power and current
linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP
setChannelType 5 Voltage_div10
setChannelLabel 5 "Voltage"
setChannelType 6 Power
setChannelLabel 6 "Power"
setChannelType 7 Current_div1000
setChannelLabel 7 "Current"
EDIT: Checked it also with TOMPD-63-WiFi, with the same results: Version 1.17.796 showing V, I, P as 0, and reconnecting relay by itself when switching off from the web or even from the device. Version 1.17.795 works OK
There was indeed a bug. I've added a support for multiple VCP dpIDs for 3 phase meters, but the old behaviour of VCP, which was not working before because I forget that channel was unsigned integer. Here is my fix:
https://github.com/openshwprojects/OpenBK7231...mmit/f229e2c2047134b59e1e80c5e5ef3a05a214b62f Can you check whether the old VCP approach (without channel index in command) works again now?
The relay was auto-resetting because device tried to write voltage to channel 0 i guess. Current to 1, power to 2, etc.
>>21363783 Thanks, I'll try the fix ASAP.
I had already found after reading your post here that, if I added the voltage channel to the syntax of RAW_TAC2121C_VCP, in my case:
// Measurements - Dpid 6 "phase_a" - channel RAW_TAC2121C_VCP -> 5,6,7
// TAC2121C VoltageCurrentPower Packet
// This will automatically set voltage, power and current
linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP 5
setChannelType 5 Voltage_div10
setChannelLabel 5 "Voltage"
setChannelType 6 Power
setChannelLabel 6 "Power"
setChannelType 7 Current_div1000
setChannelLabel 7 "Current"
(added 5 at the end of linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP)
Then the problem with the switch dissapeared, and it started showing the correct voltage, but the values for power and current weren't good:
The first image is ver. 795 with "old" autoexec (without channel number at the end), the second, ver. 812 with old autoexec (shows 0 witha ll measurements), the third, ver. 812 with autoexec corrected (shows correct voltage, but higher power and current). The last one is to check if the new syntax works OK with old version (795), which apparently does, but it would be better for the new versions to work without the channel number after "linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP", to avoid having to update the autoexecs after updating versions. All of them are for TOMPD-63WIFI.
I'll check the behavior of the fix with these issues. Thanks again!
Added after 6 [hours] 27 [minutes]:
>>21363783 Ok, tried ver. 813 with the same results as 812...
Ver. 813 with "old" autoexec (without channel number afer linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP) gives 0 for voltage, current, and power, and restarts relay, while adding channel number after it gives correct value for voltage but wrong values for current and power (.4 A instead of .2 and 170W instead of 40; Im using a 40W lamp as load and old versions values match with the device's display), but relay doesn't restart when switching off
It's VCP, as in title, Voltage, Current, Power. You seem to have Voltage, Power, Current order. So Current value goes to Power and Power goes to Current.
>>21365272 True!! 🤦♂️
Its curious that it worked OK with old syntax and that it worked also well with old versions and the same autoexec 🤔
I'll try changing the order of the measurements, but now I'm away from home
CONCLUSIONS: 1.- With the old (single phase) syntax (no number after RAW_TAC2121C_VCP), it seems to put power and current in the corresponding type channel, regardless if channel order is V-C-P or V-P-C.
2.- With the new syntax (ready for multi phase), if V-C-P order is not respected, it shows current in the second channel and power in the third, regardless the channel type.
3.- This behaviour is good, in the sense older autoexecs with bad order will continue to work; in new autoexecs for multi-phase devices, it's not tolerant to errors in the order, so attention should be paid to put channels in the correct one (which shouldn't be a problem).
Many thanks to @p.kaczmarek2 for all his work!
EDIT 2: Just for the sake of testing it, I tried changing also the order of voltage with the "old" syntax. Works perfectly, so the "backwards compatible syntax" for single-phase devices is completely tolerant to channel order:
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.
![[ZIGBEE] 20A Zigbee socket with energy metering (Tuya TS011F_plug_3)](https://obrazki.elektroda.pl/1000454900_1749493372_thumb.jpg)
![[W600 / TW-03] Door Sensor - Bootloop on 1.18.110/109 Firmware](https://obrazki.elektroda.pl/5552096400_1749191730_thumb.jpg)
