Normal Modbus is strictly one-to-one: a master addresses one slave by its unit ID, the slave acts, and the slave answers. Address 0 breaks that pattern on purpose. A message sent to slave address 0 is a broadcast, meant for every device on the serial line at once, and by design no device replies to it. This guide explains how broadcast works, why it applies only to write commands on RTU and ASCII rather than to reads or to Modbus TCP, the real danger of a write that nobody acknowledges, and the handful of jobs broadcast is genuinely good at, such as pushing a common setpoint or a time value to a whole line in one shot.
Broadcast Write Address 0 in one line: A Modbus broadcast write is a message sent to slave address 0 on a serial line, which every device on that line receives and acts on but none acknowledges. It works only for write function codes on Modbus RTU and ASCII - reads and Modbus TCP do not use it - and because there is no response, the master gets no confirmation that any device succeeded. It is useful for pushing one identical value to many devices at once, at the cost of that silent, unverifiable delivery.
On a Modbus serial line, every slave has a unit ID from 1 up, and each device only responds to frames carrying its own ID. Address 0 is reserved and belongs to no single device; it is the broadcast address. When the master transmits a write frame with the unit ID field set to 0, every device on the bus recognizes it as a broadcast, processes the write, and then stays silent. The silence is not a failure - it is required. If several devices all tried to answer a broadcast at once, their responses would collide on the shared line and garble each other, so the specification simply says no device answers a broadcast.
That design has a direct consequence for the master. In a normal unicast exchange the master sends a request and then waits for a reply, using the reply both as confirmation and as the trigger to move on to its next transaction. With a broadcast there is no reply to wait for, so the master sends the frame, waits a short fixed turnaround time to let every slave finish processing, and then proceeds. The whole conversation is one-directional. The master has spoken to the entire bus in a single frame, but it has learned nothing back about whether the message was received cleanly, whether the values were legal, or whether any device rejected the write.
Because broadcast rides on the same framing as a normal write, the frame still carries a function code, a starting address, the quantity, the data, and a valid checksum. Only the address byte and the absence of a response distinguish it. A slave that receives a corrupted broadcast simply discards it in silence, exactly as it would discard any frame that fails its checksum, which is part of why broadcast delivery is inherently best-effort.
Broadcast makes sense only for write function codes - the ones that push data out, such as write single coil, write single register, write multiple coils, and write multiple registers. It makes no sense for reads, because a read is a request for data to be sent back, and if every device on the bus answered a broadcast read at once the responses would collide and be unusable. There is no meaningful notion of broadcasting a read, so read function codes are always addressed to a single unit ID and always expect one reply.
The other major limit is transport. Broadcast to address 0 is a serial-line concept from Modbus RTU and ASCII, where all devices share one physical bus and a single frame naturally reaches everyone. Modbus TCP does not work this way. Over TCP, a client opens a connection to a specific server and unit, and there is no shared bus to broadcast onto in the RTU sense. The Modbus TCP unit identifier is used mainly for routing through gateways to a downstream serial device, so a broadcast semantics on TCP is not part of the standard behavior; a client that needs to write the same value to many TCP devices simply sends many individual writes.
This is why broadcast is a niche tool rather than a general one. It exists to solve a specific serial-bus problem - reaching many devices on one wire efficiently - and outside that setting it does not apply. Where a gateway bridges TCP to serial, whether a broadcast on the TCP side is honored as a serial broadcast on the downstream bus depends entirely on the gateway, so relying on it across a converter is fragile and should be verified against the specific hardware rather than assumed.
The defining hazard of a broadcast write is that no device acknowledges it, so the master cannot know the outcome. In a normal write, a slave that receives an illegal address or an out-of-range value returns an exception, and the master can log it, retry, or alert an operator. A broadcast throws that safety net away. If one device on the bus was momentarily busy, missed the frame, or rejected the write, the master hears nothing and carries on as if everything succeeded. The bus can silently drift into an inconsistent state where some devices took the new value and others kept the old one, with no error anywhere to reveal it.
That risk is exactly why broadcast is inappropriate for anything safety-critical or anything where devices must agree. You would not broadcast a command that trips equipment or changes a control mode, because a partial delivery could leave the process in a dangerous mix of states with no indication that it happened. For those actions, addressing each device individually and checking each response is the correct, if slower, approach. Broadcast trades verifiability for speed, and that trade is only acceptable when a missed write on one device is harmless or self-correcting.
Where broadcast genuinely earns its place is bulk operations of identical, low-consequence data. A common example is time synchronization: pushing the same clock value to every device on a line in a single frame keeps their timestamps aligned without a slow round of individual writes. Another is a uniform setpoint or configuration value that legitimately should be identical across a group of like devices. In a larger monitoring architecture, an edge gateway might use a broadcast internally on a dense serial segment to keep timestamps consistent, then rely on its normal per-device polling to actually read back and confirm each instrument's state to the cloud. That pairing - broadcast for the cheap uniform push, unicast reads for the trustworthy readback - is how the technique is used responsibly rather than as a shortcut around acknowledgment.
Because address 0 is the broadcast address, and a response is deliberately suppressed. If every device on the shared serial line answered the same broadcast at once, their replies would collide and corrupt each other on the wire. The specification therefore requires that no device reply to a broadcast, which means the master gets no confirmation that the write was received.
No. Broadcast applies only to write function codes. A read asks for data to be returned, and if all devices on the bus answered a broadcast read simultaneously their responses would collide and be unreadable. Reads are always sent to a single unit ID that returns exactly one reply, so broadcasting them is not part of the protocol.
Not in the way serial does. Broadcast to address 0 is a Modbus RTU and ASCII concept built around a shared physical bus where one frame reaches every device. Modbus TCP uses point-to-point connections and does not have that shared bus, so writing the same value to many TCP devices normally means sending individual writes. Behavior across a TCP-to-serial gateway depends on the specific gateway and should be verified rather than assumed.
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.