NMIS, MQTT, and Why Open Source Flexibility Still Matters
Open Structured Data to support Event Driven AI Integrations
I’ve been building and working with NMIS for a long time. One of the design decisions I’m still proudest of is the plugin architecture, the idea that the core system should be solid and opinionated about network management, but open and flexible about how it connects to everything else.
That flexibility is why I was able to build a new NMIS event notification plugin last week, publish it to GitHub, and have events flowing to an MQTT broker in an hour or so.
The project is nmis-mqtt-event, and I want to explain why it matters and where it’s heading.
The Plugin Architecture That Makes This Possible
NMIS has always supported custom notification methods. When NMIS detects an event (a node goes down, an interface flaps, a threshold is breached) the notification system determines what to do with it. Out of the box, you get email, syslog, and other standard methods. But the architecture was designed so that anyone can write a new notifier and plug it in.
That’s exactly what nmis-mqtt-event does. It’s a Perl module that sits in the NMIS notification path and publishes events as structured JSON to an MQTT broker. Each event is published to a topic hierarchy organised by node name, so downstream systems can subscribe to exactly what they care about.
The plugin also includes a configurable ignore list using regex patterns, so you can filter out the noise before it ever hits the broker. Authentication, topic configuration, and logging are all handled through a simple config file.
Why MQTT Changes the Integration Story
If you’ve worked with network management event processing, you know the traditional pattern: events go to email, maybe syslog, maybe a ticket system if you’ve set up the integration. Each destination requires its own connector, its own configuration, and often its own maintenance burden.
MQTT flips this. Instead of point-to-point integrations, you publish events to a broker. I’m using Mosquitto, which is open source and runs happily on minimal hardware, and any number of downstream systems can subscribe.
This is a fundamental shift from “NMIS sends events to System X” to “NMIS publishes events and any system can consume them.”
The JSON payload means downstream systems get a structured data object they can immediately parse and act on. No screen-scraping emails. No parsing syslog strings. Just clean, structured event data.
What You Can Build With This
Once events are flowing through MQTT, the integration possibilities open up significantly. Two open source tools I’d highlight:
Node-RED, a flow-based visual programming tool originally built by IBM. You can subscribe to the MQTT topic, receive the JSON event, and build processing flows visually. Route critical alerts one way, performance events another. Enrich events with additional context. Forward to Slack, Teams, PagerDuty, or anything else with an API. Node-RED makes this kind of event routing accessible to people who aren’t writing code full-time.
n8n, a workflow automation platform that takes a similar approach but with a broader integration ecosystem. Subscribe to the MQTT events, parse the JSON, and connect to hundreds of downstream services and APIs.
The pattern is the same in both cases: NMIS event → MQTT broker → subscriber tool → process and act. Each component is open source, each is independently replaceable, and the whole chain can run on modest infrastructure.
Build and Release With Claude Code
A side note on how this was built: I used Claude Code, Anthropic’s AI coding assistant, to develop the plugin release. The plugin was designed and written by me including the configuration and optional ignore list feature. AI helped with the code comments, README, the install script, all developed in collaboration with the AI. This is becoming my preferred way to work on focused projects like this. Many times I have written useful code, but not made it public because of documentation and the release process, AI made that problem go away, and a release is what we have.
What’s Coming Next
This is where it gets interesting. In an upcoming article, I’ll be walking through an integration between NMIS, MQTT, n8n, and an AI large language model. The idea is straightforward: NMIS detects an event, publishes it via MQTT, n8n receives and processes it, and then passes the event context to an LLM for intelligent analysis and response recommendations.
Imagine your network management system not just telling you “Node X is down” but providing context-aware analysis: what’s likely affected, what similar events have occurred before, and what the recommended response should be. That’s where this is heading.
The foundation is the open, message-based architecture that nmis-mqtt-event enables. Get the events flowing as structured data through a broker, and the downstream intelligence can evolve independently.
Getting Started
The nmis-mqtt-event repository includes an install script and documentation. You’ll need NMIS 9, a Mosquitto broker (or any MQTT broker), and the Perl Net::MQTT::Simple module. The install script handles the file placement and permissions.
If you’re running NMIS and want to start exploring message-based event integration, this is a practical starting point. Fork it, adapt it, improve it, that’s how open source works.
Keith Sinclair is the founder of NMIS and has spent his career designing and building infrastructure management solutions and highly scalable enterprise applications. The nmis-mqtt-event project is available under GPL-3.0 at github.com/kcsinclair/nmis-mqtt-event.