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

FW: Lighting output

Expand Messages
  • David Ritter
    Hi All, At the conference call yesterday we discussed adding a new reliability ( INDETERMINATE_STATE) to be used when the Lighting Output was reset but the
    Message 1 of 3 , Jun 10, 2011
    • 0 Attachment

      Hi All,

       

      At the conference call yesterday we discussed adding a new reliability ( INDETERMINATE_STATE) to be used when the Lighting Output was reset but the physical output retained its previous value (i.e., we don’t want to change the state of the lights just because the controller reset). In this case the present value of the Lighting Output and the value of the physical output may not match and could be inconsistent. The new reliability state would indicate this situation.

       

      In discussing this with Carl he pointed out that the problem with setting the reliability to something other than NO FAULT DETECTED is that it causes a fault condition. This should not be considered a fault condition so setting a reliability is likely not a reasonable choice.

       

      This condition probably already exists with the current output objects and it is not indicated so I propose that we not make this condition network visible. The email discussion between Carl and myself is below. Any additional comments are welcome.

       

      David

       

      From: Carl Neilson
      Sent: Friday, June 10, 2011 11:13 AM
      To: David Ritter
      Subject: RE: Lighting output

       

      I agree with Fisher on the current use of Overridden.

       

      The problem is that we do not have a construct for this case, and fault really is the wrong thing to use. Do you want fault alarms every time the lighting controller resets?

       

      I think that either 1) there be a new property for this (yuck), or 2) that it not be network visible that the output might not match present-value.

       

      Thinking on this more, I think 2 is the correct approach. The lighting controller believes that the light output is following everything it does. It is up to the lighting controller manufacturer to ensure this. If the controller can be attached to things that will not follow it across a reset, then the lighting controller should update the physical output. In the same way, that for an AO, the AO would be updated. The time it takes for the LO (or AO) to get around to this is a local matter and is reflected in the usability of the lighting controller product.

       

      But the lighting controller should NOT expect that some outside source would be forcing it to perform an update on startup.

       

      Carl

       

      From: David Ritter
      Sent: Friday, June 10, 2011 11:06 AM
      To: Carl Neilson
      Subject: RE: Lighting output

       

      I had originally proposed using  the Overridden flag for this situation but it was Dave Fischer’s  opinion that Overridden was to be used in the case where the value of the output was changed at the physical device (i.e., an HOA switch) and the device was no longer writable using BACnet services. A similar object would be the Analog Output:

       

      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).

       

      While this definition does not seem to prohibit the use for this context the statement regarding the “reliability property is no longer a reflection of the physical output” seems somewhat troublesome.

       

      Certainly, as you suggest, there are other cases where the physical value does not match present value such as transition from out of service to in service. Object creation likely writes the value immediately.

       

      This problem will also happen with binary  and analog output and we are silent on it in those object types. Is that the better way to go?

       

      David

       

      From: Carl Neilson
      Sent: Friday, June 10, 2011 10:48 AM
      To: David Ritter
      Subject: RE: Lighting output

       

      The problem with this approach is that it places the object into a fault condition when it is not actually a fault; it is just that it does not current know whether or not the physical output is consistent with the Present_Value. This would be more like Overridden to me that Fault.

       

      But regardless, I think the language is a bit unclear and may be better re-ordered:

       

      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 Reliability shall be set to INDETERMINATE_STATE until the physical output is updated to reflect the value of Present_Value.

      Are there other conditions under which an update would not necessarily be done such as switching into/out of Overridden or OutOfService? How about when the object is initially created? What about when the object comes out of fault (someone has disconnected the physical light and then later re-connected it)?

       

      Carl

       

      From: David Ritter
      Sent: Friday, June 10, 2011 10:40 AM
      To: Carl Neilson
      Subject: Lighting output

       

      Hi Carl,

       

      When you have a moment take a look at this.

       

      I am adding a statement to the present value of the lighting output object to say that on startup or reset the physical output may be kept at the previous level (which may be lost due to priority array being cleared) rather than taking on the value of present value.  Let me know if you think this will be adequate.

       

      New State added for Reliability property.

       

      INDETERMINATE_STATE

      The physical entity, which this object represents, is in an unknown state.

       

      Present_Value:

      The physical lighting output shall be updated whenever the Present_Value is commanded or changed as a result of executing a lighting command. However, it is a local matter as to whether the physical lighting output is updated at startup or reset with the current value of the Present_Value. If the physical lighting output is not updated at reset or startup then Reliability shall be set to INDETERMINATE_STATE until the physical output has been updated.

       

      Thanks

       

      David

       


      David Ritter, MSc
      Delta Controls Inc
      delta_right_logo_small.

      www.deltacontrols.com

       

      dritter@...

      direct:   +1.604.574.8492

      mobile: +1.604.837.1330

      office:   +1.604.574.9444

       

      P Please consider the environment before printing this e-mail.

      This email message is directed in confidence solely to whom it is addressed. If you are not the intended recipient, you may not use or disclose any information contained here. If you received this email message in error, please reply to the sender immediately and delete the message along with any associated attachments. While every effort is made to ensure safe transmissions, it is still recommended that you scan any attachments for viruses.

       

    • Steve Karg
      Hi David, Thanks for asking Carl about the new Reliability option, and about Overridden.  The text for OVERRIDDEN for the Output objects (Analog Output,
      Message 2 of 3 , Jun 11, 2011
      • 0 Attachment
        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,

        Steve
        --
        http://steve.kargs.net/
      • David Ritter
        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
        Message 3 of 3 , 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.

           

          David

           

          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,

          Steve
          --
          http://steve.kargs.net/

        Your message has been successfully submitted and would be delivered to recipients shortly.