What Is ReinitializeDevice?
ReinitializeDevice is the BACnet service for restarting and recovering devices over the network, defined in Clause 16.4 of ANSI/ASHRAE 135-2024. A client uses it to reboot a remote device (cold start), reset it to a defined initial state (warm start), activate staged network-port changes, or drive the standard backup and restore procedure. It is a confirmed service, and because it can take a controller offline, the device may require a password.
Restart sounds like a small corner of the standard. It isn’t. The spec also defines what a device should remember about a reboot and how it tells the rest of the network, and together those pieces decide whether a restart is a routine event or a mystery the BMS (Building Management System) never finds out about.
Where You’d Hit This in the Field
The everyday case is the remote reboot: a controller on the far side of the campus needs a restart after a configuration change, and ReinitializeDevice does it from the head end instead of a truck roll. The quieter, more valuable case is the backup: before anyone touches a controller’s firmware or program, a backup tool snapshots its configuration using the same service, so the recovery path exists before the risky work starts. And when a device does come back from an unplanned outage, the questions that matter are all restart questions: did the schedule come back, did the trend buffer survive, and does the BMS even know the device rebooted? (Scenarios illustrative; every integrator has lived at least one of them.)
What the Spec Defines
The restart choices. COLDSTART reboots the device. WARMSTART resets it to a defined initial state. ACTIVATE_CHANGES applies staged Network Port changes without a full reboot, which is also the final step of a BACnet SC certificate swap.
The backup and restore machinery. STARTBACKUP and ENDBACKUP bracket a configuration snapshot; STARTRESTORE, ENDRESTORE, and ABORTRESTORE bracket a recovery. Between the brackets, the actual configuration moves as reads and writes of the device’s File objects using AtomicReadFile and AtomicWriteFile. A device can support only the restart choices; backup and restore support is claimed separately.
Passwords and refusals. Clause 16.4 defines the error codes: PASSWORD_FAILURE when a required password is wrong or missing, CONFIGURATION_IN_PROGRESS when the device is mid-configuration. One interaction is worth knowing cold: while a DeviceCommunicationControl disable is in effect, the backup and restore choices are refused, but plain cold start and warm start still work. That is deliberate. It is how you recover a device you have silenced.
What the device remembers. After a restart (the procedure is Clause 19.3), the Device object can tell the story. Last_Restart_Reason records why: COLDSTART, WARMSTART, DETECTED_POWER_LOST, DETECTED_POWERED_OFF, HARDWARE_WATCHDOG, SOFTWARE_WATCHDOG, SUSPENDED, or UNKNOWN. Time_Of_Device_Restart records when. And Restart_Notification_Recipients controls who gets told: the default is a broadcast on the local network, a specific list restricts the audience, and an empty list silences the notification entirely. A BMS that listens for these notifications learns about every reboot on the network the moment it happens; one that doesn’t finds out at the next comfort complaint.
What the CAS BACnet Stack Supports Today
The CAS BACnet Stack executes ReinitializeDevice, including the cold and warm restart choices and the backup and restore state machine. Device management has been through our full test suite and is running on customer sites today.
If you are building a device on the stack, two design questions land on your desk early, and we can help with both. First, what does WARMSTART mean for your product: which state resets and which persists is your application’s decision, and the spec expects you to have made it deliberately. Second, what survives a power cycle: the trend-buffer question from our trend logging article is really a restart question, and the answer belongs in your design review, not in a post-mortem.
In the field, the free CAS BACnet Explorer can read a device’s Last_Restart_Reason and Time_Of_Device_Restart directly, which turns “when did this thing last reboot, and why” from a guess into a property read.
How 6.x Expands This
In 6.x we are widening BTL verification of the device-management services, including ReinitializeDevice’s restart and backup paths, against the BACnet Testing Laboratory’s published test plans. The behavior ships today; 6.x deepens the third-party evidence behind it.
Where This Lives in the BACnet Spec
Restart-safe operation touches a specific set of objects, services, BIBBs, and profiles. Each links to its reference page.
Object types
- Device (Clause 12.11):
Last_Restart_Reason,Time_Of_Device_Restart, andRestart_Notification_Recipients. - File: the payload container for backup and restore.
- Network Port: the staged settings that
ACTIVATE_CHANGEScommits.
Services
- ReinitializeDevice (Clause 16.4): restarts, activation, and the backup/restore brackets.
- DeviceCommunicationControl: the silence switch whose recovery path runs through ReinitializeDevice.
- AtomicReadFile and AtomicWriteFile: move the configuration during backup and restore.
BIBBs (see the BIBBs reference for how the codes read)
- DM-RD-B: the device executes ReinitializeDevice.
DM-BR-B: the device-side backup and restore machinery.- DM-DCC-B: the device executes DeviceCommunicationControl.
Profiles
- B-BC: requires ReinitializeDevice execution and the backup and restore machinery.
- B-AAC: requires ReinitializeDevice execution.
Where to Go Next
- Reference pages: the ReinitializeDevice service with its error codes, and the Device object restart properties.
- Building restart-safe BACnet into a product? Request the CAS BACnet Stack developer kit.
- Have a specific BACnet need? Talk to us about your project.