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
flowchart LR
subgraph sg0["MQTT Sensor Data Ingestion Flow"]
direction LR
n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/mqtt.svg' width='40' height='40' /></div><br/>MQTT Sensor Data Ingestion"]
n1@{ icon: "mdi:swap-vertical", form: "rounded", label: "Workflow Configuration", pos: "b", h: 48 }
n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Edge Preprocessing & Validat.."]
n3@{ icon: "mdi:swap-vertical", form: "rounded", label: "Normalize Sensor Data", pos: "b", h: 48 }
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/postgres.svg' width='40' height='40' /></div><br/>Store Raw Data in Time-Serie.."]
n5@{ icon: "mdi:cog", form: "rounded", label: "Aggregate Sensor Readings", pos: "b", h: 48 }
n6@{ icon: "mdi:robot", form: "rounded", label: "AI Anomaly Detection Agent", pos: "b", h: 48 }
n7@{ icon: "mdi:brain", form: "rounded", label: "OpenAI Chat Model", pos: "b", h: 48 }
n8@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Check for Anomalies", pos: "b", h: 48 }
n9["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/postgres.svg' width='40' height='40' /></div><br/>Store Anomaly Records"]
n10["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Send Alert to Dashboard API"]
n11["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/slack.svg' width='40' height='40' /></div><br/>Send Slack Alert"]
n12@{ icon: "mdi:message-outline", form: "rounded", label: "Send Email Alert", pos: "b", h: 48 }
n16["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Statistical Anomaly Detection"]
n11 --> n12
n7 -.-> n6
n8 --> n9
n3 --> n4
n9 --> n10
n1 --> n2
n5 --> n16
n6 --> n8
n0 --> n1
n10 --> n11
n16 --> n6
n2 --> n3
n4 --> n5
end
subgraph sg1["Model Retraining Schedule Flow"]
direction LR
n13@{ icon: "mdi:play-circle", form: "rounded", label: "Model Retraining Schedule", pos: "b", h: 48 }
n14["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/postgres.svg' width='40' height='40' /></div><br/>Fetch Historical Data for Re.."]
n15["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Retrain ML Model via API"]
n13 --> n14
n14 --> n15
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0,n13 trigger
class n6 ai
class n7 aiModel
class n8 decision
class n4,n9,n14 database
class n10,n15 api
class n2,n16 code
classDef customIcon fill:none,stroke:none
class n0,n2,n4,n9,n10,n11,n16,n14,n15 customIcon
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
| Vad det här flödet automatiserar | Resultat du får |
|---|---|
|
|
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.
- Lägg till noden MQTT Stream Intake och ställ in Topics till
sensors/+/data. - Om er MQTT-broker kräver autentisering, lägg till inloggningsuppgifter i MQTT Stream Intake (inte förkonfigurerat i det här arbetsflödet).
- Bekräfta att exekveringsflödet fortsätter från MQTT Stream Intake till Pipeline Settings.
Steg 2: Anslut pipeline-inställningar
Definiera delade konfigurationsvärden som används i hela arbetsflödet.
- Öppna Pipeline Settings och ställ in anomalyThreshold till
2.5. - Ställ in dashboardApiUrl till
<__PLACEHOLDER_VALUE__Dashboard API endpoint URL__>. - Ställ in slackChannel till
<__PLACEHOLDER_VALUE__Slack channel name__>. - Ställ in alertEmail till
<__PLACEHOLDER_VALUE__Alert recipient email address__>. - Ställ in mlModelApiUrl till
<__PLACEHOLDER_VALUE__ML model training API endpoint__>.
{{ $('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.
- I Edge Data Validation, behåll Mode inställt på
runOnceForEachItemoch bevara den medföljande JS-koden för validering och rensning. - 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) }}. - 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.
- 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 }}. - Inloggningsuppgifter krävs: Anslut era Postgres-inloggningsuppgifter i Archive Raw Readings.
- Ställ in Aggregate Metrics till Aggregate =
aggregateAllItemData. - 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.
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.
- Konfigurera AI Anomaly Reviewer med den medföljande systemprompten och behåll Prompt Type inställt på define.
- Säkerställ att OpenAI Chat Engine är ansluten som språkmodell för AI Anomaly Reviewer.
- Inloggningsuppgifter krävs: Anslut era openAiApi-inloggningsuppgifter i OpenAI Chat Engine (inloggningsuppgifter läggs till på den överordnade LLM-noden, inte agenten).
- I Anomaly Decision Gate, ställ in det booleska villkoret till att
{{ $('AI Anomaly Reviewer').item.json.is_anomaly }}är lika medtrue.
Steg 6: Konfigurera larm och loggning
Logga bekräftade avvikelser och skicka realtidslarm till er dashboard, Slack och e-post.
- I Log Anomaly Entries, skriv till schemat public och tabellen anomaly_records med mappningar som
{{ $json.explanation }}och{{ $json.recommended_action }}. - Inloggningsuppgifter krävs: Anslut era Postgres-inloggningsuppgifter i Log Anomaly Entries.
- Konfigurera Post Dashboard Alert med URL inställd på
{{ $('Pipeline Settings').first().json.dashboardApiUrl }}och body-parametrar försensor_id,timestampochanomaly_type. - I Slack Alert Dispatch, behåll Text som angivet och ställ in Channel ID till
{{ $('Pipeline Settings').first().json.slackChannel }}. - Inloggningsuppgifter krävs: Anslut era slackOAuth2Api-inloggningsuppgifter i Slack Alert Dispatch.
- I Email Alert Send, ställ in To Email till
{{ $('Pipeline Settings').first().json.alertEmail }}och ersätt From Email med er avsändaradress. - 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.
- Ställ in Retraining Schedule Trigger att köras var 7:e dag kl. 02:00.
- 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. - Inloggningsuppgifter krävs: Anslut era Postgres-inloggningsuppgifter i Fetch Training History.
- 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.
- Trigga MQTT Stream Intake manuellt genom att publicera en exempel-payload till
sensors/+/dataoch bekräfta att den går vidare till Pipeline Settings → Edge Data Validation → Standardize Sensor Values. - Kör en manuell exekvering från Z-Score Anomaly Check och verifiera att AI Anomaly Reviewer returnerar ett JSON-svar med
is_anomalyochconfidence. - Kontrollera output-kedjan Anomaly Decision Gate → Log Anomaly Entries → Post Dashboard Alert → Slack Alert Dispatch → Email Alert Send för lyckad körning.
- Exekvera Retraining Schedule Trigger manuellt och bekräfta att Fetch Training History skickar data till Trigger Model Retrain API.
- När allt är bekräftat, växla arbetsflödet till Active för att starta livebearbetning.
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
Cirka en timme om din MQTT-broker och Postgres redan kör.
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).
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.
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.
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.
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.
Väldigt många, så länge dina Postgres- och n8n-resurser är dimensionerade för det.
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.