Tényleg ez a Home Assistant a de-facto smart home app?

Offtopic

Én ezt komolyan nem értem.... Mintha vennénk egy csomag spagettit, kiborítanánk, majd benyálaznánk a végét, majd összeragasztva ebből építenénk valamit.

Az egész a sajtreszelővel rejszolás... És még lehet az a kellemesebb dolog. Ez a körülményesség a konfigszerkesztés terén... Hogy keresel valamit, valami tök bot egyszerűt, és halvány lila fingod nincs még arról se, hogy merre kéne elindulni, mert a doksiban nincs egy faék épkézláb példa, a fórumokba meg amit találsz az kurvára nem segít... Teljesen inkonzisztens a kézzel írt konfig a webes szerkesztővel pl. trigger esetén... (Vagy még erre se jöttem rá hogy hogy kell rendesen). Hogy egy dologhoz van 6 féle plugin, de igazából egyik se működik rendesen....

Mielőtt nekiindultam úgy voltam vele, hogy a tököm se fog ilyenekkel kínlódni, megoldom zabbix-szal, azt ismerem, működik. Most megint inkább kihajítanám az egészet.

  • 496 megtekintés

HA-val hasonló bajaim vannak mint neked, de sajnos megkerülhetetlen, hatalmas a community körülötte, így az integrációk is ebben lesznek meg leginkább. Persze eléggé egyénfüggő, de ha akarom integrálni az inverterem, klímám, autóm, robotporszívóm, akármim, akkor ez lesz az a megoldás ami mindegyiket tudja. Ha mérlegre teszem, hogy mással mennyit szopnék/veszítenék, akkor még mindig ez a kisebb rossz.

A config file vs. gui agymenéssel nem tudsz mit kezdeni, egy olyan fejlesztési fázisban vannak, ahol maguk sem tudják feltétlenül hogy merre akarnak ezzel menni, és ez roppantul idegesítő. Viszont a telepítésre, karbantartásra és az üzemeltetésre van egy tippem: felejtsd el a dockeres idiótaságait, HA OS-t, meg az összes bloat szart, ott a Home Assistant core, hozzáértőnek szerintem azt érdemes használnia egy python venvben. Ez viszonylag tiszta, átlátható eredményt ad. Persze nem lesz "store" jellegű felületről egy kattintásra NVR belőle, meg 3D nyomtató manager, se NAS, virtualizációs platform, de ez a kutyának se hiányzik.

Mármint melyik része nem érdekel? A community alatt fejlesztői communityt értettem, nem a legyeket.

Ha kizárólag mqtt eszközeid vannak, vagy egyéb nagyon homogén megoldások (akár saját építési dolgok kizárólag), akkor azt használsz ami jólesik, kb. mindegy. Viszont sok esetben marha nehéz úgy eszközt választani, hogy az minden igénynek megfeleljen (ár, beszerezhetőség, funkció, stb..), és még a smart interface is olyan legyen ahogy az neked megfelel. Pl. csak azért nem fogok szarabb klímát venni, mert valami dzsunka gyártónak van mqtt-t tudó típusa, nem vagyok ennyire gazdag, és időmilliomos, jó nekem a Daikin :) Az meg hát úgy oldja meg ahogy, de a HA-ban van hozzá támogatás, és már core szinten, nem kell szarakodni 3rdp Pistike pluginekkel.

Ha legalább 5db ilyen probléma/eszköz jön szembe a házban, akkor hosszú távon sokkal idegesítőbb és megterhelőbb lesz bármi mást használni, amibe patkolhatod bele a támogatást, írhatod meg magad, ha egyáltalán lehetséges.

Persze te tudod, hogy miket akarsz használni, meg hogy mit hoz a jövő, én szóltam. Ha jól számolom 7 éve csinálom ezt, kezdtem pár smart relével, és saját fejlesztésű sw-vel, aztán én is azt gondoltam hogy majd a Zabbix jó lesz. Aztán jött az OpenHAB, Domoticz, és úgy 4-5 éve maradtam a HA-nál. Tetszik vagy sem, ha nagy, vagy nagy lesz a játszótér, akkor szummában ez fog a legkevésbé fájni, ebben biztos vagyok. Ha meg kicsi, és egyszerű, akkor ahogy írtam, tényleg mindegy mit használsz.

8db rest szenzorom van, csak a napelemes invertereknek kell gyakorlatilag. Eleve nem egy túl jó megoldás egy ilyen környezetbe a http poll, kerülöm ha van más lehetőség, és szerencsére nálam a legtöbb eszköznél van. Amúgy kb. 800-1000 szenzorom van, túlnyomó részt mqtt. Mondjuk az is gyalázat, hogy nem hogy típusonként, de szummában sem tudok egy egzakt számot kicsikarni a guin, szóval ne gondolod, hogy nagyon védem a HA-t.

A 30db rest senor limit kapcsán meg lennék lepve, tudsz erre linket mutatni? Én nem látok ilyet sehol.

Nem tudom már hol találtam.

Volt 28 sensor, hozzáadtam még párat (ip meg paraméter átír, egyébként tök ugyanaz mint az előzőek), majd ezekre random Unavailable-t dobott. Vagy 3 órát szoptam vele, mert az se derül ki, hogy miért (vagy legalább is nem találtam), amúgy ha az eszközt direktben curl-lel kérdezgetem természetesen mindig jó. Azt sejtettem hogy valami limitbe ment, csak gőzöm sem volt hogy mi és hol. Szóval ha csak 2 plusz szenzort adtam hozzá, akkor ment jól, látta az állapotát mindig, ha többet, akkor jöttek a random Unavailable-ok.

"Sose a gép a hülye."

Miért kell vagy jó az az mqtt? Mert ez se derült ki nekem... Azon kívül, hogy a mosqitto rövidítése és valami message queue, fogalmam sincs mi az és mire jó, azon kívül, hogy tegyünk be plusz egy servicet és egy hibalehetőséget az egész láncba.

"Sose a gép a hülye."

"on 3G networks.."

LAN-on van minden eszköz. A HTTP meg annyira minimalista, amennyire csak lehet: az arduinonak csak az első sor érdekes, ott a is GET utáni részt, de azt is max. 10 karakterig, a többi megy a levesbe. A válasz meg mindössze raw-ban az érték, illetve opcionálisan kapcsolható http1.1 header, hogy pl. ne kelljen a curl --http0.9 kapcsolóval szarakodni. De ennyi. Se XML, se JSON, se yaml, se semmi szar.

$ curl http://192.168.133.104/qt
23.40

"Sose a gép a hülye."

Azért, mert akkor fog válaszolni amikor kérdezed, és nem akkor fog magától pusholni/publisholni amikor az állapota megváltozik. Nagyon nagy különbség.

Ha nem arról szól a rendszered, hogy telefonról kapcsolgatsz lámpákat, meg hőmérsékleteket nézegetsz, mert az fun, hanem hasznos automatizációk és servicek lesznek benne, akkor a jó és reszponzív működéshez elkerülhetetlen, hogy közel realtime legyenek státuszinformációid (megnyomták a gombot, mozgást érzékelt a mozgásérzékelő, nyitást a nyitásérzékelő, egy izzó állapotot váltott, stb...). Erre a http queryk alkalmatlanok, mert vagy szét spameled velük az eszközöket (és akkor se lesz igazán reszponzív), vagy megnyom az user egy gombot, és majd pl. 5 másodperc múlva történik valami (jó esetben).

Szerintem nincs ilyen limit. 30db szenzor nem tétel, soha nem jött szembe ez semmilyen topicban, levlistán, és a doksiban sem látok ilyet. Ettől persze még lehet (pláne hogy az userek csak 3%-a használja a statisztikák alapján), csak kellene rá valami bizonyíték, azon kívül hogy "ha jól látom".

Onnét, hogy rendszeresen reportol akkor is, ha nincs változás. Mennyi a tápfesz, link quality (ha wireless), stb... Az csak a használható rendszer kritériuma, hogy státuszváltozásnál azonnal küldje az adatot, de ez nem zárja ki, hogy amúgy pl. 5-10 másodpercenként/percenként/akármikor ne küldhetne összesített státuszt. Akkus/elemes eszközöknél viszont úgy szokták csinálni, hogy deep sleepben van, és tényleg csak változás esetén ébred fel, és publikál (akku/elem státuszt is nyilván érdemes/szoktak ilyenkor küldeni). Cserébe 1db gombelemről egy hőmérő elmegy 1 évet, vagy többet, szóval valamit valamiért.

Megnéztem, ez szerintem ott fog elvérezni, hogy nincs ennyi szabad programkód. Kb. az egyik példa pár soros mqtt kódját tettem be, ~7000 bájt....

A komplett http szerver és kliens mindennel együtt befér ~5000 bájtba. Ezeket most kivettem, így 99% a programkód.

"Sose a gép a hülye."

Miért kell vagy jó az az mqtt?

 

A következő esetben nem rossz:

van egy akksis cuccod, ami az ido nagy reszeben alszik (nalam: ajtonyito elektronika).

Elvileg mqtt-ben felnyomja az allapotot, amit akar, es aludhat tovabb.

 

Hogy mitol jobb, mint egy kozponti szerver a lanon, amihez http get/posttal kommunikalnak?

Ez meg nekem is nyitott dolog, de itt egy egesz jo cikksorozat:

https://hackaday.com/2016/05/09/minimal-mqtt-building-a-broker/

 

Meg en se szantam ra magam mqtt-re. Egyelore nincs is tul sok eszkozom (4db). Iden fogom boviteni olyan 10-re. Ezekbol egyik se gyari, mind sajat epites.

 

Remelem 10 eszkoznel mar latszik, hogy kell-e nekem mqtt.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( zolti v | 2024. 01. 21., v – 18:18 )

Én is most nézegettem. Vettem egy esp32c6 devkit-et meg egy pár érzékelőt hozzá. Elkezdtem volna ismerkedni vele mikor rájöttem, hogy az esphome -vel csak egy konfig fájl kell és az elkészíti a programot majd utána használhatom az eszközt a Home Assistant -al. Viszont az esphome nem támogatja a lapot ezért most rendeltem egy másikat. Közben feltettem a Home Assistan -ot nézegettem és rájöttem, hogy ezzel így elvesztette minden értelmét a projektem én programozni akartam, nem szívni a konfigokkal. :(
Szóval érdekel mi lesz a vége.

Én teljesen saját cuccokat csináltam, lásd pl. itt: https://hup.hu/node/183945

Semmi varázslat, sima HTTP GET-ekkel megy minden.

Egyelőre az egyetlen előnyének az android appot és az azon készíthető dashboardokat látom, de szerintem simán meg lehetne csinálni zabbixban is.

"Sose a gép a hülye."

( hnsz2002 v | 2024. 01. 21., v – 21:43 )

Rájöttem mi az aktuális baj... 30 rest szenzor lehet max. Ez egy vicc...

"Sose a gép a hülye."