Data Panda brengt de topics, retained messages en broker-telemetrie uit je MQTT-broker samen met de data uit de rest van je bedrijf. Vanop een plek maken we er dashboards, workflows, AI-toepassingen en apps van die je team elke dag gebruikt.
MQTT is een publish-subscribe messaging-protocol dat kleine berichten verplaatst tussen veel clients over onbetrouwbare netwerken met weinig bandbreedte. Clients publiceren naar hierarchische topics zoals plant/lijn-3/temperatuur, de broker routeert die berichten naar elke client met een matchende subscription, en het wire-formaat is klein genoeg dat een minimaal control-packet in twee bytes past. Drie QoS-niveaus (at most once, at least once, exactly once), retained messages en last-will messages geven het protocol genoeg betrouwbaarheid om flakey satelliet-, cellulaire en veldnetwerken te overleven zonder zware transportlaag.
Het ontstond in 1999 bij IBM, waar Andy Stanford-Clark en Arlen Nipper (toen bij Cirrus Link) het bouwden om een oliepijpleiding te monitoren over satelliet. De afkorting stond oorspronkelijk voor MQ Telemetry Transport en werd in 2013 officieel afgevoerd toen het protocol zijn SCADA-wortels ontgroeid was. OASIS publiceerde MQTT 3.1.1 als standaard in oktober 2014 en MQTT 5.0 in maart 2019. Vandaag zit het onder fleet-, manufacturing-, smart-building-, automotive-, energie- en consumer-IoT-stacks, op brokers als Eclipse Mosquitto, HiveMQ, EMQX, AWS IoT Core en Azure IoT Hub.
Het punt van MQTT naar een warehouse halen is niet om elke device-payload te landen, die zijn meestal hoogfrequent en horen op de hot path tussen sensor en controlelus. Wel om de broker-laag zichtbaar te maken: aantal connected clients, message-rate per topic-tak, leeftijd van retained messages, dropped-message-aantallen per QoS, last-will-fires per device-klasse, bytes in en uit per gateway. Die data staat naast ERP-productieruns, CRM-fiches en field-service-tickets, en de vraag waarom lijn 3 dinsdag stopte met readings sturen, stopt met gissen tussen firmware, netwerk en broker.
MQTT-broker- en topic-telemetrie gekoppeld aan ERP, CRM en field-service in SQL.
Laat MQTT-signalen acties starten over je stack heen.
Gebruik broker- en device-telemetrie om gedrag te scoren en te voorspellen waar de volgende uitval ontstaat.
Interne tools die MQTT-telemetrie lezen zonder toegang tot de broker-console.
Een lijst van concrete rapporten, automatisaties en AI-toepassingen die we op MQTT-data hebben gebouwd. Kies er een die bij je situatie past.
Waarom stopte lijn 3 dinsdagochtend met readings sturen?
Aantal connected clients, message-rate per topic-tak, last-will-fires en leeftijd van retained messages op dezelfde tijdlijn als productieruns, netwerk-events en firmware-deploys. Het gat van dinsdag stopt met vingerwijzen tussen firmware, netwerk en broker, en wordt een grafiek die onderhoud, IT en operations op dezelfde manier lezen.
Welke device-klasse veroorzaakt de meeste last-will-fires?
Last-will-events opgesplitst per device-klasse, firmware-versie, gateway en site. Toont de firmware-build die stilletjes elke paar uur een TCP-keep-alive laat vallen, de gateway met een onstabiele cellulaire verbinding, en de site waar het installatieteam nog de oude image heeft staan. Het gesprek met de device-leverancier stopt met anekdotes.
Wat kost onze IoT-park eigenlijk per klant?
Broker-uitgaven, cellulaire bytes per gateway en aantal connected clients gekoppeld aan de klantfiche in het warehouse. De IoT-lijn krijgt een noemer per klant, en account managers praten concreet over welke installaties de volgende broker-tier of SIM-plan-upgrade naar voren trekken.
Broker-uitgaven en cellulaire kosten gekoppeld aan message-volume, gateway en klant. De IoT-lijn is geen vlakke infrastructuurkost meer, maar krijgt een noemer per klant die finance kan verdedigen in de budgetbespreking.
Aantal connected toestellen, uptime en message-volume per klant op de CRM-fiche. Account managers praten concreet over SLA, plan-limieten en upgrade-triggers zonder eerst engineering de cijfers uit de broker-console te laten halen.
Connected-client counts, topic-gaten, last-will-fires en leeftijd van retained messages op een plek over firmware-deploys en netwerk-events heen. Het field-service-ticket vertrekt van een grafiek, niet van een telefoontje van de klant.
Je houdt de rapporteringstool die je al hebt. Wij koppelen hem aan het warehouse waar je MQTT-data staat.
OAuth-authenticatie. Standaard read-only. Wij tekenen een DPA en je admin houdt de sleutels.
Data stroomt naar je warehouse op het schema dat jij kiest. Bijna real-time of 's nachts, aan jou. Jij bent eigenaar.
We bouwen het eerste dashboard, de eerste workflow of AI-toepassing samen met jou, en geven de sleutels over. Of we blijven erbij voor doorlopende levering.
Wij zetten de basis op. Jouw team bouwt erop verder.
Beste match Teams die al een BI-analist of data engineer in huis hebben en zelf willen bouwen.
Wij bouwen het geheel, van A tot Z.
Beste match Teams zonder BI- of dev-capaciteit in huis. Jij zegt wat je nodig hebt en wij leveren het.
Jij. Ze komt in jouw warehouse terecht, op jouw cloud-account. Wij verkopen ze niet door en aggregeren ze niet. Stop je met ons, dan blijft het warehouse van jou en blijft het draaien.
Bijna real-time voor de meeste operationele systemen. Voor zwaardere bronnen plannen we per uur of per nacht. Je kiest op basis van wat de rapporten nodig hebben.
Nee. Heb je er geen, dan helpen we je er een kiezen en zetten we het op als deel van de eerste levering. Gangbare startpunten zijn Snowflake, Microsoft Fabric of een kleine Postgres-start.
Nee, en dat is bewust. Device-payloads zijn meestal hoogfrequent en horen op de hot path tussen sensor en controlelus. Wij halen broker-side metadata: aantal connected clients, message-rate per topic-tak en QoS, leeftijd van retained messages, last-will-fires, bytes in en uit per gateway. Die metadata beantwoordt de fleet-, capaciteits- en SLA-vragen. Als een specifieke topic readings draagt die je wel als bevraagbare historiek wil, splitsen we die expliciet af per topic, met bewaartermijnen en downsampling-regels eraan gekoppeld.
Wij halen broker-stats uit de system topics of admin-API die de broker zelf al aanbiedt (de $SYS-tak van Mosquitto, de management-APIs van HiveMQ en EMQX, de metrics-endpoints van AWS IoT en Azure IoT Hub). Voor per-topic-volume samplen we, in plaats van elke boodschap te mirroren, gescoped per topic filter, en we cachen lokaal, zodat een warehouse-refresh de belasting niet vermenigvuldigt. Op zware brokers leunen we op de metrieken die de broker zelf al aggregeert, in plaats van per client afzonderlijk te bevragen.
We bekijken je MQTT-opzet en de systemen eromheen. Samen kiezen we wat we als eerste bouwen.