Loading ...
Sorry, an error occurred while loading the content.

299RE: [BACnetLighting] FW: Lighting output

Expand Messages
  • David Ritter
    Jun 13, 2011
    • 0 Attachment

      Thanks for the response Steve,


      The problem I have with using the OVERRIDDEN flag is contained in the statement “the physical output is no longer tracking changes to the Present_Value property”. Using “no longer” implies that the physical output is not changeable by writing to the present value when in fact this is not the case.


      We may be able to slightly change the definition of OVERRIDDEN to allow for this case.




      From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] On Behalf Of Steve Karg
      Sent: Saturday, June 11, 2011 6:14 AM
      To: BACnetLighting@yahoogroups.com
      Subject: Re: [BACnetLighting] FW: Lighting output



      Hi David,

      Thanks for asking Carl about the new Reliability option, and about
      Overridden.  The text for OVERRIDDEN for the Output objects (Analog
      Output, Binary Output, and Multi-state Output) is a good fit for these
      Lighting Output object use cases:

      "OVERRIDDEN Logical TRUE (1) if the point has been overridden by some
      mechanism local to the BACnet Device. In this context "overridden" is
      taken to mean that the physical output is no longer tracking changes
      to the Present_Value property and the Reliability property is no
      longer a reflection of the physical output. Otherwise, the value is
      logical FALSE (0)."

      For the use case where a local momentary override occurs at the
      lighting actuator which leave the actuator different than the present
      value or when the lighting device resets and the actuator is somehow
      different than the Present_Value, building operators need a way to
      know that the Physical Output does not match the Present Value.

      I don't agree that "In this context "overridden" is taken to mean that
      the Present_Value property is not changeable through BACnet services."
      applies to these cases for outputs, or the output objects would have
      had that language from the beginning.

      I think using OVERRIDDEN in the Status_Flags is the appropriate method
      for indicating the condition.

      Using the following language in the Lighting Output object should suffice:
      "However, when the device starts up or is reset, it is a local matter
      as to whether the physical lighting output is updated with the current
      value of Present_Value. If the physical lighting output is not updated
      then Status_Flags shall be set to OVERRIDDEN until the physical output
      is updated to reflect the value of Present_Value."

      Best Regards,


    • Show all 3 messages in this topic