Automatizarea care a mers impecabil șase luni și într-o dimineață nu mai pornește este o experiență universală în casele conectate. Reacția obișnuită — se reface regula de la zero, se reinstalează aplicația, se resetează dispozitivul — funcționează uneori, din întâmplare, și te lasă fără să știi ce s-a stricat. Există o metodă mai bună, care cere cinsprezece minute și găsește cauza aproape întotdeauna: împarți lanțul în trei bucăți și afli care dintre ele s-a rupt.
Prima întrebare: nu pornește deloc sau pornește degeaba?
Orice automatizare, indiferent de platformă, are aceeași structură: un declanșator, una sau mai multe condiții și un set de acțiuni. Prima decizie de depanare este să afli în care dintre cele trei stă problema, pentru că testele sunt complet diferite.
Verificarea durează un minut. Rulează manual doar blocul de acțiuni — aproape orice sistem are un buton de execuție manuală a scenei sau a secvenței. Dacă acțiunile se execută corect, problema este în amonte: fie declanșatorul nu mai apare, fie o condiție îl blochează. Dacă nici manual nu se întâmplă nimic, ai un dispozitiv sau un serviciu căzut și nu mai trebuie să te uiți la logică deloc.
Al doilea instrument este jurnalul. Toate platformele serioase păstrează un istoric al execuțiilor, iar unele — sistemele care rulează local, în particular — păstrează chiar traseul complet, pas cu pas, cu valorile evaluate. Acolo vezi negru pe alb dacă automatizarea a fost declanșată și s-a oprit la condiție, sau nu a fost declanșată niciodată. Diferența asta îți economisește ore. Dacă platforma ta nu îți arată așa ceva, este un argument serios pentru migrarea către un sistem care rulează pe un server local, unde ai acces la loguri reale.
Declanșatorul: ce anume ar fi trebuit să intre în automatizare
Cele mai multe automatizări moarte au declanșatorul rupt, iar cauza este aproape mereu una dintre următoarele.
- Entitatea a fost redenumită. Ai reasociat un senzor după ce i-ai schimbat bateria sau l-ai mutat, iar sistemul l-a înregistrat ca dispozitiv nou, cu un identificator având un sufix numeric. Automatizarea ascultă în continuare identificatorul vechi, care nu mai emite nimic. Verifică lista de entități și caută duplicate.
- Senzorul e „indisponibil”, nu „oprit”. O stare de indisponibilitate nu produce tranziția pe care o aștepți. Un senzor cu baterie descărcată poate rămâne blocat pe ultima valoare raportată la nesfârșit, fără niciun semnal de eroare.
- Declanșatorul pe prag numeric se activează la traversare, nu la depășire. Dacă valoarea era deja peste prag când ai repornit sistemul, nu va traversa nimic. Aceeași capcană la declanșatoarele „de la oprit la pornit”: dacă era deja pornit, nu se întâmplă nimic.
- Ora sau evenimentul solar s-a mutat. Automatizările legate de răsărit și apus se deplasează cu câteva ore de-a lungul anului, iar cele legate de oră fixă pot avea probleme la schimbarea orei de vară dacă fusul orar al hubului nu este setat corect.
Condițiile care blochează silențios execuția
O condiție falsă nu produce niciun mesaj de eroare — automatizarea pur și simplu se oprește. De aceea condițiile sunt locul unde se pierde cel mai mult timp.
Cel mai frecvent vinovat este prezența. Multe sisteme decid „e cineva acasă” după telefonul conectat la rețeaua locală, iar telefoanele moderne generează o adresă MAC aleatorie, diferită pentru fiecare rețea și, în unele configurații, rotită periodic. După o resetare a routerului sau o actualizare a telefonului, dispozitivul devine invizibil pentru regula ta. Soluția durabilă: dezactivează adresa privată pentru rețeaua de acasă sau folosește o metodă de prezență bazată pe aplicație și localizare, nu pe MAC.
Al doilea vinovat: un comutator auxiliar rămas într-o poziție de test. Ai creat un buton virtual „mod vacanță” sau „automatizări suspendate” ca să testezi ceva acum trei săptămâni și ai uitat să îl închizi. Merită o automatizare separată care resetează toate comutatoarele auxiliare la o oră fixă și îți trimite un mesaj dacă a găsit ceva pornit.
Al treilea: instanța blocată. Dacă automatizarea este configurată să ruleze într-o singură instanță și conține o pauză lungă sau o așteptare după un eveniment, ea rămâne formal „în execuție”, iar orice declanșare nouă este ignorată tăcut. Se vede în lista de automatizări active. Rezolvarea e fie limitarea timpului de așteptare, fie schimbarea modului de execuție. Dacă regulile tale au ajuns complicate, merită o recitire a principiilor din articolul despre configurarea scenariilor automate, unde structura simplă e tratată ca o măsură de întreținere, nu de stil.
Acțiunile care eșuează pe drum
Când blocul de acțiuni rulează, dar rezultatul nu apare în casă, cauza e aproape întotdeauna fizică sau de rețea, nu logică.
Într-o rețea Zigbee sau Thread, dispozitivele alimentate la priză servesc drept rutere pentru cele pe baterie. Dacă ai scos din priză lampa din hol pentru că plecai în concediu, ai eliminat, fără să știi, singura cale prin care senzorul din pod ajungea la hub. Simptomul e caracteristic: mai multe dispozitive nelegate între ele cad simultan, în aceeași parte a casei. Verifică harta rețelei mesh, dacă platforma ta o oferă, și reține că un ruter scos din priză cere uneori câteva ore până când rețeaua se reorganizează.
La dispozitivele care depind de un serviciu extern, jetonul de autentificare expiră. Producătorii schimbă politicile de acces, forțează reautentificarea cu doi factori sau limitează numărul de comenzi pe minut. O secvență care trimite zece comenzi consecutive către același serviciu poate fi respinsă parțial, fără eroare vizibilă. Adaugă pauze de una-două secunde între comenzi către același dispozitiv și evită să comanzi într-o rafală un grup întreg.
Contează și ordinea. O comandă de aprindere trimisă imediat după o comandă de setare a culorii ajunge uneori înaintea celei de-a doua, iar becul pornește pe ultima culoare memorată. Setează întâi starea, apoi aprinde, sau folosește comanda combinată acolo unde protocolul o oferă.
Ce se strică după o actualizare sau o schimbare de rețea
Actualizările sunt suspectul numărul unu când mai multe automatizări cad deodată. O versiune nouă de platformă poate redenumi servicii, poate scoate din uz o integrare sau poate schimba formatul de configurare. Înainte de orice actualizare majoră, citește notele de versiune la secțiunea de modificări incompatibile și fă o copie de siguranță pe care chiar știi să o restaurezi.
Schimbările de rețea sunt la fel de brutale și mai greu de bănuit. O actualizare de firmware la router poate activa izolarea clienților, care împiedică dispozitivele să comunice între ele; poate opri retransmiterea mDNS între rețeaua principală și cea dedicată dispozitivelor IoT, ceea ce face ca hubul să nu mai descopere nimic; sau poate reatribui adrese IP prin DHCP, iar o integrare configurată cu adresă fixă rămâne să vorbească în gol. Rezervarea de adresă pentru hub, pentru NVR și pentru orice dispozitiv configurat manual este o măsură de cinci minute care previne o oră de căutări. Alegerea protocolului contează și ea în cât de fragil e ansamblul — comparația e detaliată în articolul despre Wi-Fi, Zigbee sau Matter.
Ce te scoate cel mai repede din astfel de situații nu e o unealtă, ci un obicei: schimbă un singur lucru o dată, notează ce ai schimbat și când, păstrează configurația într-un sistem de versiuni dacă platforma permite și ține o automatizare-santinelă care îți trimite zilnic un semnal de viață. Când semnalul lipsește, știi din prima oră, nu în seara în care ai nevoie ca lumina să se aprindă și nu se aprinde.
