Blogg | Vemco Group

Raspberry Pi närvarolarm — Automatiseringsguide för närvarolarm med Raspberry Pi | Vemco Group

Skriven av Admin | 2026-jul-14 16:22:04

En Raspberry Pi är billig nog att sätta upp i tio konferensrum utan att någon frågar om budgeten — och det är exakt där problemen börjar. Ett litet skript som skickar ett larm när ett rum passerar sin maxgräns låter enkelt, men skillnaden mellan en demo som fungerar en fredag och ett system som håller i produktion under sex månader ligger i detaljer som sällan nämns: strömavbrott, klockdrift, sensordrift och falsklarm klockan tre på natten. Den här guiden fokuserar på det som faktiskt avgör om ditt bygge överlever.

Vad ett närvarolarm egentligen ska göra

Ett larm är inte samma sak som en räknare. Räknaren mäter hur många personer som befinner sig i ett utrymme; larmet är beslutet du fattar när räknaren passerar ett fördefinierat gränsvärde. Att skilja på dessa två i koden gör hela skillnaden, eftersom du då kan justera larmtröskeln utan att röra räkningslogiken. En vanlig missuppfattning är att ett rum antingen är "tomt" eller "fullt". I verkligheten vill du ha flera trösklar: ett mjukt larm vid 80 procent av kapaciteten och ett hårt larm vid överskriden gräns.

Sensorval och den ärliga sanningen om noggrannhet

Du har tre realistiska vägar med en Raspberry Pi: PIR-sensorer, ToF-sensorer (time-of-flight) och kamerabaserad räkning via en Pi Camera med en modell som körs lokalt. PIR är billigast men känner bara av rörelse, inte antal — den missar en person som sitter still. ToF räknar passager över en tröskel och lämpar sig för dörröppningar. Kamera med lokal AI ger antal per rum, men kräver mer processorkraft än en Pi Zero orkar med.

Här är en punkt värd att vara noggrann med: ingen räknelösning ger exakt rätt siffra jämt. Professionella AI-sensorsystem som Vemcos har en avtalad miniminivå på 96 procent, och når typiskt 98–99 procent när ljus, layout och besökarbeteende tillåter det. En egenbyggd Pi-lösning ligger normalt lägre än så, särskilt vid gruppinträden och motljus. Räkna med det när du sätter dina larmtrösklar — bygg in en marginal snarare än att lita blint på ett exakt tal.

Grundarkitektur som håller

Undvik att låta Pi:n skicka larm direkt via e-post eller SMS. Det binder larmlogiken till en enhet som kan hänga sig. Bygg istället i lager:

  • Sensornod (Pi): läser sensorn, filtrerar brus och publicerar antal via MQTT.
  • Broker: en Mosquitto-instans som samlar alla noder på ett ställe.
  • Regelmotor: jämför antal mot tröskel och avgör när larm ska utlösas — här bor logiken, inte på Pi:n.
  • Notifiering: Slack, Teams eller ett larmsystem som tar emot beslutet.

Fördelen är att du kan byta ut en trasig Pi utan att röra tröskellogiken, och att en enhet som tystnar i sig själv blir ett larm — "ingen data på fem minuter" är lika viktigt som "för många personer".

Filtrering: det som gör skillnad i verkligheten

Råvärden från en sensor pendlar. En person som lutar sig fram och tillbaka kan räknas som två inträden. Lägg alltid en debounce på minst någon sekund och ett glidande medelvärde över flera avläsningar innan du fattar ett larmbeslut. Utan detta får du larm som utlöses och släcks tio gånger i minuten, och det första teamet gör är att stänga av notifieringarna helt — vilket gör hela systemet meningslöst.

En praktikerobservation som sällan står i handledningar: personal och städteam förstör din data mer än du tror. En städare som går in klockan 06:00 höjer siffran och triggar larm i ett tomt rum. Kommersiella system som Vemcos hanterar detta med särskild personalexkludering, så att räkningen speglar besökare snarare än fast personal. På en Pi-lösning får du bygga detta manuellt — till exempel genom att stänga av larm inom vissa tidsfönster eller genom att markera vissa dörrar som personalingångar.

Från larm till åtgärd

Ett larm som bara syns på en skärm sparar inga pengar. Värdet uppstår när närvarodata styr något. Om ett kontor eller en föreläsningssal står tomt behöver ventilation, belysning och kyla inte gå på full effekt. Det är precis den principen bakom Vemcos plattformar: VemSpace använder beläggningsdata för ytoptimering och för att se hur utrymmen faktiskt nyttjas, medan VemFusion kopplar samma data till HVAC, BMS och säkerhetssystem. Vemco har byggt detta sedan 2005 för kontor, universitet och offentliga byggnader, just för att kapa slöseriet från system som står och går dygnet runt.

På Pi-nivå kan du efterlikna en del av detta genom att låta regelmotorn skicka kommandon till din BMS via BACnet eller Modbus när ett rum varit tomt i tio minuter. Var försiktig med att styra kritiska system direkt från en prototyp — separera "föreslå åtgärd" från "utför åtgärd" tills du litar på datan.

När du bör gå från Pi till plattform

En Raspberry Pi är utmärkt för att bevisa ett koncept, mäta ett par rum och övertyga en beslutsfattare. Gränsen nås när du behöver garanterad noggrannhet, GDPR-hantering av kamerabaserad data, driftövervakning på hundratals noder och SLA på svarstider. Att underhålla trettio egenbyggda enheter, hålla operativsystem uppdaterade och hantera SD-kort som slits ut blir snabbt dyrare i arbetstid än en färdig lösning kostar. Regeln många integratörer följer: pilot på Pi, produktion på plattform.

Checklista innan driftsättning

  • Watchdog som startar om Pi:n vid hängning.
  • Read-only filsystem eller loggning till extern lagring för att spara SD-kortet.
  • NTP-synk så tidsstämplar på larm stämmer.
  • Larm för utebliven data, inte bara för överbeläggning.
  • Dokumenterade tröskelvärden per rum, inte hårdkodade i skriptet.

Har du kört en Raspberry Pi-pilot för närvarolarm och vill ta den vidare till drift med garanterad noggrannhet och integration mot HVAC, BMS och säkerhet? Kontakta Vemco så går vi igenom hur din pilotdata kan bli ett system som faktiskt kapar energislöseriet i dina byggnader.