Ring-kamera és Home Assistant világítás: valódi automatizálások tanulságai

1. A cél: segítsen a lámpa, de ne vegye át az irányítást

Egy mozgásra felkapcsoló lámpa egyszerű ötletnek tűnik: valaki belép, a kamera érzékel, a világítás bekapcsol. A mindennapokban azonban a kikapcsolás, a második mozgás és a kézi használat dönti el, valóban kényelmes-e a rendszer. A rossz pillanatban lekapcsolt lámpa nem apró technikai részlet, hanem a használó számára a legfontosabb eredmény.

Ez az esettanulmány saját Home Assistant-rendszerünk négy világítási automatizálását vizsgálja. Két beltéri lámpa külön mozgásjelzést kap, két kültéri lámpa pedig több kamera jelzése alapján működik. A helyiségek, entitások és címek általánosítottak; a nyilvános leírás nem tartalmaz hozzáférési adatot vagy kameraképet.

A cikk nem egy minden házba változtatás nélkül bemásolható kész automatizálás. A dokumentált felépítést és annak következményeit mutatja meg: mi indítja a fényt, mikor engedélyezett, mire vár a kikapcsolás, és hol vannak a kézi használat védelmének határai. Ha először ismerkedsz a rendszerrel, az első lépések útmutató ↗ segít az alapfogalmakban.

2. Mit bizonyít a mostani vizsgálat?

A 2026. október 18-i ellenőrzés során csak olvasási kérésekkel vizsgáltuk a központ állapotát, a négy kiválasztott automatizálás konfigurációját és az entitásnyilvántartást. A központ Home Assistant Core 2026.10.2-t futtatott, a négy szabály engedélyezett állapotú volt. Ez erősebb alap egy régi feljegyzésnél, de nem helyettesíti a kamerák és lámpák megfigyelésével végzett élő próbát.

Nem futtattunk kapcsolási műveletet, nem indítottunk automatizálást, és nem változtattunk otthoni beállítást. A kódok szerkesztett, anonimizált oktatási minták. A korábbi gyakorlati tapasztalatot és a most olvasott konfigurációt külön kezeljük a javasolt továbbfejlesztéstől.

3. Az eseményláncot négy helyen lehet megszakítani

A vizsgálat sorrendje: kamera vagy mozgásforrás → Home Assistantban megjelenő jelzés → automatizálási döntés → kapcsoló és fizikai lámpa. Ha a lánc eleje működik, a vége még lehet hibás. A fordítottja is igaz: a kézzel működő lámpa nem bizonyítja, hogy a kamera eseménye eljut a központig.

A kamera alkalmazásában látható mozgás és a Home Assistant jelzése külön megfigyelés. A kamerakép megnyithatósága sem elég: lehet videó úgy, hogy az eseményátadás hibás, és lehet megérkezett mozgásjelzés úgy, hogy a videó még töltődik.

A Ring hivatalos integrációja felhőn keresztül kommunikál. Egy helyben működő MQTT-kapcsolat ettől még nem teszi a teljes Ring-adatutat internetfüggetlenné. Külön kell érteni a kamera szolgáltatását, az esetleges köztes hidat, a brokert és a központot.

Hibánál az első eltérő pontot keresd. Ha nincs Home Assistant-jelzés, ne a lámpa kikapcsolási késleltetésével kezdj. Ha a megfelelő jelzés és a szabályindulás is látszik, a feltételek és a célzott művelet következik. Ez sokkal gyorsabb, mint minden rétegben egyszerre átállítani valamit.

4. Mielőtt szabályt írsz: készíts egy rövid térképet

Válassz ki egyetlen mozgásforrást és egyetlen lámpát. Privát feljegyzésben párosítsd össze a megjelenített nevüket a tényleges entitásazonosítóval, és írd mellé, melyik integrációhoz tartoznak. Hasonló név mögött lehet régi és új kapcsolat, illetve ugyanannak a kamerának több eltérő jelzése.

A lámpánál különítsd el a Home Assistant állapotát és a fizikai eredményt. Attól, hogy egy switch on állapotot mutat, még meg kell nézni a megfelelő lámpát. Ha ezt nem látod, kérj a helyszínen tartózkodótól egyértelmű visszajelzést, és ne találgasd a két kimenet helyét.

Írd le előre a kívánt viselkedést is: nappal maradjon-e sötét, melyik kamera kapcsoljon fel, mindegyik jelzésnek meg kell-e szűnnie a kikapcsoláshoz, és mi legyen kézi felkapcsoláskor. A „legyen okos” helyett néhány konkrét esetet határozz meg.

Változtatás előtt legyen ellenőrzött mentés ↗ és kézi vezérlési lehetőség. Egy meglévő családi világítást ne alakíts át úgy, hogy közben nincs biztos mód visszaállni a megszokott használatra.

5. Mozgásállapot vagy pillanatnyi esemény?

A vizsgált szabályok binary_sensor entitásokat használnak. Ezeknél a kikapcsolt és bekapcsolt állapotot lehet figyelni. A mai hivatalos Ring-dokumentáció viszont eseményentitásokat is használ, és a korábbi bináris érzékelős felépítés lecserélésére hívja fel a figyelmet. A saját szabályok MQTT-s érzékelőit ezért nem szabad automatikusan egy új, hivatalos Ring-telepítés mintájának tekinteni.

Az event entitás állapota a legutóbbi esemény időpontját jelöli, nem folyamatos on/off jelenlétet. Egy csengetés például pillanatnyi történés. Ha ilyen forrást választasz, nem várhatsz tőle ugyanúgy „mozgás vége: off” átmenetet, mint egy megfelelő bináris érzékelőtől.

Előbb nézd meg, milyen jelzést ad a saját integrációd. A grafikus felületen az adott entitáshoz kínált indítót válaszd, és egy ártalmatlan értesítéssel ellenőrizd. A cikk későbbi bináris példáját eseményentitáshoz változtatás nélkül bemásolni hibás lenne.

A Ring–MQTT híd közösségi projekt, külön működési és karbantartási feladatokkal. A mostani nyilvántartási ellenőrzés az MQTT-platformot igazolta, nem az összes háttérszolgáltatás pontos verzióját vagy konfigurációját. Ezeket nem pótoljuk feltételezéssel.

6. A lámpát külön ellenőrizd, még az automatizálás előtt

Kezdd a megfelelő célentitás kézi vezérlésével, alkalmas időpontban, a helyszínen tartózkodók tudtával. Egyes eszközök light, mások switch entitást adnak. A vizsgált négy szabály switch.turn_on és switch.turn_off műveletet használ. Más rendszerben a megfelelő light művelet lehet helyes.

Ne általános kapcsolócsoportot válassz első próbának. Egyetlen célon ellenőrizd a bekapcsolást, a visszajelzett állapotot és a kikapcsolást. Jegyezd fel, nem kapcsol-e vele együtt másik lámpa is. A siker az adott fizikai kimenet megfigyelése, nem pusztán a gomb színének változása.

Ha a kézi vezérlés sem megbízható, előbb az eszközkapcsolatot kell rendezni. Ezen a ponton még nincs értelme a kamerazóna érzékenységét állítani. Ha a kézi művelet stabil, később egy elmaradt automatikus kapcsolást már szűkebb körben kereshetsz.

A jelen cikk készítésekor ilyen kapcsolási próbát nem hajtottunk végre az otthoni rendszeren. A sorrend az olvasónak szóló ellenőrzési módszer, nem új helyszíni teszteredmény. Hálózati feszültségű bekötést ne módosíts szoftveres hibakeresés közben; az külön villamos szakmunka.

7. A napnyugtás időablak nem egy fix esti időpont

A saját szabályok napnyugta előtt harminc perctől napkelte után harminc percig engedélyezik az indítást. Ez az otthon helyéhez és a napálláshoz kapcsolódik; a központ hely- és időbeállítása ezért lényeges. Nem a távolról használt laptop aktuális országából kell kiindulni.

A kültéri konfiguráció általánosított feltételrészlete:

condition: or
conditions:
  - condition: sun
    after: sunset
    after_offset: "-00:30:00"
  - condition: sun
    before: sunrise
    before_offset: "00:30:00"

Ez feltételrészlet, nem teljes automatizálás. A VAGY kapcsolat az éjfél előtti és utáni részt fogja össze. A beltéri szabályok egy régi sun feltételben használják a napnyugta utáni és napkelte előtti mezőket; ennek éjszakán átívelő jelentését a hivatalos dokumentáció külön leírja.

A mai dokumentáció az új grafikus szabályokhoz újabb Sun-csoportbeli feltételeket is javasol. A meglévő YAML értelmezése és egy új szabály felépítése ezért nem mindig ugyanazt a menüpontot jelenti. A félórás eltolás és a természetes sötétség érzete sem feltétlenül esik egybe: a kívánt fényhez később helyben ellenőrzött napmagasság- vagy fényérzékelés is választható.

8. A beltéri példa: egy mozgásforrás, egy lámpa

A két beltéri szabály felépítése hasonló. A kiválasztott mozgásérzékelő off→on átmenete indít. A szabály csak a megadott esti időablakban és kezdetben kikapcsolt lámpánál lép a műveletekre. Bekapcsolja a célt, majd a saját érzékelő on→off átmenetére vár.

A várakozást húsz perc korlátozza. Normál megszűnéskor, illetve a jelenlegi továbbhaladási beállítás szerint lejáratkor is a kikapcsoló művelet következik. Ez konkrétan olvasott konfigurációs tulajdonság, nem minden otthon számára ajánlott általános szabály.

A külön beltéri automatizálások előnye, hogy az egyik helyiség jelzése nem feltétlenül kapcsolja a másik lámpáját. Könnyebben látható, melyik kamera és melyik kimenet tartozik össze. A két szabályt ugyanakkor külön kell tesztelni: a hasonló felépítés nem bizonyít azonos fizikai működést.

Az indításkori „lámpa kikapcsolva” feltétel azt szolgálja, hogy a már égő fénybe a szabály ne avatkozzon bele. Ennek pontos korlátját később külön megvizsgáljuk, mert önmagában az állapotból nem derül ki, ki kapcsolta fel a lámpát.

9. A kültéri példa: több kamera, közös megvilágítás

A két kültéri szabály egyenként három mozgásforrást figyel, de külön lámpát céloz. Bármelyik forrás bekapcsolt állapotra váltása indíthatja a megfelelő szabályt, ha a feltételek teljesülnek. Így több megközelítési irányhoz ugyanaz a világítás kapcsolódhat.

A kikapcsolási várakozás szigorúbb: a konfiguráció mindhárom kiválasztott érzékelő off állapotát kéri. Ha az egyik kamera még aktívnak jelzi a területet, az összetett feltétel még nem teljesül. A három kamera közül tetszőlegesen az első megszűnésére lekapcsolni egészen más viselkedés lenne.

A források körét a kívánt megközelítési útvonalak alapján válaszd. Egy távoli, oda nem tartozó kamera hozzáadása feleslegesen tarthatja felkapcsolva a lámpát. Két azonos fizikai eseményt ismétlő entitás pedig könnyen többletindítást vagy nehezen érthető állapotot adhat.

A saját felépítésnél a később bevont új kamera is része a többforrású logikának. Ezért egy új kamera hozzáadása nem csak egy plusz indító: a kikapcsolást meghatározó érzékelőlistát és a hibapróbákat is együtt kell felülvizsgálni.

10. Miért nem egyszerűen háromperces időzítő?

Egy korábbi tapasztalatban említett körülbelüli mozgásjelzési idő és egy automatizálásba beírt háromperces késleltetés nem ugyanaz. Az érzékelő maga tarthatja aktívan a jelzést, míg a szabály egyáltalán nem használ külön háromperces delay lépést. A most vizsgált négy konfiguráció ilyen fix késleltetést nem tartalmaz.

Az a fontos kérdés, mihez képest számolod az időt: az első mozgáshoz, az utolsó eseményhez, a szenzor kikapcsolásához vagy a kézi felkapcsoláshoz? Ugyanaz a „három perc” ezekben egészen más eredményt adna.

A beltéri példa egy jövőbeli állapotátmenetre vár. A kültéri példa az aktuális összesített állapotot vizsgálja. Utóbbinál a már eleve teljesülő feltétel azonnal továbbengedhet; előbbinél egy már korábban megtörtént átmenetet nem feltétlenül lehet újra elkapni.

A tényleges érzékelési időt saját próbával kell megmérni. Most a jelzés tartási idejét nem mértük újra, ezért nem adunk belőle mindenkire érvényes számot. A ma igazolt húsz perc a konfiguráció várakozási felső korlátja, nem a mozgásérzékelő általános tulajdonsága.

11. A húszperces korlát és a lejárat következménye

Mind a négy saját szabályban continue_on_timeout: true szerepel. Ez azt jelenti, hogy ha a várakozás feltétele húsz perc alatt sem teljesül, a következő művelet ettől még végrehajtódik. A vizsgált sorozatban ez a lámpa kikapcsolása.

Fontos különbség: a lejárt idő nem bizonyít szabad területet. A szenzor lehet tartósan aktív, elérhetetlen vagy hibás állapotú. A jelenlegi konfiguráció ilyen esetben is továbbhaladhat a kikapcsolás felé. A cikk nem nevezi ezt általánosan biztonságos megoldásnak; a kívánt viselkedésről a helyi használat szerint kell dönteni.

Lehetséges továbbfejlesztés a normál megszűnés és a lejárat külön ága: például utóbbinál értesítés és kézi felülvizsgálat, vagy más, tudatosan meghatározott állapot. Ez nem most elvégzett javítás. Az otthoni szabályokat a cikk szerkesztése miatt nem változtattuk meg.

A húsz percet ne írd át gondolkodás nélkül rövidebbre. Előbb mérd meg a jelzések viselkedését, gondold végig a kimaradást, és legyen ellenőrizhető normál, illetve lejárati útvonal. A fény bekapcsolva maradása és váratlan kikapcsolása más-más kockázatot jelenthet az adott helyen.

12. A restart mód önmagában nem hosszabbít minden mozgásra

Mind a négy szabály restart módú. A Home Assistant ilyenkor az új indítás feltételeinek teljesülése esetén állítja le a korábbi futást és indít újat. A saját szabályok egyik felső feltétele viszont az, hogy a cél lámpa éppen off állapotú legyen.

Ha az automatizálás már bekapcsolta a lámpát, a következő mozgásnál ez a feltétel nem teljesül. Nem helyes tehát pusztán a restart szóból azt állítani, hogy minden új mozgás újraindítja a teljes időzítést. Az aktuális várakozás viselkedése és a felső feltételek együtt számítanak.

A single, queued és parallel mód sem általános javítás. Sorba álló régi mozgások később is kapcsolhatnak; párhuzamos futások egymás munkáját olthatják le. A futási módot a kívánt esetekre válaszd, ne egyetlen hibajelenség elfedésére.

13. Mit véd a kezdetben kikapcsolt lámpa feltétele?

A saját szabályok egy már bekapcsolt lámpa mellett nem indulnak új automatikus kapcsolási sorozatba. Ez hasznos alapvédelem: ha a családtag előre felkapcsolta a fényt, egy mozgásnak nem kell feltétlenül átvennie a későbbi kikapcsolást.

A feltétel azonban nem mondja meg, hogyan kapcsolódott fel a lámpa. Egy másik automatizálás, alkalmazás vagy fizikai gomb ugyanúgy on állapotot eredményezhet. Pontosabb úgy fogalmazni, hogy az induláskor már égő lámpát kerüli el a szabály, nem úgy, hogy minden kézi szándékot felismer.

Ha a fényt az automatika kapcsolta fel, majd valaki menet közben szeretné tartósan használni, az eredeti várakozó futás ettől még megmaradhat. Egy újabb gombnyomás viselkedését a tényleges kapcsoló és a többi szabály alapján kell vizsgálni. A kezdeti off feltétel nem teljes értékű kézi felülbírálás.

Haladóbb megoldás lehet külön automatikus/kézi üzemmód, vagy egy egyértelmű, a kikapcsolás előtt is ellenőrzött jelzés. A segéd létrehozása önmagában kevés: a használatnak tényleg át kell állítania, és minden érintett szabálynak következetesen figyelembe kell vennie. A cikk ilyen változtatást nem telepít a meglévő rendszerre.

14. Első próba: a jelzésből csak értesítés legyen

Új szabály építésekor először bizonyítsd az esemény beérkezését valódi lámpakapcsolás nélkül. Az alábbi teljes automatizálásminta kizárólag tartós felületi értesítést hoz létre. A binary_sensor.proba_mozgas kitalált név; megfelelő bináris érzékelődre kell cserélni.

alias: "Mozgásjelzés ellenőrzése kapcsolás nélkül"
triggers:
  - trigger: state
    entity_id: binary_sensor.proba_mozgas
    from: "off"
    to: "on"
conditions: []
actions:
  - action: persistent_notification.create
    data:
      notification_id: "mozgasesemeny_proba"
      title: "Mozgásjelzés megérkezett"
      message: "A kiválasztott érzékelő off állapotból on állapotba váltott."
mode: single

A grafikus automatizálásszerkesztő YAML nézetéhez való mintáról van szó. Nem a teljes konfigurációs fájlt kell lecserélni vele. Ne feledd: ha az érzékelő már on állapotban van, újabb mozgás nem feltétlenül hozza létre a mintában kért off→on átmenetet.

A próbát tényleges eseménnyel is vizsgáld, majd a nyomkövetésben nézd meg az indulást. A műveletsor kézi futtatása csak az értesítési részt bizonyítaná. A minta nem helyettesíti az event entitásnak megfelelő indítót; ahhoz a saját integrációd eseménytípusát kell kiválasztani.

Ezt az új próbát most nem hoztuk létre a saját otthonban. A kódot szintaktikailag ellenőrizzük, de nem állítunk fizikailag elvégzett tesztet.

15. Több érzékelő összesített megszűnésének értelmezése

A kültéri felépítés alapja, hogy mindegyik kiválasztott forrásnak kifejezetten off állapotúnak kell lennie. Az is_state vizsgálat ezért mást jelent, mint azt ellenőrizni, hogy valami éppen nem on. Az unknown és unavailable állapotot nem szabad bizonyított mozgásmentességnek tekinteni.

Az alábbi saját oktatási részlet csak várakozást mutat; a neveket cserélni kell. Szándékosan nem tartalmaz lámpakapcsolást, és lejáratkor megáll, ellentétben a ma olvasott saját szabályok továbbhaladó beállításával.

- wait_template: >-
    {{ is_state('binary_sensor.mozgas_a', 'off')
       and is_state('binary_sensor.mozgas_b', 'off')
       and is_state('binary_sensor.mozgas_c', 'off') }}
  timeout: "00:20:00"
  continue_on_timeout: false

Ez az actions lista egy lépése, nem önálló teljes automatizálás. Ha egy valódi bekapcsolás mögé tennéd, külön meg kell tervezned a lejárat utáni állapotot és a helyreállítást. A false beállítás egyszerű megváltoztatása önmagában nem ad kész világítási rendszert: akár égve is maradhat a korábban felkapcsolt lámpa.

Az aktuális állapotot figyelő várakozás már indulásakor továbbengedhet, ha minden feltétel igaz. Ez hasznos tulajdonság, de csak akkor, ha pontosan ezt akarod. Ha egy későbbi tényleges új eseményt szeretnél megvárni, más várakozási megfogalmazás kell.

16. Két relécsatorna és egymásra ható szabályok

A korábbi projekt egyik tanulsága a külön lámpakimenetek egyértelmű azonosítása volt. Kétcsatornás kapcsolónál nem elég tudni, hogy az eszköz „kapcsolható”: a megfelelő csatornát kell a megfelelő lámpához rendelni. A mostani regiszterellenőrzés aktuális switch célokat mutat, nem új hardveres bekötési auditot.

Vizsgáld meg külön az A és B kimenetet, és nézd át, mely automatizálások hivatkoznak rájuk. Ha ugyanarra a lámpára több szabály is kikapcsolást küldhet, a külön-külön helyes logikák együtt is okozhatnak váratlan sötétedést.

A két lámpát vezérlő kültéri szabályok hasonló forráslistája nem jelenti azt, hogy egyetlen közös, ütközésmentes állapotgép irányítja őket. Mindkettő saját futással és célállapottal rendelkezik. Az egyik kézi felkapcsolása és a másik automatikus indulása ezért külön eset legyen a próbában.

A részletes kétcsatornás kapcsolóhibakeresést külön cikk ↗ tárgyalja. Ennek a mostani esettanulmánynak az eseménylánc és a használati logika a célja. Ne változtasd meg egyszerre a kamera érzékenységét, a relékiosztást és a várakozást: utána nem tudnád, melyik változtatás okozta az eredményt.

17. Hol keresd a hibát, ha valami eltér?

A nyomkövetésben keresd meg az első lépést, ahol az elvárt történet megszakad. A szabály leírása hasznos szándéknyilatkozat, de a tényleges triggers, conditions és actions mezők mondják meg, mi fut. Egy régi megjegyzés és az aktuális konfiguráció eltérhet.

Ha a probléma kifejezetten az elmaradó felkapcsolás, a célzott Ring-hibakeresési útmutató ↗ külön olvasható. A célzott útmutató lépésenkénti hibakeresést ad; itt az egész működési történetet és a saját konfiguráció tanulságait foglaljuk össze.

18. Kimaradás és újraindítás: mi marad félbe?

Egy várakozó automatizálás nem ugyanaz, mint egy tartósan eltárolt kapcsolási terv. A Home Assistant újraindítása megszakíthatja a futást; nem szabad feltételezni, hogy utána ugyanott folytatja a mozgásra várást. A lámpa fizikai és a központ visszatérő állapota külön vizsgálat.

Hálózati kimaradásnál fontos, mit jelent az adott entitás unknown vagy unavailable állapota, és mikor válik újra hitelessé a visszajelzés. Egy visszatérő on állapot egy olyan indítónál, amely csak to: on feltételt kér, másképp viselkedhet, mint a szigorú off→on változat.

Az MQTT broker, a köztes híd és a Home Assistant újraindulási sorrendje is számíthat. Nem elég, hogy valamelyik szolgáltatás futónak látszik: az érintett jelzésnek és kapcsolócél visszajelzésének is helyre kell állnia. Az egész láncot együtt kell megfigyelni.

Helyreállítási szabályt csak a kívánt eredmény tisztázása után készíts. Ne kapcsoljon le automatikusan minden fényt pusztán azért, mert a központ újraindult. Az ilyen döntésnek tudnia kell, melyik világítás volt automatikus és melyiket használja valaki kézzel. A mai cikk nem telepít új induláskori vagy hibakezelő szabályt.

19. Ellenőrizhető próbasor és tanulságok

A sikeres egyszeri felkapcsolás után jönnek a használati próbák. Lehetőleg legyen helyszíni megfigyelő, és előre egyeztessétek, melyik lámpa változhat. A világítást ne tekintsd biztonsági riasztórendszer vagy folyamatos jelenlétérzékelés helyettesítőjének.

1. Kézzel ellenőrizd az egyetlen kiválasztott lámpát és kimenetet.
2. Kapcsolási mellékhatás nélkül bizonyítsd a tényleges mozgásjelzés beérkezését.
3. Vizsgáld meg nappal és az esti időablakban is a döntést.
4. Próbálj egyetlen mozgást, majd két egymást követő jelzést.
5. Többforrású esetben külön ellenőrizd az első megszűnést és az összes megszűnését.
6. Próbáld ki a már előre égő lámpát és a futás közbeni kézi használatot.
7. Külön, tervezett időben ellenőrizd a kimaradási és lejárati útvonalat.
8. A végén állítsd vissza a kívánt alapállapotot, és őrizd meg a működő konfiguráció mentését.

Próba dátuma és érintett szabály:
Kezdeti lámpaállapot és kézi/automatikus szándék:
Forrásjelzés ideje és típusa:
Indítás / feltételek / bekapcsolás eredménye:
Újabb mozgás és másik forrás eredménye:
Normál megszűnés vagy időkorlát:
Kézi használat és végső fizikai állapot:
Első eltérő lépés és a megfigyelő visszajelzése:

A legfontosabb tanulságunk: nem az automatizálás hossza teszi megbízhatóvá a világítást. A forrás helyes értelmezése, az egyértelmű cél, a várakozás pontos jelentése és a használó szándékának kezelése együtt ad jó eredményt. Ha pedig a fali tableten kameraképet is szeretnél ↗, annak megjelenítési logikáját a lámpáétól külön érdemes felépíteni.

20. Források és ellenőrzési dátum

Ellenőrizve: 2026. október 18. A saját konfiguráció tényeit az olvasási vizsgálat adja; a működési jelentésekhez hivatalos Home Assistant-dokumentációt és a Ring–MQTT híd saját fejlesztői leírását használtuk. A menük és az entitások verziónként változhatnak. A cikk saját szerkesztésű, anonimizált esettanulmány, nem teljes dokumentációfordítás.

1. Home Assistant – Ring integráció ↗
2. Home Assistant – eseményentitások ↗
3. Home Assistant – automatizálási indítók ↗
4. Home Assistant – automatizálási feltételek ↗
5. Home Assistant – napállásfeltétel és éjszakai időablak ↗
6. Home Assistant – automatizálások futási módjai ↗
7. Home Assistant – automatizálási építőelemek ↗
8. Home Assistant – állapotra várakozás és időkorlát ↗
9. Home Assistant – automatizálások tesztelése ↗
10. Home Assistant – automatizálások hibakeresése ↗
11. Home Assistant – MQTT integráció ↗
12. Ring–MQTT – a híd fejlesztői dokumentációja ↗