Oto krótka prezentacja 3-fazowego licznika energii Tuya oferującego dostęp do pomiarów przez Internet. Przetestuję tu jego aplikację, a potem zmienię mu firmware tak by uruchomić go bez chmury i połączyć z Home Assistant. Będzie to wymagać analizy jego protokołu komunikacji TuyaMCU, który tu też opiszę. Będzie ambitnie, bo to jeden z droższych produktów które przerabiałem - można go zakupić u nas w kraju za około 300 zł, chociaż ja po prostu otrzymałem go do przeróbki od czytelnika - celem było wgranie OpenBeken.
Pokazany tu sprzęt występuje pod różnymi nazwami, można go znaleźć m. in. pod hasłem Bezpiecznik 3 Fazy Wyłącznik WiFi 4P Tuya 63A 6KV Pomiar Energii Antena lub po jednej z nazw modelów: ZXB3-125/W. W przypadku sprowadzenia z Chin zakup może być znacznie tańszy niż w naszym kraju:
Nieco informacji od sprzedających:
A więc mamy tu urządzenie na szynę DIN, które oferuje i pomiary z sieci (trzy fazy osobno), i możliwość włączenia/wyłączenia, jak również i programowalne zabezpieczenia/alarmy. Do tego antenka i port RS485.
Przyjrzyjmy się zawartości zestawu:
Dostajemy też antenkę, której nie uwzględniłem na zdjęciach.
Oto czytelne zdjęcia instrukcji, wraz z informacjami co ten licznik oferuje oraz jak go podłączyć:
Uwaga! Powiązany temat
Podobną przeróbkę już wykonywałem w przypadku innego urządzenia - tam też był system oparty o TuyaMCU. Zapraszam do zapoznania się z powiązaną serią:
Miernik energii/termostat z LCD - S1TW-FR - pierwsze wrażenie, aplikacja Tuya
Zaawansowany miernik energii/termostat z LCD Atorch S1TW-FR - działanie bez chmury
Możliwości aplikacji
Przycisk RESET na obudowie służy do parowania. Postępujemy tak jak z innymi urządzeniami Tuya:
Od razu potem możemy sterować i odczytywać pomiary. Oto krótka prezentacja video:
Po sparowaniu z Tuya otrzymujemy przede wszystkim dostęp do pomiarów każdej z faz (napięcie, prąd, moc), możliwość włączenia bądź wyłączenia wszystkich faz razem oraz dodatkowe informacje, takie jak sumaryczny pomiar energii elektrycznej, pomiar energii elektrycznej w ostatniej godzinie, czy tam temperaturę czujnika.
Dostępna jest też historia pomiarów (wykresy), ale mi osobiście brakuje zliczania energii osobno dla każdej z faz.
Dodatkowo mamy możliwość ustawienia "alarmów" z odpowiednimi wyzwalaczami, za duże napięcie, zbyt wysoki prąd, itd:
Tuya również pozwala na tworzenie scenariuszy w oparciu o stan tego produktu, tak jak zresztą w przypadku innych urządzeń.
Wnętrze produktu
Niestety tutaj urządzenie jest nieco lepiej zabezpieczone niż zwykle. Oprócz wykręcenia trzech śrubek musimy tu też rozwiercić końcówki nitów. W przypadku miernika z tematu wykonał to już czytelnik, poniżej zdjęcia:
W ten sposób dostajemy się do środka:
Całość opiera się o MCU RSF100BEA (do obsługi pomiarów) oraz o moduł CBU, czyli BK7231N.
CBU komunikuje się z głównym mikrokontrolerem przez UART, przez protokół TuyaMCU:
Protokół TuyaMCU - komunikacja pomiędzy mikrokontrolerem a modułem WiFi
Kika więcej fotek ode mnie:
Osobno na każdą fazę mamy tu BL0942, każdy z nich podłączony jest do wspomnianego MCU.
Rozpiska połączeń płytki z MCU - oprócz UART mamy tu jeszcze dwa sygnały, czyli przycisk resetowania oraz diodę LED określającą stan WiFi. Co więcej, stan WiFi wystawiany przez BK7231N jest też odczytywany przez MCU, należy o tym pamiętać przy zmianie firmware Bekena...
Samo zasilanie zapewnia ICW2540, które zdaje się być kontrolorem małej przetwornicy flyback, ale i tak nie liczyłbym, że tu jest izolacja galwaniczna od strony sieci bo BL0942 też musi jakoś wykonywać pomiar:
Roli CN8033 nie udało mi się określić.
Przechwycona komunikacja TuyaMCU
Przechwycenie komunikacji między MCU a modułem WiFi może pomóc nam określić znaczenie poszczególnych dpID. Całość należy wykonać z dużą dozą ostrożności, bo elektronika miernika nie jest izolowana od sieci, więc jeśli podłączymy się do niej ze zwykłym konwerterem USB na UART to możemy zrobić zwarcie i uszkodzić zarówno miernik, jak i komputer. Z tego powodu zastosowałem izolatory oparte o ADuM1200/ADuM1201.
Pokazywane tu urządzenie korzysta z wolniejszego trybu TuyaMCU, czyli baud 9600. Nie jest używany tu szybszy baud (115200) znany z niektórych podobnych produktów.
Komunikację można analizować w naszym analizatorze TuyaMCU.
Metoda przechwytywania była dwojaka. Dla ustawień użytkownika objąłem metodę:
1. uruchamiam przechwytywanie
2. zmieniam jakieś ustawienie
3. zatrzymuje przechwytywanie
natomiast dla pomiarów po prostu zapisywałem co jest pokazywane w aplikacji Tuya a potem starałem się znaleźć raportowane dane w pakietach.
Wnioski są następujące:
- dpID 16 to boolean, kontrola "przekaźnika", on lub off
- dpID 6, 7 i 8 to typ raw zawierający pomiar prądu, napięcia i mocy dla każdej z faz osobno, zgodny z przyjęty w OpenBeken RAW_TAC2121C_VCP, cytując kod C:
Kod: C / C++
Zaloguj się, aby zobaczyć kod
- dpID 11 to temperatura z jednym miejscem po przecinku, ale wysyłana jako liczba całkowita, więc w OBK to jest tzw. typ Temperature_div10
- dpID 12 to sumaryczne zużycie energii elektrycznej w dziesiątkach Wh (123 odpowiada 1.23kWh)
- dpID 17 oraz dpID 18 to dłuższe pakiety, odpowiednio 12-bajtowy i 16-bajtowy, zawierające alarmy (jeden bajt jako on/off oraz dwa bajty jako limit dla każdego z alarmów). Wstępny szkic znaczenia bajtów:
Gdy użytkownik zmienia ustawienie alarmu, to wysyłany jest cały pakiet o danym dpID, a MCU potwierdza zmianę odsyłając nową wartość zmienionych wcześniej danych.
Dodatkowo też pomogłem sobie metodą pobrania dpID z chmury, dzięki niej poznałem inne, nieco mniej ważne dpID:
Kod: JSON
Zaloguj się, aby zobaczyć kod
W podobny sposób uzyskałem zakresy wartości niektórych zmiennych:
switch_prepayment Boolean "{true,false}"
clear_energy Boolean "{true,false}"
charge_energy Integer
{
"unit": "kW·h",
"min": 0,
"max": 999999,
"scale": 2,
"step": 1
}
switch Boolean "{true,false}"
alarm_set_1 Raw {}
alarm_set_2 Raw {}
leakagecurr_test Boolean "{true,false}"
Code Type Values
total_forward_energy Integer
{
"unit": "kW·h",
"min": 0,
"max": 99999999,
"scale": 2,
"step": 1
}
phase_a Raw {}
phase_b Raw {}
phase_c Raw {}
fault Bitmap {
"label": [
"short_circuit_alarm",
"surge_alarm",
"overload_alarm",
"leakagecurr_alarm",
"temp_dif_fault",
"fire_alarm",
"high_power_alarm",
"self_test_alarm",
"ov_cr",
"unbalance_alarm",
"ov_vol",
"undervoltage_alarm",
"miss_phase_alarm",
"outage_alarm",
"magnetism_alarm",
"credit_alarm",
"no_balance_alarm"
]
}
switch_prepayment Boolean "{true,false}"
energy_reset Enum {
"range": [
"empty"
]
}
balance_energy Integer {
"unit": "kW·h",
"min": 0,
"max": 99999999,
"scale": 2,
"step": 1
}
charge_energy Integer {
"unit": "kW·h",
"min": 0,
"max": 999999,
"scale": 2,
"step": 1
}
leakage_current Integer {
"unit": "mA",
"min": 0,
"max": 1000,
"scale": 0,
"step": 1
}
switch Boolean "{true,false}"
alarm_set_1 Raw {}
alarm_set_2 Raw {}
breaker_number String {
"maxlen": 255
}
leakagecurr_test Boolean "{true,false}"
temp_current Integer {
"unit": "℃",
"min": -400,
"max": 2000,
"scale": 1,
"step": 1
}
Szkoda jedynie, że ta metoda i tak nie pokazała znaczenia bajtów alarmów - tj. zestawy alarm_set_1 i alarm_set_2. Trzeba będzie analizować ręcznie.
Zmiana firmware
Zgodnie z naszym poradnikiem TuyaMCU:
Przewodnik flashowania, instalacji i konfiguracji TuyaMCU - skonfiguruj dpID dla Home Assistant
Port do zmiany firmware BK7231 to ten sam port z którego korzysta TuyaMCU, z tego powodu musiałem wylutować płytkę z modułem WiFi. Starczyło nieco topnika i spoiwa ołowiowego:
Przy okazji można zobaczyć co pod tą płytką jest - wspomniane BL0942 do pomiarów:
CBU programuję naszym flasherem: https://github.com/openshwprojects/BK7231GUIFlashTool
Można posiłkować się materiałami z Youtube: https://www.youtube.com/@elektrodacom
Po zaprogramowaniu CBU musi wrócić na miejsce:
Przed wlutowaniem na miejsce płytki trzeba oczyścić otwory ze starego spoiwa:
Urządzenie włączam ponownie dopiero po dokładnym sprawdzeniu, czy CBU został dobrze wlutowany, bez żadnych zwarć czy zimnych lutów.
Uruchomienie OpenBeken
Początkowa konfiguracja jest taka sama jak w Tasmocie - konfigurujemy nasze WiFi przez otwarty access point, a potem podłączamy się do urządzenia już przez nasz router.
Problemy zaczynają się krok dalej.
Trzeba skonfigurować TuyaMCU i choć mamy już gotowe szablony do podobnych urządzeń, to tutaj sprzęt nie chciał mi zgłaszać większości dpID. Wysyłane były tylko podstawowe informacje.
Próbowałem metod znanych z dokumentacji, czyli tuyamcu_sendQueryState oraz tuyamcu_defWifiState, ale ostatecznie rozwiązanie było gdzie indziej. W przypadku tego urządzenia moduł WiFi powinien wystawić odpowiedni stan logiczny na jeden z pinów poza UART by dopiero pozwolić MCU na raportowanie dodatkowych danych. Szczegóły w temacie: Jak sprawić, by urządzenie TuyaMCU wysyłało więcej danych? Dlaczego dpID nie są wysyłane?
W tym konkretnym przypadku musiałem ustawić P8 na tryb zawsze niski:
Manipulacja P8 zmienia nie tylko stan diody LED na obudowie, lecz też określa ile danych może wysłać MCU. MCU wysyła pełne dane tylko gdy na P8 jest stan niski, czyli zapalona jest zielona dioda:
Dopiero po tej zmianie mogłem ruszyć dalej, ale wtedy natrafiłem na kolejny problem...
Działała tylko jedna faza - a dokładniej dla innych pomiary były zerowe. Po dłuższym śledztwie winną problemów okazała się być włożona odwrotnie wtyczka:
W teorii nie powinno dać się jej wsadzić odwrotnie, ale jak widać jest to możliwe, tym bardziej, że przewody są bardzo krótkie i ogólnie całość jest bardzo trudno złożyć po otwarciu, a wtyczkę ze zdjęcia trzeba wkładać pęsetą...
Ostatecznie jednak udało się opracować następujący skrypt:
startDriver TuyaMCU
startDriver NTP
//tuyaMcu_setBaudRate 115200
// not really needed here
tuyaMcu_defWiFiState 4
setChannelType 1 Toggle
linkTuyaMCUOutputToChannel 16 bool 1
// phase A
setChannelType 2 Voltage_div10
setChannelType 3 Current_div1000
setChannelType 4 Power
linkTuyaMCUOutputToChannel 6 RAW_TAC2121C_VCP 2 3 4
// phase B
setChannelType 5 Voltage_div10
setChannelType 6 Current_div1000
setChannelType 7 Power
linkTuyaMCUOutputToChannel 7 RAW_TAC2121C_VCP 5 6 7
// phase C
setChannelType 8 Voltage_div10
setChannelType 9 Current_div1000
setChannelType 10 Power
linkTuyaMCUOutputToChannel 8 RAW_TAC2121C_VCP 8 9 10
// temperature
setChannelType 11 Temperature_div10
linkTuyaMCUOutputToChannel 102 val 11
// balance (increases)
linkTuyaMCUOutputToChannel 1 val 12
setChannelType 12 EnergyTotal_kWh_div100
Wszystko zgodnie z naszą dokumentacją, jedynie warto wspomnieć, że typ dpID RAW_TAC2121C_VCP za argument pobiera indeks pierwszego kanału (napięcia) a dalej domyślnie zakłada, że kolejny kanał to prąd, a jeszcze kolejny to moc. Tak jak sama nazwa wskazuje, Voltage, Current, Power.
Widok panelu:
Teraz można dowolnie nazwać ustawione kanały oraz wykonać Home Assistant Discovery by połączyć urządzenie z HA.
Podsumowanie
To chyba jedno z najdroższych urządzeń Tuya jakie przerabiałem i nie obyło się bez problemów. Na początku wszystko szło zgodnie z oczekiwaniami, od początku spodziewałem się, że będzie ono opierać się o mechanizm TuyaMCU więc postępowałem zgodnie z utartym już szlakiem, ale potem pojawiły się nowe problemy. Pierwszym problemem było to, że tutaj TuyaMCU nie raportuje stanu "połączenia z chmurą" przez UART, tylko osobnym pinem, i zorientowanie się w tej sytuacji zajęło mi troszkę czasu, a drugim problemem była ta odwrotnie wsadzona wtyczka - to przez nią druga i trzecia faza uparcie nie pokazywała pomiarów...
Ostatecznie jednak podstawa już działa.
Tak przerobione urządzenie działa 100% lokalnie, niezależnie od serwerów producenta i można je łatwo połączyć z Home Assistant, jak również dowolnie programować i skryptować.
Teraz zostały do wykonania jeszcze ze dwie rzeczy:
- uruchomienie zaawansowanych funkcji (zabezpieczenie nadprądowe) które są zaszyte w tych wyspecjalizowanych pakietach typu raw o dpID 17 i 18; będzie to wymagało odpowiedniego ich parsingu oraz również ich wysyłania (aby użytkownik mógł zmienić ustawienia). Nie starczą do tego gotowe mechanizmy, bo gotowe mechanizmy zakładają że dany dpID to jedna zmienna typu przykładowo integer czy tam boolean, a tu jeden dpID to ciąg bajtów (zbiór wielu alarmów)
- przetestowanie i opracowanie podłączenia przez RS485 oferowanego przez tą serię - może ktoś z czytających próbował? Na ten moment nie wiem nawet, czy w tym modelu jest to funkcjonalne...
Chciałbym to wkrótce uzupełnić - może będzie drugi temat z serii?
Mam jeszcze w kolejce:
Spoiler: 
Tymczasem zapytam, czy ktoś korzystał już z tego typu liczników, a może nawet je przerabiał tak by działały z HA?
Załączam przechwycone pakietu TuyaMCU z fabrycznego oprogramowania tego urządzenia.
Fajne? Ranking DIY Pomogłem? Kup mi kawę.
