I have a few devices using Openbk, They are AT4P power meters with switches using BK7231N Before 1.17 I had no issues but recently updated all to 1.18.21/22/23 and I now have a strange issue. Here is my autoexec.bat Now my two issues are that from a cold boot it now sticks at the QR code on the...

Why do you think that it's related to OBK version? Maybe it's just by coincidence and you need a delay before query update. You may also need to add tuyaMcu_defWiFiState 4 to force paired state for the MCU.

I've been doing a lot of testing but to confirm my results I need to wait until power comes back at my office. But long story short I think it's one of two issues, one issue is I used startDriver tmSensor in my config and another is I used a 'dirty flash backup' as my goto start from tuya image (restore image). Anyway I still need to test on three known units with the issues but my home unit seems to be fine with removing tmsensor and adding wifistate To clarify my country has a power problem and these units are on incoming mains power and power is 100% random so I have to be lucky to be day available time power and I can work on them. I recently dumped the firmware from another Tuya device (mcu side not wifi) and I think I can do the same here so I just need to confirm the fixes then I can then attempt fw dump darkspr1te Added after 2 [hours] 41 [minutes]:ok issue was I kept using 'startDriver tmSensor' in my configs thinking it was needed and that would cause random protocol issues and when I went from v1.15 to v1.17 the configs would be the same buuut if I then went to v1.18.21 it would use a diff mem location and have the old config with startDriver tmSensor in it. I will do a write up to explain my mistake and the bug soon but it's resolved now and am going for food and sleep. darkspr1te

tmSensor is only for Tuya Battery-Powered devices, like a Door Sensor, or a Humidity Sensors, these are powered by like 3 AAA batteries, etc. Don't ever use it for devices powered from mains.

AT4P Power Meters with BK7231N: Issues After OpenBK 1.18.00 Update

crg1darkspr1te 342 3

Reply | New topic

#1 21406037 23 Jan 2025 12:06

crg1darkspr1te crg1darkspr1te

Level 8

Post #1
21406037 23 Jan 2025 12:06

I have a few devices using Openbk, They are AT4P power meters with switches using BK7231N

Before 1.17 I had no issues but recently updated all to 1.18.21/22/23 and I now have a strange issue.
Here is my autoexec.bat

Quote:

startDriver TuyaMCU
startDriver tmSensor
startDriver NTP
ntp_setServer 192.168.10.1

tuyaMcu_setBaudRate 115200
tuyaMcu_sendQueryState
setChannelType 1 toggle
setChannelType 2 Voltage_div10
setChannelType 3 Power
setChannelType 4 Current_div1000
setChannelType 5 Frequency_div100
setChannelType 6 ReadOnly
setChannelType 7 Temperature
setChannelType 8 ReadOnly
setChannelType 9 ReadOnly

//ch 1 (dpid 1) power relay control
linkTuyaMCUOutputToChannel 1 bool 1
addChannel 1 1
//ch 2(dpid 20) voltage
linkTuyaMCUOutputToChannel 20 1 2
//ch 3(dpid 19) power watts
linkTuyaMCUOutputToChannel 19 1 3
//ch 4 (dpid 18)current Amps
linkTuyaMCUOutputToChannel 18 1 4
//ch 5 (dpid (133) frequency
linkTuyaMCUOutputToChannel 133 1 5
//ch 6 (dpid 102) energy cost used
linkTuyaMCUOutputToChannel 102 1 6
// ch 7 (dpid 135) temp
linkTuyaMCUOutputToChannel 135 1 7
//ch 8 (dpid 134) power factor
linkTuyaMCUOutputToChannel 134 raw 8
//ch 9 (dpid 123) energy consumed
linkTuyaMCUOutputToChannel 123 1 9

tuyaMcu_sendQueryState

Now my two issues are that from a cold boot it now sticks at the QR code on the lcd even though it does connect to the wifi network and it also does not report this back to the tuya MCU fully as it is reporting rssi but not that it's connected, I have to manually press the change screen button whereas before as soon as openbk reported the rssi it would display the main screen. The second issue is it won't report the data back until I either manually run the command tuyaMcu_sendQueryState or do a warm reset of the openbk side and then it starts reporting and after a while it switches the lcd display.

Now another odd thing is that restoring back to 1.17.00 does not restore the correct function, only restoring original tuya f/w then flashing openbk 1.17 will it auto start the lcd and reporting functions.

Any ideas, what logs should I post ?

darkspr1te

Added after 23 [minutes]:

Ok i am just guessing here at the moment, but i suspect the TuyaMCU is reporting to the obk device and expecting info back before it it send any more data.
I think this as in the boot log is this section

Quote:

Info:MAIN:Main_Init_Before_Delay
Info:CFG:####### Boot Count 101 #######
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 14 changes count.
Error:CMD:no file early.bat err -2
Info:GEN:PIN_SetupPins pins have been set up.
Info:MAIN:Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay
Info:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:Using SSID [fsshome]
Info:MAIN:Using Pass [67p1nf0ld]
Info:MQTT:MQTT_RegisterCallback called for bT obk_1FB200001/ subT obk_1FB200001/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/obk_1FB200001/ subT cmnd/obk_1FB200001/+
Info:MQTT:MQTT_RegisterCallback called for bT obk_1FB200001/ subT obk_1FB200001/+/get
Error:CMD:cmd tuyaMcu_sendQueryState NOT found (args )
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Started TuyaMCU.
Info:MAIN:Started tmSensor.
Info:NTP:NTP driver initialized with server=192.168.10.1, offset=0
Info:MAIN:Started NTP.
Info:NTP:NTP server set to 192.168.10.1
Info:GEN:Channel 1 type changed to toggle
Info:GEN:Channel 2 type changed to Voltage_div10
Info:GEN:Channel 3 type changed to Power
Info:GEN:Channel 4 type changed to Current_div1000
Info:GEN:Channel 5 type changed to Frequency_div100
Info:GEN:Channel 6 type changed to ReadOnly
Info:GEN:Channel 7 type changed to Temperature
Info:GEN:Channel 8 type changed to ReadOnly
Info:GEN:Channel 9 type changed to ReadOnly
Info:GEN:CHANNEL_Add channel 1 has changed to 1

Info:GEN:CHANNEL_Set channel 1 has changed to 1 (flags 0)

Info:MQTT:Channel has changed! Publishing 1 to channel 1
Info:MAIN:Time 1, idle 255353/s, free 77016, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:TuyaMCU:Received: 55 AA 03 01 00 2A 7B 22 70 22 3A 22 74 6A 74 69 67 67 39 39 31 6B 76 6F 69 69 71 69 22 2C 22 76 22 3A 22 31 2E 30 2E 34 22 2C 22 6D 22 3A 30 7D 1B
Info:TuyaMCU:ProcessIncoming[v=3]: cmd 1 (QueryProductInformation) len 49
Info:TuyaMCU:ParseQueryProductInformation: received {"p":"tjtigg991kvoiiqi","v":"1.0.4","m":0}
Info:MAIN:Time 2, idle 185449/s, free 77016, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 3, idle 190583/s, free 77016, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 4, idle 188195/s, free 77016, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 5, idle 188093/s, free 77016, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:WiFi SSID: waiting for SSID switch 1/3 (using SSID1)
Info:MAIN:Registered for wifi changes
Info:MAIN:Connecting to SSID [fsshome]
Info:MAIN:ssid:fsshome key:gfhgfhfghfghgfhgf
Info:MAIN:Time 6, idle 181366/s, free 71120, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Boot complete time reached (5 seconds)
Info:CFG:####### Set Boot Complete #######

so it seems it receives the QueryProductInfo command and does nothing more in terms of comms to the TuyaMCU until i re-run the command tuyaMcu_sendQueryState or warm reset the obk device which seems to kick the TuyaMCU out of it's wait state.
could the obk devie be replaying to the query state command too fast or not at all on a cold boot ? as i mentioned this only happens in a cold boot from mains power on, if i reboot the OBK device after mains has been restored it will function as expected.

Added after 11 [minutes]:

Ok,
Problem solved for the voltage/freq updating,
I added to autoexec.bat and now it reports voltage/frequency etc back to the obk device from cold boot. i have not yet sorted the lcd switching option yet as it still displays the QR code and not current stats as it used too. I still manually have to swap pages.
Quote:

addRepeatingEvent 10 -1 tuyaMcu_sendQueryState
ADVERTISEMENT
#2 21406685 23 Jan 2025 19:16

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

Post #2
21406685 23 Jan 2025 19:16

Why do you think that it's related to OBK version? Maybe it's just by coincidence and you need a delay before query update.

You may also need to add tuyaMcu_defWiFiState 4 to force "paired" state for the MCU.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT
#3 21417503 30 Jan 2025 22:22

crg1darkspr1te crg1darkspr1te

Level 8

Topic author Helpful post? (0)

Post #3
21417503 30 Jan 2025 22:22

I've been doing a lot of testing but to confirm my results I need to wait until power comes back at my office. But long story short I think it's one of two issues, one issue is I used startDriver tmSensor in my config and another is I used a 'dirty flash backup' as my goto start from tuya image (restore image). Anyway I still need to test on three known units with the issues but my home unit seems to be fine with removing tmsensor and adding wifistate

To clarify my country has a power problem and these units are on incoming mains power and power is 100% random so I have to be lucky to be day available time power and I can work on them. I recently dumped the firmware from another Tuya device (mcu side not wifi) and I think I can do the same here so I just need to confirm the fixes then I can then attempt fw dump

darkspr1te

Added after 2 [hours] 41 [minutes]:

ok issue was I kept using 'startDriver tmSensor' in my configs thinking it was needed and that would cause random protocol issues and when I went from v1.15 to v1.17 the configs would be the same buuut if I then went to v1.18.21 it would use a diff mem location and have the old config with startDriver tmSensor in it. I will do a write up to explain my mistake and the bug soon but it's resolved now and am going for food and sleep.

darkspr1te
#4 21418023 31 Jan 2025 07:55

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

Post #4
21418023 31 Jan 2025 07:55

tmSensor is only for Tuya Battery-Powered devices, like a Door Sensor, or a Humidity Sensors, these are powered by like 3 AAA batteries, etc. Don't ever use it for devices powered from mains.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Create an account, log in and become active in a forum and ads will not appear. You will receive points by participating in discussions.
Join this discussion.

Install the application

Didn't find an answer? Ask Artificial Intelligence

*I agree to send the question to OpenAI, Anthropic PBC, Perplexity AI, Inc., Kagi Inc., Google LLC - owners of language models in order to prepare the best response. The companies may monitor and log information entered into the form.

*I agree to publicly display my question and answer. The question and answer will be publicly available to everyone. The process may take a few minutes. Upon completion, you will be redirected to the page with the answer.

Wait...(2min)

Reply | New topic

Report a violation of the law

Home page
/
Forum
/
Smart Home
/
Smart Home IoT
/
AT4P Power Meters with BK7231N: Issues After OpenBK 1.18.00 Update

AT4P Power Meters with BK7231N: Issues After OpenBK 1.18.00 Update

Didn't find an answer? Ask Artificial Intelligence