An MQTT event looks simple enough: a publisher sends a message and an automation reacts. Working out what that message means is harder. A device joining the network, becoming reachable, going offline, or exposing a changed service can tell you something useful. But it can also reflect a normal reboot, a sleeping phone, or a Wi-Fi change.
This guide is for a Home Assistant installation and MQTT broker you own or administer. It covers turning device-related events into automations you can test, without treating every network observation as an emergency.
Define the event first
MQTT sends application messages to named topics. A subscriber receives messages for the topics it subscribes to. MQTT alone does not tell the subscriber how to interpret the payload. MQTT defines delivery behavior and topic matching. The publisher defines what the payload means. Before writing an automation, record exactly what produces the event. OASIS: MQTT Version 5.0
For network monitoring, useful event names might be new_device, device_online, device_offline, or new_port. Each means something different. A new_device event may mean the monitor has seen an identifier for the first time in its inventory. That tells you nothing about who owns the device or whether it's unwanted. An offline event may come from missed probes; it doesn't prove the power has failed.
Before configuring Home Assistant, write one sentence defining the event: “This event is emitted when…” Include the observation point, time window, and exclusions. Otherwise, an “intruder alert” label can make a stronger claim than the data supports.
Discovery and event messages
Home Assistant's MQTT integration can discover devices and entities from MQTT discovery messages, or you can configure devices manually. Discovery describes how Home Assistant should create or restore an entity. An event message reports a later state change or occurrence that an automation can use. These flows are related, but retaining a discovery configuration doesn't mean an event should also be retained or replayed. Home Assistant: MQTT integration
After a broker or Home Assistant restart, discovery information may be processed again before devices and entities become available. A publisher can respond to Home Assistant's birth message by republishing discovery data. Whether it is safe to delay or repeat ordinary events is a separate judgment call. Home Assistant: MQTT discovery messages and availability
Start with one documented event entity or state topic. Avoid using the broad topic filter # as a permanent trigger. The listening tool is handy for a quick inspection. An automation you keep running should use a narrow source.
Real-message inspection before notifications
Leave the phone alert for later. First, inspect a few real messages while making a harmless change you expect to see: reconnect a test device, restart a lab service, or change a known device's network connection. Open the MQTT integration in Home Assistant and use its listening tool for the documented topic. Record the topic, payload fields, time, and any unique identifier. The integration documentation explains how to use # to inspect messages temporarily and a topic-specific filter to narrow the view. Home Assistant: listening to an MQTT topic
Check four things in the captured data:
- Identity: Which stable field identifies the source? Prefer a documented device ID or a combination of inventory ID and MAC address over a display name alone.
- Timestamp: Does the publisher supply a time? If so, is it clearly the detection time, publication time, or last-seen time?
- Reason: Can the payload tell a first observation apart from a reconnect, a restart, or an error?
- Duplicates: Does one physical change produce multiple messages? Record a short test sequence before adding any suppression rule.
If the payload doesn't give the automation enough context, stick to a Home Assistant logbook entry during testing. Don't infer a device name, owner, location, or security severity from a MAC address or vendor lookup alone.
A first automation with limited consequences
A record is usually more useful than an alarm at this stage. For example, create a notification that says “A network monitor reported a new device event; review the inventory” and include only fields the publisher actually supplied. The administrator can then compare the event with a known-device list, the router's client list, or switch and access-point data.
Keep the trigger narrow. Add a condition that matches what the event means: a new_device event might be worth recording only when its stable identifier isn't already in a documented allow-list. For a device_offline event, you might want a notice only for a chosen NAS, access point, or service host, and only after the monitor's own grace period has passed. Don't trigger a security response from a generic “device went offline” message.
Add an explicit test mode and send the result to a persistent notification, logbook, or quiet testing channel first. Make the known change again. Did the automation run once, with the fields you expected? If your publisher or broker can replay messages, test again after a restart. A successful test proves only that particular path works. It doesn't show that every device will be seen or every outage explained.
Noise control based on observed events
Network events often arrive in bursts. Wi-Fi clients roam and devices sleep; routers reboot and DHCP records change. A short cooldown can prevent repeated notices, but base it on behavior you've observed rather than a number copied from another network. During testing, keep a small table with the event type, source, time, what actually happened, and whether the notification was useful.
Give each purpose its own rule. One can record a first-seen device for later review. Another can alert you when a NAS becomes unavailable, while a third collects repeated events for a daily summary. Put everything in one catch-all automation and it becomes hard to adjust sensitivity without accidentally silencing something important.
Keep credentials, full network inventories, and unredacted MAC and IP lists out of mobile notifications. Those fields can be useful in the local Home Assistant history or a protected dashboard. Notification content, though, may appear on lock screens and in backups. When an authorized administrator needs more detail, link them to the local record.
The role of a network inventory publisher
An MQTT publisher that exposes network observations gives Home Assistant a structured way to react to changes. It's still only one input among several. DeviceShelf's server edition is one option: its documented Home Assistant export uses MQTT discovery and provides an event entity for new_device, device_online, device_offline, and new_port. Treat those events as prompts to inspect the underlying inventory, not as automatic conclusions about security or ownership. Server documentation
The same approach applies to any publisher. Limit broker access to the systems that need it and use a dedicated account with the least permissions the integration supports. Before changing discovery, availability, or retained-message settings, check the publisher's current documentation. Home Assistant's setup instructions explain how to configure the MQTT integration through its Devices & services settings, without assuming a particular add-on or custom component. Home Assistant: setting up MQTT
Automation review after normal network changes
For a week, compare each event with what actually happened. Was the device new, just reconnecting, or already known under a private Wi-Fi address? Did a planned restart cause the offline event? Did a port change come from an intentional service update? Mark false or unhelpful events, then adjust the narrow rule that produced them.
This review helps make the automation dependable enough for everyday use. A few events you can explain are worth more than a busy dashboard or an urgent-sounding notification nobody can act on. You need a repeatable way to decide whether to record, review, investigate, or ignore an event, based on evidence from the network you manage.