Not every message a DNP3 outstation sends carries measurement data - some carry only status. The null unsolicited response is exactly that: an unsolicited message with no data objects at all, whose entire purpose is to deliver the outstation's internal indication flags. It is what an outstation sends to say it just powered up, that it is still alive, or simply that it is present and waiting. This guide explains what a null unsolicited response contains, why an outstation sends one on startup and as a heartbeat, and how a master uses it to detect restarts and bring unsolicited reporting online.
Null unsolicited response in one line: A DNP3 null unsolicited response is an unsolicited message that contains no event or measurement data, carrying only the outstation's internal indication (IIN) status flags. An outstation sends one on startup and can send them periodically as a keep-alive, using it to prove the communications link is alive and to signal its state - such as a recent restart - without transferring any point values.
Every DNP3 outstation response includes two internal indication bytes, a compact set of status flags describing the device's condition - whether it has restarted, whether it needs the time set, whether its event buffers have overflowed, and more. A normal response carries those flags alongside the actual data objects the master asked for or the events the outstation is pushing. A null unsolicited response strips the data away and sends the flags on their own, so the message is effectively a status-only heartbeat with an empty payload.
Because it is unsolicited, the outstation sends it on its own initiative rather than in reply to a poll. And because it is null, it costs almost nothing to send - a short frame with no point values to encode. That combination makes it an efficient way for an outstation to communicate the one thing that matters when there is no new data to report: that it is present, running, and in a particular state. The master reads the IIN flags out of the message and learns the outstation's condition without any measurement data changing hands.
It helps to see the null unsolicited response as the small sibling of the ordinary unsolicited response. Both are pushed by the outstation without a poll; the ordinary one delivers events, the null one delivers only status. An outstation that supports unsolicited reporting uses both - the null form for presence and state signaling, the data-bearing form for actual changes - and a master has to be ready to receive and process either.
The most important null unsolicited response is the one an outstation sends when it first comes online. Right after a power-up or restart, before it has any events to report and before it necessarily knows the correct time, an outstation configured for unsolicited operation typically sends an initial null unsolicited response with the Device Restart flag set. This is the outstation announcing itself: it is alive, it has just restarted, and it is waiting for the master to complete initialization. A master that receives it immediately knows to run its restart-recovery routine rather than waiting to discover the reboot some other way.
Beyond startup, an outstation can send null unsolicited responses at intervals as a keep-alive. When a site is quiet and no points are changing, an ordinary event-driven scheme would go silent, and a silent link is ambiguous - the master cannot tell a healthy-but-idle outstation from one that has dropped off. A periodic null unsolicited response resolves that ambiguity by proving, at regular intervals, that the outstation is still there and the path back to the master still works. It is a low-cost liveness signal that fills the gaps between real events.
Both uses share the same virtue: they let the master learn something important - the device restarted, or the device is still alive - without the expense of a full data exchange. On a constrained or costly link, sending a tiny status-only frame is far cheaper than provoking a complete integrity read just to confirm presence, so the null unsolicited response earns its keep as the lightweight signal in the protocol.
For a master, the initial null unsolicited response is a clean trigger for its reconnection logic. Seeing the Device Restart flag arrive in an unsolicited message tells the master, without any polling, that the outstation is freshly up and needs to be re-initialized. The master then walks its standard sequence: clear the restart flag, set the time if the outstation is asking for it, and read current values so its copy of the device state is rebuilt. Because the signal is pushed rather than discovered by polling, the master can react promptly even if its next scheduled poll of that device is some way off.
The null unsolicited response is also woven into how unsolicited reporting gets turned on in the first place. When an outstation is configured for unsolicited operation, it will not begin sending event-bearing unsolicited responses until the master has confirmed the initial null response and explicitly enabled unsolicited reporting for the relevant classes. That handshake ensures the master is actually ready to receive pushed events before the outstation starts pushing them, avoiding a situation where an outstation streams events into a master that has not finished coming up. The null response is the opening move in that exchange.
In a cloud SCADA deployment such as Merobix, where remote outstations across oil and gas sites push data over cellular and satellite links, these null messages are quietly doing a lot of work. The startup null tells the platform an unattended RTU rebooted - after a solar dip or a firmware update - so it can re-baseline that site's data. The periodic null heartbeat lets the platform distinguish an idle-but-healthy well from one that has genuinely lost communications, which is the difference between leaving a site alone and dispatching someone to check it. A message with no data still tells the operator something worth knowing.
It contains no event or measurement data at all - only the outstation's internal indication (IIN) status flags. Those flags describe the device's condition, such as whether it has restarted or needs its time set. The message is essentially a status-only heartbeat with an empty payload, used to signal presence and state rather than to transfer any point values.
To announce that it has just powered up or restarted and is waiting for the master to initialize it. The initial null response typically carries the Device Restart flag, which tells the master to run its restart-recovery routine - clearing the flag, setting the time, and re-reading current values. It also opens the handshake by which the master enables unsolicited reporting before the outstation begins pushing event data.
Both are pushed by the outstation without being polled, but a normal unsolicited response carries event data - actual changes in point values - while a null unsolicited response carries only status flags and no data. The null form is used for presence and state signaling, such as startup announcements and keep-alive heartbeats, whereas the data-bearing form delivers the events themselves.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.