Home Assistant: ovládáme interní data a vizualizujeme

Databáze Home Assistant

Základní součástí snad každého software, který pracuje s větším množstvím dat, je databáze. Konkrétních implementací je nepřeberné množství, v dnešním díle se podíváme na některé z nich. Když poprvé nainstalujeme a spustíme Home Assistant, možná nás ani nenapadne, že nějakou databázi používá. Přece ano a velmi jednoduchou.

Pohledem do adresářové struktury uvidíme soubor home-assistant_v2.db, což je ve skutečnosti databáze SQLite. Jedná se o relační databázi, ale na rozdíl od známých databází jako jsou např. MySQL/MariaDB, PostgreSQL, MSSQL nebo Oracle DB se však nejedná o službu, která běží v operačním systému a vyžaduje určité systémové prostředky. Je vlastně pouze knihovna, která ve spojení s programovacím jazykem zprostředkuje základní volání jazyka SQL nad datovým souborem uloženém na souborovém systému: co soubor, to jedna databáze.

Je to tedy opravdu velice jednoduchý databázový systém (pokud se tak dá nazývat), často používaný jako jednoúčelové úložiště dat desktopových aplikací nebo pro opravdu jednoduché webové aplikace. Podporuje však základní náležitosti jako např. ACID, transakce, cizí klíče, triggery apod. Naopak vůbec neřeší řízení přístupových práv. Pokud má uživatel oprávnění k souboru, může provádět s daty veškeré operace. V čem rozhodně nevyniká, je běh na sdíleném úložišti, protože nepodporuje zámky, proto by se tato databáze měla provozovat ideálně jen lokálně a s jedním aplikačním přístupem. Stejně tak můžeme zapomenout na replikaci dat či další pokročilé funkce.

Můžeme namítnout, že pro domácí automatizaci není potřeba žádný robustní databázový systém. Zvlášť, když často takové systémy provozujeme na zařízeních typu Raspberry Pi, kde často šetříme každý megabajt paměti či procesorový čas. Souhlasím, ale toto tvrzení bude platit jen z počátku. Pro seznámení s problematikou nebo pro ovládání několik málo zařízení to bude určitě stačit.

Jak se ale bude instance Home Assistanta rozrůstat a do databáze se budou ukládat stavy a historie čím dál více zařízení, bude práce s ní náročnější a zdlouhavější. Je to zkrátka jen jeden soubor uložený na filesystému, s jedním přístupem. Tento soubor bychom měli samozřejmě také zálohovat, avšak nejlépe ve chvíli, kdy do něj aplikace nezapisuje, aby byl konzistentní. To je další komplikace. Navíc o nějakých optimalizacích nebo možnostech rychlejšímu vyhledávání nemůže být také ani řeč.

V tu chvíli přichází čas na migraci do plnohodnotné relační databáze. Home Assistant používá pro práci s databázovým backendem interní integraci „Recorder“ a díky SQLAlchemy tak podporuje databáze MariaDB/MySQL, PostgreSQL a samozřejmě již známou SQLite. Podrobně si projdeme postupy pro obě citované databáze, které jsou na Linuxových systémech navíc nejčastěji používané.

Ve výchozím stavu neobsahuje konfigurační souboru configuration.yaml žádné nastavení týkající se databázového systému. Zkrátka se počítá s tím, že bude existovat konkrétní soubor s SQLite databází a standardní nastavení doby uchovávání dat. Nejdříve začneme tím, že do konfigurace přidáme, např. na konec, novou sekci:

recorder:
  db_url: !secret db_string

Tímto minimálním zadáním budeme zatím definovat připojovací informace k námi vybrané databázi, tedy uživatelské jméné, heslo, název databáze a server. Později se ještě vrátíme k pokročilejším nastavením. Direktiva !secret značí, že obsah proměnné db_string bude uložen v souboru secrets.yaml, kam je vhodné všechna tajemství ukládat.

Nyní se musíme rozhodnout, zda-li budeme migrovat SQLite databázi do MariaDB nebo PostgreSQL. Pro oba případy uvádím konkrétní postup v následujících kapitolách. Pokud jsme se rozhodli pro MariaDB (což bude asi nejčastější případ), do tohoto souboru zadáme tento connection string:

db_string: "mysql://USERNAME:PASSWORD@SERVER/homeassistant"

V případě výběru PostgreSQL databáze pak tento:

db_string: "postgresql://USERNAME:PASSWORD@SERVER/homeassistant"

Do pole PASSWORD zadáme patřičně komplexní heslo a do pole SERVER pak IP adresu/hostname databázového serveru. Hodnota polí SERVER a USERNAME se ale může lišit dle toho, jakou instalaci zvolíme. Podrobněji se k tomu vrátím níže. Pokud databázový server běží na výchozím portu (tj. TCP/3306, resp. TCP/5432), pak jej není potřeba udávat. Tím máme základní nastavení hotové a můžeme přistoupit k instalacím.

Přechod na MariaDB

Databázi MariaDB asi není potřeba představovat. Jedná se o plnohodnotný fork databáze MySQL (stále se vyvíjí) a jedná se o jednu z nejpoužívanějších databází pro webové projekty. Pokud ještě MariaDB nepoužíváme například pro jiný projekt, je potřeba ji nejdříve nainstalovat.

Pokud používáme variantu Home Assistant OS nebo Supervised, stačí přejít do Nastavení → Doplňky a jednoduše nainstalovat. Databáze a databázový účet jsou již připravené. Před spuštěním databáze však ještě klikneme na menu Nastavení a zadáme v sekci Logins heslo do proměnné password. Pozor, je potřeba heslo zadat do uvozovek. Ještě nesmíme zapomenout na zadání konkrétní hodnoty SERVER pro definici recoder: v souboru secrets.yaml. Klikneme na menu Informace tohoto doplňku a použijeme jeho název, který by měl být ve všech případech core-mariadb. Hodnotu USERNAME nastavíme na  homeassistant.

V ostatních případech můžeme použít oficiální image z Docker hub a nebo nainstalovat klasickým způsobem pomocí balíčkovacího systému v linuxové distribuci. Doporučuji použít aktuální LTS verzi, tedy MariaDB 10.11. Po úspěšném spuštění databáze vytvoříme v MariaDB konzoli novou databázi, databázového uživatele s heslem, které jsme zadali do konfiguračního souboru a nastavíme plná oprávnění k této databázi:

MariaDB [(none)]> CREATE DATABASE homeassistant;
MariaDB [(none)]> GRANT ALL PRIVILEGES ON homeassistant.* to 'homeassistant' IDENTIFIED BY '_PASSWORD_';

Uživatelské jméno (proměnná USERNAME) pro definici recoder: v souboru secrets.yaml tedy zůstává i v tomto případě homeassistant. Hodnotu SERVER pak nastavíme dle našeho konkrétního scénáře, tj. jako IP adresu databázového serveru.

Dalším krokem je provést dump/zálohu aktuální dat. Pokud jsme v rámci instalace a konfigurace Home Assistanta v souvislosti s databází SQLite nic neměnili, jsou data uložena v hlavním adresáři v souboru home-assistant_v2.db. Abychom mohli s touto databází pracovat, potřebujeme mít nainstalovanou utilitu sqlite3, která je k dispozici jako balíček snad v každé linuxové distribuci. Dump/zálohu dat provedeme standardním způsobem:

# sqlite3 home-assistant_v2.db .dump > ha-database_sqlite.dump.sql

Nahlédneme-li do obsahu databázového dumpu, uvidíme tam několik specifik pouze pro databáze SQLite, na kterých by se následný import do MariaDB zastavil. Musíme tedy tyto řádky buď odstranit nebo nahradit.

Prvním krokem je spuštění níže uvedeného příkazu, který odstraní nepotřebné řádky, případně upraví některé znaky:

# sed -i -e '/PRAGMA.*;/d' -e '/BEGIN TRANSACTION.*;/d' -e '/COMMIT.*;/d' -e '/^ANALYZE.*;/d' -e '/^INSERT INTO sqlite_stat1.*/d' -e 's/"end"/`end`/g' ha-database_sqlite.dump.sql

SQLite databáze nepracuje s polem AUTO_INCREMENT, proto je ještě před importem potřeba najít všechny sloupce, nad kterými se používá PRIMARY_KEY a přidat tuto definici. Pro zjednodušení předpokládám jen ty sloupce, které jsou definované jako  INTEGER NOT NULL.

# sed -i 's/INTEGER NOT NULL,/INTEGER NOT NULL AUTO_INCREMENT,/g' ha-database_sqlite.dump.sql

Tímto způsobem se po importu dat automaticky nastaví pole AUTO_INCREMENT na hodnotu ID posledního vloženého řádku dané tabulky. Pokud bychom totiž přidali definici pole AUTO_INCREMENT pomocí ALTER TABLE až po naimportování dat, museli bychom pole AUTO_INCREMENT pro každou tabulku nastavit ručně pomocí SQL funkce  MAX.

Nyní již můžeme provést import databázového dumpu, který může vzhledem k větší velikosti databáze trvat i několik minut:

# mysql homeassistant < ha-database_sqlite.dump.sql

V tuto chvíli již konečně můžeme spustit Home Assistant s konfigurací, která využívá MariaDB. V logu se mohou objevit následující upozornění nebo chybová hlášení, kterých se nemusíme obávat, aplikace si tyto nesrovnalosti automaticky vyřeší. Kliknutím na položku Záznamy a Historie zkontrolujeme, že jsou původní data k dispozici, a pokud ano, máme migraci úspěšně za sebou.

ERROR (Recorder) [homeassistant.components.recorder.auto_repairs.schema] Column start_ts in database table statistics does not support double precision (stored=1.0 != expected=1.000000000000001)

WARNING (Recorder) [homeassistant.components.recorder.migration] Database is about to correct DB schema errors: ...

WARNING (Recorder) [homeassistant.components.recorder.migration] Modifying columns created_ts, ..., ... in table statistics. Note: this can take several minutes on large databases and slow computers. Please be patient!

WARNING (Recorder) [homeassistant.components.recorder.migration] Updating character set and collation of table statistics to utf8mb4. Note: this can take several minutes on large databases and slow computers. Please be patient!

Přechod na PostgreSQL

Pro fanoušky databáze PostgreSQL jsem připravil druhý praktický postup. I zde máme dvě možnosti instalace, pokud již tuto databáze nepoužíváme. Tou první je využít v případě používané varianty Home Assistant OS nebo Supervised vestavěný obchod s doplňky. Bohužel tato databáze standardně není k dispozici, a proto musíme pomocí volby Repozitáře přidat PostgreSQL TimescaleDB addon, který aktuálně obsahuje PostgreSQL verzi 15.3. Nyní již stačí najít a nainstalovat produkt Timescale.

Společně s tímto doplňkem doporučuji nainstalovat i doplněk pgAdmin4 od stejného autora. Jednoduše tak můžeme procházet databázovou strukturu a také změnit heslo, které je po instalaci a spuštění PostgreSQL nastaveno pro uživatelské jméno postgres na  homeassistant.

Po instalaci doplňku pgAdmin4 jej stačí spustit a zobrazit na postranní liště. Z doplňku Timescale si uložíme název hostitele, v mém případě 77b2833f-timescaledb, který použijeme pro přihlašovací údaje jak v doplňku pgAdmin4, tak v konfiguraci Home Assistant. Jakmile se úspěšně přihlásíme k databázi pomocí doplňku pgAdmim4, stačí už rozkliknout pole Login/Group Roles, vybrat uživatele postgres, pravým tlačítkem vybrat CREATE SCRIPT, zadat ALTER USER postgres WITH PASSWORD '_PASSWORD_'; a spustit.

Pokud nejsme příznivci webového rozhraní pro správu databází, pak je možné heslo změnit klasickým postupem z příkazového řádku. Potřebujeme k tomu jen název, pod kterým vystupuje doplněk Timescale – viz výše:

# docker exec -it addon_77b2833f_timescaledb /bin/bash
root@77b2833f-timescaledb:/$ su - postgres
77b2833f-timescaledb:~$ psql
psql (15.3)
Type "help" for help.

postgres=# ALTER USER postgres WITH PASSWORD '_PASSWORD_';
ALTER ROLE
postgres=# quit

Nyní ještě zbývá vhodně upravit soubor secrets.yaml a tedy databázového uživatele (proměnná USERNAME), poněkud netradičně, pojmenovat jako postgres a jako proměnou SERVER použijeme opět název doplňku jako hostname.

V ostatních případech instalace je opět možné opět využít oficiální image z Docker hub a nebo nainstalovat klasickým způsobem pomocí balíčkovacího systému v linuxové distribuci. Doporučuji použít aktuální verzi 16. Není-li v linuxové distribuci tato verze ještě k dispozici, můžeme použít oficiální repozitáře.

Po instalaci PostgreSQL je vhodné v konfiguračním souboru postgresql.conf upravit dle potřeby volbu listen_adresses a případně nastavit na *, tj. přístupné odkudkoliv. Dále pak ještě konfigurační soubor s oprávněními pg_hba.conf nastavit zdrojovou adresu/síť, ze které se bude Home Assistant připojovat. Po těchto změnách nezapomeneme na restart služby, vytvoříme databázi a databázového uživatele s heslem dle konfigurace v souboru  secrets.yaml:

# su - postgres
# postgres$ createuser homeassistant -P
# postgres$ createdb -O homeassistant homeassistant

Uživatelské jméno (proměnná USERNAME) v souboru secrets.yaml bude tedy homeassistant. Hodnotu SERVER pak nastavíme dle našeho konkrétního scénáře, tj. jako IP adresu databázového serveru.

Import dat budeme provádět trochu jiným způsobem. Pro migrace mezi různými databázemi existuje velmi zdařilá utilita PgLoader, která je k dispozici jako balíček pro různé linuxové distribuce. Předpokládá však, že již v databázi existuje struktura tabulek. Ze všeho nejdříve tedy upravíme soubor secrets.yaml, kde definujeme připojovací údaje pro PostgreSQL. Následně provedeme restart Home Assistanta.

Jakmile zjistí, že má používat jiný databázový backend a cílová databáze neobsahuje žádné tabulky, vytvoří kompletní strukturu. V tuto chvíli již můžeme vytvořit konfigurační soubor pro utilitu pgloader a provést import dat. V souboru db-migrate definujeme cestu k původní databázi SQLite a stejné připojovací údaje k PostgreSQL:

load database
  from sqlite:///tmp/home-assistant_v2.db
  into postgresql://USERNAME:PASSWORD@SERVER/homeassistant
with data only, drop indexes, reset sequences, truncate, batch rows = 1000
SET work_mem to '32 MB', maintenance_work_mem to '64 MB';

Konečně spustíme import dat:

# pgloader db-migrate

Pokud v tento okamžik provedeme restart Home Assistant a budeme si myslet, že máme hotovo, tak tomu tak bohužel nebude. V log souboru totiž s největší pravděpodobností uvidíme chyby tohoto typu:

sqlalchemy.exc.IntegrityError: (psycopg2.errors.UniqueViolation) duplicate key value violates unique constraint "states_pkey"
DETAIL:  Key (state_id)=(93) already exists.
[SQL: INSERT INTO states (entity_id, state, attributes, event_id, last_changed....]

To znamená, že data se sice úspěšně naimportovala, ale neprovedlo se nastavení pole AUTO_INCREMENT ve všech tabulkách podle poslední vložené hodnoty. Proto ty chyby s duplicitními záznamy. Pro opravu, tedy korektní nastavení ve všech tabulkách, jsem připravil jednoduchý skript  repair_autoincrement_psql.sh.

#!/bin/bash

DB="homeassistant"

SQL_TABLES="
event_data;data_id
event_types;event_type_id
events;event_id
recorder_runs;run_id
schema_changes;change_id
state_attributes;attributes_id
states;state_id
states_meta;metadata_id
statistics;id
statistics_meta;id
statistics_runs;run_id
statistics_short_term;id
"

for DATA in `echo ${SQL_TABLES}`; do

TABLE=`echo ${DATA} | cut -d ";" -f1`
COLUMN=`echo ${DATA} | cut -d ";" -f2`
SEQ="${TABLE}_${COLUMN}_seq"

TABLE_COUNT=`echo "SELECT COUNT(${COLUMN}) FROM ${TABLE};" | psql -t ${DB}`

if [ ${TABLE_COUNT} -ne 0 ]; then
psql ${DB} << END
SELECT SETVAL('${SEQ}', (select max(${COLUMN}) from ${TABLE}));
END
fi

done

Nejdříve zastavíme Home Assistant, aby se nesnažil logovat další záznamy, spustíme skript pod uživatelem postgres a poté opět nastartujeme Home Assistant. Chyby by se již neměly objevovat a původní data v menu Záznamy a Historie by měly být k dispozici.

# su - postgres
postgres$ bash repair_autoincrement_psql.sql

Pokročilé možnosti integrace recorder

V úvodu jsem se zmiňoval, že ve výchozí konfiguraci Home Assistant není uvedeno žádné nastavení databázového backendu. K tomu, abychom mohli přejít z SQLite na relační databázi MariaDB nebo PostgreSQL, definovali jsme sekci recoder: a proměnnou db_url a tak nám po několika dalších potřebných úpravách již vše funguje s novou databázi. Zde není potřeba nic dalšího řešit, řekneme si, o vše se postará plnohodnotná databáze.

To je pravda, nicméně se sama nepostará o jednu věc – množství dat. Sám jsem si toho všiml v podstatě až po integraci střídače fotovoltaické elektrárny, kdy se začal zvětšovat databázový dump v rámci nočních záloh. Víte, kolik máte senzorů, světel, různých pomocníků, skriptů, automatizací? Vyzkoušejte si zadat níže uvedený cyklus v menu Nástroje pro vývojáře → Šablony:

{%- for domain in states | groupby('domain') %}
  {{ domain[0] }}: {{ states[domain[0]] | count }}
{%- endfor %}

Zajímavá čísla, že? V mém případě vyhrávají senzory – celkový počet 553. V tuto chvíli bychom měli začít přemýšlet, které entity (typicky právě senzory, kterých bude u většiny z vás nejvíce) do databáze logovat nepotřebujeme. Pokud přeci jen ano, nebylo by vhodnější tato data ukládat do vhodnějšího software? Jeden takový existuje a v další kapitole se tomu budeme věnovat.

Ale zpět k problému velkého množství entit. Integrace recoder totiž umožňuje konfigurovat, které entity zahrnout do logování do databáze a které naopak ne. Ty je možné definovat podle tzv. domén (např. všechny automatizace), podle vzoru (pattern), podle konkrétních entit nebo podle typů událostí. Konfigurace může vypadat např. takto:

  recorder:
  db_url: !secret db_string
  exclude:
    domains:
      - automation
      - update
    entity_globs:
      - binary_sensor.vstup*
      - lock.zasuvka_*
    entities:
      - sun.sun
      - sensor.date
      - sensor.timestamp
      - sensor.pv1_power

Vše výše uvedené se tedy nebude do databáze ukládat. Samozřejmě můžeme využít opačnou volbu include:  pro případ, že bychom chtěli z již vyjmuté skupiny logovat vybrané položky.

Tímto způsobem přesně určíme, které entity logovat chceme a které nikoliv. Zbývá ještě poslední důležitá volba – retence dat, tedy jak dlouho držet v databázi historii. Výchozí hodnota je 10 dnů. Pokud jste tedy narazili na to, že v historii jakéhokoliv senzoru vidíte pouze několik dní zpět, definuje to proměnná purge_keep_days. Komu tato hodnota nevyhovuje, může ji buď navýšit nebo naopak snížit a důležitá data ukládat do jiné databáze.

Pokud se dostaneme do stavu, že databáze velice narostla a nechceme čekat, než se automaticky uvolní historické záznamy, můžeme využít volání služeb, které záznamy smažou. Spuštění jakékoliv interní služby můžeme provést v menu Nástroje pro vývojáře → Služby. Zde vyhledáme službu recorder.purge a zvolíme počet dnů, které mají v databázi zůstat. Jen pozor na volbu repack, v češtině poměrně nešťastně pojmenovanou Přebalit. Ta funguje na principu vacuum v databázi PostgreSQL, tedy že „setřese“ volné místo po smazání záznamů. Pokud ji zapneme, může se Home Assistant pod tíhou těchto náročnějších operací zpomalit.

K dispozici je ještě jedna užitečná služba pro mazání dat. Tou je recorder.purge_entities, u které můžeme ke smazání vybrat konkrétní entity nebo domény. Smazat je můžeme buď kompletně nebo opět se zadáním počtu dnů. Navíc kliknutím na odkaz Přejít do režimu YAML si můžeme kompletní definici některé ze služeb zkopírovat do schránky a použít např. pro automatizaci, která bude každou půlnoc promazávat nepotřebná data vybraných entit.

Ukládání dat do InfluxDB

Nejdříve trocha teorie, protože možná někteří o této databázi slyší prvně. InfluxDB je jiným typem databáze než předchozí případy. Jedná se totiž o databázi typu time series, která je primárně určena a optimalizována pro ukládání velkého množství časových řad. Poskytuje jazyk podobný SQL a disponuje řadou optimalizovaných agregačních funkcí. Obecný formát dat vypadá následovně:

<measurement>[,<tag_key>=<tag_value>[,<tag_key>=<tag_value>]] <field_key>=<field_value>[,<field_key>=<field_value>] [<timestamp>]

První položku measurement můžeme připodobnit k databázové tabulce, popisuje tedy na první pohled, o jaká data půjde. Položky tag a field jsou dvojice klíč – hodnota. Klíč tag_key a hodnota tag_value musí být vždy typu řetězec. Tagy jsou volitelné položky, ale jejich výhodnou je, že jsou indexované. Je možné pomocí nich efektivněji vyhledávat. Klíč field_key je typu řetězec, ale hodnota field_value již může nabývat různých typů, kromě řetezce, také číslo nebo logickou hodnotu. Hodnota field_value ve vlastně ta konkrétní hodnota, kterou do databáze ukládáme, společně s časovým razítkem  timestamp.

Pro lepší pochopení jsem připravil ukázku s ukládáním cen pohonných hmot. Do databáze budeme ukládat informaci o čerpací stanici, typu paliva a jeho ceně. Samozřejmě s vazbou na čas. Formát dat bude vypadat takto:

phm,cs=Praha-stanice1,palivo=diesel cena=39.90 1699552802000000000
phm,cs=Praha-stanice1,palivo=natural cena=38.50 1699552802000000000

Získat data můžeme pomocí jednoduchého SQL dotazu, který se v tomto případě neliší od SQL dotazů v relačních databázích:

select cena,timestamp from phm where palivo='diesel' and cs='Praha-stanice1';

Pro zápis dat buď použijeme známý příkaz INSERT, a nebo, což je můj oblíbený způsob, požadavek POST:

# curl -i -XPOST http://127.0.0.1:8086/write?db=phm --data-binary "phm,cs=Praha-stanice1,palivo=diesel cena=39.90 1699552802000000000"

Instalace a konfigurace

Krátký úvod máme tedy za sebou, pojďme se podívat na instalaci. Používáme-li Home Assistant OS nebo Supervised, pak opět stačí zavítat do Nastavení → Doplňky a vybrat InfluxDB. Doporučuji zaškrtnout možnost Zobrazit v postranním panelu a službu můžeme spustit. Nastavení není potřeba v zásadě nijak měnit, případně můžeme povolit nebo zakázat autentizaci – menu Nastavení, položka Auth.

Pokud budeme InfluxDB používat pouze s Home Assistantem a daný doplněk nebude nikterak dostupný z veřejné sítě, můžeme klidně autentizaci vypnout. Po úspěšném spuštění vytvoříme databázi – hlavní menu InfluxDB → InfluxDB Admin (ikonka korunky). Pokud máme aktivní autentizaci, pak ještě v menu Users vytvoříme uživatelský účet s heslem a oprávněním read+write do zvolené databáze.

V případě ostatních variant Home Assistant můžeme použít oficiální image z Docker hubu nebo nainstalovat klasickým způsobem pomocí balíčkovacího systému v linuxové distribuci. I přesto, že první verze ve větvi 2.0 vyšla na konci roku 2020, doporučuji pro tento případ zůstat na poslední větvi 1.8. Tuto verzi koneckonců používá i oficiální doplněk z obchodu Home Assistant. Pro jednoduchost budu v tomto případě ignorovat autentizaci, takže jen pomocí utility influx (distribuční balíček influxdb-client nebo přímo z dockerového kontejneru) vytvoříme databázi:

# influx
Connected to http://localhost:8086 version 1.8.10
InfluxDB shell version: 1.6.7~rc0
> create database homeassistant
> show databases
name: databases
name
----
_internal
homeassistant
>

Nyní ještě musíme nakonfigurovat Home Assistant, aby všechny nebo naopak jen vybrané entity automaticky posílal do InfluxDB. Konfigurace se provádí přímo v hlavním souboru configuration.yaml a může vypadat následovně:

influxdb:
  host: SERVERNAME
  port: 8086
  database: homeassistant
  default_measurement: state
  include:
    entity_globs:
      - sensor.*temperature*
      - climate.*
      - sensor.my_car*
    entities:
      - sensor.on_grid_l1_power
      - sensor.on_grid_l2_power
      - sensor.on_grid_l3_power
  exclude:
    entities:
        - sensor.my_car_temperature

Jako hodnotu SERVERNAME použijeme buď název doplňku, tj. v mém případě a0d7b954-influxdb nebo IP adresu služby/dockerového kontejneru. Máme-li nastavenou autentizaci, pak ještě přidáme řádky username: !secret influxdb_username a password: !secret influxdb_password s uloženými údaji v souboru secrets.yaml. Následně do definic include nebo exclude doplníme, které entity nebo bloky se mají logovat a které naopak nesmí.

Vizualizace v Grafana

Ačkoliv můžeme pro vizualizaci dat uložených v InfluxDB využít jeho webové rozhraní, většinou spíše sáhneme po nástroji Grafana. Instalaci si ukážeme opět dvěma způsoby. Pro variantu Home Assistant OS nebo Supervised nastalujeme pomocí Nastavení → Doplňky, kde vybereme Grafana. Po instalaci nezapomeneme kliknout na pole Zobrazit v postranním panelu a konfiguraci můžeme ponechat ve výchozím stavu.

V případě ostatních variant můžeme opět využít oficiální image z Docker hubu nebo nainstalovat pomocí distribučního balíčku. Ten však ve standardních linuxových distribučních repozitářích není, proto je potřeba postupovat podle oficiálního návodu.

Abychom mohli pracovat s daty uložených v InfluxDB, je potřeba v Grafaně přidat tzv. Data source. Připojíme se na webové rozhraní Grafany, buď klikem na postranní menu Home Assistant a nebo přistoupíme na IP adresu, na které běží, typicky na portu 3000.

Nový datový zdroj vytvoříme klikem na menu (tři vodorovné čáry v levém horním rohu) Connections → Add new Connection, vybereme InfluxDB a potvrdíme Add new data source. Vyplníme pole Name s názvem datového zdroje a pole HTTP URL v podobě http://SERVER:8086, kde buď vyplníme název doplňku InfluxDB, v mém případě a0d7b954-influxdb  nebo IP adresu, pokud je InfluxDB nainstalován mimo oficiální doplňky. Dále ještě doplníme pole Database v sekci InfluxDB details, a pokud používáme autentizaci, pak ještě i pole User a Password. Kliknutím na tlačítko Save & test se ověří konfigurace a pokud je vše v pořádku, je datový zdroj vytvořen.

Nyní můžeme vytvořit první vizualizaci. Podrobněji procházet všechna nastavení, jak pracovat s Grafanou, jakou syntaxi či omezení má Influx jazyk apod. by vydalo na vlastní článek. Proto jen opravdu ve zkratce s doplňujícím obrázkem. V InfluxDB máme (viz ukázková konfigurace výše) uložená data ze všech teplotních senzorů, které existují v Home Assistantu. Vytvoříme nový Dashboard pomocí menu Dashboards → New → New dashboard → Add visualization. Zvolíme dle předchozího kroku datový zdroj a otevře se nám základní pohled.

V dolní části Query zvolíme, jak bude vypadat dotaz do databáze a v pravé části můžeme upravovat vizuální styl grafu. V tomhle grafu budeme chtít zobrazit teploty ze všech senzorů, které ve svém názvu obsahují dva různé řetězce a pomocí klauzule GROUP BY podobně, jako v relačních databázích jednotlivá data agregujeme. Výsledný dotaz do databáze a graf bude vypadat následovně:

SELECT last("value") FROM "°C" WHERE ("entity_id"::tag =~ /vt/ OR "entity_id"::tag =~ /[0-3]p_temperature/) AND $timeFilter GROUP BY time($__interval), "entity_id"::tag fill(null)

Zálohování

Na chvíli se ještě zastavím u zálohování. Databáze MariaDB, PostgreSQL nebo InfluxDB instalované a používané jako oficiální doplněk v Home Assistantu nemají žádný oficiální postup, jak provádět zálohu dat. Ve svém nastavení tedy tuto možnost neobsahují. Máme tedy dvě možnosti. Nezálohovat vůbec, protože pro nás tato historická data nemají žádnou cenu. Nebo to zkusit trochu oklikou, z linuxového terminálu. Buď přímo nebo pomocí doplňku SSH & Web Terminal. Všechny nainstalované doplňky, jak víme z předchozích dílů seriálu, jsou ve skutečnosti dockerové kontejnery. Všechny tři databáze, se kterými jsme pracovali, obsahují i svojí klientskou utilitu. Můžeme tedy pomocí dockerových volání spustit jednotlivé zálohovací příkazy.

Ve všech níže uvedených případech se provede základní dump dat všech existujících databází bez dodatečných parametrů a uloží přímo na daný připojený Docker volume, abychom o tyto zálohy v případě restartu kontejneru nepřišli. Persistentní úložiště každého doplňku je typicky uloženo v /mnt/data/supervisor/addons/data/_NAZEV_. Samozřejmě je možné zálohy umístit kamkoliv jinam, třeba na sdílené úložiště. Záleží tak na každém konkrétním případě.

Ukázka zálohování MariaDB:

# docker exec -it addon_core_mariadb mysqldump -R -A > /mnt/data/supervisor/addons/data/core_mariadb/backup.sql

Ukázka zálohování PostgreSQL:

# docker exec -it --user postgres addon_77b2833f_timescaledb pg_dumpall > /mnt/data/supervisor/addons/data/77b2833f_timescaledb/backup.sql

Ukázka zálohování InfluxDB. Zde narozdíl od předchozích případů se pro uložení zálohy nepřesměrovává výstup, ale jako cílový adresář se uvádí cesta uvnitř dockerového kontejneru.

# docker exec -it addon_a0d7b954_influxdb influxd backup -portable /data/backup/

Pro instalace databází bez Dockeru jsou příkazy pro zálohování samozřejmě stejné.

Domigrováno

V tuto chvíli bychom měli mít vyřešený problém s nárůstem dat v interní databázi a s tím spojeného zpomalení. Dále jsme ještě vyřešili zálohování a navíc jsme získali, díky nástroji Grafana, další možnosti pro vizualizaci dat. Pochlubte se v diskuzi, zda máte nějaký speciální případ, kvůli kterému používáte grafy raději v Grafana, než přímo v Home Assistantu.

V příštím pokračování se podíváme pro změnu na frontend část Home Assistanta a tedy na pokročilejší práci s dashboardy společně s různými tipy, jak si právě vizuální rozhraní chytré domácnosti co nejvíce vylepšit. Abychom toho docílili, ukážeme si a nainstalujeme také HACS, díky kterému získáme přístup k velkému množství integrací a doplňků rozhraní od komunity a přispěvatelů.