Pokażę tutaj wnętrze 'inteligentnego' radaru/czujnika ruchu/oświetlenia Tuya opartego o TuyaMCU, przeanalizuję jego protokół komunikacji, a potem przedstawię jak można go obsłużyć w OpenBeken. Dla wygody użytkowania utworzę też dla tego urządzenia mini stronkę WWW w Bootstrapie, którą zahostuję na OBK i skomunikuję z samym firmware poprzez interfejs REST. Skutkiem zabawy będzie całkowite uwolnienie urządzenia od chmury przy jednoczesnym zachowaniu interesującej nas jego funkcjonalności.
Temat powstał we współpracy z @DeDaMrAz . Urządzenia z tematu nigdy u siebie nie miałem, kolega z Serbii wykonywał wszystkie pomiary, fotki i testy.
UWAGA: Jakiś czas temu uruchamialiśmy podobne urządzenie, które było tylko czujnikiem oświetlenia. Temat o nim można znaleźć poniżej:
https://www.elektroda.pl/rtvforum/topic3984681.html
Zakup czujnika-radaru
Zakupu dokonaliśmy na chińskim serwisie wysyłkowym. Czujnik dostępny jest w wersjach na Zigbee oraz na WiFi, wybraliśmy WiFi. W tej samej ofercie można też zamówić hub od Zigbee. Za sam czujnik zapłaciliśmy 20$:
Oto specyfikacja produktu. Zasilanie jest z 5V, produkt oferuje wykrywanie ruchu w zakresie odległości ustawianym przez użytkownika, jak również wykonuje pomiar oświetlenia:
Wymiary i grafiki promocyjne:
Zawartość paczki, wnętrze
Zaglądamy, co dostaliśmy. Obudowa trzyma się na zaczepach.
Okazuje się, że to jest urządzenie oparte o TuyaMCU i moduł WiFi, nad którego wsparciem prace dopiero trwają. Czy to oznacza, że ten temat już zaraz się zakończy?
Nic bardziej mylnego! To jest urządzenie oparte o TuyaMCU, czyli na początek można przechwycić pakiety ich komunikacji UART. Omawiałem to w temacie o analizatorze TuyaMCU:
https://www.elektroda.pl/rtvforum/topic3970199.html
https://www.elektroda.com/rtvforum/topic3970199.html
Link do repozytorium analizatora:
https://github.com/openshwprojects/TuyaMCUAnalyzer
Sam TuyaMCU też bym omawiany, więc nie będę tu powtarzać szczegółów takich jak to czym jest dpID, jakie są typy zmiennych w TuyaMCU i tak dalej:
https://www.elektroda.pl/rtvforum/topic3880546.html
https://www.elektroda.com/rtvforum/topic3880546.html
Komunikacja TuyaMCU
Zatem robimy przechwytywanie pakietów. Podłączamy masę oraz RX konwertera USB na UART pracującego w trybie 3.3V najpierw do TX modułu WiFi, a potem do RX i zapisujemy dane wysyłane. Baud to z reguły 9600, ale tutaj było inaczej - tu był użyty 115200, który też można spotkać w niektórych urządzeniach Tuya.
Oto zebrane dane, najpierw to co wysyła MCU do modułu WiFi:
Widzimy tu najpierw zameldowanie się MCU wraz z kodem produktu w JSON:
Kod: JSON
a potem mnóstwo zmiennych o różnych dpID, których znaczenie dopiero będziemy poznawać. Tu mamy zmienne, które MCU do nas wysyła, czyli pomiary.
Z kolei pakiety wysyłane przez moduł WiFi do MCU wyglądają następująco:
Tu mamy zmienne, które wysyła moduł WiFI do MCU. To są parametry działania urządzenia, np. tu wysyłana jest czułość radaru.
Krótka analiza i testy z aplikacją Tuya pokazuje nam co jest czym. Po prostu przełączaliśmy opcje w apce i patrzyliśmy co się zmienia. Obserwowaliśmy co pokazuje UART, a co pokazuje aplikacja. Oto role poszczególnych dpID:
- 1 alarm obecności
- 2 czułość radaru
- 3 dystans min wykrywania (chyba jako cm)
- 4 dystans max wykrywania (chyba jako cm)
- 6 selft test (0 lub 1)
- 9 wykryty dystans do ruchu (chyba jako cm)
- 101 opóźnienie wykrycia (jednostka to dziesiętne części sekundy, więc 10 oznacza 1 sek, a 5 oznacza 0.5sek)
- 102 obecność z opóźnieniem (podobnie jak obecność, ale wyłącza się po opóźnieniu)
- 103 debug CLI flaga (domyślnie 32)
- 104 odczyt sensora oświetlenia
Te role też można wyciągnąć z API Tuya, ale tego podejścia tutaj nie użyliśmy.
Pełne zrzuty komunikacji umieściłem na repozytorium analizatora:
https://github.com/openshwprojects/TuyaMCUAna...mmit/9a7a87fde797d56b29095d9218910384c0b84b1c
Obsluga TuyaMCU w OpenBeken
Napotkany w środku moduł WiFi nie jest jeszcze obsługiwany, ale producenci często stosują go zamiennie z TYWE3S (ESP8266, raczej kiedyś) i CB3S oraz WB3S (BK7231). Można zatem na próbę zrobić podmiankę modułu i potestować obsługę TuyaMCU w OpenBeken. Da to nam trochę więcej informacji na temat działania tego urządzenia oraz pokaże nam, czy wsparcie TuyaMCU w OBK sobie poradzi z dość nietypowym sprzętem.
Zatem - gorące powietrze w ruch i lutujemy na miejsce CB3S już z wgranym OBK:
Potem należy skonfigurować TuyaMCU w OpenBeken. W skrypcie autoexec.bat mapujemy dpID zmiennych z TuyaMCU na kanały OpenBeken oraz ustawiamy ich typy. Potrzebne jest to by system wiedział jak je wyświetlić na GUI oraz jak je wysyłać do Home Assistant, też przy automatycznym Discovery urządzenia.
Skrypt umieszczamy w systemie plików LIttleFS poprzez Web App.
startDriver TuyaMCU
// always report paired
tuyaMcu_defWiFiState 4
// baud
tuyaMcu_setBaudRate 115200
// 104 is light sensor
setChannelType 2 ReadOnly
setChannelLabel 2 Lux
linkTuyaMCUOutputToChannel 104 val 2
// 1 is presence alarm
setChannelType 1 ReadOnly
setChannelLabel 1 Presence
linkTuyaMCUOutputToChannel 1 bool 1
//2 is dp_sensitivity - default 7
setChannelType 3 TextField
setChannelLabel 3 DP_sensitivity
linkTuyaMCUOutputToChannel 2 val 3
// 9 is target distance
setChannelType 4 ReadOnly
setChannelLabel 4 Meters
linkTuyaMCUOutputToChannel 9 val 4
// 3 is near detection
setChannelType 5 TextField
setChannelLabel 5 Near_detection
linkTuyaMCUOutputToChannel 3 val 5
//102 is fading time
setChannelType 6 TextField
setChannelLabel 6 Fading_time
linkTuyaMCUOutputToChannel 102 val 6
//4 is fading time
setChannelType 7 TextField
setChannelLabel 7 Far_detection
linkTuyaMCUOutputToChannel 4 val 7
Ten skrypt wykonuje się raz na starcie urządzenia.
startDriver TuyaMCU
Ta komenda uruchamia sterownik TuyaMCU.
// always report paired
tuyaMcu_defWiFiState 4Ta komenda wymusza zawsze raportowanie stanu WiFi 0x04 do TuyaMCU, czyli "online and connected to cloud"
// baud
tuyaMcu_setBaudRate 115200Ta komenda ustawia baud rate komunikacji.
// 104 is light sensor
setChannelType 2 ReadOnly
setChannelLabel 2 Lux
linkTuyaMCUOutputToChannel 104 val 2 Następnie mamy trójki komend, które kolejno ustawiają typ kanału OpenBeken (określa jego wyświetlanie, przetwarzanie oraz sposób publikacji jego wartości do HA), ustawiają label (nazwę) kanału a potem mapują dane dpID oraz typ zmiennej z TuyaMCU na ten właśnie kanał.
Oto rezultat:
Nie wygląda to GUI zbyt dobrze, zaraz je nieco ulepszymy...
Własna strona konfiguracyjna
Urządzenie już może działać z Home Assistant, ale nie odwzorowaliśmy jeszcze całego GUI producenta. Można zatem iść o krok dalej. OpenBeken nie ma swoim firmware możliwości dużego dostosowania kanałów z głównego panelu do specyficznych potrzeb tego urządzenia, więc normalnie byłby problem z ustawieniem ładnych sliderów z odpowiednimi zakresami i opisami, ale na ratunek przybywa nam tutaj LittleFS i interfejs REST.
OpenBeken pozwala nam utworzyć własną mini stronkę urządzenia, pisaną w HTML i w Javascript, hostowaną właśnie na samym urządzeniu z WiFi i komunikującą się z głównym firmware poprzez interfejs REST, bez odświeżania strony.
Było to prezentowane w temacie poniżej (wersja angielska i polska):
https://www.elektroda.pl/rtvforum/topic3971355.html
https://www.elektroda.com/rtvforum/topic3971355.html
Repozytorium demek:
https://github.com/openshwprojects/OpenBekenRESTDemo
Tutaj też uznałem, że warto byłoby coś takiego zrobić. W ten sposób powstała zalinkowana poniżej strona:
https://github.com/openshwprojects/OpenBekenR.../main/examples/TuyaMCU_RadarSensorConfig.html
Stronkę potem rozwinąłem też o pokazywanie odczytów z sensora:
https://github.com/openshwprojects/OpenBekenR...ples/TuyaMCU_RadarSensorConfigAndResults.html
Przeanalizujmy działanie tej strony.
Strona to jeden plik - dokument HTML z osadzonym Javascriptem. Strona nie przeładowuje się cała, tylko skrypt odświeża jej części w tle. Strona załącza style i pomocnicze skrypty Bootstrapa, by mieć jakikolwiek estetyczny wygląd. W samym HTML utworzone są też suwaki i pola z wynikami pomiarów:
Kod: HTML, XML
Te suwaki mają podpięte zdarzenia onChange, czyli wywołują skrypt gdy użytkownik zmieni ustawienie.
W momencie zmiany wartości suwaka wywoływana jest wspólna funkcja ustawiająca kanał OpenBeken, gdyż w OBK w kanałach może być każda wartość, kanał jest tak jakby zmienną:
Kod: Javascript
Samo setChannel jest współdzielone i używa fetch by wysłać do OBK zmianę wartości zmiennej (kanału):
Kod: Javascript
To byłoby wszystko, gdyby nie potrzeba poznania początkowego stanu parametrów. Czyli to, co pobieramy raz przy otwarciu strony. Odbywa się to w window.onload oraz potem w interval co jakiś czas (aby odświeżać zmiany które nadeszły z zewnątrz):
Kod: Javascript
No i sama funkcja pobierająca kanały:
Kod: Javascript
Funkcja odświeża zarówno parametry które możemy edytować, jak i wartości tylko do odczytu (bieżący rezultat pomiaru odległości itd).
Warto dodać, że poprzez interfejs komend REST w stylu Tasmoty można tu również wykonywać komendy Tasmoty, typu POWER, STATUS, ich odpowiedzi w formacie JSON też trzymają standard Tasmoty. Tylko sam dostęp do kanałów jest w OBK niezgodny z Tasmotą, gdyż Tasmota po prostu jako takich kanałów nie posiada.
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/README.md
Ostatnie poprawki
Na koniec warto zalinkować do naszej nowej strony z głównego panelu OBK. Tutaj pomoże nam sterownik httpButtons - poniżej kod, który należy dopisać do autoexec.bat:
startDriver httpButtons
setButtonEnabled 0 1
setButtonLabel 0 "Open Config"
setButtonCommand 0 "*/api/lfs/cfg.html"
setButtonColor 0 "#FF0000"
Najpierw startuje on sterownik przycisków, potem włącza przycisk pierwszy (indeks zero), potem ustawia mu label, potem ustawia mu komendę, w tym przypadku z gwiazdką, czyli link, a na koniec ustawia jego kolor.
Rezultat:
Podłączenie do Home Assistant
OpenBeken wspiera Home Assistant Discovery, więc urządzenie można łatwo podłączyć do HA i tam śledzić jego stan oraz tworzyć automatyzacje.
(wartość odległości powyżej nie ma jeszcze poprawionej jednostki)
Automatyzacje wtedy tworzymy w HA tak jak dla każdego innego urządzenia.
Automatyzacje bez Home Assistant
W OBK można też zrobić automatyzacje bez HA. Wystarczą do tego zdarzenia zmiany wartości kanału. Kanał to może być dowolna zmienna i dowolne dpID zmapowane z TuyaMCU, więc możemy wywoływać skrypty na skutek odczytu dowolnego pomiaru z urządzenia. Można też konstruować zdarzenia warunkowe, np. włączać światło tylko gdy odczytany jest ruch i poziom oświetlenia jest mniejszy niż ustalona wartość. Samego włączenie światła można dokonać poprzez wysłanie żądania GET do innego urządzenia. Pozwala to zrealizować wszystko bez zewnętrznego serwera.
Oto przykłady obsługi zdarzenia zmiany wartości kanału:
// when channel 1 becomes 0, send OFF
addChangeHandler Channel1 == 0 SendGet http://192.168.0.112/cm?cmnd=Power0%20OFF
// when channel 1 becomes 1, send ON
addChangeHandler Channel1 == 1 SendGet http://192.168.0.112/cm?cmnd=Power0%20ON
// This will automatically turn off relay after about 2 seconds
// NOTE: addRepeatingEvent [RepeatTime] [RepeatCount]
addChangeHandler Channel0 != 0 addRepeatingEvent 2 1 setChannel 0 0
Podsumowanie
To było dla mnie coś nowego, takiego rodzaju czujnika ruchu/radaru jeszcze nie widziałem. To urządzenie rzeczywiście daje bardzo duże możliwości dostosowania swojego działania do potrzeb. W zależności od miejsca montażu można tu dostosować odległość z której wykrywany jest ruch, można również dostosować jego czułość oraz czas ruchu po którym zostaje on zgłoszony jako wykryty. Dodatkowo jest też pomiar poziomu oświetlenia, co również może być przydatne.
OpenBeken bez problemów radzi sobie z tym urządzeniem, przy czym, tak jak wspominałem, testowaliśmy na sztucznie zrobionej wersji z BK7231N, gdyż moduł BR nie jest jeszcze w pełni wspierany, choć SDK dla niego jest dostępne i prace nad tym trwają.
Możliwość tworzenia prostych stron w systemie plików LittleFS bezpośrednio na OBK (na samym module WiFi) dodatkowo ułatwia nam integrację tego urządzenia i pozwala znacznie lepiej i estetyczniej odwzorować jego stronę z aplikacji Tuya. Oczywiście można by na tej stronie umieścić znacznie więcej niż w moim przykładzie, możliwości są bardzo duże.
To na razie tyle, a teraz już zapowiem że u kolegi @DeDaMrAz czekają już kolejne sprzęty do recenzji:
Na koniec mogę jeszcze podziękować @DeDaMrAz za wciąż rozwijaną, owocną współpracę nad uwalnianiem chińskich gadżetów od chmury i przerabianiem ich tak, by mogły pracować 100% lokalnie przy zachowaniu wygody i funkcjonalności.
Fajne? Ranking DIY Pomogłem? Kup mi kawę.
