Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan
januari 22, 2026

Slack + Postgres: pålitliga MQTT-avvikelselarm

Rickard Andersson Partner, Nodenordic.se

Dina sensorer pratar oavbrutet. Dina aviseringar gör det också. Efter ett tag blir Slack-pingar bara bakgrundsbrus, och den enda toppen som faktiskt spelar roll slinker igenom eftersom den ser ut som de andra hundra ”kanske”-topparna.

Det här drabbar driftansvariga först. Men underhållschefer och produktteam som kör uppkopplade enheter känner av det lika mycket. Med den här automationen för MQTT-avvikelseaviseringar slutar du reagera på rått brus och börjar få notifieringar du kan agera på.

Du får se hur flödet fångar MQTT-mätvärden, lagrar dem säkert i Postgres, kontrollerar avvikelser två gånger (matematik plus AI) och först därefter skickar Slack- och e-postaviseringar med en dashboardlänk som underlag.

Så fungerar den här automationen

Hela n8n-flödet, från trigger till slutligt utfall:

n8n Workflow Template: Slack + Postgres: pålitliga MQTT-avvikelselarm

Problemet: brusiga aviseringar och att missa den riktiga toppen

MQTT är utmärkt på att flytta data snabbt. Problemet är vad som händer efteråt. Råa mätvärden hoppar, sensorer driver, och ”normalt” förändras beroende på tid på dygnet, belastning, väder eller ett dussin andra faktorer. Om du larmar på enkla trösklar får du spam. Om du höjer trösklarna för att minska spammen missar du tidiga varningssignaler som hade kunnat förhindra stillestånd. Under tiden fastnar teamet i manuella stickprovskontroller, att skanna dashboards och att diskutera om ett larm är på riktigt.

Friktionen växer. Och den dyker oftast upp vid värsta möjliga tillfälle.

  • Larmtrötthet byggs snabbt upp, så svarstiden blir långsammare även när felet är allvarligt.
  • Manuell övervakning blir en daglig vana som i tysthet äter upp en eller två timmar, särskilt över flera enheter och topics.
  • Inkonsekventa sensorformat och saknade värden skapar falsklarm, och sedan slutar folk lita på systemet.
  • Utan tillförlitlig loggning kan du inte enkelt granska vad som hände eller träna om detekteringslogiken baserat på verklig historik.

Lösningen: logga allt, flagga avvikelser och larma bara när det är på riktigt

Det här flödet tar emot MQTT-sensormätvärden när de kommer in, strukturerar dem och lagrar den råa sanningen i Postgres så att du alltid har en tillförlitlig historik. Därefter aggregerar det mätvärden till användbara nyckeltal (så att du inte reagerar på varje liten svajning), kör en snabb avvikelsekontroll med en z-score-metod och skickar bara misstänkta fall vidare till en AI-agent för granskning. Den andra granskningen är förtroendelagret: AI-agenten kontrollerar kontext, validerar om avvikelsen ser meningsfull ut och hjälper till att minska falsklarm. Om det verkligen är värt uppmärksamhet loggar flödet avvikelsen, postar ett dashboard-larm för visualisering och skickar notifieringen till Slack och e-post.

Flödet startar med MQTT-inläsning och grundläggande pipeline-inställningar. Därefter valideras och standardiseras värden, och arkiveras i Postgres för rapportering och modellträning. Efter z-score-kontrollen och AI-granskningen styr en ”beslutsgrind för avvikelse” vad som eskaleras till Slack, e-post och din dashboard.

Det här får du: automation vs. resultat

Exempel: så här ser det ut

Säg att du övervakar 20 sensorer och idag tittar du på en dashboard cirka 5 gånger per dag eftersom larmen inte går att lita på. Även om varje koll bara är ”en minut” blir det ungefär 2 timmar i veckan i kontextbyten, plus tiden som slösas på att jaga falsklarm. Med det här flödet loggar du fortfarande varje MQTT-mätvärde till Postgres, men bara bekräftade avvikelser når Slack och e-post. I praktiken tittar du på dashboarden när du får en ping, inte hela dagen.

Det här behöver du

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
  • MQTT-broker för intag av sensormeddelanden i realtid
  • Postgres för att lagra råa mätvärden och avvikelser
  • OpenAI API-nyckel (hämta den från din OpenAI-dashboard)

Kunskapsnivå: Medel. Du kopplar ihop tjänster, klistrar in inloggningsuppgifter och justerar några prompts och trösklar.

Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).

Så fungerar det

MQTT-mätvärden triggar flödet. Så fort en enhet publicerar till dina prenumererade topics startar flödet och tillämpar dina pipeline-inställningar för den strömmen.

Värden valideras och normaliseras. Dåliga payloads filtreras bort, enheter och format standardiseras och du får korrekt formaterade, jämförbara mätvärden i stället för en stökig mix av strängar, null-värden och ”nästan-siffror”.

Avvikelsedetektering körs i två pass. Aggregerade nyckeltal går igenom en z-score-kontroll för att fånga tydliga toppar, och sedan granskar en AI-agent de misstänkta händelserna så att du inte väcker folk för ofarligt jitter.

Bara bekräftade problem skickas vidare. Flödet loggar avvikelsen i Postgres, postar ett dashboard-larm via en HTTP-förfrågan och skickar samma händelse till Slack och e-post så att rätt personer ser den snabbt.

Du kan enkelt ändra känslighetströsklarna så att de matchar din miljö utifrån dina behov. Se hela implementeringsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementering

Steg 1: Konfigurera MQTT-triggern

Börja med att definiera hur sensordata kommer in i arbetsflödet i realtid.

  1. Lägg till noden MQTT Stream Intake och ställ in Topics till sensors/+/data.
  2. Om er MQTT-broker kräver autentisering, lägg till inloggningsuppgifter i MQTT Stream Intake (inte förkonfigurerat i det här arbetsflödet).
  3. Bekräfta att exekveringsflödet fortsätter från MQTT Stream Intake till Pipeline Settings.

⚠️ Vanlig fallgrop: Om MQTT-brokern kräver inloggningsuppgifter kommer triggern att misslyckas utan tydlig felindikering tills ni lägger till dem i MQTT Stream Intake.

Steg 2: Anslut pipeline-inställningar

Definiera delade konfigurationsvärden som används i hela arbetsflödet.

  1. Öppna Pipeline Settings och ställ in anomalyThreshold till 2.5.
  2. Ställ in dashboardApiUrl till <__PLACEHOLDER_VALUE__Dashboard API endpoint URL__>.
  3. Ställ in slackChannel till <__PLACEHOLDER_VALUE__Slack channel name__>.
  4. Ställ in alertEmail till <__PLACEHOLDER_VALUE__Alert recipient email address__>.
  5. Ställ in mlModelApiUrl till <__PLACEHOLDER_VALUE__ML model training API endpoint__>.

Tips: Dessa värden refereras av flera noder med uttryck som {{ $('Pipeline Settings').first().json.dashboardApiUrl }}. Håll dem uppdaterade för att undvika fel längre fram i flödet.

Steg 3: Sätt upp datavalidering och standardisering

Validera inkommande sensordata och normalisera fält innan lagring.

  1. I Edge Data Validation, behåll Mode inställt på runOnceForEachItem och bevara den medföljande JS-koden för validering och rensning.
  2. Konfigurera Standardize Sensor Values för att mappa fält med uttryck som {{ $json.sensor_id }}, {{ new Date($json.timestamp).toISOString() }} och {{ parseFloat($json.value) }}.
  3. Säkerställ att normalized_value beräknas med {{ $json.sensor_type === 'temperature' && $json.unit === 'F' ? (parseFloat($json.value) - 32) * 5/9 : parseFloat($json.value) }}.

Steg 4: Lagra mätvärden och beräkna anomali-score

Arkivera rådata, aggregera mätvärden och tillämpa statistisk avvikelsedetektering.

  1. Konfigurera Archive Raw Readings för att skriva till schemat public och tabellen sensor_readings med kolumnmappningar som {{ $json.sensor_id }} och {{ $json.normalized_value }}.
  2. Inloggningsuppgifter krävs: Anslut era Postgres-inloggningsuppgifter i Archive Raw Readings.
  3. Ställ in Aggregate Metrics till Aggregate = aggregateAllItemData.
  4. Låt JS-koden i Z-Score Anomaly Check vara intakt, som använder {{ $('Pipeline Settings').item.json.anomaly_threshold || 3 }} för tröskelvärdet.

⚠️ Vanlig fallgrop: Koden refererar till anomaly_threshold, men Pipeline Settings sätter anomalyThreshold. Synka fältnamnet eller uppdatera koden för att undvika att standardvärdet används.

Steg 5: Sätt upp AI-granskning och beslutlogik

Använd en AI-agent för att verifiera avvikelser och skicka bekräftade vidare i flödet.

  1. Konfigurera AI Anomaly Reviewer med den medföljande systemprompten och behåll Prompt Type inställt på define.
  2. Säkerställ att OpenAI Chat Engine är ansluten som språkmodell för AI Anomaly Reviewer.
  3. Inloggningsuppgifter krävs: Anslut era openAiApi-inloggningsuppgifter i OpenAI Chat Engine (inloggningsuppgifter läggs till på den överordnade LLM-noden, inte agenten).
  4. I Anomaly Decision Gate, ställ in det booleska villkoret till att {{ $('AI Anomaly Reviewer').item.json.is_anomaly }} är lika med true.

Steg 6: Konfigurera larm och loggning

Logga bekräftade avvikelser och skicka realtidslarm till er dashboard, Slack och e-post.

  1. I Log Anomaly Entries, skriv till schemat public och tabellen anomaly_records med mappningar som {{ $json.explanation }} och {{ $json.recommended_action }}.
  2. Inloggningsuppgifter krävs: Anslut era Postgres-inloggningsuppgifter i Log Anomaly Entries.
  3. Konfigurera Post Dashboard Alert med URL inställd på {{ $('Pipeline Settings').first().json.dashboardApiUrl }} och body-parametrar för sensor_id, timestamp och anomaly_type.
  4. I Slack Alert Dispatch, behåll Text som angivet och ställ in Channel ID till {{ $('Pipeline Settings').first().json.slackChannel }}.
  5. Inloggningsuppgifter krävs: Anslut era slackOAuth2Api-inloggningsuppgifter i Slack Alert Dispatch.
  6. I Email Alert Send, ställ in To Email till {{ $('Pipeline Settings').first().json.alertEmail }} och ersätt From Email med er avsändaradress.
  7. Lägg till SMTP-inloggningsuppgifter i Email Alert Send om er n8n-instans kräver det.

Steg 7: Konfigurera omskolningsschema och API-anrop

Automatisera omskolning av modellen med en schemalagd batch av historiska data.

  1. Ställ in Retraining Schedule Trigger att köras var 7:e dag kl. 02:00.
  2. I Fetch Training History, behåll SQL-frågan: SELECT sensor_id, timestamp, value, normalized_value, data_quality FROM sensor_readings WHERE timestamp > NOW() - INTERVAL '30 days' ORDER BY timestamp DESC.
  3. Inloggningsuppgifter krävs: Anslut era Postgres-inloggningsuppgifter i Fetch Training History.
  4. Konfigurera Trigger Model Retrain API med URL inställd på {{ $('Pipeline Settings').first().json.mlModelApiUrl }} och JSON Body inställd på den medföljande payloaden som inkluderar {{ $('Fetch Training History').all() }}.

Steg 8: Testa och aktivera ert arbetsflöde

Validera varje väg och aktivera arbetsflödet för användning i produktion.

  1. Trigga MQTT Stream Intake manuellt genom att publicera en exempel-payload till sensors/+/data och bekräfta att den går vidare till Pipeline SettingsEdge Data ValidationStandardize Sensor Values.
  2. Kör en manuell exekvering från Z-Score Anomaly Check och verifiera att AI Anomaly Reviewer returnerar ett JSON-svar med is_anomaly och confidence.
  3. Kontrollera output-kedjan Anomaly Decision GateLog Anomaly EntriesPost Dashboard AlertSlack Alert DispatchEmail Alert Send för lyckad körning.
  4. Exekvera Retraining Schedule Trigger manuellt och bekräfta att Fetch Training History skickar data till Trigger Model Retrain API.
  5. När allt är bekräftat, växla arbetsflödet till Active för att starta livebearbetning.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • Slack-inloggningar kan löpa ut eller kräva specifika behörigheter. Om det skapar fel, kontrollera först Slack-appens installation och token-scopes i dina Slack-admininställningar.
  • Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om efterföljande noder fallerar på grund av tomma svar.
  • Standardprompter i AI-noder är generiska. Lägg in din tonalitet tidigt, annars kommer du att redigera utdata för alltid.

Vanliga frågor

Hur lång tid tar det att sätta upp den här automationen för MQTT-avvikelseaviseringar?

Cirka en timme om din MQTT-broker och Postgres redan kör.

Behöver jag kunna koda för att automatisera MQTT-avvikelseaviseringar?

Nej. Du kommer mest att koppla ihop konton och redigera några fält och prompter. Det hjälper att vara bekväm med grundläggande dataformat (JSON, tal, tidsstämplar).

Är n8n gratis att använda för det här flödet för MQTT-avvikelseaviseringar?

Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna med OpenAI API-kostnader, som vanligtvis är några cent per dag vid låg larmvolym.

Var kan jag hosta n8n för att köra den här automationen?

Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och hanterar n8n bra. Egen drift ger obegränsat antal körningar men kräver grundläggande serveradministration.

Kan jag anpassa det här flödet för MQTT-avvikelseaviseringar med olika känslighet per sensortyp?

Ja, och det är en av de första justeringarna du bör göra. De flesta team justerar trösklarna i z-score-avvikelsekontrollen och reglerna i prompten för AI-granskaren så att ”brusiga” sensorer inte väcker folk. Du kan också ändra pipeline-inställningarna och standardiseringsstegen för att tillämpa olika baslinjer per topic. Om du tränar om modeller enligt ett schema, uppdatera frågan för träningshistorik så att varje sensorgrupp lär sig av sina egna historiska mönster.

Varför misslyckas min Slack-anslutning i det här flödet?

Oftast beror det på en utgången token eller saknade scopes efter en Slack-adminändring. Återanslut Slack-noden i n8n och bekräfta att appen fortfarande har behörighet att posta i målkanalen. Om flödet postar i privata kanaler, se till att appen är explicit inbjuden. Rate limiting kan också uppstå vid toppar, så det kan hjälpa att batcha larm eller posta sammanfattningar när trafiken sticker iväg.

Hur många mätvärden klarar den här automationen för MQTT-avvikelseaviseringar?

Väldigt många, så länge dina Postgres- och n8n-resurser är dimensionerade för det.

Är den här automationen för MQTT-avvikelseaviseringar bättre än att använda Zapier eller Make?

Ofta, ja, eftersom det här flödet inte bara är ”skicka MQTT till Slack”. Du har förgreningslogik, en databas-skrivväg, aggregering och ett AI-valideringslager, och n8n är helt enkelt mer bekvämt med den typen av pipeline. Egen drift är också viktigt när du har konstant sensortrafik, eftersom exekveringsbegränsningar snabbt blir smärtsamma på andra plattformar. Zapier eller Make kan fortfarande fungera om du bara behöver ett enkelt tröskellarm och volymen är låg. Om du är osäker, prata med en automationsexpert och få en snabb rekommendation.

När det här väl är igång blir Slack tyst på ett bra sätt. Du fångar fortfarande varje mätvärde i Postgres, men bara avvikelser som är värda uppmärksamhet avbryter din dag.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Launch login modal Launch register modal