Dobrý den,
mám pouze dřívější zkušenost s tímhle USB teploměrem, než jsem začal používat různé varianty od Zigbee (zmíním se o tom v některém z příštích pokračování).
Řešil jsem to voláním jednoduchého scriptu, který pravidelně četl informaci o teplotě z teploměru a uložil ji do souboru. A v Home Assistant na to pak použil vlastní sensor pro čtení ze souboru.
VS.
Ja som z papoucha tahal data cez snmp. Sice nie do home assistenta, ale do promethea, ale princip by mal byt ten isty. Treba si stiahnut mib a pozriet, ktory oid vycitat.
Jediny drobny zadrhel s papouchom bol, ze typ teploty bol integer a cele to bolo prenasobene 10. Takze skutocna hodnota bola vycitany integer / 10.
Zdravím, prosil bych o radu. Zrovna včera jsem vytvářel KVM HomeAssistenta na domácím RPI a snažil se nastavit abych měl k VM přístup z ostatních zařízení v domácí síti.
1. je určitě potřeba z githubu stáhnout správný image (samozřejmě s aarch64 v nazvu), což mi taky chvíli trvalo, protože v návodech to nenajdete :)
2. Routování jsem nastavil pomocí iptables takto:
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8123 -j DNAT --to-destination <ip kvm s HA>:8123
sudo iptables -I LIBVIRT_FWI -s <cidr domácí síte> -d <cidr kvm bridge> -j ACCEPT
uložení:
sudo iptables-save | sudo tee /etc/iptables/rules.v4
Problém byl že KVM nadto pořád přidávalo svoje pravidla a z:
ACCEPT all -- <cidr domaci site> <cidr kvm bridge>
ACCEPT all -- anywhere <cidr kvm bridge> ctstate RELATED,ESTABLISHED
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
bylo vždy:
ACCEPT all -- anywhere <cidr kvm bridge> ctstate RELATED,ESTABLISHED
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
ACCEPT all -- <cidr domaci site> <cidr kvm bridge>
ACCEPT all -- anywhere <cidr kvm bridge> ctstate RELATED,ESTABLISHED
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Nenašel jsem jinou možnost než přidat do `/etc/libvirt/hooks/qemu` a pak mi zůstalo moje pravidlo nahoře:
#!/bin/bash
GUEST_NAME="HomeAssistant"
echo "$1 $2" >> /tmp/hook.log
if [ "$1" = "$GUEST_NAME" ]; then
if [ "$2" = "started" ]; then
iptables -D LIBVIRT_FWI -d 192.168.100.0/24 -o virbr1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -D LIBVIRT_FWI -o virbr1 -j REJECT --reject-with icmp-port-unreachable
fi
fi
a použít na soubor chmod +x.
Mohl jsem to udělat nějak lépe? S iptables teprve začínám... Stejně tak KVM jsem použil poprvé...
27. 6. 2023, 08:53 editováno autorem komentáře
Ono to moze byt este zaujimavejsie, pokial je potreba odizovalovat iot-lan od main-lan.
Vtedy sa tiez bridguje, ci uz do vm alebo dockeru, ale iba interface pre prislusnu VLAN, plus zabezpecit ten reverzny proxy. Alebo, v pripade HAOS (t.j. vm, fyzicke zariadenie), ak ma ten viacero interfaces, da sa nastavit, na ktorom z nich ma hladat zariadenia cez multicast.
Ono je hezké říct, že nejjednodušší je instalace na Raspberry Pi (4 B), ale co teď, když Rpi není nikde skladem? Když se dívám třeba na Alzu, jsou tam
Raspberry Pi 3 Model B, případně asi nějaké klony 3 Model B+ (PRAIM, JOY-IT). Případně RADXA ROCK 4 SE 4GB, BANANA Pi M5.
Kolik bude potřeba paměti? Předpokládám, že 1 GB je málo. Co z výše uvedeného vybrat, abych na to mohl nainstalovat nějakou supervised/HAS-OS verzi?
A jakou paměťovou kartu nebo disk k tomu pořídit, aby to zvládlo zátěž?
Moc díky za konkrétní odpovědi a nápady. Potřebuji nějaký HW...
Co jsem tak koukal okolo, tak u Raspberry Pi by mělo stačit 2 GB RAM a 16 GB úložiště, pravděpodobně by i ten model 3B+ stíhal.
Osobně bych počkal na 4B a volil 4 GB RAM variantu; SD kartu pod 32 GB budete hledat dlouho, to nemá cenu. (Hlavně počítat s tím, že se ošoupe a včas ji vyměnit.)
Ale třeba se dočteme pár praktických rad v příštím díle... ;o)
27. 6. 2023, 10:34 editováno autorem komentáře
Tak nějak mi stačilo i 1 GB. Při nákupu nového bych se klonil spíše k těm 2 GB (cenový rozdíl není až takový).
Kartu jsem vybíral A1/A2. Jedna věc je rychlost*, druhá věc je, že IIUC tyto třídy budou typicky mít lepší controller, který bude s trochou štěstí řešit i wear leveling.
*) Dostal jsem nepoužívané Pi i s kartou (IIRC v označení nebylo nic lepšího než C10) a tak nějak to jelo, boot asi trval déle, ale hlavně aktualizace byly PITA. Jednak aktualizace HA trvala klidně kolem ¾h, ale hlavně během ní byl celý systém naprosto nepoužitelný. Nejen byl problém se jakkoliv připojit (web, SSH, …), ale byl problém i jen zhasnout světlo vypínačem (obojí přes zigbee2mqtt). Možná by pomohla větší RAM (větší cache => méně čtení z μSD).
Dobrý den,
v článku jsem uváděl několik alternativ k RPi, např. nějaký starý desktop, různé tenké klienti a nebo i vysloužilý notebook.
1GB RAM bude tak na hraně, lépe 2GB. Samozřejmě paměťová karta nevydrží tolik jako disk/ssd, ale u desktopů to není problém. Ale opět záleží k čemu budete HA používat a kolik dat ze sensorů budete ukládat (zápisy/čtení). Jakmile budete tím např. řídit FVE, pak máte opravdu hodně dat…
VS.
Permanentně puštěný notebook nebo počítač s Windows mít rozhodně nechci. A ano, zrovna na řízení FVE se chystám. Takže hledám alternativu RPi. Na základě výše uvedených rad - díky za ně - volím Radxa ROCK 4 SE s nVME diskem. Mělo by to být srovnatelné, či spíše o něco lepší, než RPi 4B. Tak snad se mi to podaří rozchodit:-)
Díky za článek, těším se na pokračování.
Mam dve instancie HA, jednu HAOS a druhu v dockeri.
HAOS na Odroid N2+ (co je v podstate presne to iste zariadenie, ako na uvodnom obrazku, len v skaredsej krabicke), so 4 GB RAM a 128 GB eMMC. HA so vsetkymi addonmi zoberie tak 1.2 GB RAM.
Druha instancia, v dockeri na Synology NAS, v cca podobnym rozsahom addonov, ale bez zvysku rezie HAOS, zoberie 250 MB (s mosquito mqtt a node-red 340 MB; plus ako reverzny proxy je pouzity nginx co bezi na Synology by default).
Ani jedna instancia nie je narocna na CPU, v podstate su idle. Slaby CPU sa prejavi len pri starte.
Jsem radikální fanoušek podmanu, doporučuji používat podman (pokud opravdu není sakra důvod používat docker). Třeba v tomto případě by výrazně pomohl:
podman generate systemd
- vygeneruje systemd unitu (parametry umožňují restartovat jeden kontejner, nebo pokaždé vytvořit nový, s různými jmény ... )
A když už to člověk má jako systemd unit (a nastaví správný label na kontejneru), může používat podman auto-update
pro pohodlnou aktualizaci.
Více v dokumentaci.
Chápu správně že příkaz podman generate systemd
vytvoří a zaregistruje skript pro automatický start kontejneru?
Pokud ano, proč rovnou nepoužít docker native cestu --restart unless-stopped
.
Ja mám v homelab jeden VM s alpine linuxem a dockerem... Vše pohodlně ovládám přes Portainer. Nevidím důvod proč bych měl pro každý kontejner generovat init skripty - do toho linuxu se příhlásím jenom když je nějaký problém na úrovni OS...
Sakra, člověče, nechcete napsat článek co podman umí? Já na to migroval nedávno z dockeru a ani jedno jsem se pořádně nenaučil. A tak mám docker-compose.yml a na update skript, co to přes systemd shodí, zavolá podman-compose pull, podman image prune --force a nahodí to znova.
Nějak tuším, že podman-compose lze přemigrovat na pod, ale zatím jsem se do toho dobrodružství nepouštěl.
Další nešikovná věc je, že ~/.config/systemd/user/podman-compose.service startuje při zalogování uživatele a nenapadlo mě nic lepšího, než znásilnit v init skriptech cosi, aby se na tty1 zalogoval uživatel automagicky bez hesla.
Mimochodem, ještě jedna věc ke zvážení při koupi HW: Pokud chcete spolu s HA používat i https://esphome.io/ plugin, chce to opravdu něco výkonnějšího, třeba v případě Maliny Pi 4 s víc RAM. Buildění firmware pro OTA updaty zařízení je poněkud náročnější. A rozhodně to stojí za to :)
Upřímně? pokud člověk si stím sám hraje s home assistenty, tak v poho...
Ale když to má zákazník, který zprva myslí, jak je to super... dostane facku potom co přestane jedna z věcí komunikovat, nebo dokonce odejde a není náhrada... Pak člověk kouká, že ten servis je mastnej a co hůř... pořád tomu člověku to řádně nejde. Jestli 5 let to funguje dobře je dobré, ale pak... To je lepší půl míče nasypat jinam...
Pokud to má obyčejný zákoš, má to patrně objednané od nějaké firmy a spravované nějakou firmou. A stejně jako se např. Loxone stará o svůj produkt, měla by se firma starat o HA (tj. aktualizace na ověřené verze, seznam kompatibilních IoT věcí kterých se bude držet a bude se starat o pluginy) a měla by to započítat do prodejní ceny. Pokud si někdo vážně myslí že může vzít OS produkt "as-is", začít ho přeprodávat bez práce a vydělat na tom, je na omylu (ale to platí u všech produktů)
Je to něco jako nezjistitelný čidlo na autě. Čidlo se pokazí, ale systém to nezjistí a myslí, že funguje, dokud auto nekixne... A to je samé s chytrou domácností. A opravdu Loxone dodá produkt po 5 letech jako náhradní díl? Byť za zvýšenou cenu? Ne.... dostaneš možnost koupit nové a je jim jedno jestli jsi kompatibilní nebo ne... A 10 let mají ze zákona držet produkt na náhradní díl. To i unich neplatí...
Presne tak ... typicky to specielne prave u dodavek od nekoho zcela vzdy dopadne tak, ze az neco umre, coz je jen otazka (kratkeho) casu, tak dotycny zjisti, ze nahradni dily nejsou zadne, kompatabilniho se nic poridit neda, a jedina moznost je, vyhodit to vse, a postavit to cele znova.
A vsichni hracickove dojdou drive nebo pozdeji k zaveru, ze uz je nebavi to neustake opecovavat, ze mechanicky ventil kterym otoci funguje lip, nez 30 cidel a vsemozne krivky nastaveni ... je to totiz presne stejne jako tamagoci.
Lidi v mem okoli si s timhle hrali uz pred 30 lety. Vsichni to uz davno vsechno vyhodili. Jednou z "neuzasnejsich" veci jsou treba "inteligentni" svetla, ktera si velmi "inteligentne" nerozvitite, kdyz se neco z toho podela, protoze se "usetrilo" 0,00001 promile porizovaci ceny domu za tech par desitek metru dratu.
A to se vyplati.
BTW: Videl sem na vlastni oci, ovladani v kazde mistnosti do drzaku cvaklym iphonem ... a majitel to zvladl znicit behem prvnich 14 dnu. Opetna konfigurace za 50kKc.
Dobrý den,
závislost na HA lze eliminovat v případě Zigbee žárovek, vypínačů i zásuvek pomocí přímého párování obou zařízení (tzv. "binding"). Zmíním se o tom v příštích dílech. Sám mám takto napárované všechny žárovky či LED pásky v domě k jednotlivým vypínačům, protože cokoliv ostatní dočasně oželím, že by nefungovalo, ale rozsvítit si chci v každém případě.
Jinak souhlasím s tím, že pokud chce někdo HA provozovat komerčně, je to úplně jiná disciplína a mělo by se k tomu jinak přistupovat...
VS.
JIste, ono toti vysroubovat zarovku z mista A a dat ji na misto B je neresitelny problem... bez toho, aby bylo treba nekde neco prenastavovat.
Ad vypinace, ty samozrejme zcela 100% zamenitelne jsou, kdyz dotycny vi, jak ktery funguje. Mozna nenahradi celou funkcnost obvodu, ale minimalne to svetlo rozsviti. Ostatne, kdyz na to prijde, nemusi tam ani ten vypinac byt, staci spojit ty draty ze?
Ale jo, mam z toho radost, uz nekolikrate jsem se osobne ucastnil vyletu bo okolnim bydlisti. Naplni pak bylo rozveceni a zhasinani inteligentnich svetel sousedu ... ve 3 rano. Beru to jako takove skoleni na tema technologie a bezpecnost, velice prakticke a nalezite nazorne. Nekteri uz to hodili do popelnic.
Tak už vám to tu psali výše.
Rozumný člověk udělá klasickou elektroinstalaci, jen pak místo vypínače dá nějaký inteligentní modul. Ten mívá fyzické tlačítko pro místní ovládání nebo stmívání a jako bonus ho můžete ovládat i z nadřízeného systému nebo jiného vzdáleného ovladače. Takže i když nejde wifi nebo umře "centrální mozek", místní tlačítko pořád funguje. A pokud bude nejhůř a umře ten modul , tak Franta od vedle vám na ty tři dráty vrátí normální vypínač...
Jen je dost výhodné na to myslet při stavbě a dávat hluboké instalační krabice.
K SMART domácnostem jen toto:
1. Bezpečnost - často si to lidé bastlí sami a zvládnout pak takto komplexní činnost, kde je nutné řešit párování, zabezpečení přístupu, kvalitní síťové prvky apod. Tohle prostě téměř nikdy nedopadne dobře. Drtivá většina lidí tomu nerozumí a nebo rozumí jen části. Ovšem NIKDY jsem ještě neviděl, že by to měli celé dobře (ne výborně) zabezpečené. Neuhlídají si totiž celý řetez. Výsledek je pak takový, že řešení ovládají telefonem a ten zabezpečený není nebo mají doma nějaký levný TP-Link shit apod.
2. Mnoho součástek nebude po více než 5ti letech sehnatelné. Soused má systém za cca 300 000,- řídil vše, tepelko, HVFE, infrastrukturu domu. Dělala mu to celé firma, ne on sám. Za cca 3 roky mu odešla "sběrnice" (tak to nazývá on i firma), kde se vše "sbíhá" a nová, která by byla pro něj kompatibilní a vhodná sice je, ale firma mu ji odmítá instalovat, protože neprošla jejich certifikací. No výsledek je takový, že má už dobře rok nefunkční SMART za 300K. Zde je mi téměř jedno, jestli je blbý on nebo firma. Je to ilustrace úskalí SMART řešení.
3. Nastavení. Jeden můj zákazník má celý domovní systém SMART. Pokrývá to mu to internet po celém domě, zahradě, dále zabezpečení zahrady, domu, garáže. Celý systém má v mísnosti cca 5x5 metrů. Switchů, servrů apod. fakt dost. Umí si z telefonu řídit vše od světel až po splachování hajzlíku. Teď jsem mu na jeho systém napojoval i závlahový systém a je to porod. Spojení není 100% stabilní a občas vypadne, což je veliký problém. Veliký problém je ovšem v tom, že jeho řešení dělala firma před cca 15 lety a dnes už nikdo neví (z té samé firmy, ta funguje dodnes), jaké tam jsou vychytávky na řízerní, skripty apod., takže hluboký zásah je problém. Jinak celá techniologie domu ho před cca 15 lety vyšla na více než 6M. Když jsem tam řešil onen zavlažovací systém, nestačil jsem se divit.
Schválně vše nerozepisuji, je to zbytečné. Za celých 10 let, jsem nebyl nikde, kde jim SMART systém 100% funguje a nebo kde když jim celý systém shodím, tak ho dotyčný zvládne i po několika letech do pár dní nahodit zpět. Mnoho mých zákazníků, kteří i třeba nejsou diletanti sami přiznávají, že po 10 letech už si přesně nepamatují, co kam psali, aby systém přizpůsobili. Doufají, že jim to nespadne a když jo, tak si hold vezmou volnou a celé to budou muset nastavit znovu, to umí. Navíc, jeden můj klient, když jsem mu při elektorinstalaci shodil celý dům, protože měl špatně popsané kabely, tak byl doslova v řiti. Tedy on ne, on byl v zahraničí na služebce, ale jeho žena s dětmi musela jít bydlet na týden k matce, protože dům se "zamkl" a nic nešlo, ani voda. Vše bylo až moc AI. No, vtipné :-D, to mi věřte. Prostě nějaká komponenta nenaběhla a vyžadovala ruční "zásah" - zákazník přijel a vše do hodinky nahodil. K čemu to ovšem je, když se to stane a není, kdo by to nahodil? K prdu.
Osobně všem říkám. Ano, uměl bych si SMART domáctnost nahodit, řídit kotel, el. kotel, HFVE, čerpadla, kamery a já nevím, co všechno, ale k čemu? Až během svátků odejde příkladně router, tak co? Budu mít zabité Vánoce apod.? Nehledě na to zabezpečení. Jak mohu vědět, že mé kamery nejsou i kamery někoho jiného :-D ... A že i takové případy znám. Za mě jsou takový lidé naivní, když se spoléhají na SMART řešení. Je to prostě jen taková loterie, že jim to bude fungovat i za 30 let. Můj systém, který je automatizovaný mechanicky či pomocí stykačů, relé nebo několika cestných ventilů (viz. topení) a jiných prvků bude fungovat i za 100 let a když se něco pokazí, náhrada vždy bude (resp. když ne, bude problém tak veliký, že tohle mě trápit nebude + toto tvrzení úplně neplatí o HFVE, ta je řešená jinak). Když třeba skončím v nemocnici a musel bych "spát" - což už jsem také jednou na cca měsíc musel, tak žena vezme mnou sepsaný manuál a vše zvládne řídit sama, včetně topení v zimě. A nebude muset nikam hrabat do nastavení sítě apod.
Můj názor? Za mě SMART nikdy, je to jen ztracený čas a peníze. To radši zainvestuji obojí do věcí, které mají větší smysl :-) třeba koupím náhradní čerpadlo do vrtu a čističky, a když se rozbije i během Vánoc, tak půjdu ven a za hodinku je vše zase v normálu.
ad 1) jasne, zatimco kdyz si koupite hotovy reseni, tak bezpecnost je lepsi... akorat ze vubec ;-)
ad 2) vyhoda otevrenych reseni - tu soucastku nahradite necim jinym...
ad 3) jasne, nastaveni se da zmrsit... ale to riziko je steny, jako kdyz vam elektrikar jen blbe zapoji draty... taky se stava :D
Ty rizika proti "konvencnim" reseni jsou podobna... ve finale nejvetsi slabinou je ten lidsky faktor, co to instaluje. A to bez rozdilu plati u medenych dratu ve zdi stejne jako i u tech chytrych reseni.
A tvrdit, ze po sto letech to vymenite stejne je neznalost toho, jak se to delalo pred sto lety ;-) Treba i obycejny vypinace/krabice mely tehda jiny rozmery, nez se pouzivaji dnes... takze nahradit porouchany stolety vypinac minimalne znamena, ze musite presekat krabici, takze hromada zedniciny kolem....
A i predstava, ze kdykoliv koupite jakykoliv nahradni dil je fakt naivni... to je jen o stesti, nikoliv o tom, ze by clovek i behem tech Vanoc sehnal cokoliv z konvecnich reseni, ktere se mu zrovna v ty dobe vyserou... :-)
ad 2) ... teorie vs realita. Nesezenes nic.
Muzu ti presne popsat jak tyhle veci fungujou.
Faze prvni - nadseni.
Ses zrucnej nadsenec a rozhodnes se si "zesmartit" svuj dum/byt. Zacnes nakupovat ruzny komponenty, tahat kablely, wifiny, ... psat vsemozny scripty, mozna si na to napises i nejaky ten treba webovy frontend. Nic co by spousta lidi nezvladla.
Faze druha - chlubeni
Svuj uzasnej automatismus zacnes ukazovat pribuznym/znamym/rodine ... ti co nejakou zkusenost maji, se obcas usmeji, ostatni nechapave hledi na to, jak takovou pitomost jde delat tak slozite.
Faze treti - vnucovani
Kdyz uz si do toho nalil ty penize, a tisice hodin casu, chces primet alespon nejblizsi rodinu aby to pouzivala. Takze se je snazis za pomoci vsemoznych prekazek (demontovani mechanickych ventilu ...) prinutit, aby konecne zacli to topeni nastavovat "smartovne".
Faze ctvrta - deziluze
Tvoje stara to postavila tak, ze bud ona nebo intelignetni barak, tvoje deti hledaji pikacu, ale v pokoji jim mrzne, protoze netusi jak to nastavit jinak. Ty navic musis neustale nekde neco vymenovat(baterky) opravovat a shanet nahrady a cely system porad hodiny a hodiny predelavat, protoze ta uplne kompatabilni nahrada zas tak kompatablni neni.
Faze pata - terminace
Uz si nepanatujes den, kdy bys nemusel zase nekde neco restartovat/prenastavovat/... manzelka se odstehovala k matce, deti te poslaly ... takze prave sis nechal pristavit kontejner a vse co jen zavani "smart" hazes do nej.
Nemohu se ubránit dojmu, že všechny vámi popisované nedostatky smart řešení nemají se smart řešením žádnou souvislost. Všechna pramení ve dvou nesouvisejících problémech:
1) Vůbec nerozlišujete míru "smartizace". Překombinovat a zkomplikovat tak, že se v tom nikdo nevyzná jde i vodovodní potrubí. Znám dost lidí, kteří netuší, kde mají hlavní uzávěr vody či jak je napojená pračka - jestli má nebo nemá vlastní uzávěr... Stejně tak "smart" řešení nemusí být nutně komplikované, záleží, co všechno je do něj připojeno a jak moc jsou řešení zdokumentovaná. A taky co je uživatel ochoten se naučit! A uživatelem nemyslím objednatele. Pokud sdílím dům s manželkou, musí být schopna ten systém sama ovládat, stejně jako asi chci, aby věděla kdy a komu platím nájem, i když se o to obvykle starám já.
A s tím souvisí:
2) Vámi popsaná nekompatibilita předpokládá uzavřená firemní řešení - to je u takové dlouhodobé instalace důvod s firmou prostě nespolupracovat. A zase to není binární: buď zfušovaný homemade nebo closed firemní. Stačí sehnat firmu, která svá řešení neuzavírá a kvalitně dokumentuje. I amatér nemusí být lempl a může chápat, že všechny změny systému musí dokumentovat.
Je to všechno jen otázka promyšlenosti systému. A to nahrává kutilům s přehledem, kteří ví, co mají od firmy chtít, co zvládnou sami a co naopak sami dělat nemůžou. No a pak je taky potřeba mít na to od firmy rozumnou záruku. Pak se prostě nemůže stát, že bude firma tvrdit, že jedinou možnost opravy neudělá, protože není certifikovaná. Prostě nefunguje zařízení, na které dali záruku, tak ho opraví ve sjednaném termínu.
1. Ano, bezpečnost bývá do nějaké míry problém. Třeba spousta lidí nepoužívá šifrované spojení, protože jsou v lokální síti. Což na telefonu/notebooku, který se připojuje k jiným sítím, které mohou třeba otrávit cache prohlížeče, není úplně ideální…
2. To může být do nějaké míry problém, ale zrovna HA toto relativně řeší. Možná nenajdete stejnou komponentu (holt vývoj), ale nejspíš najdete něco podobného. Možná si to vyžádá trochu jiné nastavení.
Ano, je dobré přemýšlet, co se může stát, když se některá část pokazí, a jestli máme nějaký rychlý plán B. Některé věci řešit jde za cenu nějakých kompromisů (např. ZigBee světla napárovaná přímo na vypínač, takže obcházejí řídicí jednotku). Hlavice na topení, která je schopna fungovat relativně samostatně – funkčnost trochu degraduje, ale nějak bude fungovat dál.
Na projekt HA jsem narazil uz kdysi, ale nejak se nerozhoupal k rozchozeni. Mel bych tu 2 bazarove ARM krabky, kdyby nekdo chtel:
* Nano-pi R2S 1GB RAM, hlinikove chlazeni s vetrackem
* NVIDIA Jetson Nano Developer Kit 2 GB RAM, pasivni chladic i s krabickou
ceny priznive, docker umi, zaruka osobni 6 mesicu
Postupoval jsem podobne. Tuya/SmartLife HW, SonOff, ale i IKEA atp. Od vypinacu, zasuvek, zarovek, ovladacu zalevani zahrady, detekce pohybu na kamerach....HA je naprosto super. Bezi mi v clusteru tri OrangePi One+ jednotek, pro strycka nahodu. Zel treba zalevaci kontrolery jsem si musel dopsat sam (resp, dohledat jak na to, projit navrhovane merge a pull requesty do HA, opravit v nich nedostatky a pak merge do me vlastni struktury). Nelituji.
Dalsim ukolem, nejspis na zimni obdobi je preklopit vsechny tuya jednotky na localtuya.