Opis:Używam inteligentnego licznika energii opartego na TuyaMCU z najnowszą kompilacją OpenBeken (1.18.288). Wiele urządzeń TuyaMCU zgłasza wartość "0" dla całkowitej energii (dpID 105/2) przez kilka sekund po cyklu zasilania lub ponownym uruchomieniu, zanim rzeczywista wartość zostanie zsynchronizowana z MCU.
Problem: To początkowe "0" jest natychmiast publikowane w MQTT i, jeśli trwałość nie jest dostępna lub skrypty zawodzą, nadpisuje skumulowane dane dotyczące energii w Home Assistant, powodując ogromne ujemne skoki w Energy Dashboards.
Proponowane rozwiązanie:
Filtr wewnętrzny: Wdrożenie flagi lub ustawienia dla linkTuyaMCUOutputToChannel, które ignoruje wartości "0", jeśli poprzednia znana wartość była wyższa niż zero.
Ulepszenia trwałości:
Upewnienie się, że nawet w kompilacjach, w których brakuje setChannelPersistence, sterownik energii może utrzymać ostatnią znaną wartość podczas uścisku dłoni podczas uruchamiania z TuyaMCU.Consistent
Skrypty: Upewnienie się, że funkcja addChangeHandler z logiką warunkową (np. if $CH5 < $CH10) jest obsługiwana we wszystkich kompilacjach, w tym tych z ograniczoną pamięcią.
Informacje o urządzeniu:Kompilacja: 3 maja 2026 13:32:48 wersja 1.18.288Chip: BK7231 (T/N)
Jaka jest dokładna marka/model licznika energii TuyaMCU (lub identyfikator produktu/modułu Tuya) i czy możesz potwierdzić, czy dzieje się tak przy każdym ponownym uruchomieniu/cyklu zasilania, czy tylko na tym konkretnym urządzeniu?
Używam mikroinwertera WVC (wyposażonego w moduł CBU IPEX, BK7231N) z systemem OpenBeken w wersji 1.18.288. Ponieważ jest to urządzenie słoneczne, często się przełącza (każdego ranka lub przy słabym oświetleniu).
Czy możesz opublikować odpowiednią konfigurację / skrypt OpenBeken i krótki dziennik rozruchu lub ślad MQTT pokazujący najpierw dpID 105/2 publikowanie 0, a następnie rzeczywistą całkowitą wartość energii (w tym konfigurację linkTuyaMCUOutputToChannel / addChangeHandler, jeśli istnieje)?
00:00:01 - Urządzenie uruchamia się, synchronizacja NTP.
00:00:03 - Sterownik TuyaMCU wysyła pierwszą aktualizację:
Info:TuyaMCU:P przetwarzanie DP 105 (typ 2): Wartość 0
Info:MQTT:P przesyła wartość 0 do mi_sklad_back/5/get retain=1 <-- TO JEST PROBLEM
00:00:08 - TuyaMCU w końcu synchronizuje prawdziwą pamięć wewnętrzną:
Info:TuyaMCU:P przetwarzanie DP 105 (typ 2): Wartość 15420
Info:MQTT:P przekazanie wartości 154.20 do mi_sklad_back/5/get retain=1
Problem: To początkowe "0" jest natychmiast publikowane w MQTT i, jeśli trwałość nie jest dostępna lub skrypty zawodzą, nadpisuje skumulowane dane dotyczące energii w Home Assistant, powodując ogromne ujemne skoki w Energy Dashboards.
Proponowane rozwiązanie:
Filtr wewnętrzny: Wdrożenie flagi lub ustawienia dla linkTuyaMCUOutputToChannel, które ignoruje wartości "0", jeśli poprzednia znana wartość była wyższa niż zero.
Ulepszenia trwałości:
Upewnienie się, że nawet w kompilacjach, w których brakuje setChannelPersistence, sterownik energii może utrzymać ostatnią znaną wartość podczas uścisku dłoni podczas uruchamiania z TuyaMCU.Consistent
Skrypty: Upewnienie się, że funkcja addChangeHandler z logiką warunkową (np. if $CH5 < $CH10) jest obsługiwana we wszystkich kompilacjach, w tym tych z ograniczoną pamięcią.
Informacje o urządzeniu:Kompilacja: 3 maja 2026 13:32:48 wersja 1.18.288Chip: BK7231 (T/N)
Jaka jest dokładna marka/model licznika energii TuyaMCU (lub identyfikator produktu/modułu Tuya) i czy możesz potwierdzić, czy dzieje się tak przy każdym ponownym uruchomieniu/cyklu zasilania, czy tylko na tym konkretnym urządzeniu?
Używam mikroinwertera WVC (wyposażonego w moduł CBU IPEX, BK7231N) z systemem OpenBeken w wersji 1.18.288. Ponieważ jest to urządzenie słoneczne, często się przełącza (każdego ranka lub przy słabym oświetleniu).
Czy możesz opublikować odpowiednią konfigurację / skrypt OpenBeken i krótki dziennik rozruchu lub ślad MQTT pokazujący najpierw dpID 105/2 publikowanie 0, a następnie rzeczywistą całkowitą wartość energii (w tym konfigurację linkTuyaMCUOutputToChannel / addChangeHandler, jeśli istnieje)?
startDriver TuyaMCU
startDriver NTP
tuyaMcu_setBaudRate 115200
tuyaMcu_defWiFiState 4
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 %"
setFlag 7 1
setFlag 10 1
setFlag 21 1
setFlag 40 1
setFlag 19 1
setFlag 35 1
setFlag 37 1
setFlag 51 1
setFlag 29 1
MqttClient mi_sklad_back
ShortName mi_sklad_back00:00:01 - Urządzenie uruchamia się, synchronizacja NTP.
00:00:03 - Sterownik TuyaMCU wysyła pierwszą aktualizację:
Info:TuyaMCU:P przetwarzanie DP 105 (typ 2): Wartość 0
Info:MQTT:P przesyła wartość 0 do mi_sklad_back/5/get retain=1 <-- TO JEST PROBLEM
00:00:08 - TuyaMCU w końcu synchronizuje prawdziwą pamięć wewnętrzną:
Info:TuyaMCU:P przetwarzanie DP 105 (typ 2): Wartość 15420
Info:MQTT:P przekazanie wartości 154.20 do mi_sklad_back/5/get retain=1
