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

157Re: Meeting in Germantown, Maryland

Expand Messages
  • Steve Karg
    Jun 17, 2008
    • 0 Attachment
      Hello Lighting Applications Working Group!

      We met in Germantown for two days, and had some fantastic discussion.
      Appended are the meeting minutes, which are also in the LA023.doc file
      which has been uploaded to the BACnet FTP server.

      Best Regards,

      1.Opening remarks – by Steve Karg (8:30AM)
      2.Circulation of attendance sheet, and introduction of those present
      Name, Affiliation
      David Fisher, Polarsoft
      Coleman Brumley, Polarsoft
      Steve Karg, The Watt Stopper
      Robert Hick, Leviton
      Duane King, Acuity Brands Lighting
      Dana Peterson, Johnson Controls
      Christoph Zeller, Sauter
      David Ritter, Delta Controls

      3.Meeting role assignments
      time keeper - David Fisher
      scribe - Robert Hick, Steve Karg
      non-agenda item attendant - Coleman
      4.Approval of the minutes from the previous meeting.
      5.Discussion and approval of the agenda for this meeting.
      6.Liaison updates (NEMA, IESNA, DALI)

      Robert Hick reported on progress of NEMA 243 DALI protocol standard
      and harmonization with IEC 602386 DALI protocol standard. Hope was to
      have a final draft for IEC voting by summer.

      7.Status of SSPC-135-2004 Addendum i PPR2

      PPR2 ends on May 9. Steve Karg submitted one comment due to initial
      PPR2 document not matching the draft submitted. Current PPR2 document
      matches the draft, and the public review period was extended. Steve's
      comment is now mute.

      8.LA-WG proposal discussion / resolution via consensus

      DMF-051-1: Color Lighting Object

      David Fisher presented DMF-051-1 and a discussion ensued.
      DMF-051-1 proposed a new color object with separate properties for
      control of fading and luminance.

      There was another proposal that color should be merged into the
      current lighting object since it already has the Luminance properties
      built in.

      David Ritter also suggested that we should reference the color object
      with the light object instead.

      After much discussion there was a consensus to add color functionality
      to the existing light object. David F agreed to create a proposal to
      amend the Light object to incorporate the color properties and

      There was also discussion on how to best define color?

      It was noted that there were several ways to define color.
      RGB values – used in entertainment lighting and combines luminance
      CIE xy coordinates – Precise color only, used to define LED's
      Color Temperature Tc– Used to define white light – warm to cool

      After much discussion, it was determined that all three methods have
      specific benefits for different applications of color in lighting.
      There was a consensus to use the Lighting Command to command the color
      in any of the 3 different ways. David F suggested that the xy
      coordinates be expressed in integers.

      Another issue discussed was how to present the current color value and
      should the device only present the color method being used or be
      required to calculate values for all methods.

      David Ritter also expressed a need for a light weight object for
      lighting control. There was a brief discussion about adding Color to
      BO, however it was decided that color would rarely be used with Binary
      devices. The subject of the need for Blink Warn in the BO resurfaced
      and the group is considering reviving the past proposal.

      References in Clause 25:
      CIE 13.3
      ANSI, NEMA ASNL6C78-377-2008

      Discussion of Delta Comments on SSPC 135-2004 Addendum i PPR2

      David Ritter and his team at Delta Controls reviewed Addendum I and
      provided a number of comments that were submitted to the Lighting
      Applications working group and discussed. Concern was raised that the
      time it takes for PPR to happen would delay the publication at least
      another year.

      1. In_Process property should be a required property since the
      lighting command property is required and its purpose is to show the
      progress of the lighting command.
      Discussion: There are no objections from the working group to making
      In_Process a required property, except that this comment on its own
      should not be cause to have a PPR3. This would be a substantive
      2. In the Lighting_Command property the sentence "..the write shall
      fail and a Result(-) with an error class of PROPERTY and a error class
      of OPTIONAL_FUNCTIONALITY_NOT_SUPPORTY." the second "error class"
      should be "error code".
      Discussion: This item is an erratta.
      3. In the Lighting_Command property should there be a subset of
      operations which are required to be supported?
      Can a device not support any lighting command operations? If a device
      is not required to support any operations the sentence "Devices are
      not required to support all BACnetLightingOperations" should be
      changed to "Devices are not required to support any
      Discussion: The working group agreed that it was assumed to be at
      least one command. STOP, GOTO_LEVEL, and RELINQUISH should be
      required. Seems that this potential ambiguity could eventually receive
      an interpretation request and we should address it now. It would be
      Can vendors extend the Lighting_Command enumeration? Working group
      decided that extending the enumeration for vendors would be okay, and
      agreed that the values be 16-bit, 0-255 reserved for ASHRAE. This may
      promote non-interoperability, however.
      4. In the Lighting_Command property there are 6 different ramp
      commands defined. This is an excessive number of similar commands. The
      commands can be reduced to two choices:
      The other 4 commands can easily be achieved by these two commands.
      Discussion: While it may be better to be simpler, the Addendum is not
      unclear by having them. However, it may result in more
      interoperability problems having more choices. Simplifying the number
      of commands would be a substantive change.
      5. In the Lighting_Command property the commands RAMP_UP and RAMP_DOWN
      should be changed to RAMP_MAX and RAMP_MIN respectively to better
      denote the function of the commands.
      Discussion: If we accept #4 comment to simplify, then this comment is
      mute. Yes, these may be better names. The change would be
      6. The Blink_Time property should be changed to tenths of a second
      rather than hundredths. Specifying a blink time in hundredths of a
      second is excessive.
      Discussion: The only sub-seconds defines in BACnet are currently
      milliseconds or hundredths or REAL seconds. Adds complexity for
      clients to have an additional time conversion. Should use milliseconds
      to be SI compliant, but resolution a local matter. Blink is probably
      only visible if it is longer than 50ms, so tenths of seconds may be
      not enough resolution. The change to milliseconds would be
      7. There is a type inconsistency among the properties that specify
      time duration. Some properties specify the duration in seconds as a
      REAL (Lighting_Command.fade-time, Fade_Time, Off_Delay, On_Delay)
      while other specify the duration in seconds as an Unsigned
      (Lighting_Command.Duration, Elaspsed_Active_Time). It would be
      preferable to have a consistent measure and unit of duration
      throughout the object type.
      Discussion: The non-REAL are consistent with other objects similar
      properties. The REAL were changed from non-REAL during SSPC and
      working group discussion prior to PPR1.
      8. On_Delay/Off_Delay property should specify that the value cannot
      take on negative values. It should specify what error code to return
      if an invalid value is attempted to be written.
      Discussion: Time values in this object should never be negative.
      Should we specify this as affecting all time properties in this
      object? Which Error class/code?
      9. The property name "Off_Delay" should be changed to "Blink Warn
      Delay" as it is only used when a blink warning is in effect.
      Discussion: Permits Off_Delay when Blink_Time is zero - see
      Blink_Time. Perhaps some language is needed to define this ability
      clearly. Perhaps a diagram would be useful - see David's white paper.
      Note that most of the diagrams from David Fisher's white paper would
      be useful in this object.
      On_Delay does not utilize a priority threshold, and this behavior
      seems to be an omission. Perhaps use Blink Priority Threshold, but
      change the name to Delay_Priority_Threshold.
      10. The order of properties in the property descriptions should match
      the order given in the table (i.e., Profile Name should be last).
      Discussion: editorial
      11. Power should be specified in watts not kilowatts as most lighting
      fixtures would be significantly less than 1 kilowatt. The value may
      also be changed to Unsigned from REAL.
      Discussion: The Power units and datatype are consistent with Load
      Control object Full_Duty_Baseline property. Perhaps the Power
      property name should be changed to be consistent with the Load Control
      object property.
      12. The Power property would be more useful for load shedding if it
      was the instantaneous power consumption rather than maximum power
      Discussion: It might make it more useful, but it doesn't make it
      invalid or bad by keeping it the way it is. We could add another
      13. The Binary_Active_Value, Binary_Inactive_Value and Polarity
      properties should be removed from this object.
      13a. Adding these properties adds significant confusion to the object
      as it is unclear whether the object is an analog or binary lighting
      object. It would be much more clear to have different objects for
      binary and analog lighting.
      13b. If these optional properties are in the object then the object
      must behave as a binary lighting object. For manufacturers who have
      static object definitions per device this is a problem as it means
      that you cannot controller both analog and binary lights from a single
      Discussion: The language seems to prescribe the behavior even in the
      case of analog lighting. What of the case of a dimmer which includes a
      relay and could be used in either case? Change the language? The
      functionality is necessary - whether it is necessary to expose and
      define it is really the question. Should this functionality be moved
      to a Binary Lighting object, or just add blink warn into Binary Output
      as in Addendum i PPR1?
      14. In the Elapsed_Active_Time property the statement "…that the
      Present_Value has been ACTIVE since this property was most recently
      set to a zero value" should be replaced with "…that the Present_Value
      has been ACTIVE. This value is reset when a value of zero is written
      to this property.". As it is written there may be confusion concerning
      whether "this property" refers to the Present_Value property or the
      Discussion: Perhaps the language should be more clear and refer to
      Present_Value by name.
      15. Property descriptions of 12.x.22 – 12.x.26 should state "This
      optional property…" to be consistent with the property table.
      Discussion: yes, the table is correct.
      16. The Min_Pres_Value property should have a value range of 0...100
      rather than 1...100. What is the reasoning for restricting it to
      non-zero values? The default for this should be 0.
      Discussion: Minimum on value cannot be zero - but why? The default
      value is currently undefined when this property is present. Is there a
      use case for 0? Yes, it could be 0 if the property is present but the
      functionality is not used. Perhaps 0 should be default, and allowed.
      17. The Max_Pres_Value property should value a value range of 0...100.
      The default value should be 100.
      Discussion: The default value is currently undefined when this
      property is present. Why is the range not using the full range? Is
      there a use case for 100? Yes, it could be 100 if the property is
      present but the functionality is not used. Perhaps 100 should be
      default, and allowed.
      Are Max_Pres_Value and Min_Pres_Value both really required to be
      present? No, it seems they are not coupled, and there could be a use
      case for having one and not the other. Are they really required to be
      writable? There seem to be cases where it might be desirable to have
      this property Read-Only when limiting outside applications.
      18. The Power_On_Value and System_Failure_Value properties are
      problematic because both are only used in the special case when
      communication to a remote lighting device, which is being controlled
      by this object, is lost. Neither of these properties has anything to
      do with the functionality of this object and should be considered to
      be outside of the scope of BACnet.
      Discussion: We received PPR1 and comments from vendors who want to use
      these in non-DALI remote systems, along with pre-PPR1 comments that
      desired these properties to adequately model their DALI systems via
      BACnet. Removing the DALI like properties would disenfranchise these
      18a. When communication is lost to the remote device should the object
      take on the System_Failure_Value value? If so, at what priority should
      it be written at in the priority array?
      Discussion: These values are used as configuration values that the
      output device uses before it sets the value from the Priority_Array)
      In addition, Power_On_Value is confusing because its name implies that
      this is the value the object will take on when the device starts up.
      Discussion: The name is derived from the DALI property of the same name)
      BACnet does not specify what the values of the Priority_Array are
      after a power failure, and these values might be useful in that case
      (for example, when Out of Service is TRUE and non-volatile). We could
      also define a value that gets written to Priority_Array (at a specific
      priority) upon power up when the Priority_Array is volatile. This
      property might or might not be this property.

      Discuss Addendum H clause H.X "Using BACnet with DALI"
      Robert agreed to continue working towards providing a draft later in the year.

      Lighting Application BIBB? 135.1 Testing additions?
      This discussion was tabled until next meeting.

      9.Discussion of Non-Agenda Items
      10.Schedule for future meetings.
      The group plans to meet at the next SSPC meeting in Salt Lake City in
      June, 2008. The date and time of the meeting will be determined at a
      later date.

      Meeting minutes respectfully submitted by Robert Hick. Edits by Steve Karg.
    • Show all 12 messages in this topic