Fotopułapka na złodziei

[MasterYoda95]

Wstęp

Od poprzednich właścicieli mieszkania dowiedziałem się, że w piwnicy zdarzają się kradzieże. W związku z tym postanowiłem zbudować fotopułapkę na złodzieja: urządzenie, które po wykryciu ruchu robi zdjęcia i wysyła je na serwer. Serwer natomiast powiadamia mnie mailowo (z załączonymi zdjęciami) o wykryciu ruchu.

Finał tej historii był taki, że... nie zdążyłem. Jakiś miesiąc przed ukończeniem projektu było seryjne włamanie, którego także padłem ofiarą 😕
Wracając do meritum:

Hardware

- ESP32-CAM
- Arduino Pro Mini (klon)
- moduł czujnika ruchu PIR HC-SR501
- moduł czytnika RFID MRFC522
- akumulator żelowy 6 V 4,5 Ah
- obudowa Kradex Z2AW
- przetwornica mini step-down 360
- Raspberry Pi 4 (serwer)

Zasilanie

W piwnicy nie ma gniazdka, więc założyłem, że zasilanie będzie akumulatorowe. Nie chciałem kombinować z wpinaniem się w oprawę oświetleniową i ryzykować oskarżenie o kradzież prądu. Gdybym nawet miał dostęp do prądu, to i tak dobrze byłoby zastosować akumulator buforowy. No może uprościłoby to projekt o tyle, że ESP, które jest nadrzędnym modułem urządzenia, mogłoby pracować w sposób ciągły, bez usypiania.
Napięcie akumulatora obniżane jest do 3,3 V przez małą, tanią, chińską przetworniczkę step-down i... w zasadzie tyle.

Komunikacja

Miałem to wielkie szczęście, że w piwnicy łapie mi zasięg domowego WiFi. Dzięki temu odpadło kombinowanie z LoRa czy GSM. ESP "gada" z serwerem z wykorzystaniem socketów TCP.

Schemat działania

ESP jest w trybie deepsleep z którego budzi się co 2 godziny w celu zaraportowania napięcia akumulatora, albo od przerwania wywołanego sygnałem z czujnika ruchu.
Jeśli wybudzenie wywołał czujnik ruchu, ESP w pętli robi zdjęcia i wysyła je do serwera w mieszkaniu. Wszelki zapis na karcie SD odpadał już w założeniach, bo złodziej może urządzenie zniszczyć albo po prostu zabrać ze sobą. Zdjęcia przesłane na serwer są już bezpieczne. Wyjście z pętli następuje w dwóch przypadkach: gdy czujnik PIR przestanie wykrywać ruch, albo gdy obecność zostanie zautentyfikowana przez przyłożenie tagu RFID do czytnika.
Serwer ma następujące zadania: stanowi sprzętowy watchdog układu - kontroluje, czy ESP skomunikuje się przynajmniej raz na 4 godziny oraz oczywiście wysyła powiadomienia mailowe o detekcji. Powiadomienia mailowe są dwa - pierwsze zawsze po wykonaniu dwóch zdjęć (chyba że wcześniej nastąpi autentykacja), kolejne to już transfer wszystkich zdjęć jakie urządzenie zdążyło wykonać i przesłać do wyjścia z pętli.  Jeśli uwierzytelnię się przez zeskanowanie breloka RFID, to drugi mail ze zdjęciami nie jest wysyłany - obrazki usuwane są z serwera.

Jaką rolę ma w tym Arduino, skoro wszystko ogarnia ESP? Prostą, zabrakło mi pinów w ESP, żeby podłączyć wszystkie peryferia 🙂 czytnik RFID komunikuje się po SPI, więc zabiera ich sporo. Arduino jest interfejsem, który odczytuje i przechowuje UID odczytanego tagu, a na żądanie (otrzymane z ESP przez Serial), podaje tę wartość. Dodatkowo mierzy napięcie baterii (również w odpowiedzi na komendę Serial) oraz daje akustyczny sygnał buzzerem, gdy odczyta tag.
Nie bawiłem się nawet w usypianie Arduino. Jest ono podłączone do masy przez tranzystor i ESP załącza je sobie przy starcie i wyłącza gdy nie jest już potrzebne.

Ciekawym problemem, który pojawił się pod koniec realizacji projektu było fałszywie pozytywne wzbudzanie czujnika ruchu, gdy ESP wybudzało się "z timera". W Internecie były dziesiątki wątków sygnalizujących ten problem z modułem HC-SR501. Dwa największe tropy to było zasilanie (spory pobór prądu przy starcie ESP, gdy łączy się z WiFi) oraz sam sygnał WiFi. To drugie było łatwiejsze do zdebugowania i okazało się od razu celnym strzałem. Pomogło stworzenie ekranu z folii aluminiowej wokół tylnej części modułu PIR.

W montażu wspomagałem się drobnymi elementami, które sam projektowałem i drukowałem w 3D - panel przedni, tylna pokrywa PIR, uchwyt montażowy baterii, ramka montażowa czytnika RFID. Żeby było trochę druciarstwa to w niektórych miejscach wspomógł mnie hot-glue i... sznurek.

Oprogramowanie

ESP32-CAM - Micropython
Raspberry Pi (serwer) - Python
Arduino - C++ (Arduino)
Jeśli ktoś jest zainteresowany, mogę upublicznić repozytorium na Githubie. Jeszcze tego nie zrobiłem, bo musiałbym wyczyścić kod z danych osobistych, a najlepiej przenieść te zmienne do oddzielnego pliku.

Zdjęcia

front

wnętrze

bonus - jednooki Project Manager

Wydawało mi się że mam gdzieś zdjęcie z zamkniętą obudową, ale nie znalazłem. W sumie wygląda to prawie jak oryginalna obudowa, bo oprócz wystających z panelu frontowego obiektywu kamery i czujnika ruchu, na zewnątrz nie ma żadnych elementów.

fot. Kradex

 

[Gieneq]

@MasterYoda95 ciekawy projekt, na pewno praktyczny 🙂 A jak jest z jakością zdjęć?

[MasterYoda95]

@Gieneq  Bez tragedii, ale i bez szału. Nie zgłębiałem tematu możliwości wykorzystania lepszej kamery.

 

[MasterYoda95]

Okazjonalnie występują problemy z zawieszaniem się aplikacji serwera. Nie umiem znaleźć przyczyny w logach, ale mam przypuszczenie, że jest to związane z nieoczekiwanym zerwaniem połączenia, przez co serwer czeka na dane w nieskończoność.

Ostatnio poczytałem trochę o MQTT i uznałem, że można spróbować przepisać części programów odpowiedzialne za komunikację tak, żeby zamiast socketów, łączyły się przez ten właśnie protokół. Mam już RPi, więc postawiłem Mosquitto. Robię obsługę poszczególnych funkcji (zdjęcia, autentykacja, napięcie baterii) w oddzielnych callbackach, więc program upraszcza się nieco, bo nie muszę "ifować" po treści wiadomości, żeby wywołać odpowiedni kod do jej przetworzenia. Jeśli coś pojawi się w temacie BasementAlarm/batteryVoltage, to wiadomo co to jest i od razu wywoływana jest odpowiednia metoda.

Druga sprawa, to pozwoli to na kolejkowanie, gdyby połączenie było niestabilne. Zamierzam używać Quality of Service = 2 przy subskrypcji i persistent session dla serwera, a wszelkimi ewentualnymi zaburzeniami połączenia i dbaniem o to, żeby wiadomości dotarły zajmie się broker.

Na razie mam roboczo przepisaną aplikację serwera, trochę więcej zabawy będzie z kodem na ESP32. Ale póki co zamierzam przetestować serwer skryptami z poziomu PC - szybciej się debuguje. Póki co, nauczyłem się przesyłać zdjęcia przy pomocy pary skryptów: publishera i subskrybenta.

Jeśli starczy mi wytrwałości, to zaletą tego, że zmienię protokół komunikacji będzie też to, że przy okazji zrobię refactoring kodu. Bez "większego" celu nie chciałoby mi się tego robić, a w micropythonowych obiektach panuje lekki bałagan 🙂 Nie wiem tylko czy istnieje siła, która zmusiłaby mnie do zrobienia dokumentacji 😛

EDIT: Aplikacja serwerowa już prawidłowo łączy się z Mosquitto i prawidłowo reaguje na nadsyłane komendy oraz zdjęcia. Działa to tak jak zakładałem - dzięki persistent session, nawet jeśli aplikacja na raspberry nie jest podłączona do brokera, a klient w tym czasie prześle do niego dane, to po uruchomieniu serwera dane są mu przekazywane, nie giną.

Pora przerobić oprogramowanie ESP32.

Edytowano Marzec 29, 2022 przez MasterYoda95

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[MasterYoda95]

No i dokonałem: komunikacja między alarmem i serwerem odbywa się już wyłącznie przez brokera MQTT. Ciekawe jest dla mnie to, że teraz ESP działa szybciej (operacja wykonania i przesłania zdjęcia zajmuje mniej czasu), a przecież MQTT jest zbudowane na TCP, więc używane wcześniej przeze mnie sockety są rozwiązaniem niższego poziomu (czy warstwy, nie znam się na sieciach) i sądziłem że powinny działać szybciej. Albo po prostu nieefektywnie je wykorzystywałem. Dodatkowo przesył przez MQTT oznacza konieczność przesłania wiadomości najpierw do brokera, a potem do aplikacji serwera, a jednak działa to szybciej 🙂

W każdym razie logika alarmu i serwera nie zmieniła się, ale szybkość i niezawodność po tej zmianie wzrosła.