Home Assistant tilstedeværelse: pålidelig detektion trin for trin

Klokken er 14.40, og i mødelokale A sidder fire personer og lytter til en præsentation. Ingen bevæger sig ret meget. Efter tolv minutter slukker lyset, ventilationen går i hvile, og nogen rejser sig og vifter med armene for at vække PIR-sensoren. Det er den klassiske fejl i Home Assistant tilstedeværelse: binary_sensor.occupancy er bygget på bevægelse, ikke på personer. Denne artikel går kun ét sted hen: hvordan du bruger ind/ud-tælling og belægningssensorer som et pålideligt tilstedeværelsessignal i Home Assistant, trin for trin. Hvis du mangler det brede overblik over arkitektur, datakilder og automatiseringer, så start med vores komplette guide til Home Assistant occupancy-integration og vend tilbage hertil, når du skal bygge selve detektionen.

Trin 1: Definér, hvad home assistant tilstedeværelse betyder pr. zone

Før du rører en eneste YAML-linje, skal du beslutte tre ting for hver zone: hvilket personantal udløser "optaget", hvor længe antallet skal være nul, før zonen regnes som "tom", og hvilket sekundært signal der skal bekræfte den tomme tilstand. Svarene er forskellige for et mødelokale, et auditorium og en hel kontorfløj. Et mødelokale skal reagere hurtigt på den første person, mens en fløj efter arbejdstid skal være meget konservativ, fordi en falsk "tom"-tilstand med én person tilbage er et sikkerhedsproblem. Skriv beslutningerne ned i en tabel med zonenavn, tærskel, karensperiode og bekræftelsessignal. Den tabel bliver din specifikation for resten af arbejdet.

Trin 2: Få personantallet ind som en talværdi, ikke en binær tilstand

Tilstedeværelse skal afledes af et tal, ikke leveres som et ja/nej fra sensoren. Derfor skal tælleplatformen publicere øjeblikkeligt antal pr. zone til MQTT, fx på et topic som bygning/etage3/moederum_a/count, og Home Assistant skal læse det som en mqtt sensor med numerisk værdi. Brug MQTT Discovery, hvis platformen understøtter det, ellers definér entiteten manuelt med state_class måling og en tydelig enhed. Kontrollér i udviklerværktøjerne, at entiteten faktisk viser et heltal og ikke en streng. Det lyder banalt, men en talværdi, der kommer ind som tekst, får enhver sammenligning i en template til at opføre sig uforudsigeligt.

Datakvaliteten bestemmes her, ikke senere. AI-baserede tællesensorer er den eneste klasse, der leverer retningsbestemt ind/ud-tælling med dokumenterbar nøjagtighed. Vemco garanterer kontraktuelt minimum 96 % og ser typisk 98–99 %, når lysforhold, layout og adfærd tillader det. Sørg desuden for, at sensoren håndterer medarbejdereksklusion ved kilden, så rengøring og servicepersonale ikke tænder bygningen om natten gennem din tilstedeværelseslogik.

Trin 3: Byg tilstedeværelsessensoren som en template med forsinkelser

Nu opretter du en template binary_sensor med device_class occupancy pr. zone. Tilstanden er sand, når antallet er større end eller lig med tærsklen fra trin 1. Det afgørende er de to forsinkelser: delay_on holdes kort eller nul, så lys og ventilation reagerer, så snart den første person er talt ind, mens delay_off sættes til zonens karensperiode. For et mødelokale kan det være få minutter, for en fløj i natdrift væsentligt længere. Karensperioden er ikke et skøn over nøjagtighed, men en bevidst afvejning: den dækker over den korte periode, hvor en person går ud ad døren og straks ind igen, og den giver plads til at afstemme med det sekundære signal.

Tilføj en availability-template, så sensoren bliver utilgængelig, hvis den underliggende tællerentitet er unknown eller unavailable. Uden den vil en mistet MQTT-forbindelse blive tolket som nul personer, og zonen går i hvile med folk til stede. En utilgængelig sensor skal få automatiseringerne til at holde den sidste kendte tilstand, ikke til at slukke.

Trin 4: Bekræft den tomme tilstand med et sekundært signal

Tælleren alene skal styre "optaget". "Tom" skal kræve to kilder. Byg en ekstra template, "bekræftet tom", der kun er sand, når antallet har været nul i hele karensperioden, og et PIR- eller mmWave-signal i samme zone heller ikke har registreret bevægelse i perioden. Dørkontakter kan bruges som tredje signal i små rum: en dør, der ikke har været åbnet, siden sidste person blev talt ud, er et stærkt bevis. Her vender logikken fra indledningen om. Bevægelsessensoren er dårlig som primær kilde, fordi stillesiddende mennesker forsvinder for den, men den er glimrende som veto: hvis den ser bevægelse i en zone, tælleren siger er tom, så skal zonen ikke slukkes, og du har samtidig fundet et sted, hvor tælleren skal kontrolleres.

Trin 5: Håndtér drift og retained messages

Akkumulerede ind/ud-tællere driver over dagen, uanset leverandør. Selv ved 98–99 % nøjagtighed opbygger en dør med 2.000 daglige passager en lille restfejl, og ved midnat kan zonen stå med minus to eller plus fire personer. Plus fire betyder, at din tilstedeværelsessensor aldrig falder til "tom", og bygningen kører hele natten. Minus to betyder, at de første to personer om morgenen ikke tænder noget. Planlæg derfor en natlig nulstilling som automation på et tidspunkt, hvor "bekræftet tom" har været sand længe, og log afvigelsen før reset. Afvigelsen pr. zone over tid er din bedste indikator for, hvilke døre der skal have justeret sensorplacering.

Det andet faldgrube er MQTT retained messages. Efter en Home Assistant-genstart kan en gammel retained-værdi genindlæse en forældet belægning og udløse automatiseringer på spøgelsesdata. Tag en bevidst beslutning: øjeblikkeligt antal bør som regel ikke være retained, så en genstart giver unknown og dermed utilgængelig sensor, indtil næste reelle måling ankommer. Gem i stedet sidste kendte tilstand i en input-hjælper, hvis du har brug for kontinuitet.

Trin 6: Test med en person efterladt i zonen

Validér nøjagtigheden med manuel kontroltælling over mindst tre dage, ikke én formiddag, og test derefter hver nul-belægnings-automation med én person bevidst siddende stille i zonen gennem hele karensperioden. Hvis lyset slukker, har du fundet fejlen, før brugerne gør. Notér også, hvordan sensoren opfører sig i ydertimerne: en glasfacade med lavtstående vintersol er netop den situation, hvor nøjagtigheden presses, og hvor den flade garanti på 99 % fra visse leverandører afslører sig selv.

Når home assistant presence på denne måde er bygget på tal og bekræftet af et sekundært signal, kan det bære både komfortstyring og sikring. Vokser opgaven til flere ejendomme, håndterer Vemcos VemSpace arealudnyttelse på tværs af porteføljen, og VemFusion kobler belægningsdata direkte til HVAC, BMS og sikringssystemer, mens Home Assistant beholder rollen som lokalt automatiseringslag.

Ofte stillede spørgsmål

Kan jeg nøjes med mmWave til tilstedeværelse i Home Assistant? Til et enkelt lille rum, hvor du kun skal vide, om nogen er der, kan mmWave være tilstrækkeligt. Så snart automatiseringen skal skaleres efter antal personer, eller zonen er stor og åben, skal du bruge retningsbestemt tælling som primær kilde og mmWave som bekræftelse.

Hvor lang skal karensperioden være, før en zone regnes som tom? Det afhænger af zonens risiko, ikke af sensoren. Et mødelokale tåler få minutter, mens en hel fløj i natdrift bør kræve markant længere stabilt nul kombineret med et sekundært signal, fordi konsekvensen af en falsk tom-tilstand er større.

Hvad gør jeg, hvis tælleren viser et negativt antal? Negative værdier er et tegn på drift og skal behandles som nul i din template, så tilstedeværelsen ikke bliver permanent falsk. Log afvigelsen, nulstil om natten, og brug mønstret over flere dage til at finde den dør, der tæller skævt.

Skal jeres tilstedeværelsesdata være til at stole på, når lyset, luften og låsene afhænger af dem? Vemco har arbejdet med persontælling og belægningsdata siden 2005 og hjælper integratorer og smart building-teams med at få præcise realtidstal ind i Home Assistant, BMS og sikring. Kontakt os på vemcogroup.com/contact-us og få en konkret vurdering af jeres zoner, tærskler og sensorplacering.