Search Icon

    Komplet guide til Home Assistant occupancy-integration

    Komplet guide til Home Assistant occupancy-integration

    De fleste, der har prøvet at bygge belægningsstyring i Home Assistant, kender scenariet: Mødelokalet er fuldt af mennesker, der sidder stille og lytter til en præsentation – og lyset slukker. PIR-sensoren har ikke registreret bevægelse i fem minutter, så systemet konkluderer, at rummet er tomt. Det er ikke en fejl i Home Assistant. Det er en fejl i datagrundlaget. Bevægelse er ikke det samme som tilstedeværelse, og tilstedeværelse er ikke det samme som belægning. Den skelnen er hele fundamentet for en Home Assistant occupancy integration, der faktisk virker i en professionel bygning.

    Tre datatyper, tre helt forskellige use cases

    Før du vælger sensorer og integrationsmetode, skal du være skarp på, hvilket spørgsmål du egentlig vil have svar på:

    • Bevægelse (motion): "Skete der noget lige nu?" PIR-sensorer er billige og hurtige, men blinde over for stillesiddende personer. Fint til gangarealer og lys i depotrum.
    • Tilstedeværelse (presence): "Er der nogen i rummet?" mmWave-radarsensorer registrerer mikrobevegælser som vejrtrækning og løser mødelokale-problemet. I Home Assistant eksponeres det typisk som en binary_sensor med device_class occupancy.
    • Belægning (occupancy count): "Hvor mange er der – og hvor mange plejer der at være?" Det kræver reel persontælling ved indgange og zoner. Først her kan du dimensionere ventilation efter faktisk personbelastning, håndhæve kapacitetsgrænser og levere udnyttelsesdata til facility management.

    Mange projekter fejler, fordi de forsøger at besvare det tredje spørgsmål med sensorer bygget til det første. En binær tilstedeværelsessensor kan tænde lyset, men den kan ikke fortælle dit CTS-anlæg, om der sidder 4 eller 40 personer i kantinen.

    Integrationsveje ind i Home Assistant

    Der er fire realistiske veje til at få belægningsdata ind i Home Assistant, og valget afhænger mere af din driftsmodel end af teknologien:

    • MQTT: Standardvalget til professionelle installationer. Tællesensorer eller en mellemliggende gateway publicerer til en broker, og Home Assistant abonnerer via MQTT-integrationen. Skalerer godt på tværs af mange zoner og understøtter discovery, så entiteter oprettes automatisk.
    • REST/webhooks: Cloudbaserede tælleplatforme kan pushe events til en Home Assistant-webhook eller polles via en RESTful sensor. Enklere at komme i gang med, men vær opmærksom på latenstid, hvis du styrer noget tidskritisk som ventilationstrin.
    • ESPHome: Til udviklere, der bygger egne mmWave- eller ToF-baserede zonesensorer. Fuld kontrol og lokal drift, men du ejer selv kalibrering, firmware og vedligehold på hver enhed.
    • Modbus/BACnet-brorløsninger: Relevant når belægningsdata allerede lever i et BMS, og Home Assistant skal fungere som overbygning eller testmiljø.

    Et praktikertip, som sjældent står i dokumentationen: Sæt retain-flaget på jeres MQTT-belægningstopics. Uden det starter Home Assistant efter en genstart med ukendt tilstand på alle occupancy-entiteter, og jeres automatiseringer opfører sig uforudsigeligt, indtil næste event ankommer – hvilket i et tyndt besat kontor kan være timer senere. Kombinér med en availability-topic, så I kan skelne mellem "rummet er tomt" og "sensoren er offline". De to tilstande må aldrig se ens ud i jeres dashboards, for de kræver vidt forskellige reaktioner.

    Fra rå events til brugbare entiteter

    Rå ind/ud-events er ikke nok. I skal bygge et lag af afledte entiteter, som automatiseringerne kan stole på. En typisk opsætning for en zone består af en tællersensor (aktuelt antal personer), en template-sensor der beregner belægningsgrad mod zonens kapacitet, og en binær sensor med hysterese – for eksempel "over 80 % i mere end 5 minutter" – som trigger for ventilationsboost eller alarmer. Hysteresen er vigtig: Uden den vil en zone, der svinger omkring grænseværdien, få jeres HVAC-styring til at pendle konstant, og det slider på både spjæld og troværdighed.

    Overvej også en natlig nulstillingsautomatisering. Selv gode tællesensorer akkumulerer drift over tid – to personer, der går tæt sammen, en barnevogn, en person der vender om i døråbningen. En reset til nul kl. 03:00 på hverdage, kombineret med en anomali-notifikation hvis tælleren står på mere end nul ved lukketid, fanger driftproblemer, før de bliver til dårlige data i jeres udnyttelsesrapporter.

    Automatiseringer der faktisk sparer penge

    Lysstyring er indgangsniveauet. Den reelle økonomi ligger i tre andre mønstre:

    • Behovsstyret ventilation: Skaler luftmængder efter faktisk personantal i stedet for tidsskemaer. Det er her, kontorer, universiteter og offentlige bygninger typisk henter den største besparelse, fordi always-on-drift af HVAC er den dyreste standardindstilling i bygningen.
    • Kapacitetsalarmer: En automatisering, der advarer ved en foruddefineret grænse, gør belægningsdata operationelle for reception, kantinedrift og sikkerhed – ikke kun for rapporter.
    • Rengøring efter brug: Send zoner med nul registreret belægning direkte til "spring over"-listen i rengøringsplanen. Det kræver tælledata, ikke bevægelsesdata, for en PIR-sensor kan ikke fortælle, om lokalet blev brugt af én person i to minutter eller tyve personer i tre timer.

    Hvornår Home Assistant ikke længere er nok

    Home Assistant er et fremragende miljø til prototyper, mindre bygninger og til at bevise businesscasen for belægningsstyret drift. Men vær ærlig om grænserne. Når porteføljen vokser til flere bygninger, når facility management skal bruge revisionssikre udnyttelsesdata til lejekontrakter og arealbeslutninger, eller når belægningsdata skal ind i et kommercielt BMS med SLA-krav, rammer gør-det-selv-tilgangen et loft – både på datakvalitet og på ansvar.

    Datakvaliteten er det afgørende skel. Hjemmebyggede zonesensorer har ingen garanteret nøjagtighed, og fejlene er systematiske, ikke tilfældige – de undertæller ved høj trafik, netop når data betyder mest. Professionelle AI-baserede tællesensorer leverer en kontraktlig minimumsnøjagtighed på 96 %, og i praksis typisk 98–99 %, når forhold som lysforhold, indretning og besøgsadfærd tillader det. Dertil kommer eksklusion af medarbejdere fra tællingerne – en funktion, der er næsten umulig at replikere selv, men afgørende hvis udnyttelsesdata skal afspejle reel brug og ikke pedellens runder. Platforme som VemFusion er bygget til præcis det næste skridt: at koble validerede belægningsdata direkte til HVAC, BMS og sikkerhedssystemer, så den logik, I har bevist i Home Assistant, kan køre i produktionsskala med drift og support bag.

    En pragmatisk model, vi ofte anbefaler integratorer: Brug Home Assistant som pilotmiljø i én bygning eller én etage, dokumentér besparelsen på ventilation og rengøring over et kvartal, og brug dén businesscase til at begrunde en certificeret tælleinfrastruktur på tværs af porteføljen. Så bliver hobbyplatformen ikke en blindgyde, men et beslutningsværktøj.

    Står I med en Home Assistant-pilot, der skal skaleres – eller vil I springe direkte til belægningsdata med dokumenteret nøjagtighed koblet på jeres HVAC og BMS? Kontakt Vemco Group, og lad os gennemgå jeres zoner, integrationskrav og den konkrete besparelsescase sammen.

    Join Our Newsletter Community Today!

    Form-right