Template sensors w Home Assistant: 5 praktycznych przykładów na start

Czym są template sensors i kiedy je stosować?

Template sensor to czujnik, który nie pochodzi z fizycznego urządzenia. To twór logiczny. Bierzesz dane z kilku sensorów, przetwarzasz je w szablonie Jinja2 i dostajesz nową wartość. Brzmi prosto. I często takie jest.

Wyobraź sobie czujnik wilgotności w łazience i czujnik temperatury. Osobno mówią ci niewiele. Ale gdy połączysz je w jeden template sensor obliczający punkt rosy, dostajesz ostrzeżenie, zanim na suficie pojawi się pleśń. To konkret. To działa.

Z mojego doświadczenia template sprawdzają się świetnie przy przeliczaniu jednostek (metry na stopy, stopnie Celsjusza na Fahrenheita) oraz przy wyciąganiu stanu z długich stringów JSON. Diabeł tkwi w szczegółach. Nie każdy sensor potrzebuje logiki. Czasem prosty binary sensor wystarczy. Ale gdy potrzebujesz czegoś więcej, szablon to twoja tajna broń.

Przykład 1: Sensor pogodowy z prognozą na jutro

Wyobraź sobie, że chcesz wiedzieć, czy jutro będzie lało. I to bez otwierania apki pogodowej. Template sensor rozwiązuje to w minutę.

Podstawowy kod wygląda tak. W pliku configuration.yaml dodajesz nowy sensor. Bierzesz dane z integracji pogodowej, na przykład Met.no. Następnie wyciągasz prognozę na jutrzejszy dzień.

template:
 - sensor:
 - name: "Prognoza opadów na jutro"
 state: >
 {% if state_attr('weather.home', 'forecast')[1].precipitation > 0 %}
 Będzie padać
 {% else %}
 Sucho
 {% endif %}

I tu zaczyna się magia. state_attr pozwala sięgnąć do atrybutów encji. Indeks [1] to jutrzejsza prognoza (indeks 0 to dziś). Sprawdzasz, czy opady są większe od zera. Proste jak drut.

Mylne założenie? Wielu myśli, że to działa od razu. Cóż... trzeba odświeżyć encję lub poczekać na aktualizację z serwisu pogodowego. Czasem to 30 minut.

Możesz też zrobić sensor numeryczny. Podający dokładną wartość opadów. Wystarczy zmienić warunek na {{ state_attr('weather.home', 'forecast')[1].precipitation }}. Wtedy dostajesz liczby. Diabeł tkwi w szczegółach.

Przykład 2: Łączny czas pracy urządzenia w ciągu dnia

Chcesz wiedzieć, ile godzin dziennie grzeje twój bojler? A może pracuje klimatyzacja? Template sensor sumuje czas binarnych stanów. Prostsze niż myślisz.

Zaczynasz od encji binarnej. Sensor binary_sensor.bojler_praca daje stan on przy grzaniu. Teraz template:

template:
 - sensor:
 - name: "Czas pracy bojlera dzisiaj"
 unique_id: bojler_czas_pracy_dzis
 icon: mdi:timer-outline
 state: >
 {% set dzis = namespace(start=as_timestamp(now().replace(hour=0, minute=0, second=0))) %}
 {% set czas = namespace(sum=0) %}
 {% for state in states.binary_sensor.bojler_praca | selectattr('last_changed', 'ge', dzis.start) | list %}
 {% if state.state == 'on' %}
 {% set czas.sum = czas.sum + as_timestamp(state.last_changed) %}
 {% endif %}
 {% endfor %}
 {{ czas.sum | timestamp_custom('%H:%M', false) }}

Działa to tak: sensor przelicza sumę czasu, gdy urządzenie było włączone od północy. Wynik dostajesz w godzinach i minutach. Moim zdaniem to jedno z najważniejszych narzędzi do optymalizacji. Bez niego działasz po omacku. Z nim widzisz, czy sprzęt nie pracuje zbyt długo.

W praktyce dodajesz automatyzację. Jeśli czas pracy przekroczy 6 godzin, dostajesz powiadomienie. Proste. A co jeśli chcesz te dane wykorzystać w szerszym kontekście? Sprawdź główny artykuł na ten temat.

Przykład 3: Stan drzwi (otwarte/długo otwarte)

Drzwi otwarte przez chwilę to nic złego. Ale gdy ktoś zostawi je na kilkanaście minut, zaczyna się problem. Zimą ucieka ciepło, latem chłód. A do tego jeszcze kwestie bezpieczeństwa.

Template sensor pozwala rozróżnić te dwa stany. Prostszy wariant to binary_sensor oparty o kontaktron. Zwraca on tylko on lub off. Bez kontekstu czasowego.

Oto szkielet kodu dla drzwi wejściowych:

template:
 - binary_sensor:
 - name: "Drzwi wejściowe długo otwarte"
 state: >
 {% set elapsed = (as_timestamp(now()) - 
 as_timestamp(states('binary_sensor.drzwi_wejściowe_kontaktron'))) %}
 {{ elapsed > 300 and 
 is_state('binary_sensor.drzwi_wejściowe_kontaktron', 'on') }}
 delay_off:
 minutes: 1

Działa to tak. Sensor sprawdza od kiedy kontaktron jest w stanie on. Jeśli minęło 300 sekund (5 minut), a drzwi nadal są otwarte, sensor zwraca prawdę. Delay_off zapobiega migotaniu przy zamykaniu.

Można też dodać drugi sensor, który włączy alarm po 30 minutach. Albo wyśle powiadomienie na telefon. Brzmi prosto. A różnica w komforcie jest ogromna.

Z mojego doświadczenia takie rozwiązanie działa lepiej niż proste czujniki czasu w automatyzacjach. Bo template sensor trzyma stan. Automatyzacja tylko go odczytuje. Mniej logiki do debugowania.

Przykład 4: Poziom naładowania baterii z ostrzeżeniem

Baterie w czujnikach to najsłabsze ogniwo systemu. Padają zawsze wtedy, gdy akurat wyjeżdżasz na weekend. Znam to z autopsji.

Proste rozwiązanie:

1. Sensor pobiera atrybut battery_level z czujnika.
2. Template {% raw %}{{ state_attr('binary_sensor.okno_salon', 'battery_level') | int(0) > 20 }}{% endraw %}
3. Jeśli wartość spada poniżej 20%, sensor zwraca true.
4. Do tego automatyzacja wysyłająca powiadomienie na telefon.

Diabeł tkwi w szczegółach. Musisz sprawdzić, czy twój czujnik w ogóle raportuje poziom baterii. Nie wszystkie to robią. Moim zdaniem to karygodne, że producenci oszczędzają na takiej informacji. Kosztuje ich to grosze, a użytkownik traci czas.

Z mojego doświadczenia najlepiej ustawić próg ostrzegawczy na 30%, a krytyczny na 15%. Kropla drąży skałę. Mała zmiana, która oszczędza ci nerwów. Bez tego system nie działa jak należy.

Jeśli chcesz połączyć ten alert z bardziej złożoną logiką, polecam szerszy kontekst w głównym artykule. Znajdziesz tam sposób na warunki czasowe i wykluczenia.

Kiedy zrezygnować z template sensora na rzecz innego rozwiązania?

Tu zaczyna się problem. Jeśli zależność od sieci ma krytyczne znaczenie, template sensor nie wystarczy. Dla bezpieczeństwa, alarmów, czujników życia codziennego lepiej postawić na dedykowane urządzenia. Kontaktron przewodowy. Czujnik Zigbee z lokalnym przetwarzaniem. To działa nawet przy awarii internetu. Template sensor tego nie zagwarantuje.

Moim zdaniem wiele osób przesadza z template sensorami. Robią skomplikowane obliczenia, które można obsłużyć prostą automatyzacją w systemie. Zobacz główny artykuł na ten temat, gdzie pokazuję różne podejścia. Czasem wystarczy jeden włącznik, a nie cały sensor logiczny. Nie zawsze trzeba iść na całość.

Kolejna sprawa. Wydajność. Template sensory wykonują kod przy każdej zmianie stanu. Przy dużej liczbie odświeżeń potrafią spowolnić Home Assistanta. Wtedy lepiej użyć dedykowanej integracji lub skryptu. Diabeł tkwi w szczegółach. A czasem najprostsze rozwiązanie jest najlepsze.