[CBU/BK7231N] Tuya czujnik ruchu PIR Krasław 120°, głęboki sen, zasilanie bateryjne

Przedstawię tu wnętrze, zasadę działania oraz zmianę firmware (w celu uwolnienia od chmury i zyskania niezależności od serwerów producenta) taniego czujnika PIR produkcji Tuya, kupionego na jednym z polskich portali wysyłkowych. Na koniec podam jego pełną konfigurację dla OpenBeken, wraz z szablonem. Oczywiście urządzenie skonfigurujemy do pracy z głębokim snem a czujnik PIR będzie je tylko wybudzać. Jest to niezbędne w przypadku zasilanych bateryjnie gadżetów z komunikacją WiFi.

Zakup czujnika
Czujnik kupił jeden z użytkowników OpenBeken na polskim portalu aukcyjnym, z intencją podrzucenia mi go bym mógł mu zmienić firmware. Poniżej zrzuty ekranu z oferty:

Zapłaciliśmy jedyne 50 zł, przesyłka była darmowa (w pakiecie dla stałych klientów tego portalu).
Parametry, nie ma tu konkretów:

Dopiero w cechach wyczytamy np. że czujnik przez 30 sekund "trzyma" wykrycie obecności, albo w jakiej odległości może wykrywać:


Czujnik ten jest zasilany trzema bateriami AAA (nie są one zawarte w zestawie, należy dokupić je osobno).
Opakowanie, niestety nie ma konkretnych oznaczeń:

Zaglądamy, co dostaliśmy w zestawie:

Jest taśma i kluczyk do resetowania.
Produkt ma również zaczep do przyklejenia na ścianę (po to taśma), a po jego zdjęciu mamy dostęp do baterii, do przycisku ON-OFF i do przycisku od resetowania (czyli parowania):



Wnętrze czujnika
Niby czujnik posiada plombę od sprzedawcy, ale przyklejona jest ona tak, że nie trzeba jej zdejmować.

W środku jest moduł CBU, jego dokumentacja jest na stronie Tuya, a OpenBeken wspiera BK7231N.

Przyjrzyjmy się płytce:

Dużo na tej płytce to się nie dzieje. Czujnik PIR jest typowy, taki jak w popularnych modułach do Arduino. Moją uwagę przykuł układ U3, czyli 7333, regulator LDO 3.3V. Myślałem, że tu będzie nieco bardziej wydajna przetwornica step down, ale jednak nie. W sumie ma to jakiś sens, tutaj przecież są trzy bateryjki po nominalnie 1.5V, czyli 4.5V w sumie, oczywiście coraz mniej z ich rozładowywaniem. Produkty Tuya zasilane bateryjnie z przetwornicami zamiast regulatorów są raczej na dwie baterie, wtedy jest tam 3V, a przetwornica je podwyższa do 3.3V.
Przycisk on-off pozwala wyłączyć całkiem czujnik bez wyciągania baterii:

Tranzystory R1 i A09T, których ról nie analizowałem:

CBU:

To urządzenie nie korzysta z TuyaMCU. Nie ma tu dodatkowego mikrokontrolera, nic nie blokuje UART1 od CBU. CBU sam wszystko kontroluje i zapada w głęboki sen gdy nic się nie dzieje. Urządzenie to wybudza się i łączy się z WiFi tylko gdy trzeba zaraportować stan.

Programowanie, konfiguracja
Podłączamy wspólną masę, RX i TX od konwertera UART i ewentualnie zasilanie, uruchamiamy flasher, i robimy cykl zasilania (off i on). Wszystko tak jak opisane na naszym repo:
https://github.com/openshwprojects/BK7231GUIFlashTool
Ten sam proces można zobaczyć na naszym kanale YT:
https://www.youtube.com/@elektrodacom
Przylutowane kabelki:

Flasher w ruch:

Flasher też potrafi odczytać konfigurację Tuya:

Tutaj mamy JSON z Tuya, ich format opisu urządzenia:

Opis słowny tego samego z mojego flashera:

Częściowo gotowy szablon w naszym formacie JSON:

Trochę tu tego jest. Mamy tu oczywiście przycisk od parowania, Button, na P20. Jest tu dioda LED WiFi czy tam status na P26. Jest sensor PIR na P16. No i mamy układ kontroli stanu baterii, czyli ADC + GPIO które załącza dzielnik rezystorowy. Te GPIO jest po to, by oszczędzać energię i by dzielnik rezystorowy tylko puszczał prąd gdy wykonujemy pomiar. Tuya też określa, jakie mamy napięcia baterii maksymalne i minimalne, używane to jest do obliczeń.
O sterowniku baterii był już temat tutaj:
https://www.elektroda.pl/rtvforum/topic3959103.html
https://www.elektroda.com/rtvforum/topic3959103.html
Teraz zostaje kwestia samego głębokiego snu. Moduł WiFi nie może pracować cały czas, to by zbyt szybko zużyło baterie. W tym celu wykorzystamy rozwiązanie oparte o głęboki sen, opisywane tu:
https://www.elektroda.pl/rtvforum/topic3960149.html
https://www.elektroda.com/rtvforum/topic3960149.html
Warto też zapoznać się z tym temacie o głębokim śnie:
https://www.elektroda.pl/rtvforum/topic3972898.html
https://www.elektroda.com/rtvforum/topic3972898.html
Podsumowując, tutaj należy skonfigurować:
- ustawić rolę Button dla przycisku na P20 by móc awaryjnie wybudzić urządzenie z głębokiego snu
- ustawić rolę LED (lub WiFi LED - wedle uznania, bądź LED_n) na P26, dobrać tam kanał 1
- ustawić rolę DoorSensorWithDeepSleep dla P16, gdyż użyjemy sterownika door sensor do raportowania ruchu, też ustawić kanał 1
- dodatkowo, w zależności od tego jaką wersję PCB macie, może być potrzeba skonfigurowania DSEdge, tak aby wybrać rodzaj zbocza wybudzającego czujnik (narastające, opadające, bądź odpowiednio narastające gdy układ zaśnie ze stanie niskim na czujniku bądź opadające gdy układ zaśnie ze stanem wysokim na czujniku)
- skonfigurować battery driver, tak jak w zalinkowanym wcześniej temacie
Po tym można wykonać Home Assistant Discovery by połączyć urządzenie z HA:
https://www.youtube.com/watch?v=pkcspey25V4

W razie czego, tutaj jest dokumentacja OBK:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/README.md
A wszelkie pytania można zadawać na naszym forum.

Oto końcowy rezultat:

Dioda LED zapala się jak tylko zostanie wykryty ruch.


Podsumowanie
Kolejne urządzenie uwolnione od chmury i od serwerów producenta. Dodatkowo kolejny raz udało nam się napotkać na coś korzystającego ze sterownika baterii opartego o wejście ADC i wyjście cyfrowe GPIO, gdzie cyfrowe GPIO załącza rezystorowy dzielnik napięcia tylko na czas pomiaru. Już to kilka razy widziałem w tego typu produktach, też np. w przypadku czujnika drzwi.
Co do samej konfiguracji urządzenia, to warto zaznaczyć, że można byłoby je też obsłużyć "ręcznie", poprzez skrypt OpenBeken, po prostu wpisując prostą pętle z IF i GoTo, która wprowadzi je w sen za pomocą komendy PinDeepSleep gdy nie ma zmian na czujniku przez jakiś czas.
Tu też pojawia się pytanie, czy chcemy by urządzenie "zasypiało" tylko gdy nie ma ruchu (a było "wybudzone" dopóki PIR raportuje obecność ruchu), czy by "zasypiało" w obu stanach. W przypadku użycia drivera DoorSensor zasypia w obu stanach. Tak chyba jest lepiej pod kątem czasu życia baterii.
Warto jeszcze dodać, że w OBK takie urządzenie może sterować innymi nawet bez Home Assistant - wystarczy oskryptować komendę SendGET i po IP np. wysyłać nowy stan dla włącznika światła.
To chyba tyle, na koniec tylko przypomnę jeszcze o tym, że statyczne IP i umiejscowienie urządzenia blisko routera z pewnością też przedłuży życie baterii w pewnym stopniu.
Czy ktoś z czytających korzysta z tego typu czujników PIR? A jeśli tak, to czy w wersji "chmurowej", związanej z serwerami producenta, czy może już w wersji w pełni lokalnej?