Resourceplanning in Home Assistant: waarom internetstoringen het gedrag van lokale bediening veranderen

Een internetstoring zorgt er niet automatisch voor dat lokale automatiseringen in Home Assistant uitvallen. Lokale Zigbee-, Z-Wave-, Matter-, ESPHome-, MQTT- en LAN-integraties kunnen blijven werken terwijl de WAN-verbinding uitvalt. Wat verandert, is de werklast eromheen: cloudverzoeken verlopen in een time-out, integraties proberen opnieuw, DNS-lookups mislukken, externe verbindingen verdwijnen en herstelwerk kan in pieken binnenkomen wanneer de verbinding terugkeert.

Resourceplanning is daarom belangrijk tijdens een storing, zelfs wanneer het lokale besturingspad intact blijft. De vraag is niet: ‘Heeft Home Assistant internet nodig?’ De vraag is of mislukt werk op afstand geïsoleerd blijft of event-loop-tijd, executor-threads, DNS-capaciteit, logboek-I/O of het opnieuw laden van integraties begint te verbruiken, waardoor het lokale beheer wordt gehinderd.

Mislukte cloudverzoeken veranderen snelle succesroutes in time-outroutes

Wanneer de WAN-verbinding goed werkt, kan een cloudverzoek snel worden voltooid. Tijdens een storing kan dezelfde aanroep de volledige time-outduur bezetten, opnieuw proberen en een fout loggen voordat deze terugkeert. Een paar aanroepen zijn onschadelijk; wanneer veel integraties dit tegelijk doen, ontstaat een ander planningsprofiel dan tijdens normaal gebruik.

De levenscyclus van configuratie-items in Home Assistant bevat expliciet een setup retry-status voor afhankelijkheden die nog niet gereed zijn, waarbij het interval tussen automatische pogingen na verloop van tijd toeneemt. De exacte foutmodus is nog steeds afhankelijk van elke integratie, maar opnieuw proberen is een vast onderdeel van beperkte werking en geen uitzonderlijk randgeval.

Voorkom dat kritieke automatiseringen een externe API afwachten voordat ze de lokale actie uitvoeren. Verstuur de melding, cloudupdate of externe webhook nadat de fysieke actie is uitgevoerd wanneer dat externe resultaat niet nodig is om te bepalen wat het huis moet doen.

Netwerktime-outs kunnen resources vasthouden zonder hoge CPU-belasting

Een vastgelopen netwerkbewerking kan weinig CPU-belasting laten zien en toch een taak, verbinding, thread of time-outbudget bezet houden. Daarom bewijst ‘de CPU-belasting is slechts 10%’ niet dat een storing geen gevolgen heeft.

Een Home Assistant-geval uit 2026 bracht herhaalde time-outs van integraties en opeenvolgende herladingen in verband met een defect IPv6-pad waardoor verbindingen bleven wachten in plaats van snel te mislukken. Het symptoom was vertraging in de planning rond netwerkaanroepen, niet een tekort aan rekenkracht.

Houd openstaande netwerktaken, waarschuwingen van integraties, DNS-fouten en de tijd tussen de trigger en de lokale serviceaanroep in de gaten. Als lokale acties snel blijven terwijl cloudentiteiten niet beschikbaar zijn, is de storing correct geïsoleerd. Als de lokale latentie toeneemt door mislukte externe aanroepen, zoek dan de integratie of aangepaste code die de gedeelde runtime bezet houdt.

Blokkerend werk is gevaarlijker dan asynchroon wachten

De kern van Home Assistant is asynchroon, zodat goed ontworpen integraties kunnen pauzeren tijdens het wachten op I/O en andere taken kunnen laten doorgaan. Het gevaarlijke geval is blokkerend werk dat de event loop zelf bezet houdt, of aangepaste code die op de verkeerde plek synchrone netwerkaanroepen uitvoert.

De ontwikkelaarsdocumentatie van Home Assistant legt uit dat een blokkerende bewerking in de event loop voorkomt dat ander werk wordt uitgevoerd totdat deze is voltooid. Een internetstoring kan deze zwakte blootleggen, omdat een aanroep die normaal onmiddellijk terugkeert plotseling lang op een time-out kan wachten.

Daarom kan een aangepaste integratie een storing laten aanvoelen als een vertraging van het hele platform, ook al zijn native lokale integraties goed ontworpen. Vergelijk het gedrag met uitgeschakelde aangepaste componenten voordat je de hardware de schuld geeft.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Herstel kan een tweede piek in de werklast veroorzaken

Wanneer de internetverbinding terugkeert, kunnen meerdere integraties vrijwel tegelijk opnieuw verbinding maken, de status vernieuwen, opnieuw authenticeren, entiteiten bijwerken en nieuwe geschiedenisgegevens opslaan. De herstelperiode kan daardoor drukker zijn dan het midden van de storing.

Beschouw een piek in CPU-, netwerk- of Recorder-schrijfbewerkingen direct nadat de WAN-verbinding terugkeert niet als bewijs dat de normale capaciteit bij stabiel gebruik onvoldoende is. Meet hoelang de piek duurt en of de latentie van lokale besturing daarna terugkeert naar het uitgangsniveau.

Het artikel van ZimaSpace over bewaarde, in de wachtrij geplaatste, discovery- en beschikbaarheidsberichten na opnieuw verbinden laat hetzelfde herstelprincipe zien: opnieuw verbonden gedistribueerde componenten kunnen status opnieuw afspelen en werk creëren dat niet bestond toen de verbinding stabiel was.

Plan voor beperkte werking, niet alleen voor normaal gebruik

Tijdens WAN-uitval moeten lokale bewegings-naar-lichtpaden blijven werken zonder afhankelijk te zijn van een externe voorwaarde. Cloudpolling kan overschakelen op begrensde pogingen, externe meldingen kunnen mislukken of in de wachtrij worden geplaatst, DNS-afhankelijke services moeten voorspelbaar falen en het herstel van de verbinding kan een korte vernieuwingspiek veroorzaken.

Het ontwerpdoel is selectieve beperking: optioneel werk op afstand wordt trager of verdwijnt, terwijl lokale besturing binnen het normale tijdsbereik blijft. De beste storingstest is om de WAN-verbinding tijdens een normale huishoudelijke werklast te verbreken, enkele kritieke lokale automatiseringen te meten en vervolgens opnieuw verbinding te maken om zowel de herstelpiek als de tijd tot terugkeer naar het uitgangsniveau te meten.

Veelgestelde vragen

Maakt een internetstoring lokale automatiseringen in Home Assistant trager?

Niet vanzelf. Een volledig lokale automatisering kan op normale snelheid blijven werken. Deze wordt trager wanneer mislukte cloud-, DNS-, aangepaste-integratie- of gedeelde netwerkbewerkingen resources op hetzelfde kritieke pad verbruiken.

Moet ik agressieve nieuwe pogingen toevoegen zodat cloudintegraties sneller herstellen?

Nee. Agressieve nieuwe pogingen kunnen een storing versterken en onnodige werklast veroorzaken. Kies bij voorkeur voor begrensd opnieuw proberen en houd herstel van cloudverbindingen buiten het tijdkritieke pad van lokale automatiseringen.