Komplett guide till beläggningsintegration i Home Assistant

Ett mötesrum för tolv personer, fullt ventilerat och uppvärmt klockan 07:30, tomt fram till 10:15, används av tre personer i fyrtio minuter och står sedan tomt igen. Den som har grävt i energidata från en kontorsfastighet känner igen mönstret. Home Assistant kan lösa exakt det här problemet – men bara om beläggningsdatan som matas in faktiskt speglar hur många som är i rummet, inte bara att någon rörde sig för sju minuter sedan.

Den här guiden går igenom hur du bygger en Home Assistant beläggningsintegration som håller i produktion: val av datakälla, transportlager, entitetsdesign och de automationsmönster som skiljer en fungerande installation från en som teamet stänger av efter tre veckor.

Rörelsedetektering är inte beläggning

De flesta som börjar med Home Assistant i en kommersiell miljö gör samma misstag: de behandlar en PIR-sensor som en beläggningskälla. En PIR svarar på frågan "rörde sig någon nyss?" – inte "hur många personer finns här?". Skillnaden är avgörande så fort du vill göra mer än att tända en lampa.

• Behovsstyrd ventilation kräver ett antal, inte ett ja/nej. Luftflödet för 3 personer och 30 personer är inte samma sak.
• Kapacitetslarm – till exempel att ett utrymme närmar sig en fördefinierad gräns – förutsätter en löpande räkning med in- och utpassering.
• Utnyttjandeanalys över tid kräver att stillasittande personer inte "försvinner", vilket är PIR-sensorers klassiska svaghet.

Det är därför professionella installationer använder AI-baserade räknesensorer i entréer och zoner. En viktig detalj för kontors- och campusmiljöer: sensorer med personalexkludering gör att städpersonal och vaktrundor inte triggar ventilation och belysning på natten – en felkälla som annars äter upp en stor del av besparingen.

Tre vägar in i Home Assistant

Oavsett sensorleverantör landar du i praktiken i ett av tre integrationsmönster:

• MQTT – förstahandsvalet för realtid. Sensorn eller räkneplattformen publicerar in/ut-händelser eller aktuellt antal per zon till en broker, och Home Assistant prenumererar via MQTT-integrationen. Latens på under en sekund, lätt att felsöka med en MQTT-klient.
• REST-polling – Home Assistants rest-sensor hämtar aktuell beläggning från leverantörens API med fast intervall. Fungerar bra för utnyttjandegrad och dashboards, sämre för snabba automationer eftersom du alltid ligger ett pollingintervall efter.
• Webhooks – räkneplattformen pushar händelser till en webhook-trigger i Home Assistant. Bra mellanting när MQTT inte är tillgängligt, men kräver att HA-instansen är nåbar från plattformen.

För styrning av HVAC och belysning: välj MQTT. För rapportering och veckovisa utnyttjandebeslut räcker REST. Många installationer kör båda parallellt – realtidsantal via MQTT och verifierade dygnssummor via API.

Entitetsdesign som håller över tid

Bygg en sensor-entitet per zon med aktuellt antal som state, inte en binary_sensor. Lägg sedan template-sensorer ovanpå för det automationerna faktiskt behöver: "zon upptagen" (antal > 0), "zon över 80 % av kapacitet", "våning total". Att skilja rådata från härledda tillstånd gör att du kan byta sensorleverantör eller justera trösklar utan att skriva om trettio automationer.

Två saker som erfarna implementatörer alltid gör:

• Retained messages och availability-topics på MQTT. Efter en omstart av Home Assistant står annars alla beläggningsentiteter på "unknown" tills nästa händelse kommer – vilket i en lågtrafikzon kan dröja timmar. Utan retain-flaggan kör din ventilationsautomation blint under den tiden. Det här är det enskilt vanligaste felet i annars välbyggda installationer.
• Hysteres i automationerna. Trigga aldrig HVAC direkt på antal > 0. Använd en fördröjning på utgången (till exempel zon tom i 15 minuter innan nedreglering) så att en person som går ut och hämtar kaffe inte får aggregatet att pendla. Kompressorer och spjällmotorer tackar dig.

Automationsmönster som ger mätbar effekt

När datan väl finns i Home Assistant är det här mönstren som brukar motivera investeringen:

• Stegvis ventilation: mappa antalsintervall mot fläktlägen eller börvärden i stället för av/på. Kombinera gärna med CO2 som säkerhetsnät – beläggning är snabb, CO2 är trög men sanningsenlig.
• Belysningszoner med efterlöp: antal styr scener, tomt-i-X-minuter släcker. I korridorer och trapphus är det här ofta den snabbaste återbetalningen.
• Kapacitetsnotiser: när en zon passerar en fördefinierad gräns skickas en avisering till reception eller facility-teamet – användbart i hörsalar, matsalar och entréer.
• Mötesrumslogik: bokat men tomt i 15 minuter frigör rummet i bokningssystemet. Kräver räkning, inte rörelse – en person som sitter still i ett videomöte får inte "försvinna".

Noggrannhet: var ärlig mot dig själv

All automationslogik ärver datakvaliteten. En löpande räkning driftar om varje in/ut-passage har fel på några procent – felen ackumuleras under dagen. Professionella räknesystem hanterar detta med hög grundnoggrannhet och nollställningslogik. Som riktmärke arbetar Vemco med en kontraktuell miniminivå på 96 % noggrannhet, och typiskt 98–99 % när förhållandena – belysning, entréutformning och besöksbeteende – tillåter. Lova aldrig en fast siffra i ett projekt innan platsen är verifierad; en bred entré med mottrafik och barnvagnar beter sig inte som en kontorskorridor.

När Home Assistant inte räcker hela vägen

Home Assistant är utmärkt som integrationsnav i en byggnad eller ett pilotprojekt. Men för en portfölj med flera fastigheter, ett befintligt BMS och krav på revisionsbar data vill de flesta fastighetsteam ha ett dedikerat lager mellan sensorerna och styrsystemen. Här sitter plattformar som VemFusion, som kopplar beläggningsdata direkt mot HVAC, BMS och säkerhetssystem, medan VemSpace hanterar utnyttjandeanalysen – vilka ytor som faktiskt används och vilka som kan konsolideras. Ett vanligt upplägg: VemFusion mot huvudsystemen, Home Assistant för den lokala logiken som BMS:et är för trögt eller för dyrt att programmera om för. Mönstret används redan i kontor, universitet och offentliga byggnader för att komma bort från alltid-på-drift.

Praktisk tumregel för integratörer: låt räkneplattformen äga sanningen om antalet, och låt Home Assistant äga besluten. Blandar du ansvaren – med lokal räknelogik i templates ovanpå råa passageevent – får du två system som är oense om hur många som är i huset, och felsökningen blir därefter.

Kom igång med rätt datagrund

Bygger ni beläggningsstyrd automation – i Home Assistant, mot ett BMS eller båda? Vemco har sedan 2005 levererat räknedata som styrsystem kan lita på, med AI-sensorer, personalexkludering och färdiga integrationsvägar via MQTT och API. Boka en teknisk genomgång med vårt team på vemcogroup.com/contact-us så går vi igenom er zonindelning, val av transportlager och hur ni verifierar noggrannheten innan automationerna går live.