OpenBeken 1.18.288 TuyaMCU dpID 1052 zero MQTT energy on BK7231TN

Description:I am using a TuyaMCU-based smart energy meter with the latest OpenBeken build (1.18.288). Many TuyaMCU devices report a "0" value for Total Energy (dpID 105/2) for several seconds after a power cycle or reboot before the real value is synchronized from the MCU.
The Problem:This initial "0" is immediately published to MQTT and, if persistence is not available or scripts fail, it overwrites the cumulative energy data in Home Assistant, causing massive negative spikes in Energy Dashboards.
Proposed Solution:
Internal Filter: Implement a flag or setting for linkTuyaMCUOutputToChannel that ignores "0" values if the previous known value was higher than zero.
Persistence improvements:
Ensure that even on builds where setChannelPersistence is missing, the energy driver can maintain the last known value during the boot-up handshake with TuyaMCU.Consistent
Scripting: Ensure that addChangeHandler with conditional logic (e.g., if $CH5 < $CH10) is supported across all builds, including those with limited memory.
Device Info:Build: May 3 2026 13:32:48 version 1.18.288Chip: BK7231 (T/N)
What is the exact brand/model of the TuyaMCU energy meter (or the Tuya product/module ID), and can you confirm whether this happens on every reboot/power cycle or only on this specific device?
I am using a WVC Microinverter (equipped with a CBU IPEX module, BK7231N) running OpenBeken version 1.18.288. Because this is a solar device, it power-cycles frequently (every morning or during low light).
Can you post the relevant OpenBeken config/script and a short boot log or MQTT trace showing dpID 105/2 publishing 0 first and then the real total energy value (including your linkTuyaMCUOutputToChannel / addChangeHandler setup, if any)?


00:00:01 - Device starts, NTP syncs.
00:00:03 - TuyaMCU driver sends first update:
Info:TuyaMCU:Processing DP 105 (Type 2): Value 0
Info:MQTT:Publishing val 0 to mi_sklad_back/5/get retain=1 <-- THIS IS THE PROBLEM
00:00:08 - TuyaMCU finally syncs real internal memory:
Info:TuyaMCU:Processing DP 105 (Type 2): Value 15420
Info:MQTT:Publishing val 154.20 to mi_sklad_back/5/get retain=1

Maybe we could add a simpler solution - add a basic "warm up time" during which TuyaMCU values are not published? Like first 15 seconds or something, configurable.

>>21899550
Yes, making the warm-up time configurable is definitely better. Some WVC inverters might need only 10 s, but others could take longer to stabilize. A command like tuyaMcu_setWarmUpTime [seconds] would be perfect so users can adjust it based on their specific hardware.

Hm, perhaps move linkTuyaMCUOutputToChannel for 105 dpId to the end, and add delay_s 8 before it?

>>21899606 >>21899606
Delay linkTuyaMCUOutputToChannel 2 2 5 didn't work.
This works: delay_s 15 startDriver MQTT

stopDriver MQTT
startDriver TuyaMCU
startDriver NTP
tuyaMcu_setBaudRate 115200
tuyaMcu_defWiFiState 4

setFlag 10 1
setFlag 29 1

MqttClient mi_sklad_back
ShortName mi_sklad_back

linkTuyaMCUOutputToChannel 101 1 1
linkTuyaMCUOutputToChannel 102 2 2
linkTuyaMCUOutputToChannel 103 2 3
linkTuyaMCUOutputToChannel 18 2 4
linkTuyaMCUOutputToChannel 2 2 5
linkTuyaMCUOutputToChannel 105 2 6

setChannelType 1 Toggle
setChannelType 2 Power_div10
setChannelType 3 Power_div10
setChannelType 4 Temperature
setChannelType 5 EnergyTotal_kWh_div100
setChannelType 6 Dimmer

setChannelLabel 1 "Switch"
setChannelLabel 2 "Power DC"
setChannelLabel 3 "Power"
setChannelLabel 4 "Temperature"
setChannelLabel 5 "Total energy"
setChannelLabel 6 "Limit %"

delay_s 15

startDriver MQTT

What's going on? We don't have "startDriver MQTT", this does nothing.

>>21900081
Hi everyone,

You were right, startDriver MQTT is indeed not a valid command in my build and it was throwing an error in the logs. I have removed both the stopDriver and startDriver lines from my autoexec.bat.

It turns out that the solution was much simpler: a plain delay_s 15 at the end of the script was enough.

Why it works:
The delay provides enough time for the TuyaMCU to communicate with the Wi-Fi chip and populate the channels with real sensor data (Power, Energy, Temperature) before the system finishes its startup routine and initiates the MQTT connection. By the time the MQTT client connects to the broker, the "zero" values in the RAM have already been overwritten by actual data from the MCU.

Here is my simplified, working autoexec.bat:
startDriver TuyaMCU
startDriver NTP
tuyaMcu_setBaudRate 115200
tuyaMcu_defWiFiState 4

setFlag 10 1
setFlag 29 1

MqttClient mi_sklad_back
ShortName mi_sklad_back

linkTuyaMCUOutputToChannel 101 1 1
linkTuyaMCUOutputToChannel 102 2 2
linkTuyaMCUOutputToChannel 103 2 3
linkTuyaMCUOutputToChannel 18 2 4
linkTuyaMCUOutputToChannel 2 2 5
linkTuyaMCUOutputToChannel 105 2 6

setChannelType 1 Toggle
setChannelType 2 Power_div10
setChannelType 3 Power_div10
setChannelType 4 Temperature
setChannelType 5 EnergyTotal_kWh_div100
setChannelType 6 Dimmer

setChannelLabel 1 "Switch"
setChannelLabel 2 "Power DC"
setChannelLabel 3 "Power"
setChannelLabel 4 "Temperature"
setChannelLabel 5 "Total energy"
setChannelLabel 6 "Limit %"

delay_s 15

Delay_s 15 at the end of autoexec.bat does nothing. Script is run like a separate thread, MQTT starts on it's own without script. Where are you getting false info from? Sounds like you're being mislead by ChatGPT.