Temat wraca relatywnie często, więc warto zebrać wszystko w jednym miejscu.
W dużym skrócie: jak stwierdzamy w tym momencie czy Spejs jest otwarty czy nie oraz jak to ogłaszamy?
Zadziwiająco wiele elementów bierze w tym udział i każdy z nich może się wywalić na swój sposób.
Von Count czyli Raspberry Pi 3 + kamera + wyświetlacz + obudowa. Zwykle wisi pod sufitem w cow-worku i jest zasilany przez PoE.
Na karcie SD ma obraz Balena (czyli Docker dla IoT). W tej chwili podpięty jest pod kąto Claude’a ale w międzyczasie założyłem ogólnohaesowo konto Balena żeby każdy kto potrzebuje mógł w tym macać.
Balena odpala kontener w którym znajduje się aplikacja robiąca zdjęcie co jakiś czas i odpalająca YOLO by rozpoznać ile osób jest w środku. Jak już policzy to wysyła po MQTT info do serwera MQTT który obecnie stoi tam gdzie Home Assistant.
Były z tym różne problemy:
- YOLO bardzo grzeje paja więc lepiej odpalać YOLO na dużym mocnym serwerze niż na małej skromnej pajce
- połączenie MQTT potrafiło się zerwać i nie było reconnect
- z jakiegoś powodu Balena domyślnie pytała nasz DNS i jakiś globalny o adresy .hs3. Jeśli globalny odpowiedział szybciej to adres był niedostępny (bo globalne nie wiedzą nic o naszej infrze, co nie)
- nikt poza Claude nie wie jak zobaczyć logi i co się tak naprawdę z tą pają dzieje
- gdy serwer MQTT był niedostępny (albo leżał albo DNS dał zły adres) to Von Count nie był w stanie wstać
Dwa pierwsze z nich załatwia nam feat: Split the Counter from the Peeper by DoomHammer · Pull Request #7 · hs3city/voncount · GitHub
W tej chwili info o liczbie osób idące z Von Count to jedyne źródło prawdy o otwarciu/zamknięciu Spejsu.
Kolejny element układanki to broker MQTT. W zasadzie jedyne co robi to jest, jest dostępny pod mqtt.hs3 i wiele więcej nie musimy na jego temat wiedzieć bo zawsze świetnie robi swoją robotę.
Z MQTT informację o liczbie osób czyta Home Assistant. Na podstawie tej liczby ustawia wartość binary_switch.open_for_tours na 0 (ludzie == 0) lub 1 (ludzie > 0).
Jeden z komponentów Home Assistant obsługuje renderowanie SpaceAPI. Informację o tym czy stan jest open czy closed bierze z powyższego binary_switch. SpaceAPI to międzynarodowy standard spejsów opisujący pewne rzeczy jak adres, projekty, czy właśnie stan otwarcia drzwi.
Nie monitorujemy w tej chwili nijak kiedy została opublikowana ostatnia wiadomość, więc jak Von Count wyśle “open” po czym przestanie wysyłać cokolwiek bo się wywali to klient MQTT dalej widzi jedynie że jest “open”. Analogicznie z “closed” ale to raczej mniejszy problem.
Komponent SpaceAPI ma niestety jedną wadę. Wystawiany edpoint jest dostępny wyłącznie dla zalogowanych. W praktyce chcemy by SpaceAPI było widoczne dla całego świata i tu trzeba szukać jakiegoś obejścia. Obecne obejście polega na tym że na titanie chodzi sobie usługa z dwoma kontenerami: jeden to nginx serwujący statyczny plik z systemu plików; drugi to pętla odpalająca curl wraz z wygenerowanym tokenem dla HA by pobrać spaceapi.json i wystawić je publicznie. Całość jest frontowana przez Traefik jako https://spaceapi.in.hs3.pl .
curl potrafi się wykrzaczyć gdy np. źle resolvuje domenę Home Assistant albo gdy token traci ważność. Póki co nie mam pomysłu jak możemy to rozegrać lepiej chyba że chcemy jednak olać Home Assitant i wrócić do hostowania własnej usługi renderującej SpaceAPI.
Jak już mamy wystawione wszystko na SpaceAPI to wchodzi Glider. Bot w Pythonie który robi dwie rzeczy: sprawdza co jakiś czas stan otwarcia drzwi w SpaceAPI i publikuje te informacje na Discorda.
Niezależnie od tego jak publikuje to zawsze są jakieś problemy, bo Discord nie jest kuma jak często zmieniać statusy.
Oprócz tego korzystamy z jakiegoś publicznego widgetu na stronie https://hs3.pl który również ustawia odpowiednio tekst w zależności od tego co pokazuje nasze SpaceAPI.
Pytania otwarte:
- jak raportować stan spejsu gdy jest otwarty ale to tylko serwis sprzątający?
- co zrobić gdy jesteśmy w Spejsie ale niekoniecznie chcemy gości?
×1 (
×1 (bartykraus)