HA działa jako kontener na dockerze. Nie jest to najprostsza konfiguracja, ale jedna z najbardziej elastycznych. Z jednej strony mamy możliwość aktualizacji HA, a z drugiej możliwość uruchomienia dodatkowego oprogramowania – w moim przypadku: Ebusd oraz Samba.
Dodatki
Dodatek
Cel
DuckDNS + Ngnix
Konfiguracja SSL plus wystawienie HA do internetu
ESPHome Device Builder
ESPHome – oprogramowanie dla chipów i czujników
File editor
Edycja plików
Frigate HailoRT
Podgląd kamer, analiza ruchu, serwer NVR
Home Assistant Google Drive Backup
Automatyczne backupy w chmurze
Mosquitto broker
Serwer MQTT
SQLite Web
Klient SQL dla SQLLite
TasmoAdmin
Zarządzanie urządzeniami Tasmota
TasmoBackup
Backup urządzeń Tasmota
Uptime Kuma
Monitoring urządzeń
Zigbee2MQTT
Obsługa urządzeń Zigbee
HACS
Niestandardowe integracje
Integracja
Cel
HACS
Moduł do pobierania dodatkowych komponentów i integracji
Antistorm
Prognoza burz i opadów
Disk Space
Sensor wielkości dysku
Frigate
Integracja z frigate
Media player template
Dedykowany player dla niestandardowych urządzeń multimedialnych
Uptime Kuma
Integracja z Uptime Kuma
Viomise
Integracja dla odkurzacza Viomi SE and Xiaomi STY02YM, STYJ02YM
Do monitorowania obrazu z kamera do niedawna używałem addona motionEye, jednak ostatnio przesiadłem się na addon Frigate. Oferuje znacznie większe możliwości, takie jak rozpoznawanie określonych obiektów oraz dzięków. W tym rozwiązaniu jest używany akcelerator NPU Hailo8L, odciża procesor RP5 z operacji analizy obrazu. Hailo ma bardzo dobry współczynnik ilości obliczeń do zużywanej mocy. Całość jest zasilana ze standardowego zasilacza RPI5.
Hardware
„tania” chińska kamera P05-7
ESP32 + kamera OV2460
Raspberry Pi AI Kit (M.2 HAT+ i akcelerator Hailo-8L) – link
(opcjonalnie) TV z GoogleTV
(opcjonalnie) Telefon z Androidem wraz ze skonfigurowaną aplikacją HA
Software
Addon: Frigate HailoRT
Integracja HACS: Frigate Home Assistant Integration
Komponent HACS: Advanced Camera Card
(opcjonalnie) TvOverlay – aplikacja umożliwiająca wyświetlanie powiadomień na Google TV
uruchomiony serwer Samba
Konfiguracja HA
Używam podłączonego dysku USB do przechowywania nagrań. Dysk jest skonfigurowany jako dysk sieciowy przy użyciu Samby.
Niestety paczka hailo-all zawiera firmware i sterownik w wersji 4.20, a wersja Frigate HailoRT 0.15 zwiera oprogramowanie do Hailo w wersji 4.19. Konieczne jest przygotowanie własnej wersji sterownika i frimware do obsługi Hailo. Szczegóły rozwiązania w artykule link.
Następnie można przetestować powiadomienie wywołując usługę w HA z menu Narzędzia deweloperskie -> Akcje
action: notify.tvoverlaynotify
data:
message: The garage door has been open for 10 minutes.
title: Your Garage Door Friend
data:
id: notification_sample
appTitle: AppTitle
appIcon: mdi:unicorn
color: "#FFF000"
smallIcon: mdi:speaker-multiple
largeIcon: mdi:camera
corner: bottom_end
seconds: 20
image: https://picsum.photos/300
Wysłanie powiadomienia z Frigate na telefon i TV
Jeżeli wysyłanie następuje tylko na telefon to można skorzystać z gotowego blueprinta (link).
Poniżej moja automatyzacja
- id: '1663062012156'
alias: Frigate Notifications
trigger:
- platform: mqtt
topic: frigate/events
id: frigate-event
payload: NAZWA_KAMERY
value_template: "{{ value_json['after']['camera'] }}"
variables:
after_zones: "{{ trigger.payload_json['after']['entered_zones'] }}"
before_zones: "{{ trigger.payload_json['before']['entered_zones'] }}"
camera: "{{ trigger.payload_json['after']['camera'] }}"
id: "{{ trigger.payload_json['after']['id'] }}"
label: "{{ trigger.payload_json['after']['label'] }}"
score: "{{ trigger.payload_json['after']['score'] }}"
time_clip_start: "{{ trigger.payload_json['after']['start_time'] - 10.0 }}"
# Conditions must be used to filter out objects / detections that are not of interest
condition:
# This condition is used to ensure that I am only notified of objects that are new or only just entered a zone. This is to avoid getting loads of updated notifications for the same dog in my backyard (as an example).
- condition: or
conditions:
- condition: template
value_template: "{{ trigger.payload_json['type'] == 'new' }}"
- condition: template
value_template: "{{ before_zones | length == 0 }}"
- condition: template
value_template: >-
{{ 'Chodnik' in (after_zones + before_zones) }}
# - condition: template
# value_template: >-
# {{
# (as_timestamp(now())-as_timestamp(state_attr('automation.frigate_notifications_with_details2',
# 'last_triggered') | default(0)) | int > 5) }}
- condition: state
entity_id: input_boolean.tv_notify_motion
state: 'on'
action:
- service: notify.mobile_phone_app
data:
message: >-
{{ label }}({{ int(score | round(2) * 100) }}%) na {{ after_zones }} wykryty przez {{ camera }}, {{ id }}
data:
image: >-
/api/frigate/notifications/{{ id }}/thumbnail.jpg
url: >-
https://HAOS_EXTERNAL_LINK/api/frigate/notifications/{{ id }}/{{camera}}/clip.mp4
actions:
- action: URI
title: Video
uri: >-
https://HAOS_EXTERNAL_LINK/api/frigate/notifications/{{id}}/{{camera}}/clip.mp4
- action: URI
title: Snapshot
uri: >-
https://HAOS_EXTERNAL_LINK/api/frigate/notifications/{{ id }}/snapshot.jpg
- action: URI
title: Thumbnail
uri: >-
https://HAOS_EXTERNAL_LINK/api/frigate/notifications/{{ id }}/thumbnail.jpg
- service: notify.tvoverlaynotify
data:
data:
appTitle: Frigate
largeIcon: mdi:camera
color: "#000800"
seconds: 30
image: >-
https://HAOS_EXTERNAL_LINK/api/frigate/notifications/{{id}}/thumbnail.jpg
title: >-
{{ label }} wykryto na {{ camera }}
message: >-
{{ label }}({{ int(score | round(2) * 100) }}%) na {{ after_zones }} wykryty przez {{ camera }}
mode: parallel
max: 10
# trace:
# stored_traces: 20
Fajny projekt, gdzie niewielkim kosztem jest wyświetlane podświetlenie LED za telewizorem na podstawie wyświetlanego obrazu. W moim rozwiązaniu użyta jest kamera umieszczona naprzeciwko TV oraz „stare” Rasberry PI3, które wcześniej sterowało moim domem i po upgrade do RPI5 leżało w szufladzie.
Została użyta kamera ponieważ na TV wyświetlane są tylko programy z aplikacji streaminowych, nie ma możliwości użycia grabbera sygnału i odczytu obrazu z we/wy HDMI.
Instalacja jest podzielona na dwie części:
RPI3 wraz kamerą USB (kamera umieszczona prawie naprzeciw telewizora),
sterowalna listwa LED z ESP32.
Instalacja
Schemat blokowy instalacji LED za TV
Sprzęt
Zasilacz 5V/20A (koszt ok 50 PLN) – pewnie można użyć trochę mniejszy,
Listwa RGB 2805 (koszt ok 80 PLN) – długość ok 4m (72LED na poziomych listwach i 40 na pionowych),
ESP32-DevKitC-32U z anteną (koszt ok 10$),
bezpieczniki samochodowe 2x10A,
kostka połączeniowa,
rezystor 300om (tłumienie zakłóceń na linii DATA),
kabel zasilający 2×1.5mm2 – połączenie od zasilacza do kostki.
Uwagi
Niestety listwa dolna jest mocniej zasłonięta przez obudowę TV – co powoduje słabsze świecenie diód w dolnej części.
Konfiguracja
ESP32
Zainstalowane oprogramowanie WLED (z przeglądarki Chrome) – link. WLED działa przez WIFI, na routerze ustawiony jest stały adres IP. Dodatkowo w WLED ustawiono ilość diód (Length), maksymalną wydajność prądową zasilacza (Maximum PSU Current ) oraz pin z linią danych (Data GPIO).
Aby zmniejszyć opóźnienie na linii kamera a listwa LED rejestruje obraz z rozdzielczością 320×240 przy 30FTPs. Relatywnie po kadrowaniu w moim przypadku zostaje ok 100×55 co i tak przewyższa ilość diód LED.
Integracja z HA
Standardowa integracja
Automatyzacje
Automatyczne włączenie/wyłączenie nagrywania i przetwarzania obrazu przy włączeniu telewizora.
Duża ilość urządzeń w domowej sieci wifi powoduje zawsze problemy z dostępnością wszystkich urządzeń. Do monitoringu działania urządzeń wykorzystuje oprogramowanie „Uptime Kuma” jak dodatek zainstalowany w HA
Konfiguracja
Ustawienia pojedynczego monitora dla urządzenia
Powiadomienia wysyłam bezpośrednio poprzez HA na komórkę. Większość urządzeń monitoruje na odpowiednim temacie MQTT – przykład powyżej.
Aby pominąć błędne powiadomienia:
dla MQTT – heartbeat: 60 sek oraz ilość prób: 5,
dla ping – heartbeat: 300 sek oraz ilość prób: 5,
Konfiguracja HA
Za pomocą dodatkowej integracji HACS: „Uptime Kuma HACS integration: dodane są sensory do HA, dodatkowo wykorzystany Dashboard HACS: button-card.
Prosty projekt odczytujący z analogowego licznika dane i przekazujący informację do HomeAssistant przez MQTT. Projekt wykorzystuje bibliotekę uczenia maszynowego Tensorflow Lite do analizy obrazu.
Hardware
ESP32 + OV2640 2.0MP camera module + antena (koszt ok 10$)
Integracja z kotłem Valliant VC 186 oraz sterownikiem pogodowym VC400 korzysta z protokołu eBUS. Jako adapter eBUS wykorzystywana jest płytka w wersji 2.2 zbudowana na podstawie strony eBus Adapter 3. Od czasu jego zlutowania (2020) pojawiło się kilka nowszych wersji adaptera, ale nie zamierzam zmieniać, bo działa bardzo skutecznie. Komunikacja z HA jest za pomocą serwera MQTT.
Schemat blokowy
Wygląd płytki adaptera eBus z UART
Oprogramowanie
Korzystam z ebusd uruchomionego na Linuxie (Debian) jako serwis.
Oczywiście wartości mqtthost, mqttport, mqttuser, mqttpass należy ustawić na poprawne.
Aby zmieniać niektóre wartości (krzywa grzewcza, stany liczników gazu) ebusd musi działać w trybie instalatora. Weryfikację, czy dany parametr jest modyfikowalny można sprawdzić w projekcie GIT https://github.com/john30/ebusd-configuration wyszukując odpowieni plik dla instalacji.
Weryfikacja działania ebusd
ebusctl info
dla mojej instalacji komenda zwraca
version: ebusd 24.1.24.1
update check: OK
device: /dev/ttyUSB0, serial
access: install
signal: acquired
symbol rate: 22
max symbol rate: 1441
min arbitration micros: 0
max arbitration micros: 3168
min symbol latency: 0
max symbol latency: 15
scan: finished
reconnects: 0
masters: 3
messages: 432
conditional: 7
poll: 110
update: 16
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0516;HW=7401", loaded "vaillant/bai.308523.inc" ([id_hw=7401]), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=40000;SW=0139;HW=7301", loaded "vaillant/15.400.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Problemy
Ponieważ rozwiązanie działało już przez kilka lat nastąpiło przepełnienie liczników (ebusd/bai/PrEnergyXXX) odpowiedzialnych za zliczanie zużycia gazu.
Poniżej komendy do zresetowania odpowiednich liczników:
#odczyt
ebusctl read -V -c bai PrEnergyCountHwc1
#zapis
ebusctl write -c bai PrEnergySumHc1 0
ebusctl write -c bai PrEnergySumHwc1 0
ebusctl write -c bai PrEnergyCountHc1 0
ebusctl write -c bai PrEnergyCountHwc1 0
Jeżeli przy zapisie są błędy „ERR: element not found” powyższe komendy należy wykonać w trybie instalatora (parametr „–accesslevel=install”).
Home Assistant
Karta ogrzewania w HA
Rozwiązanie bazuje na cyklicznym odczycie danych przez MQTT. Aby oczytać jakąś wartość należy najpierw wysłać wiadomość odpowiedni topic MQTT. Do testowania najlepiej użyć klienta umożliwiającego podłączenie się bezpośrednio do serwera MQTT, np. MQTT Explorer
Zużycie gazu można wyliczyć na podstawie liczników PrEnergySumHwc1 oraz PrEnergySumHw1. Na podstawie pomiarów należy wyliczyć stosunek zużycia gazu do sumy PrEnergySumHwc1 i PrEnergySumHw1.
Komponent do wprowadzenia poprzednich wartości odczytanych
Kiedyś wymyśliłem, że przydałaby się informacja, czy w garażu jest zaparkowany samochód. Wyszło całkiem proste urządzenie, które poza identyfikacją samochodu, jednocześnie weryfikuje – czy jest otwarta, czy zamknięta brama garażowa oraz mierzy temperaturę i wilgotność w garażu. Koszt ok 40 PLN (bez obudowy i zasilacza na microUSB).
Czujnik temperatury jest opcjonalny.
Ważne jest umiejscowienie całego urządzenia – na suficie, czujnik odległości skierowany w dół, nad końcem otwartej bramy garażowej, dzięki temu można wyłapać stany (otwarty garaż, auto/zamknięty garaż, brak auta/zamknięty garaż) dodatkowo czujnik musi być umieszczony nad zaparkowanym autem.
Wykorzystane komponenty:
Czujnik odległości HC-SR04
Czujnik SI7021 (ja wykorzystałem wolny czujnik od Sonoff TH10, TH16, itd.)
Wemos D1 mini
Poniżej schemat:
plus podłączenie SI7021 na D5 (pin 12). Na schemacie nie zaznaczono masy i podłączenie zasilania do Wemos D1 mini.
Oprogramowanie
Należy wcześniej zainstalować dodatek ESPHome w HomeAssistant.
Poniżej konfiguracja Wemos D1 mini w ESPHome. Należy dodatkowo utworzyć plik secrets.yaml w EspHome.
Istnieje oczywiście możliwość integracji przez moduł eth, ale ponieważ jest on kosztowny zaprojektowałem proste rozwiązanie wykorzystując wolne wyjścia w domowej centrali Satel Integra. Nie jest to dwukierunkowa integracja, a jedynie przekazywanie informacji od alarmu do HomeAssistant. Dzięki temu można stworzyć fajne automatyzacje na podstawie wykrytego ruchu. Koszt integracji ok 50 PLN
W tym rozwiązaniu akumulator w centrali alarmowej jest wykorzystywany jako UPS dla RaspberryPI, co oczywiście skraca czas działania alarmu przy długich wyłączeniach prądu.
NodeMCU (alternatywnie Wemos D1 mini – tańsze rozwiązanie, ja miałem pod ręką akurat wolny chipset NodeMCU)
Schemat blokowy
Zastosowałem 25W przetwornicę napięcia, aby z alarmu zasilić od razu RaspberryPI na którym jest uruchomiony HomeAssistant. Dzięki temu w przypadku braku zasilania RPi działa aż do wyczerpania baterii w alarmie.
Ważne jest użycie i skonfigurowanie odpowiednich wyjść w na płycie Integra – nie wszystkie wyjścia są wyjściami wysokoprądowymi.
Uwaga na schemacie nie zaznaczono masy.
Widok płytki od strony elementów
Software
Alarm
Konfiguracja w systemie alarmowym jest wykonana w oprogramowaniu DLOADX.
Wyjścia typu Out są wysterowane przez 3 sekundy przez wejścia z czujek PIR