Karmnik - fotopułapka na wifi z AP mode - automatyzacja pobierania nagrań

Witam,
Niedawno zakupiłem karmnik dla ptaków z kamerą na wifi. Jeden już miałem wcześniej, sprawdzał się jako tako (działa w chmurze tuya). Ten nowy był duużo tańszy więc się połakomiłem. Niestety okazało się, że to nie o takie wifi mi chodziło… - karmnik nie łączy się z moją siecią, tylko wystawia swoją! To problem, bo miałem nadzieję zautomatyzować pobieranie nagranych zdjęć i filmów i teraz zastanawiam się czy to będzie możliwe. Może któryś z forumowiczów podpowie pomysł na to?

Zasada działania karmnika okazała się taka:

  1. Obrazy i filmy nagrywane są na kartę sd.
  2. Gdy użytkownik chce je zobaczyć, musi podejść aby być w zasięgu bluetooth. I wtedy w dedytkowanej aplikacji może do karmnika wysłać po bluetooth komendę włączenia wifi.
  3. Karmnik włącza wifi w trybie AP, czyli nie łączy się z moją domową siecią, tylko to ja muszę w telefonie połączyć się z tamtą.
  4. Po połączeniu, aplikacja pozwala na przeglądanie zdjęć i filmów.
  5. Po rozłączeniu, karmnik wyłącza swoje wifi (po jakimś czasie).

Próbując rozpracować temat doszedłem do kilku ważnych detali:

  • Wysłanie komendy włączenia wifi jest banalnie proste (wysłanie słowa “open” poprzez GATT) i prawdopodobnie można to zasymulować z dowolnego dongle’a BLE (próbuję).
  • Po połączeniu z karmnikowym wifi, wystawia on prostą stronę po http, gdzie znajdują się m.in. nagrane zdjęcia i filmy. Można je pobrać bez używania aplikacji. Podejrzewam, że opcje karmnika również można zmieniać przez http, po jakimś REST API. Ale póki co mi zależy tylko na nagraniach.

Mając powyższe na uwadze widzę pewne możliwości automatyzacji pobierania, niestety wszystkie moje pomysły mają “dziury”…
Do dyspozycji mam 3 routery wifi (dwa są dwuzakresowe) i kilka gołych ESP32-wroom (aktualnie działają jako BLE proxy). HA siedzi na sprzęcie który ma BLE oraz Wifi, a do rutera łączy się po kablu.

Pomysł 1.
HA musi cyklicznie łączyć się z karmnikiem i ściągać nagrania.
Problem 1: HA musiałby na ten czas wyłączać się z domowej sieci - oczywiście niedopuszczalne. Rozwiązaniem mogłoby tu być dodanie dongle’a wifi, którym HA mógłby łączyć się do karmnika.
Problem 2: Odległość - Karmnik jest oczywiście na zewnątrz, 20-30 metrów od HA, co oznacza że karmnikowe wifi raczej nie sięgnie, nie mówiąc już o bluetooth.

Pomysł 2.
Skoro HA jest za daleko, to logicznie by było użyć jakiegoś pośrednika. Mam moduł esp32-wroom z esphome na pokładzie, który mógłbym umieścić pomiędzy HA i karmnikiem. Wtedy możnaby teoretycznie zrobić tak:

  1. HA wysyła do ESP32 sygnał (po domowym wifi).
  2. ESP32 wysyła do karmnika rozkaz włączenia wifi.
  3. ESP32 rozłącza się z domowej sieci i łączy się do karmnikowej.
  4. ESP32 pobiera nagrania… i zapisuje je gdzie??

Pomysł 3.
Właściwie to jest to pomysł 1+2. Dokupujemy jakiś tani wifi extender, stawiamy obok ESP32 (tj. pomiędzy HA i Karmnikiem) i konfigurujemy tak, żeby rozszerzał zasięg karmnikowej sieci. Wtedy ESP32 ma służyć tylko do wysłania sygnału włączenia wifi.
HA ma dedykowany wifi dongle do łączenia się z karmnikowym wifi. W takiej konfiguracji kroki są następujące:

  1. HA wysyła (po domowej sieci) sygnał do ESP32.
  2. ESP32 wysyła do karmnika (po ble) komendę włączenia wifi.
  3. Wifi extender rozszerza zasięg karmnikowego wifi i HA podłącza się do niej używając dedykowanego dongle’a.
  4. HA pobiera z karmnika nagrania i zapisuje w sieci lokalnej.

Pomysł 3 wygląda że ma szanse działać, ale… może da się jakoś prościej? Trochę to już przekombinowane :slight_smile:

No i oczywiście wszystkie te kroki trzeba by jeszcze oprogramować, ale to można na razie nazwać szczegółem technicznym :slight_smile:

No ja ujmę to tak - zupełnie tego nie widzę (tzn. moim zdaniem każdy z pomysłów ma jeszcze kilka innych problemów niż zauważyłeś do tej pory).

Jestem jednak urodzonym pesymistą i być może jest to do zrealizowania, ale raczej w żaden ze sposobów które wymyśliłeś, jakkolwiek możesz próbować i pochwalić się rezultatami.

Chyba możliwe rozwiązanie to użycie sprzętu routera WiFi np. pod openwrt (lub innym otwartym i elastycznym systemem dedykowanym do obsługi sieci) w trybie mostka (czyli nie w trybach routera ani repeatera) z AP w trybie AP-client (który się będzie łączył do tej twojej sieci wystawianej przez kamerę).
Więc tu do rozwiązania kluczowy problem “pożenienia” obu sieci ze sobą (twojego normalnego LANu i tego co wystawia ta kamerka).
Skonfigurowanie sieci w HA może być trudne lub wręcz niemożliwe (to może zależeć od metody instalacji) w sposób z użyciem karty WiFi czyli tak jak chciałeś, dlatego proponuję by sieć kamery była w pewnym sensie częścią twojego zwykłego LANu (unikasz wtedy kombinacji z siecią w HA), masz też załatwiony problem łączenia się do efemerycznej sieci WiFi - w openwrt to realizujesz raczej z łatwością - gdy BSSID się pojawi to AP-klient się dk niego podłączy, w dodatku będzie to realizował bez końca, a nawet gdyby miał być jakiś problem to można mu zapodać programowego watchdoga który zrestartuje sprzęt (choć moim zdaniem to zbędny ruch).
W dodatku nada się do tego celu jakiś sprzęt za grosze (jeśli pokryjesz koszt przesyłki to mam do oddania w dobre ręce 2 sztuki TL-WR740N to już modele z muzeum, ale WiFi 2.4GHz akurat jak znalazł do IoT, bo to jedna z pierwszych konstrukcji z wsparciem BGN no i da się na nich coś ciekawego wyszyć)

Jakby co to w ESPHome synchronizuję zegarek (Xaiomi LYWSD02 z termohigrometrem) przez BLE w ten sposób

esp32_ble_tracker:

ble_client:
  - mac_address: ${ble_clock_mac}
    id:  lywsd02_clock
    on_connect:
      then:
        - lambda: |-
            ESP_LOGD("ble_client_lambda", "Connected to lywsd02_clock!");
        - delay: 20s
        - ble_client.ble_write:
            id: lywsd02_clock
            service_uuid: ebe0ccb0-7a0a-4b0c-8a1a-6ff2997da3a6 
            characteristic_uuid: EBE0CCB7-7A0A-4B0C-8A1A-6FF2997DA3A6
            value: !lambda |-
                auto time = id(sntp_time).utcnow();
                uint8_t time_byte1 =  time.timestamp & 0x000000ff;
                uint8_t time_byte2 = (time.timestamp & 0x0000ff00) >> 8;
                uint8_t time_byte3 = (time.timestamp & 0x00ff0000) >> 16;
                uint8_t time_byte4 = (time.timestamp & 0xff000000) >> 24;
                uint8_t timezone_byte = time.timezone_offset() / 3600;
                return {time_byte1, time_byte2, time_byte3, time_byte4, timezone_byte};
        - delay: 20s
        - switch.turn_off: lywsd02_ble_connection
    on_disconnect:
      then:
        - lambda: |-
            ESP_LOGD("ble_client_lambda", "Disconnected from lywsd02_clock!");

A jak wygląda definicja switch?

Nic nadzwyczajnego, w normalnej sytuacji jest włączany automatyzacją raz na tydzień, co wystarcza na utrzymywanie idealnego chodu zegara mimo ekstremalnych warunków (pracuje w łazience, oświetlony klasycznym halogenem przy lustrze, więc i temperatura wysoka i wilgotności duże), ale eksponuję go także w interfejsie (bo czasem firmware update w ESP powoduje anomalie), opóźnienia w poprzednim kawałku kodu są prawdopodobnie zbyt wysokie, można eksperymentalnie dobrać mniejsze, a aktywne połączenie prawdopodobnie mocniej zużywa baterie

switch:
  - platform: ble_client
    ble_client_id: lywsd02_clock
    name: "Ustaw czas"
    id: "lywsd02_ble_connection"
    restore_mode: ALWAYS_OFF

tak zdefiniowana automatyzacja załatwia też synchronizację czasu przy zmianach zimowy/letni (czwarta rano w niedzielę, czyli nieprawidłowy czas będzie wyświetlany tylko przez maks kilka godzin po zmianie)

time:
  - platform: sntp
    id: sntp_time
    servers: 
      - 0.pl.pool.ntp.org
      - 1.pl.pool.ntp.org
      - 2.pl.pool.ntp.org
    timezone: "Europe/Warsaw"
    on_time:
      - seconds: 0
        minutes: 0
        hours: 4
        days_of_week: SUN
        then:
          - switch.turn_on: lywsd02_ble_connection

Trochę się OFF TOPIC zrobił, więc dodałem taga lywsd02

Moim zdaniem projekt jest pełen pułapek, o których pewnie jeszcze nie wiesz. Jeśli traktujesz go jako przygodę edukacyjno, entuzjastyczną to mam w sumie taki pomysł. Może bardziej ogólnie jako zajawka do sprawdzenia.
Mianowicie - wykorzystanie Smartfona z Android jako re transmitera dzięki Android Debug Bridge, które skutecznie można integrować z HA. Zrootowany Antek może być potężnym narzędziem. Prawdopodobnie to co robi użytkownik, poprzez aplikację kamery na smartfonie, można zrobić zdalnie i automatycznie z HA. Ewentualnie użycie innego oprogramowania, może Tasker ma takie możliwości…

Poniżej link do projektu, który moim zdaniem, może pomóc w eksperymentach z ADB:

A jak już jesteśmy przy ptakach, to chciałbym wspomnieć o ciekawym projekcie na bazie Frigate:


Ciekawe jak jest z modelami dla naszej rodzimej fauny.

2 polubienia