What SCHED-E-B Is
SCHED-E-B (Scheduling External-B) is the BACnet Interoperability Building Block (BIBB) for a device whose Schedule object writes to objects hosted on other devices. The Schedule computes Present_Value the same way SCHED-I-B does, but every entry in List_Of_Object_Property_References names a property on a remote device, so each scheduled transition fires a WriteProperty request on the wire instead of a local assignment.
What It Requires
| Piece | What it does |
|---|---|
List_Of_Object_Property_References | Names properties on remote devices, resolved and reached over the network at the scheduled time |
WriteProperty | Carries the computed value to each remote target when Present_Value changes |
| Retry and failure handling | Not part of the Schedule object itself, but the surrounding engine has to decide what happens when a remote write fails, times out, or lands on an offline peer |
That last row is the entire practical difference from SCHED-I-B. A local write cannot fail because the target is offline; a remote write can, and the Schedule object’s own properties say nothing about what should happen when it does.
Where You Meet It in the Field
Any supervisory controller or head-end device that computes an occupancy schedule centrally and writes it out to rooftop units, VAV boxes, or lighting panels elsewhere on the network is claiming SCHED-E-B. It is the pattern that scales a single schedule across many downstream devices, and also the pattern where a target being offline or slow to boot at the scheduled time becomes a real operational risk. The full failure case and how to design around it is its own article.
[!NOTE] A device claiming SCHED-E-B is not claiming anything about retry behavior on a failed write. Ask specifically what happens when a target does not acknowledge the scheduled write before you rely on it across a distributed site.
What Chipkin Provides
The CAS BACnet Stack supports SCHED-E-B at the code and test level today, through the external-write-out path, with dedicated tests covering the first-tick fire, a repeated no-change tick correctly not re-firing, and an internal reference correctly not triggering the remote callback. There is no BTL profile run behind this BIBB yet, so treat it as modeled and functional end to end rather than a passed BTL claim.
The CAS BACnet Stack 6.x release is targeting retry on failed delivery and a cleaner separation between the scheduling engine and the network write engine. Talk to us about testing your specific network-write scenario against it.