Ring-kamera és Home Assistant: miért nem kapcsol fel a lámpa mozgásra?

23 perc olvasás • Ismeretterjesztő útmutató • Frissítve: 2026-10-18

Lépésenkénti hibakeresés: Ring és MQTT jelzések, nyers állapotok, nyomkövetés, indítók, feltételek és a megfelelő lámpakimenet ellenőrzése.

1. Előbb találd meg a hibás lépést, utána változtass

A Ring alkalmazása mozgást jelez, de a lámpa sötét marad. Ez még nem árulja el, hogy a kamera, az integráció, az automatizálás vagy a kapcsoló hibázott. Ha mindegyik rétegen egyszerre állítasz valamit, könnyen elveszíted azt a nyomot, amelyből a valódi ok kiderülhetne.

Ez az útmutató egy célzott hibakeresési sorrendet ad az elmaradó felkapcsoláshoz. Mindig egyetlen kamerával, egyetlen kiválasztott jelzéssel és egyetlen lámpával dolgozz. A több kamerás világítás teljes működését a részletes esettanulmány ↗ tárgyalja; itt az első hibás lépést keressük.

A leírás 2026. október 18-án ellenőrzött dokumentációra és a saját projekt korábbi, illetve aznap olvasással igazolt tapasztalataira épül. A mostani cikk készítése nem indított kamerás próbát vagy lámpakapcsolást az otthoni rendszerben. Az új kódminták oktatási célúak, a bennük szereplő nevek kitaláltak.

A jó eredmény nem feltétlenül egy azonnal átírt automatizálás. Először egy pontos mondatot szeretnénk: „A Home Assistantban megérkezik az új jelzés, de a nappali feltétel megállítja a futást.” Ebből már ellenőrizhető következő lépés következik.

2. Rögzítsd a kiinduló állapotot

Írd fel a próba időpontját, a kiválasztott kamera és lámpa szerepét, valamint azt, hogyan szeretnéd látni a működést. Az entitásazonosítókat a saját privát jegyzetedben őrizheted; nyilvános segítségkéréshez általánosítsd őket. Két hasonló nevű érzékelőt így nem fogsz véletlenül összekeverni.

Ne töröld az integrációt és ne párosítsd újra az eszközöket első lépésként. A mostani konfiguráció, a napló és a nyomkövetés segíthet megérteni, mi változott. Egy gyors újratelepítés után lehet, hogy már nem ugyanazt a helyzetet vizsgálod, és közben új azonosítók vagy további függőségek is megjelenhetnek.

Ha a család használja a világítást, egyeztesd a próbát. A kézi vezérlés maradjon elérhető, és változtatás előtt legyen visszaállítható mentés ↗. A hálózati feszültségű bekötés vizsgálata nem ennek a szoftveres útmutatónak a része.

A próba előtt azt is nézd meg, már ég-e a lámpa, illetve aktív-e még a mozgásjelzés. Ha egy új off→on átmenetet vársz, a folyamatosan on állapot nem új indítás. A kiinduló állapot is a teszt része, nem csak az utána következő séta a kamera előtt.

3. Gyors döntési térkép

Az alábbi táblázat alapján válassz vizsgálati ágat. Mindig azt a legkorábbi pontot keresd, amelyről már nincs bizonyítékod. A videó és a mozgásjelzés két külön funkció; az egyik működése nem helyettesíti a másik ellenőrzését.

Mit látsz?	Első vizsgálati pont	Mivel haladj tovább?
A lámpa kézzel sem működik a Home Assistantból.	Célentitás, kapcsolat és fizikai kimenet.	A kamera szabályát egyelőre hagyd békén.
A Ring alkalmazás jelez, a kiválasztott HA-entitás nem frissül.	Kamera–integráció–esetleges MQTT híd adatútja.	A 6–9. fejezet szerinti forrásellenőrzés.
A HA-jelzés megérkezik, új futás nem látszik.	Bekapcsolt automatizálás, helyes indító és átmenet.	A 10–11. fejezet szerinti célzott próba.
A futás indul, de feltételnél megáll.	A konkrét hamis feltétel.	Napállás, lámpaállapot és további korlátozások.
A műveletig eljut, de a fény nem változik.	A tényleges cél és a kapcsolási eredmény.	Egyetlen lámpával végzett megfigyelt kézi próba.
Csak kézi műveletfuttatáskor működik.	Az a rész, amelyet a kézi futtatás nem bizonyított.	Valódi indítás és feltételek együttes ellenőrzése.

Ha több probléma is jelen van, egyszerre csak az egyik ágat zárd le. Az olyan megállapítás, hogy „kézzel jó, de esemény nincs”, már értékes eredmény: feleslegessé teszi a lámpakimenet további találgatását.

4. A lámpa kézi próbája: a fizikai eredményt is nézd meg

A Home Assistant megfelelő eszközoldalán válaszd ki az egyetlen vizsgált lámpát. Ellenőrizd, hogy light vagy switch entitásról van-e szó, majd alkalmas időpontban próbáld a megfelelő vezérlőt. Másik tartományhoz tartozó művelet vagy üres célcsoport nem ugyanaz, mint a helyes cél közvetlen kapcsolása.

A szoftveres állapotváltozás mellett nézd meg a valódi lámpát. Ha távolról dolgozol, legyen egyértelmű helyszíni visszajelzés. Kétcsatornás kapcsolónál különösen könnyű összetéveszteni az eszköz nevét azzal, melyik kimenet melyik lámpát működteti.

Ha a kézi próba hibás, ezen az ágon maradj. Az eszköz tápellátása, elérhetősége, a kiválasztott entitás és a kimenet összerendelése következik. Ne módosíts mozgásérzékenységet azért, mert a kapcsoló kézzel sem adja a kívánt eredményt.

A saját rendszer előző vizsgálatában négy aktuális cél switch entitásként, MQTT-platformon szerepelt. Ez nem minden Ringhez használt kapcsoló általános jellemzője, és nem helyettesíti a fizikai relé ellenőrzését. A kétcsatornás kapcsoló külön útmutatója ↗ ehhez a hibacsoporthoz ad további támpontot.

5. Nézd meg a nyers állapotot és a megfelelő entitást

A felületen megjelenő „Érzékelve” felirat nem feltétlenül az a szöveg, amelyet egy állapotindítóban használnod kell. Az entitás nyers állapotát és típusát a fejlesztői eszközök állapotnézetében ellenőrizd. A pontos menüelnevezés verziótól és nyelvtől függhet.

A sablonszerkesztőben például az alábbi, kizárólag olvasási célú minta segít:

Mozgás: {{ states('binary_sensor.pelda_mozgas') }}
Lámpa: {{ states('switch.pelda_lampa') }}
Mozgás éppen aktív: {{ is_state('binary_sensor.pelda_mozgas', 'on') }}

A két entitásnév helykitöltő. A sablon csak akkor mond valamit a saját rendszeredről, ha a tényleges entitásaidra cseréled. Egy rossz név miatt kapott unknown eredményt ne tekints a valós készülék állapotának.

Az állapotképernyő értékeinek kézi átírása nem azonos a kamera eseményének beérkezésével. Ilyenkor a szoftveres állapotot módosítanád, és akár más szabályt is elindíthatnál. A megfigyeléshez most ne használd ezt a funkciót; a valódi esemény útját szeretnénk bizonyítani.

Nézd meg azt is, a kiválasztott jelzés melyik integráció eszközéhez tartozik. Egy régi MQTT-s mozgásérzékelő és egy új, hivatalos Ring-esemény hasonló feliratot kaphat, de más indítást igényelhet.

6. Bináris mozgásjelzés vagy eseményentitás?

A binary_sensor rendszerint on/off állapotot ad. A vizsgált saját világítási szabályok ilyen forrásokra épülnek. Az event entitás viszont a legutóbbi pillanatnyi történés időpontját és eseménytípusát képviseli; nem ugyanilyen folyamatos mozgásállapot.

A jelenlegi hivatalos Ring-dokumentáció eseményentitásokat használó irányt is leír, és a régi bináris jelzések lecserélésére figyelmeztet. Egy régebbi MQTT-s példát ezért nem szabad az event entitásra pusztán a név kicserélésével átültetni. Az off→on feltétel nem időbélyeg-változásra készült.

A saját felületen az adott eszközhöz elérhető eseménytípust válaszd ki. Először csak értesítést kérj, és figyeld meg, hogy a valódi mozgás vagy csengetés létrehozza-e. A felület által kínált típus és a használt integráció dokumentációja fontosabb, mint egy másik házból származó kész YAML.

Ha egy régi entitás mellett már új is megjelent, írd fel, melyik frissül és melyikre mutat a szabály. Ne válaszd mindkettőt ugyanannak a lámpának az indítójául pusztán azért, mert így „biztosabbnak” tűnik: előbb értsd meg a kapcsolatukat.

7. Mit ellenőrizz a Ring alkalmazásában?

Elsőként azt állapítsd meg, hogy az adott kamera a kívánt helyen és időpontban valóban észlel-e új mozgást. A megjelenő régi videó nem új esemény. Az érzékelési zóna, a megfigyelt útvonal és a próba időpontja legyen egyértelmű.

A projekt korábbi leírása szerint egy személyérzékeléshez kapcsolódó értesítési beállítás visszakapcsolása után ismét érkezett reakció. Ezt megőrizzük mint történeti megfigyelést. A jelen cikk készítésekor ezt a mobilalkalmazásos változtatást nem ismételtük meg, és nem igazoltunk hozzá minden modellre érvényes oksági magyarázatot.

Ezért az ellenőrzés jó kérdése az, hogy a saját rendszeredben mit befolyásol az adott beállítás. A telefonra érkező értesítés és a Home Assistantnak továbbadott esemény nem feltétlenül ugyanaz az adatút. A telefon néma módja vagy az értesítés hiánya önmagában nem bizonyít hiányzó automatizálási jelet.

Ha egy beállítás változtatását mégis szükséges kipróbálni, előbb rögzítsd az eredetit, egyszerre csak egyet módosíts, és mérd újra ugyanazt az eseményt. A saját kamerádhoz tartozó aktuális leírást kövesd; ne kapcsold át találomra az összes értesítési és adatvédelmi opciót.

8. A hivatalos Ring-integráció vizsgálata

Nézd meg az integráció állapotát: van-e javítási jelzés, hitelesítési kérés vagy az időponttal egyező hiba. Az, hogy egy kamera kártyája még látható a dashboardon, nem bizonyítja a kapcsolat jelenlegi egészségét.

A hivatalos Ring-integráció felhőn keresztül működik. A Home Assistant dokumentációja a valós idejű eseményszolgáltatáshoz kimenő TCP 5228 elérést is említ. Ez nem azt jelenti, hogy internet felől bejövő portot kellene nyitni a Home Assistanthoz vagy a kamerához.

Hálózati vizsgálatot akkor végezz, ha a bizonyíték erre az ágra mutat. Ne kapcsold ki általánosan a tűzfalat, és ne töröld az összes engedélyezett Ring-klienst első javításként. A dokumentáció speciális hibakezelési lépéseit csak az adott tünet és előfeltételek alapján alkalmazd.

A bejelentkezési és kétlépcsős hitelesítési adatokat ne másold a hibakereső jegyzetbe. A javításhoz jellemzően az időpont, a hibatípus és az érintett kapcsolat megnevezése kell, nem a fiók jelszava. Ha hitelesítést kér a szolgáltatás, azt a hivatalos felületen kezeld.

9. Ha MQTT közvetíti a jelzést

MQTT-s felépítésnél külön réteg a kamera szolgáltatása, a köztes híd, az üzenetközvetítő broker és a Home Assistantban létrejött entitás. A broker futó állapota önmagában nem bizonyítja, hogy a kiválasztott kamera friss üzenete is végigérkezett.

Először az érintett entitás elérhetőségét és frissülését figyeld. Aztán a híd és broker időben ideillő állapotát vagy naplóját vizsgáld. A híd saját dokumentációja alapján ellenőrizd, nincs-e hitelesítési vagy kapcsolódási probléma. A Ring–MQTT külön közösségi projekt, nem a hivatalos Ring-integráció másik neve.

Ha üzenetfigyelés szükséges, csak az ismert, szűk körű, saját témát vizsgáld. Ne publikálj teljes témalistát, nyers üzenetfolyamot vagy konfigurációexportot. Más otthoni eszközök adatai és hozzáférési információk is bekerülhetnek egy túl tág hibakeresésbe.

Most ne küldj kitalált MQTT-parancsot a kapcsolónak vagy érzékelőnek. Az üzenet kézi előállítása más kísérlet, mint annak megfigyelése, hogy az eredeti kameraesemény megérkezett-e. A cikk céljához először a tényleges adatút bizonyítása kell.

10. Ha a jel megérkezik, de az automatizálás nem indul

Ellenőrizd, hogy maga az automatizálás engedélyezett-e. Ezután vesd össze az indító pontos entitását azzal, amelyet az előbb megfigyeltél. A hasonló megjelenített név nem elég; az azonosító és az elvárt állapotváltozás számít.

Egy kizárólag értesítési műveletű, bináris érzékelőhöz készült diagnosztikai minta:

alias: "Ring jelzés útjának próbája kapcsolás nélkül"
triggers:
  - trigger: state
    entity_id: binary_sensor.pelda_mozgas
    from: "off"
    to: "on"
conditions: []
actions:
  - action: persistent_notification.create
    data:
      notification_id: "ring_hibakereses_proba"
      title: "A mozgásjelzés elindította a próbát"
      message: "Most az indító útját vizsgáljuk, lámpakapcsolás nélkül."
mode: single

A nevet cseréld a saját, megfelelő típusú érzékelődre; ez a grafikus automatizálásszerkesztő YAML nézetéhez való teljes minta. Nem event entitáshoz készült, és nem a teljes configuration.yaml lecserélésére szolgál. A cikk készítésekor ezt nem telepítettük vagy futtattuk otthon.

Ha az érzékelő unavailable állapotból vált on-ra, a szigorú off→on indító nem ugyanazt az átmenetet kapja. A from elhagyása viszont újracsatlakozáskor is indíthat. Egyiket sem szabad vakon javításnak tekinteni: azt döntsd el, milyen átmenetre szeretnéd ténylegesen a reakciót.

11. A nyomkövetésből készíts rövid bizonyítékláncot

A Beállítások → Automatizálások és jelenetek alatt nyisd meg az érintett automatizálást, és keresd a nyomkövetést. A megfelelő időpontú futást válaszd, ne egy korábbi sikeres példát. A pontos felirat és elrendezés a használt Home Assistant-verziótól függhet.

A következő kérdéseket külön válaszold meg. Ha valamelyikhez nem látsz adatot, azt jelöld hiányzó bizonyítékként; ne töltsd ki feltételezéssel.

Nyomkövetési pont	Mit jegyezz fel?	Mire használható?
Futás időpontja	Egyezik-e a mostani próbával?	Megelőzi a régi és új esemény összekeverését.
Indító	Melyik változás vagy esemény indított?	Kiderülhet a rossz forrás vagy eltérő átmenet.
Feltétel	Melyik ellenőrzés igaz vagy hamis?	Megmutatja, ha a szabály szándékosan nem engedett tovább.
Művelet	Mi volt a tényleges cél és eredmény?	Elkülöníti a célzási hibát a korábbi megállástól.
Befejezés	Normál vége, hiba, megszakítás vagy még futó várakozás?	Megmagyarázhatja az ismételt mozgás viselkedését.

Ha nem találsz friss nyomkövetést, ellenőrizd a szabály engedélyezését, az indítót és azt, hogy a kiválasztott szabályhoz milyen nyomkövetési adatok állnak rendelkezésre. A hiányzó nyom nem önmagában bizonyítja a kamera hibáját.

A letöltött teljes nyomkövetési fájlt ne küldd azonnal nyilvános fórumra. Entitásneveket, változóértékeket vagy üzenettartalmat is tartalmazhat. Először a hibához szükséges rövid, anonimizált részletet foglald össze.

12. Elindult, de egy feltételnél megállt

Ha a nyomkövetés eljut egy feltételig, az eseménylánc korábbi része legalább az adott futásnál már működött. Ekkor ne új Ring-bejelentkezéssel kezdd a javítást. Nézd meg a konkrét hamis feltételt és azt az állapotot, amellyel a futás pillanatában számolt.

A saját rendszer előző esettanulmányban vizsgált szabályai napnyugta előtti félórától napkelte utáni félóráig engedik az indítást. Egy nappali mozgás ezért jogosan állhat meg. A helyes próbaeredmény ilyenkor nem az, hogy mindenáron felkapcsoljon a fény, hanem hogy pontosan az elvárt döntés történjen.

A napálláshoz az otthon helybeállítása és a központ időkezelése számít. A távoli laptop másik országban megjelenített óráját ne keverd össze az automatizálás helyi időablakával. A nyomkövetés időpontját is ugyanahhoz a próbához igazítsd.

Ne töröld az összes feltételt azért, hogy „végre történjen valami”. Külön ellenőrizd az egyes feltételeket, majd az eredeti szabály egészét. Az általános engedélyezés egy éjszakára tervezett világítást nappal is működtethetne, miközben a valódi eltérés nem derülne ki.

13. A már égő lámpa miért zárhatja ki az indítást?

A saját szabályokban a cél lámpa kezdeti off állapota is feltétel. Ennek általánosított részlete:

condition: state
entity_id: switch.pelda_lampa
state: "off"

Ez egyetlen feltételrészlet. Ha a valódi lámpa on állapotú, a feltétel hamis; ettől az érzékelő és az indító még lehet hibátlan. Ha a cél unknown vagy unavailable, azt sem szabad bizonyított off állapotnak tekinteni.

Előfordulhat, hogy a lámpát kézzel már előre felkapcsolták, egy másik automatizálás vezérli, vagy a visszajelzett állapota nem egyezik a megfigyelt fizikai fénnyel. Ezeket külön kell megvizsgálni. A kapcsoló állapotát ne írd át mesterségesen csak azért, hogy átmenjen a feltétel.

A próbát egyeztetett, ismert kezdőállapotból ismételd meg. A kezdeti off feltétel elhagyása már működésmód-változtatás lenne, nem pusztán hibakeresés. Azt is át kellene gondolni, mikor vállalja át a rendszer egy kézzel égve hagyott lámpa későbbi kikapcsolását.

14. A műveletig eljutott: mégis miért sötét a lámpa?

Nézd meg a művelet tényleges célját. Egy helyiség, címke vagy eszközcsoport más célzás, mint az előbb kézzel kipróbált egyetlen entitás. Ha egy csoportban nincs a művelethez megfelelő cél, a futás látszólag végigérhet úgy, hogy a várt fizikai eredmény elmarad.

Hasonlítsd össze a kézi és az automatikus próba műveletét. Ugyanaz a tartomány, ugyanaz a cél, ugyanaz a kívánt állapot? Egy régi eszközcserére vagy átnevezésre mutató hivatkozás különösen könnyen rejtve marad, ha a dashboardon már az új eszközt használod, a szabályban viszont még a régi szerepel.

A hibaüzenet és az időpont fontosabb, mint a teljes napló mennyisége. Az adott műveletnél látható figyelmeztetést vagy hibát keresd, és csak a szükséges környezetet jegyezd fel. A „kész” állapot nem minden integrációnál ugyanaz, mint egy fizikai visszaigazolás.

Ha a két relécsatorna összekeveredett, az nem a mozgásjelzés javítását igényli. Állj vissza az egyetlen kimenet megfigyelt kézi próbájához. A bekötéshez csak az arra jogosult szakember nyúljon; az alkalmazás beállításaitól nem lesz biztonságos egy bizonytalan villamos kapcsolat.

15. Kézi futtatás, ismételt mozgás és futási mód

A „Műveletek futtatása” lehet hasznos részpróba, de nem bizonyítja, hogy az igazi indító és a felső feltételek együtt működnek. Olvasd el, melyik teszt mit ellenőriz a saját felületeden. Az egész folyamatot egy tényleges, megfigyelt forráseseménnyel is végig kell követni.

A single mód egy már futó sorozat mellé nem indít új példányt. A restart módnál pedig az új indítás feltételeinek is teljesülniük kell. A saját vizsgált szabályokban a restart és a kezdeti off lámpafeltétel együtt szerepel; már égő lámpánál ezért nem szabad minden mozgást automatikus újrakezdésként értelmezni.

Ha a mozgásjelzés hosszabb ideig on marad, újabb fizikai mozgás nem feltétlenül új állapotátmenet. Külön mérd meg, mikor tér vissza off-ra, és mi történik a következő mozgáskor. Az a megfigyelés, hogy „másodszor nem reagált”, kezdőállapot és időpont nélkül még többféle helyzetet takarhat.

Ne válts parallel módra csak azért, hogy újabb futás jelenjen meg. A párhuzamos sorozatok később egymás világítását is kikapcsolhatják. A kapcsolási és kikapcsolási folyamatot együtt kell megérteni; az elmaradó indítás tünetét nem érdemes későbbi ütközésekre cserélni.

16. Frissítés vagy kimaradás után változott meg?

Jegyezd fel az utolsó ismert működő és az első hibás időpont közötti változásokat. Frissítés, átnevezés, eszközcsere, hálózati kiesés vagy új hitelesítési kérés más vizsgálati ágat adhat. Ne csak arra emlékezz, amit legutoljára a dashboardon szerkesztettél.

Ha egy entitás kimaradás után unavailable állapotból tér vissza, a régi off→on feltételezés már nem biztos, hogy illik az első átmenetre. Ugyanakkor egy meglazított indító újracsatlakozáskor felesleges kapcsolást is okozhat. A visszatérés kívánt működését külön kell eldönteni.

Egy központi újraindítás az éppen futó várakozásokat is megszakíthatja. Ez már nem egyszerűen az elmaradó felkapcsolás kérdése: nézd meg a lámpa végső állapotát és azt, van-e tudatos helyreállítási logika. Az összetett esetekhez az esettanulmány külön fejezetet ad.

A naplóban keresd a próbával időben összefüggő bejegyzést, és hasonlítsd össze a működő mentéssel. Ne állíts vissza teljes rendszert egyetlen rossz entitásnév miatt, de ne is találgass, ha több kapcsolat egyszerre tűnt el. A változtatás mértéke igazodjon az igazolt hibához.

17. Mit tanultunk a saját rendszerünkből?

A projekt történeti tapasztalata szerint a kamera alkalmazásában látható működés mellett is hiányozhatott a Home Assistantban várt reakció. Egy személyészleléshez kapcsolódó beállítás változtatása után ismét érkezett válasz. Ez jó nyom az adott történethez, de nem elég arra, hogy minden hasonló hibához ugyanazt a kapcsolót ajánljuk.

A mai korábbi esettanulmány olvasási vizsgálata négy engedélyezett világítási szabályt talált Home Assistant Core 2026.10.2 alatt. Négy konkrét megvizsgált mozgásentitás MQTT-platformú volt, és a négy aktuális kapcsolócél is MQTT-s switch entitásként szerepelt. A platformot az entitásnyilvántartás igazolta, nem a megjelenített név.

A két beltéri és két kültéri szabály közös tanulsága, hogy az indítás, a napállás és a cél kezdeti állapota együtt határozza meg a reakciót. A többkamerás megszűnési várakozás és húszperces korlát a későbbi kikapcsoláshoz tartozik; ezeket nem kell az esemény hiányának első vizsgálatába belekeverni.

Ehhez a cikkhez ezt az aznap archivált bizonyítékot használtuk fel. Nem végeztünk újabb fizikai kapcsolási próbát, nem változtattuk meg a Ring alkalmazását, és nem állítjuk, hogy az összes történeti beszélgetést most újraolvastuk. A korábbi megfigyelés, a konfigurációs bizonyíték és a javasolt próba külön szerepel.

18. Ismételd meg a próbát rendezett esetekkel

A véletlenszerű próbálkozást váltsa fel néhány rögzített eset. A siker és a jogos elutasítás egyaránt lehet helyes eredmény. Egy éjszakai szabálynál a nappali mozgásra nem bekapcsoló lámpa például az elvárt működés része is lehet.

Próba	Mit kell megfigyelni?	Mikor tekinthető értelmezhetőnek?
Egy lámpa kézi vezérlése	Célazonosító és valós kimenet.	A megfelelő fizikai fény változását is visszaigazoltad.
Csak forrásjelzés	Nyers állapot vagy új esemény.	A mostani mozgás időpontjához kapcsolható.
Kapcsolás nélküli diagnosztika	Új futás és felületi értesítés.	Valódi indító hozta létre, nem csak kézi műveletfuttatás.
Nappali és esti próba	Ugyanaz az indító, eltérő feltételeredmény.	Az adott időablaknak megfelelő döntés születik.
Előre bekapcsolt lámpa	Kezdeti off feltétel eredménye.	Az elutasítást nem tekinted tévesen hiányzó kameraeseménynek.
Két egymást követő mozgás	Első megszűnés, második átmenet és futási mód.	Az érzékelő állapotát is feljegyezted a mozgások között.
Kimaradás utáni visszatérés	Elérhetőség és első állapotátmenet.	Tervezett próba, visszaállási lehetőséggel és ismert elvárt működéssel.

Kimaradást vagy újraindítást ne idézz elő indokolatlanul a család által használt rendszerben. Előbb az egyszerű, kisebb beavatkozású ágakat zárd le. Egy meglévő, már rögzített hibás futás gyakran több információt ad, mint egy újabb teljes újraindítás.

19. Így kérj segítséget a fórumon

A jó hibaleírás röviden megmutatja, hol van már bizonyíték és hol nincs. Az „egyik sem működik” helyett írd le például: „A lámpa kézzel működik, a mozgásentitás off→on változása látszik, a futás a napállásfeltételnél áll meg.” Ezzel a segítség is sokkal célzottabb lehet.

Kamera és használt integráció általános megnevezése:
Home Assistant verzió és próba időpontja:
Lámpa típusa / kézi próba eredménye:
Megfigyelt jelzés típusa és nyers átmenete:
Automatizálás engedélyezett állapota és futási módja:
Legutóbbi friss nyomkövetés első eltérő lépése:
Rövid, anonimizált hibaüzenet:
Eddig kipróbált egyetlen változtatás és eredménye:
Elvárt és tényleges fizikai működés:

A személyes adatokat, helyi vagy távoli elérési címeket, MQTT-témákat, fiókazonosítókat és titkos értékeket hagyd ki. Teljes kameraképet vagy nyers konfigurációexportot ne küldj csak azért, mert egyszerűbb csatolni. Ha egy képernyőrészlet szükséges, előbb nézd át és takard ki a nem oda tartozó adatokat.

A közösségi oldalon ↗ kérdezhetsz vagy cikkötletet is küldhetsz. A hibaleírásban írd meg, melyik fejezetig jutottál el. Ettől nem kell újra megismételni minden alapellenőrzést, és világos marad, hogy a következő lépés megfigyelés vagy már valódi működésmód-változtatás lenne.

20. Források és a bizonyíték határai

Ellenőrizve: 2026. október 18. Az útmutató saját szerkesztésű hibakeresési módszer, hivatalos dokumentációval és anonimizált projekttapasztalattal. A menüpontok, entitások és kínált indítók verziónként eltérhetnek. A minták nem teszik automatikusan működőképessé a saját integrációdat, és nem bizonyítanak nálad elvégzett fizikai próbát.

Végső ellenőrzőlista

A lámpa kézi próbája a megfelelő fizikai kimenetet igazolja.
A jelzés nyers állapota vagy eseménytípusa a valódi próbához köthető.
Az indító az aktuális entitást és helyes átmenetet figyeli.
A friss nyomkövetésben megvan az első eltérő lépés.
A napállás és a kezdeti lámpaállapot miatti jogos elutasítást elkülönítetted a hibától.
A nyilvános hibaleírás csak szükséges, anonimizált adatot tartalmaz.

Menj végig a pontokon a saját rendszereden.

A cikk tájékoztató jellegű, a technikai részletek eszközönként eltérhetnek.