Názory k článku Home Assistant: ovládáme interní data a vizualizujeme

Už první článek mě motivoval si to vyzkoušet a snímat nějaké údaje, Nabídlo mi to samo i tiskárny, ale u většiny jen stav toneru, ale nikoliv třeba ddleko důležitější údaj a to sice počet vytištěných stran. Docela by mě zajímalo jak to přidat (tiskárny Canon, hodnota je dostupná přes SNMP.

A to jsem chtěl primárně sledovat data z teploměrů Papouch TME PoE a Papouch Quido pro počítání impulzů plynoměru. co jsem tu zdědil :-)

Ja tomu sice vobec nerozumiem ale trvalo to celkovo 7 sekund:
Google - home assistant snmp
https://www.home-assistant.io/integrations/snmp/
https://community.home-assistant.io/t/snmp-advice-guidance/374054/3

Zdravím
už ani nevím proč, ale používám databázi "influxdb", můžete mi někdo polopaticky napsat rozdíl mezi "MariaDB" ?

výhody/nevýhody

případně jestli lze data zmigrovat ?

děkuji

maria je klasicka relacni databaze a influx db casovych rad.

Jinak v HA pouzivam sqlite tak jak se to nainstalovalo a i influx. Influx tam mam jen pro to, abych mohl pouzit grafanu.

Mam tam 800 sensoru a ani na sqlite nepozoruju problem.

Jak data migrovat neporadim. Ani nevim, jestli tim neco ziskate.

V grafaně lze ale použít i sqlite přímo....máte nějaký důvod proč používat pro grafanu spíše influx?

Dobrý den,

ano, databázi SQLite je možné i v Grafana použít, nicméně InfluxDB (jakožto time series databáze) je na tento typ dat nejvhodnější. Lépe s nimi pracuje, má menší nároky na prostor, lépe se zálohuje apod. Je to podobné, jako ukládat logy do transakční databáze MariaDB/PostgreSQL apod. Je to možné, bohužel hodně lidí to takto dělá, ale člověk časem zjistí, že to je velmi špatný nápad.

VS.

Mě donedávna přišlo, že i SQlite funguje s grafanou velmi dobře. Nicméně od posledního upgradu grafany+sqlite pluginu se načítání velmi zpomalilo. Od té doby zvažuju čím dál tím víc, že přetransformuju data z SQlite do InfluxDB a doufám, že se mi problém vyřeší resp., že načítání grafů bude opět v řádu stovek milisekund a né v řádu sekund. Neustále to odkládám, protože je to pro mě hodně práce, ale na druhou stranu to čekání je dost otravné. Současně doufám, že to je skutečně neefektivitou databáze a né ničím jiným, aby to nedopadlo stejně.

https://www.influxdata.com/comparison/influxdb-vs-mariadb/

Dobrý den,

pokud myslíte migraci dat mezi InfluxDB a MariaDB, pak se obávám, že to nebude tak jednoduché a vlastně to ani nedává smysl. Jsou to dvě různé databáze k různým účelům.

VS.

Mne to zmysel dáva - ukladal som teploty zo senzorov do MySQL,lebo som s tým mal skúsenosti. Rád by som ale prešiel na InfluxDB.

Rozumím, v tom případě Vám asi nezbyde nic jiného, než si migrační skript sestavit sám. Tedy připravit SELECT, který data o teplotách získá z MySQL databáze a připraví je pro import např. pomocí POST požadavku, viz ukázka v článku.

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

Stačí tedy jen sestavit measurement, klíče tag + field a časové razítko.

Následně pak můžete vizualizovat v Grafana či s tím dále pracovat.

VS.

Ale pozor, ve standardu (bez rozšíření) není možné v HA jednoduše zobrazovat hodnoty z InfluxDB v lovelace ani data jinak v HA používat. Databáze podporovány HA jsou pouze SQLite, MySQL (MariaDB) a PostgreSQL.

Diky za tento další výborný članek z vyživného seriálu, který spoustě lidí pomůže se v obsáhlé problematice orientovat a nakopnout správným směrem.

Bohužel i v tento článku je jak červená nit protkán jedním architektonickým nesmyslem, kteý se bohužel jako mor rozšířil po Internetu a (skoro) všichni ho bez přemýšlení opakují...

Předchozí díly se zabývaly následující topologií: ZigBee zařízení -> MQTT -> HAOS - to stačí k tomu, abychom pochopili, jak hloupě a vyloženě špatně je další část cesty HAOS -> Recorder -> storage.

Vážení, uvědomme si v prvé řadě jak pracuje HAOS s MQTT - on "nepřehrává historii" (a má k tomu sakramentsky dobrý důvod), ale zaznamenává "poslední známý stav" - což je ale v případě senzorů (např. teplota, osvit, tlak, vlhkost...) úplně něco jiného než po systému vlastně chceme a požadujeme. Toto chování má ale zásadní význam a je v pořádku pro jinou kategorii senzorů - např. Dveřní senzor, tlačítko apod.

Zatímco v prvním případě chceme s nějakou granularitou a agregací *kontinuálně* zaznamenávat historii ve formě time series dat, v druhém případě opravdu nechceme přehrát např. předchozích 10 zazvonění zvonku...

Jenže HAOS neumí mezi těmito dvěma rozdílnými formami senzorů a přístupů rozlišovat a umí jen ten druhý způsob - jinými slovy předchozí historii se ani nenamáhá dozvědět (byť to persistentní session v MQTT umožňuje), on ji prostě nechce a *nikdy* nezpracovává (ani se ji nedozvídá!) - a díky tomu je jakákoli taková snaha na něj navěsit "Recorder" odsouzena k nezdaru prvoplánově...

Ze situace mohou vést dvě správné cesty:
a) HAOS -> recorder -> ... ale jen pro věci, u kterých to má opravdu význam a nepožadujeme (časově spojitý) záznam (např. poslední stav zvonku, ale už ne záznam "kolikrát denně nám někdo zvonil")
b) MQTT - > storage -> HAOS

Konkrétní příklad pro správnou architektonickou implementaci vypadá následovně Temperature&Hu­midity senzor -> zigbee2mqtt -> eclipse-mosquitto -> Telegraf -> InfluxDB -> HAOS/Grafana.

Pokud si chceme ušetřit bolehlav a umíme jen MQTT -> HAOS, nevadí, data (až se to naučíme) můžeme kontinuálně zaznamenávat do InfluxDB i HAOS současně, ale prosím, zapomeňme na HAOS/Recorder -> InfluxDB (např.). Jde to i bez problémů a v principu naprosto správně následovně:

A) senzor -> zigbee2mqtt -> MQTT
B1) MQTT -> HAOS
B2) MQTT -> Telegraf-> InfluxDB -> Grafana
B3) MQTT -> Telegraf -> InfluxDB -> HAOS

a to vše klidně i dohromady, dle správného účelu použití.

Místo Telegraf -> InfluxDB si dosaďtě cokoli co umíte, on Telegraf má těch output pluginů fakt hodně (včetně oblíbených MariaDB, PostgreSQL atd.)

Přiznávám, že mi konečně dorazily hračky, takže řetězec jako: zmáčknuto tlačítko -> switch on -> based on lux -> nope / beep budu teprve řešit, takže zde vhodný formát řetězce neporadím. Osobně se přikláním k čistému řešení ve formě:
A1) ZigBee device -> zigbee2mqtt -> MQTT
B1) MQTT -> Telegraf -> InfluxDB -> Grafana
B2) MQTT -> HAOS (toto jen pro případnou část tlačítko -> podmínka -> akce)
B3) HAOS -> MQTT
, ale musím vyzkoušet a zhodnotit neduhy v praxi...

Bohužel jak jsem už uvedl v úvodu - celý Internet je plný špatných (opakovaných/ko­pírovaných) návodů a příkladů jak spojit MQTT s HAOS a skrze jeho Recorder nebo obdobný přístup odsypávat data do stabilní databáze (+ eventuelně downsampling) - opravdu to je pitomost pro velkou část scénářů, kterou chceme realizovat. Používejme skvělé dostupné nástroje ke správným účelům a přemýšlejme nad tím...

PS: Až mi někdo vysvětlí a obhájí si tu (mně unikající) genialitu v MQTT -> HAOS -> Recorder -> DB, hluboce smeknu a omluvím se...:-r

1. Do nějaké míry dobrá připomínka – HA má svoje limity p4i práci s historií a je dobré s nimi počítat.
2. Na druhou stranu bych to ale nepovažoval za vyloženě špatnou cestu. Jednak to může být good-enough (jsme-li si vědomi omezení) a jednak i záznam z MQTT má svá omezení – zejména ne všechna zařízení budou komunikovat přes MQTT.
3. Formální – všechny výskyty „HAOS“ bych nahradil za „HA“.

Ad 1) Vzhledem k tomu, kolik lidi se pak snaží najít "otvírák na ohýbák" si troufám tvrdit, že spousta lidí vůbec netuší o čem jsem psal...:-), natož aby si takových limitů byla vědoma... (kolik najdete na Internetu zmínek o tom (jak říkáte) limitu a jak to správně řešit?) Ono se to netýká jen historie, ale bohužel i *aktuálního stavu* (a to už považuji za průser!), který pokud nemáme Retain msg u topicu nebo po startu HA nerestartujeme také např. zigbee2mqtt, který můžeme nastavit, aby "last known state" znovu opublikovalo do MQTT po svém startu, tak naše automatizace do *dalšího* vyskytu buď a) opětovné publikace aktuálního stavu, b) publikace nového stavu, totiž vůbec není schopna se správně chovat a nastavit svoje stavy a chování dle naprogramované logiky... - ano jsou obezličky, jak to řešit, o většině z nich široká uživatelská báze nemá ani tucha. A tyto omezení nevychází vůbec z MQTT, dosaďte si za to něco jiného - i když MQTT vynecháte, tak to rozumné řešení (bez obezliček v "mezikuse") nemá, navíc se v těchto sítích často nepočítá (v tomto případě) s možností obousměrné komunikace - takže není cesta aby si HA řeklo o aktuální známý stav, ale pouze trpně poslouchá "až mu něco přirazí pod nos" (což naštěstí může tím pádem ta obezlička většinou zachránit).

Ad 2) Je to špatná cesta obecně. Pouze za předpokladu, že "good enough" je limitující vstupní podmínka (ale o tomto ta série článků není a definováno to nebylo - začali jsme se ZigBee, stejně tak si za to dosaďmě cokoli podobně použitelného Z-Wave, LoRaWan či jakýkoli jiný IoT či IIoT) jsem schopen připustit, že to může být s výhradami přijatelné řešení (přestože nechápu proč, když už ta data máme zaznamenána, bychom se jich měli dobrovolně vzdát a jednoduše je (nevědomky) zahodit).

"zejména ne všechna zařízení budou komunikovat přes MQTT" a to jako prosím pěkně proč? Kočkopsodortohumus mohu vyrobit taky, ale to snad není našim cílem... (v principu to přece není vůbec o MQTT a naopak co do MQTT neprocpu? - samozřejmě v kontextu sítě, kterou tu řešíme...:-D)

Ad 3) A co takhle HA-like, pro mne je "HA" profesně taky něco jiného než v kontextu tohoto seriálu...:-)

1. Asi se shodneme, že je fajn to omezení ve článku zmínit.
Asi se taky shodneme, že nejspíš spousta lidí bude myslet zejména na optimistický scénář, a málo na možná selhání. Což někdy může být OK (když vypínač nezapne světlo, uživatel to vidí, a asi není ani žádoucí to zkoušet znova), v některých situacích ale může dávat smysl to zkoušet znovu.
Aktuální stav – to už se netýká jen recorderu. Nicméně minimálně u zigbee2mqtt bych řekl, že po restartu HA (i když zigbee2mqtt zůstane běžet) dostanu aktuální hodnoty celkem rychle.
2. HA není jen i zigbee2mqtt, ale je tu hromada dalších integrací. Něco třeba přes Bluetooth, něco přes Matter a někdo z různých důvodů dává přednost ZHA před zigbee2mqtt. Celkem chápu, když někdo chce ukládat data z toho všeho, samotný MQTT recorder mu vyřeší jen část (byť možná lépe), a stejně musí řešit recorder v HA pro zbytek.
A jinak pokud se chci dívat třeba na trend teploty v nějaké části bytu, je ní úplně fuk, že se pár hodnot (zejména při restartu HA) nezaznamenalo.
3. Home Assistant může běžet v rámci jejich OS, můžete v jiném OS použít docker-compose, a jsou tu nějaké další možnosti. Příspěvek se zjevně týkal samotného HA, ať už běží jakkoli, proto mi nepřijde na místě psát o HAOS.

Myslím, že na spoustě věcí se tu shodneme, mne je spíše záhadou, že se 1000x opakuje ta (dle mého špatná) architektura, ale nikdo se nenamáhá napsat ta omezení a uživatele varovat - i já si tím před časem prošel... a na správné řešení jsem si musel přijít sám, to se člověk nedočte... První věc poté, co jsem dostal "nějaká data" do HA jsem měl tři otázky - jak data zálohovat a co to vše obnáší (+ jak utéct z SQLite, nic proti ni, ale sbíraná data po několik let tam nenechám opravdu ani omylem...), jak vyřešit skutečné HA (= high availability), co znamená a způsobí náhodný a neočekávaný "výpadek" jednotlivých služeb v řetězci.

Záloha - otázka jasná, odpověď přímočará a mimo rozsah tohoto příspěvku

HA -> Recorder -> relační či timeseries DB - o takové řešení jsem zakopával na každém rohu a přitom si stačilo uvědomit, ze "HA neumí persistentní session do MQTT" (záměrně, bohužel ale pro vše) a víme, že jsme fakt blbě...

HA - na úrovni sítě neřešitelné, protože ZigBee i ve verzi 3.0 umožňuje jen jednoho koordinátora v síti (ne heartbeat není varianta multi-master, tedy multi-coordinator, to bychom museli šáhnout např. po Wirepas se zásadně jinou adopcí), na úrovni zpracování dat - viz výpadky

Výpadky:
- sensor(= ZED)/router/co­ordinator -> nejsou data, není co řešit; OUTPUT ZED mohu duplikovat (INPUT ZED - tady už je to tricky, ale řešení by se často dalo spáchat), routery - lze řešit vhodným MESH, coordinator nemá řešení (leda jako vertikální duplikace celé sítě)
- z2m -> nejsou staženy (= dekódovány ze ZigBee)/poslány (do MQTT) data, není co řešit (opět leda jako vertikální duplikace celé sítě i s koordinátorem)
- MQTT - data nějakou dobu "přežijí" na z2m, MQTT lze clusterovat (opensource Mosquitto neobsahuje), takže HA i FO lze zajistit - tady už jsme tedy celkem safe
- Telegraf - MQTT mohu replikovat do aleluja, takže pokud chci (jakože doma nechci), lze vyřešit (obvykle to není potřeba řešit, máme-li persistentní session do MQTT, jen v případě, že máme blbě nastavený (ale syntakticky správný) třeba až output plugin (nebo json_time_format pro input - grrr!), tak data jsou z MQTT vyčtena a nikam nezapsána - suck!)
- InfluxDB - vede na replication cluster-like řešení (zcela mimo sféru opensource, i verze 3.0 aka Edge zřejmě také mimo - viz https://www.influxdata.com/blog/the-plan-for-influxdb-3-0-open-source/ a poznámka o "Features that we’re likely to include in the commercial single server version of InfluxDB 3.0 might include: - Replicas for high availability!)

Tím je kritická cesta pokryta, zbytek už jsou jen další vrstvy, které data primárně neafektují a tedy výpadek obvykle tolerujeme...

A Docker/Podman či K8s based řešení přece není enterprise, který nelze doma multistrojově provozovat.

Ad "Aktuální stav" - to se bohužel pletete - možná v případě ZHA si zbytek HA řekne o "last known state" podobně jako to lze řešit restartem z2m po startu HA, ale pokud něco v MQTT není, z2m nemá důvod to poslat jen tak z plezíru - tedy HA to nemá jak z MQTT vyčíst - kde nic není ani čert nebere... Leda, že by v tomto případě HA prostřednictvím HA/z2m integrace si z2m řekla o to opětovné publikování (ale zase jen "last known state", protože ze sensorů to nejde "vyčíst" - viz Cluster end-pointy, kde GET/PUT není obvykle podporován)

Ad 2) Tady jsme se nepochopili - ja jsem narážel na fakt, že když už mám nasazeno celkem robustní řešení se středobodem MQTT, proč by si nějaká "integrace" měla šahat na něco přímo, proč by se data neměla "scházet" v MQTT a pak je zpracovat dle potřeby toho kterého soudruha - některé HA integrace jdou často přímo proti principům IoT a toho, jak to celé má být seskládáno - kolem HA se motá spousta lidí, kteří jsou rádi, že "něco" "nějak" funguje, ale už to vůbec nedomýšlí... - podobě jako jsou lidé, kteří si s výpadkem Internetu u sebe doma nezatopí... - a neříkejte, že nevíte na co narážím a nejsou to jen urban legends... (a že by měli myslet na backup plán - v tomto případě na linku do činského čoudu - jim nikdo neřekl...:-D)

Navíc většina lidí se o to "fuk" začne zajímat v okamžiu, kdy zjistí jak drahá jsou pro ně data, která nemají (či o ně přišli) a hrozně by je chtěli... Na rádoby populárním eZinu budiž, na tomto serveru bych předpokládal poněkuj jinou sortu audience i erudice (z obou stran) a tudíž i přístup k řešení problematiky...

Ad 3) Open jsme se minuli - HA jako high available, nikoli jako varianty nasazení HA komunitního projektu v konkrétní podobě...

Ma nejake vyhody pouzivat InfluxDB oproti TimescaleDB?

Co koukam, tak vsechny navody pouzivaji InfluxDB. Pritom TimescaleDB je take db pro time series data a osobne se mi s ni lepe pracuje.

Klasicke relacni db, jako MySQL ted neresim. Jde mi ciste o InfluxDB vs TimescaleDB.

TimescaleDB je nadstavba nad PostgreSQL se všemi klady i zápory z tohoto faktu plynoucími... (a rozpadlých (rozuměj neopravitelných) velkých databází využivající TimescaleDB je na Internetu docela požehnaných story, děkuji radši buď čisté PgSQL (zde bych se nasazení vůbec nebál pro odpovídající data) nebo nativní timeseries DB)

Osobně jsem velice zvědavý na InfluxDB v3.0 Edge přepsanou do Rustu...:-) (jen mne nakrkli s odložením k ledu Flux-u, takové derivate přes celou timeserie s ohledem na window step je lahůdka - ne že by to v SQL nešlo, ale ten zápis je čistě pro masochisty, asi stárnu...)

Osobně razím tezi, že nástroj by se měl používat na to k čemu byl určen - a tedy v čem by měl excelovat a nedělat otvírák na ohýbák... a proto mám-li jednoznačná timeseries data, proč je cpát do relačního modelu?

Jen poznámka k tomu vámi několikrát použitému " otvírák na ohýbák "
To nedává smysl - používá se " rovnák na ohybák " ( nebo lidověji " vohejbák " )...
A ano, celé to ZigBee to mqtt je přesně tohle.

"A ano, celé to ZigBee to mqtt je přesně tohle." - v tom případě ovšem rozporujete základní paradigmata IoT a IIoT, což spolu tady nepochybně nevyřešíme...:-)

no, influxdb je menej narocna jak na spravu, tak na pouzitie. Proste vhodna na male nizkorozpoctove projekty, ktore nedokazu riadne zaplatit cloveka. Niekde kde nevadi, ze pre vecsie mnozstvo zariadeni a vecsie mnozstvo metrik, je influx niekde na tretine az desatine vykonu oproti timescale...

Diky. Neco potrebneho jsem potreboval vedet.
Ja si prave stavim ovladani celeho domu (takze ne jen par zigbee zarovek) a rad bych vybral dobrou databazi, na kterou pak roky nebudu muset sahnout. Pokud je opravdu vykon InfluxDB o tolik mensi, zni to jako velky problem.

Rad bych uchovaval data idealne na porad :-)
Bylo by zajimave po 20 letech moct delat ruzne statistiky.
Co se tyka velikosti ulozenych dat, tak ta me tolik netrapi. 1TB SSD dnes stoji par drobnych...

Opravdu by me zajimalo, proc by se mela (a jaka je sance) TimescaleDB rozbit. Pouzivam jich vetsi mnozstvi na produkcnich serverech (ty nesouvisi s domaci automatizaci) a zatim jsem nikdy nemel problem. Mozna mam jen stesti?

Byl by k tomuto tvrzení o třetinové rychosti InfluxDB nějaký regulérní benchmark? Moje vlastní zkušenosti totiž hovoří pro zcela jinou aproximaci - jak co se týče spotřebovaného místa na disku, tak při vizualizaci (= queries)... (a opravdu se nebavím zrovna o home projektíku na Malině a podobně koncipovaném HW)

oni někde asi nějaká čísla budou. Z velkého nasazení má influxdb značné problémy při hodně zapisujících streamech s vysokou kardinalitou metrik najednou, tam výkon padá i o řád proti timescaledb, řešit se to dá předagregátorem a bulkováním zápisu. Influx má prostě drahé inserty a kompakce.

Influxdb je pak o hodně (nemám v ruce čísla) pomalejší při agregování na více než jednu dimenzi (klasicky něco group by time, room, device), jde to vidět o na spotřebě paměti a iops. To vlastně platí pro jakékoliv komplexnější dotazy než prostý select s jednou dimenzí, tam timescaledb vládne.

Hlídání thresholdů (pro alerty) má zase influx výrazně rychlejší a poskytuje stabilnější latency.

Jen doplním, že mluvím o nasazení pro metriky na infrastrukturu (sítě, servery, aplikace) v počtem atributů v desítkách tisíc.

Doporucujete pouzivat Node-RED?

Ja jsem pred lety potreboval na rychlo udelat ovladani topeni. Tenkrat jsem si zvolil Domoticz (dnes uz se skoro nevyviji) a psal jsem i samotne rizeni v nem. Myslim, ze to byla LUA.
Nebylo to chytre rozhodnuti. Proto jsem to asi 2 roky zpatky prepsal cele do Node-RED a Domoticz pouzil pouze jako uzivatelske rozhranni. Vse si povida pres MQTT. Dalo to mozna vic prace, ale nelituji toho.

Uplne se mi nechce spolehnout kompletne na Home Assistant. Kdo vi, kde ten projekt bude za par let?
Porad se mi vic libi myslenka mit samotnou logiku/rizeni nezavislou na GUI.
Koncept Node-RED + Domoticz se mi osvedcil a ted planuji pro cely dum Node-RED + Home Assistant (propojeni pres MQTT a data v TimescaleDB).

Jaky na to mate nazor/zkusenos­t/doporuceni?

narozdíl od HA jde aspoň definice a jejich flow rozumně testovat (přes test inject).

Mně tyhle nástroje připadají strašně děravý a postavený na vodě, hlavně infrastruktura postavená nad tímhle je podstatě nespravovatelná nikým jiným, což v jisté životní fázi může být značná nevýhoda.

"Mně tyhle nástroje připadají strašně děravý a postavený na vodě, hlavně infrastruktura postavená nad tímhle je podstatě nespravovatelná nikým jiným, což v jisté životní fázi může být značná nevýhoda."

Ano, to je velká pravda, ale pak vám pro doma nezbývá skoro nic jiného než něco hodně komerčního jako třeba LOXONE, i s těmi cenami.

Nebo to udělat tak, aby to šlo snadno vrátit do normálního stavu.
Například klasická elektroinstalace, jen pod vypínač zapojíte např. nějaký Shelly spínač, stmívač nebo ovladač rolet. Ty dráty pak zpět do módu normálního vypínače zvládne zapojit každý elektrikář.

Ja nechci pod vypinac davat nic. Delam kompletni rekonstrukci domu. Budu mit normalni vypinace, jen do nich povedou UTP a vypinac bude spinat 12V optocleny v rozvadeci. Svetla zase budou ovladana rele modulem z rozvadece.
Optocleny i rele ovladane pres Modbus RTU.
Mit hromadu elektroniky ve vypinacich, pokud to delam cele na cisto nechci.
Pokud by blbnul software, vzdy se tam da dat komercni PLC, nebo prodratovat optocleny s rele a degradovat to na hloupou elektroinstalaci.

A jak tím UTP protáhnete 240V (10/16A) až z toho budete dělat opravdu tu "hloupou" elektroinstalaci po staru? Já vám rozumím, kam tím míříte, jenže jste taky jen na půl cesty... (a nebo jinak - vsadíte si, že 12V (krát mA) je na věky?)

A to prodrátování optočlenů s relé v rozvaděči vám pak udělá elektrikář Franta od vedle až vás třeba někdo zabije v autě?
Asi ne, že, ten bude rád, když nespojí hnědý se žlutozeleným.
Krom toho, hledání revizáka na ten rozvaděč vám nezávidím - rozvaděč je výrobek...
Udělejte si to jak chcete, ale podle mne klasická elektroinstalace s použitím hlubokých instalačních krabiček ( aby se tam pohodlně vlezla právě ta "elektronika" ) je ideální řešení.
Můžete to pak budovat postupně a bezbolestně.
"Tohle světlo by bylo fajn ovládat z PIR čidla nebo stmívat podle denní doby?
OK, tak tam pod ten spínač něco strčíme, co to vyřeší.
Tuhle zásuvku bych rád ovládal na dálku a třeba měřil spotřebu?
Zas tam pod ni něco strčíme.
A to "něco" je v řádu dvou stokorun
Ouha, po čase se to rozbilo? tak tam zatím zapojíme normální vypínač, zásuvku a uvidíme...

Ale to, ze do nejakeho komercniho reseni vrazite statisice vam ale taky nijak nezaruci, ze vysledek strasne deravy nebude :-) Pouze doufate, ze za ty prachy to je to udelane poradne... ale ono tomu tak byt nutne nemusi. A u toho se jeste budete modlit, aby vam vyrobce neukoncil podporu zarizeni a s tim i zaplatovani bezpecnostnich der.

Slovy jiného přispěvatele, tak NODE-RED je "ohejbák na rovnák na ohejbák"

Jinak Domoticz má poslední stabilní verzi z června 2023, nepřijde mi to, že se nevyvíjí...
A pokud jste v něm psal nějaké ovládání topení, tak možná podobně byste dopadl i s HA.
To patří přímo do regulátoru a nadřízený systém má předávat požadované nastavení a sbírat data.
Když se tu řešiliy ty databáze, tak Domoticz to řeší tak, že podrobná data máte týden zpět a zbytek pak denní průměr plus třeba minimum a maximum.
Samozřejmě můžete průběžně odesílat do InfluxDb a a pak se v Grafaně ukájet nad 5 let starými pětiminutovými průběhy, ale nějak nevidím smysluplné využití.
Taky jsem před lety potřeboval vyřešit regulaci podlahového topení a v kombinaci Domoticz a ESPeasy to bylo za víkend hotové a to nejsem žádný programátor, ale spíš "lepič kódu".
ESPeasy nahrané do Sonoff Basic reguluje teplotu na požadovanou hodnotu a posílá do Domoticz info o teplotách podlahy a místnosti plus spotřebovanou energii a počet sepnutí relé.
Domoticz naopak odesílá do regulátoru požadovanou teplotu, třeba i s využitím jeho časovačů, určuje jestli se má regulovat teplota místnosti nebo podlahy a přijímá výše uvedená data.
Pokud by vypadl Domoticz, což se mi za těch 6 let nestalo, tak se mohu připojit na webové rozhraní každého regulátoru přes wifi, pokud vypadne wifi, každý regulátor vytvoří vlastní AP přes které lze ovládat.
Když vypadne elektřina, tak holt zatopím v kamnech...

Zdravíčko,

potřeboval bych pomoc. Provozuju HA v docker kontejnerech a zasekl jsem se na Influxdb. Dle rad se snažím držet verze 1.8. Zkoušel jsem i 1.8.10 ale můj problém to neřeší. Ten problém je v tom, že jakmile skrz volumes namountuju /var/lib/influxdb a /etc/influxdb (tyto se nachází uvnitř kontejneru) tak nejsem schopen uvnitř kontejneru pomocí influx prostředí vytvořit persistentní databázi. Po zavolání příkazu create database homeassistant nic ve složkách není. Pokud nevytovřím persistentní úložiště a pustím kontejner, vlezu do něj a vytvořím databázi, tak vidím, že se nějaké soubory do složek /var/lib/influxdb a /etc/influxdb vložily. Vtip dne je taky v tom, že pokud provozuju ten kontejner s persistentním úložištěm a ručně (třeba touch) vytvořím soubor uvnitř toho kontejneru ve složkách /var/lib/influxdb nebo /etc/influxdb, tak ho vidím v mountnunté složce mimo kontejner. Takže práva jsou asi ok. Napadá někoho v čem je ten problém? Moc děkuji za odpovědi.

Dobrý den,

jestli to pomůže, tak takto volám docker já:

/usr/bin/docker run --rm --name influxdb -p 8086:8086 -v /mnt/docker/influxdb:/var/lib/influxdb influxdb:1.8

Přičemž jsem jen vytvořil pod uživatelem root adresář /mnt/docker/in­fluxdb na podkladu, práva neměnil a zbytek jsem nechal na influxdb image, aby si vytvořila zbylou adresářovou strukturu. Adresář /etc/influxdb neřeším. Používám to takto opravdu dlouho a bez jakéhokoliv problému se zápisem.

VS.

20. 11. 2023, 08:45 editováno autorem komentáře