Burying the Alarm Forwarder

A pair of proposals from earlier discussions came up in the afternoon. Cliff Copass' "Alarm Forwarder Object" proposal (CHC-005) holds a lot of promise for supporting small embedded devices able to send alarms, but without the storage for a "large" (whatever that is) list of alarm recipients.

The basic idea is to have an object that can receive a singular alarm from a small device and forward to many, as shown.

This was complemented by Carl Neilson's "Simple Alarm Distribution" proposal (CN-118), which adds the required properties to the Devicew object of these small devices. In a small irony, the Recipient property comes back to life (removed many years ago from the Event Enrollment object by a Carl Neilson proposal titled "Kill the Recipient").

Unfortunately the possibility of an "alarm loop" soon presented itself, either if the Alarm Forwarder object was in in its own list of recipients, or if one Alarm Forwarder forwarded to another, when then forwarded the alarm back to the first. This kicked off a lot of, um, discussion which ran out the time for considering this effort. We'll be seeing it again, reevised.

The big question was: when? 3 days meeting once a year is too little -- it could take years to churcn through this stuff. So we'll be kicking off yet another series of weekly international (Europe & North American) BACnet teleconferences, and trying to tack on 3 days to the week-long spring BACnet meetings.

Grueling times... I remember when a BACnet meeting occupied one (1) whole day.