Home Assistant bevægelsessensor: 5 automatiseringer til kontoret

Klokken er 19.40 en tirsdag, og lyset i mødelokale 2C brænder stadig. Det har det gjort siden 15.15, hvor dagens sidste møde sluttede. Automatiseringen blev slået fra for en måned siden, fordi den PIR-baserede Home Assistant bevægelsessensor i loftet slukkede lyset midt i en præsentation, hvor otte personer sad stille. Ventilationen kører på fuld hastighed i et tomt lokale, og ingen opdager det før kl. 7. Denne artikel handler ikke om, hvordan belægningsdata kommer ind i Home Assistant, men om hvilke automatiseringer man bygger oven på dem – og hvordan de skrives, så de ikke bliver slået fra igen efter første fejl.

Forudsætningen: hvad jeres Home Assistant bevægelsessensor faktisk leverer

Alle opskrifter nedenfor er skrevet til en entitet, der leverer et tal – antal personer i zonen – og ikke kun en binær tilstedeværelse. En klassisk PIR-sensor melder "tomt" efter 90 sekunders stilstand, og det er præcis den fejl, der fik lokale 2C til at slukke lyset under præsentationen. En AI-baseret tællesensor leverer i stedet et løbende personantal pr. zone med en kontraktlig minimumsnøjagtighed på 96 % og typisk 98–99 %, når lys, layout og adfærd tillader det. Sensorer med personaleeksklusion sørger desuden for, at rengøring og teknikere ikke tæller med, så natlige automatiseringer ikke udløses på falske tal.

Selve datavejen – MQTT, REST-polling eller webhooks – er dækket i vores komplette guide til Home Assistant occupancy-integration. Her forudsætter vi, at tallene allerede lander som eksempelvis sensor.zone_2c_belaegning, og at I har en entitet pr. zone, I vil styre.

Opskrift 1: Belysning, der ikke slukker midt i mødet

• Trigger (tænd): numeric_state på zonens belægningstal, above 0.
• Trigger (sluk): numeric_state below 1 med en for:-betingelse på eksempelvis 10 minutter. Det er for:-betingelsen, der gør forskellen – korte udsving til nul, når én person går ud og en anden kommer ind, udløser ingenting.
• Condition: tidsrum eller solhøjde, så lyset ikke tændes i fuldt dagslys ved vinduesfacaden.
• Action: light.turn_on med scene efter mødetype, eller light.turn_off ved tom zone.

Tilføj en input_boolean som "præsentationstilstand", der kan slås til fra et vægpanel eller companion-appen og fastholder lyset uanset tælleren. Den bruges sjældent, når tællingen er præcis, men den afgør, om brugerne stoler på systemet eller slår det fra.

Opskrift 2: Ventilation i trin efter personantal

Et auditorium er det tydeligste eksempel. CO2-sensorer reagerer med 10–15 minutters forsinkelse, så når 60 studerende forlader lokalet, kører ventilationen videre på fuld kraft et kvarter. Tælledata reagerer øjeblikkeligt. Byg automatiseringen som tre numeric_state-triggere på samme entitet, hver med sit interval – som illustration kunne et auditorium med 200 pladser bruge trinnene 0–20, 21–80 og over 80 personer, men grænserne skal sættes ud fra jeres anlægs dimensionering, ikke kopieres herfra.

• For:-betingelse på 3–5 minutter på hvert trin, så ventilatoren ikke pendler mellem hastigheder, når tallet svinger omkring en grænse.
• Action: fan.set_percentage eller climate.set_fan_mode, alt efter hvordan jeres anlæg er eksponeret i Home Assistant.
• CO2 som kontrol, ikke som styring: hvis CO2 ligger højt, mens tælleren siger tomt, har I et dataproblem – log det, og lad ikke automatiseringen slukke.

Til denne opskrift er en REST-sensor med 30–60 sekunders polling fuldt tilstrækkelig. Ventilation behøver ikke subsekund-latens.

Opskrift 3: Kapacitetsalarm med varsel før grænsen

Kantiner, eventrum og lokaler med brandmyndighedskrav har en fast maksimal belægning. Den klassiske fejl er at alarmere, når grænsen er nået – så er det for sent at handle. Byg to triggere: et varsel ved en lavere tærskel, I selv fastsætter, og en alarm ved selve grænsen. Varslet sender en notifikation via Home Assistants companion-app til facility-teamets gruppe; alarmen kan derudover tænde et visuelt signal ved indgangen eller sætte en skærmbesked.

• Datavej: her er MQTT med under et sekunds latens et krav. En REST-sensor med et minuts forsinkelse er uegnet til sikkerhedsrelaterede grænser.
• Nulstil varslet med en tredje trigger, når tallet igen falder under varselstærsklen, så teamet ved, at situationen er løst.
• Test med mennesker: notifikationskæden fejler oftere end tællingen. Lad reelle personer gå gennem zonen inden go-live, ikke kun MQTT-testbeskeder.

Opskrift 4: Nedlukning af en hel fløj

Enkeltlokaler er let; en fløj med syv zoner kræver en template-sensor, der summerer de syv belægningstal til én værdi. Når summen har været nul i 30 minutter – igen med en for:-betingelse – sænkes setpunkterne på fløjens klimaenheder, og belysningen dæmpes eller slukkes. Den modsatte trigger, sum over 0, bringer fløjen tilbage til normal drift. Det er en typisk Home Assistant automatisering, der sparer penge fra dag ét, fordi den stopper spildet fra systemer, der ellers kører efter skema uanset belægning.

To sikkerhedsregler skal med. For det første: hvis blot én af de syv sensorer står i unavailable, må template-sensoren ikke returnere nul – den skal returnere unavailable, og nedlukningen skal have en condition, der kræver gyldige tal. Ellers slukker I ventilationen i en fyldt fløj, fordi en sensor tabte netværket. For det andet: belægningstal er akkumulative, og et mistet "ud"-event kl. 9 betyder, at zonen står én person for højt resten af dagen. Planlæg en natlig nulstilling eller en periodisk afstemning mod tælleplatformens autoritative tal, så fløjen ikke står "optaget" hele natten på grund af én tabt besked.

Opskrift 5: Rengøringsliste efter dagens besøgstal

Opret en akkumulerende hjælper pr. zone – utility_meter med daglig cyklus fungerer – der tæller indgange over dagen. En tidsstyret automatisering ved arbejdstids ophør gennemgår zonerne, sorterer dem efter besøgstal og sender en prioriteret liste til rengøringsteamet. Zoner under en tærskel, I selv fastsætter, markeres som "spring over". Besparelsen er direkte og nem at dokumentere over for ledelsen. Bemærk, at Home Assistants historik er god til denne daglige logik og til fejlsøgning, mens langtidsanalyse af arealudnyttelse – hvilke mødelokaler står tomme uge efter uge, hvilke etager kan konsolideres – hører hjemme i et dedikeret værktøj som VemSpace.

Ofte stillede spørgsmål

Kan jeg bruge mine eksisterende PIR-sensorer til disse opskrifter?
Til opskrift 1 kan PIR fungere som et supplement, men den binære tilstand og timeout'en på 90 sekunders stilstand gør den uegnet til ventilationstrin, kapacitetsalarmer og fløjnedlukning. Opskrifterne 2–5 kræver et faktisk personantal pr. zone.

Hvor lang skal for:-betingelsen være?
Det afhænger af, hvad automatiseringen styrer. Lys tåler korte perioder, fordi det er billigt at tænde igen; varmeanlæg og ventilatorer bør have længere perioder for at undgå unødige cyklusser. Start konservativt, og juster ud fra loggen efter to uger.

Hvornår er Home Assistant ikke nok?
Når belægningsdata skal tale direkte med HVAC, BMS og sikkerhedssystemer på et kontraktligt driftsniveau, er en dedikeret platform som VemFusion bygget til opgaven. Mange bygninger lader de to sameksistere: platformen håndterer de kritiske koblinger, Home Assistant orkestrerer de lokale, hurtige automatiseringer og dashboardet.

Alle fem opskrifter står og falder med tal, I kan stole på. Vemco har arbejdet med præcis personantælling siden 2005 og leverer AI-sensorer med personaleeksklusion, realtidsbelægning med alarmgrænser og direkte kobling til HVAC, BMS og sikkerhed via VemFusion. Vil I gennemgå, hvilke af automatiseringerne der giver størst effekt i jeres bygning? Kontakt Vemco Group her og få en konkret gennemgang af jeres zoner og datakilder.