What SCHED-I-B Is
SCHED-I-B (Scheduling Internal-B) is the BACnet Interoperability Building Block (BIBB) for a device whose Schedule object writes to objects it hosts itself. The Schedule computes Present_Value from its Weekly_Schedule and Exception_Schedule, and every entry in List_Of_Object_Property_References names a property on the same device, so the write is a local assignment rather than a network exchange.
A device claiming SCHED-I-B is the internal counterpart to SCHED-E-B, which covers the same computation writing to remote devices instead. Where the Schedule’s targets live, on the same device or across the network, is the whole distinction between the two BIBBs; the scheduling logic itself does not change.
What It Requires
| Piece | What it does |
|---|---|
Weekly_Schedule / Exception_Schedule | Computed to produce Present_Value on the device’s own clock, no different from any Schedule |
List_Of_Object_Property_References | Names only properties hosted by the same device |
Priority_For_Writing | The priority-array slot the write lands on for each local target |
Because the target and the Schedule share a device, SCHED-I-B has no network dependency on the write path itself: nothing between the schedule engine and the target can be offline, congested, or unreachable.
Where You Meet It in the Field
Any standalone controller running its own occupancy schedule against its own air-handler or lighting points is claiming SCHED-I-B. It is the common case for a single rooftop unit controller, a VAV (variable-air-volume) box controller, or any device that both computes the schedule and owns the targets it drives.
What Chipkin Provides
The CAS BACnet Stack supports SCHED-I-B today: internal Schedule writes through List_Of_Object_Property_References, with the schedule engine passing 32 of 43 rows in the 7-3-2-23 BTL test group, including the WeekNDay and no-cross-midnight cases. Talk to us about your specific scheduling scenario.