BACnet Committee Meets in San Francisco

Our BACnet committee and working groups met in San Francisco in May, 2012.  It was fun to see friends, enjoy some cool weather, and eat some good food in a big city.

BACnet meetin in SF at PGEBACnet meeting in SF at PGE

Next door to Pacific Gas and Electric, our host, is a restaurant called Buca di Beppo, an Italian restaurant known for its large portions and eccentric decor.  We had lunch at one of the specialty tables – a “Pope’s Table” that seats 12-18.

One night, our group was feeling adventuresome, and loaded onto BART to find an infamous San Francisco dining establishment called Rosamunde Sausage Grill.

A lot of our proposals had gone out for public review in the Spring, and so we had to create comment responses to any of the comments received.  Some of the proposals sailed through the public review process without needing any substantive changes, which mean they will go to ASHRAE and be reviewed and approved for publication.

BACnet Property_List property

One of the new items that made it through publication was the Property_List property, which will be added to all objects for the new revision of BACnet. I proposed this little gem in 2007, and it was met with stiff resistance by those developing XML to describe BACnet devices.  The pundits said that if we introduced the Property_List property, everyone would use it instead of XML, and that we should wait until XML and the Application Profiles working group completed their work.  The proposal was tabled for a couple years, but came to life again during the Objects and Services working group meetings.  A few tweaks were made to the STK-026 proposal, and Add-135-2010ao was ready for public review.

12.x.X Property_List
This read only property is a BACnetARRAY of property identifiers, one property identifier for each property that exists within the object. The Object_Name, Object_Type, Object_Identifier, and Property_List properties are not included in the list.

Additionally, from the ReadPropertyMultiple specification:

The Property_List property shall not be returned when properties ALL or REQUIRED are requested.

Pretty simple, but pretty powerful for being able to discover all the properties in all the objects in a device.  One of the comments received in public review summed up our sentiments:

Property_List is a very good addition. If someone had thought of this in 1995, we could have avoided the evil “ALL” property. However, since this property is “required”, but didn’t previously exist, and since it is likely to be widely used, it is worth flagging the protocol revision at which it is introduced.

The Protocol_Revision hasn’t been issued yet for this change, since the enumerations and other numbers associated with the published specification are no longer created when the proposals are going through the public review process.

About skarg

I write software for a living. So, I dedicated some web space for some stuff that I have worked on. I mostly write embedded C for PC based controllers, but I have dabbled in a few other areas as well.
This entry was posted in BACnet, travel. Bookmark the permalink.

2 Responses to BACnet Committee Meets in San Francisco

  1. Frozenlock says:

    Okay, I know this is an old post, but OMG!

    How often have I wished for property list! (and wondered why there wasn’t one already…)
    I don’t think I’ve ever encountered it in the wild however…
    Was it officially added recently?

    ” The pundits said that if we introduced the Property_List property, everyone would use it instead of XML (…)”

    I’m not very fond of XML myself. Could you explain why their motivations for wanting others to use it? (I’m sure it’s not pure evil; there must be a reason.)

  2. skarg says:

    The Property_List property was published in 135-2012 BACnet standard as Protocol_Revision 14.

    As for the motivations wanting others to use XML, the rational from Addenda 2008t gives a fairly comprehensive answer:

    A new standard way of representing building data will give BACnet new capabilities for standardized communications between a wide range of applications. A definition for an XML syntax which can be used to represent building data in a consistent, flexible and extensible manner is defined by this addendum in the form of a new annex to the standard.

    The Extensible Markup Language (XML) is a popular technology in the data processing and communications worlds due to its ability to model a wide range of data and its ability to be transformed and extended. With this new IT-friendly way of representing building data, BACnet will open up a range of possible new ways to share data. XML can be used for exchanging files between systems, integrating buildings with energy utilities, and expanding enterprise integration with richer Web services. Some of these new applications will be standardized in future addenda to the standard based on the syntax defined here.

    This XML syntax defined in this annex is expected to be used in a wide variety of ways. Specific uses may require surrounding XML beyond that which is specified here, but this addendum defines the core data definition and data representation for all of the intended uses.

    This syntax is intended to be the core data representation for the following use cases:
    a. An electronic version of a PICS document, consumable by workstations and other tools, to describe the capabilities of a device.
    b. An XML version of an EPICS, defining not only the capabilities of the device, but also including the complete test database and other test-oriented data.
    c. An “as built” description of a deployed device, distributed either as a separate file or as a File Object resident in the device itself.
    d. Descriptions of proprietary objects and properties and datatypes (in any of the above three uses). These descriptions may be minimalistic, providing basic data sharing capabilities, or extremely rich, providing complete descriptions of the meaning and usage of the data to enable a comprehensive user interface, including the capability of providing such descriptions in multiple human languages.
    e. An export format for tools and workstations to export or publish their knowledge of the arrangement and configuration of a device or a complete system of devices and networks.
    f. Web services that exchange complex or constructed data.

Leave a Reply

Your email address will not be published. Required fields are marked *