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

163Re: Meeting in Atlanta, Georgia

Expand Messages
  • Steve Karg
    Nov 14, 2008
      Hello Hello BACnet Lighting Working Group!

      The Lighting Applications working group met in Atlanta, Georgia, on
      Monday, September 15, 2008, on Thursday, September 18, 2008. Here are
      the minutes, which are also submitted as LA026-1.doc to the SSPC-135
      BACnet committee chair.

      Best Regards,

      Steve Karg

      BACnet - Lighting Applications Working Group
      Meeting Minutes

      September 15, 2008 and September 18, 2008
      Technology Square Research Building (TSRB)
      Georgia Institute of Technology
      Atlanta, Georgia

      1.Opening remarks – by Steve Karg (8:30AM)
      2.Circulation of attendance sheet, and introduction of those present

      Name, Affiliation
      David Fisher, Polarsoft
      René Kälin, Siemens
      Steve Karg, The Watt Stopper / Legrand
      David Ritter, Delta Controls
      Duane King, Lithonia Lighting
      Dana Peterson, Johnson Controls
      Pete Baselici, The Watt Stopper / Legrand
      Robert Hick, Leviton

      3.Meeting role assignments
      time keeper - David Fisher
      scribe - Robert Hick (Monday), Steve Karg (Thursday)
      non-agenda item attendant - Duane King
      4.Minutes from the previous meeting and agenda were approved
      5.Discussion and approval of the agenda for this meeting.
      6.Liaison updates (NEMA, IESNA, DALI) - none
      7.Discussion of SSPC-135-2004 Addendum i PPR2 41 comments (Thursday)
      Steve introduced LA025-1 – Addendum I PPR2 Response Discussions with
      Commenter 0002
      It was decided that further dicussions on PPR2 would be tabled until
      Thursdays meeting
      8.Discuss Addendum H clause H.X "Using BACnet with DALI"
      Robert presented proposal RLH-001-1 and a discussion ensued
      Main Points:
      Format needs to be in accepted style – Steve forwarded style document.
      Should annex be limited to LO, or should it cover AO,BO also? –
      consensus was to cover AO and BO also.
      What about scenes? – Recommend the Multistate Value Object
      Consistent use of terminology
      Need to clarify DALI Variable ranges
      Read of PV should refer to 19.2
      Discussed issues with group addressing
      Progress value may be retrieved or calculated by gateway – local matter
      Ramp-to may be achieved indirectly
      Major discussion about how to use priority array with lighting
      commands in LO object– David will review and suggest solution
      Robert agreed to make revisions by the end of Sept.

      9.Discuss Color and associated properties proposed for lighting
      (DMF-051, DMF-054). David Fisher presented DMF-054-2
      A discussion ensued about having multiple definitions for color (xy, rgb, Tc)
      It was decided that the only color definition should be xy.
      It was also decided that xy should be represented as a sequence of type REAL
      David agreed to revise his proposal.

      Adjournment of Monday Session

      10.Discussion of SSPC-135-2004 Addendum i PPR2 41 comments (Thursday)

      Reviewed comment 0002-004. Discussion of Resolution property in LO.
      Could add property, but add text that talks about non-linear curve in
      DALI or other output.
      [Karg] What about Ramping as we have defined it in LO? DALI is steps
      per seconds, and is non-linear.
      Response: Accept - optional property will be added.

      Reviewed comment 0002-006. Discussed proposed text for
      Power_On_Value. We didn't agree that it was better. David Fisher
      made the case that the device may not be a gateway in the case where
      the controller is communicating to the dimmer via I2C or SPC rather
      than direct microcontroller pin control, and that this property would
      be valuable in those non-gateway applications. We agree to Reject
      this comment, except as noted, and name the Power_On_Value to
      Remote_Power_On_Value and Remote_ System_Failure_Value.

      The use of the BACnet Lighting Output object in both DALI-like and
      non-DALI remote applications has been discussed in our working group
      and as comments to our first public review of this object. We will
      rename the property to clearly convey the intended use.

      Reviewed the remaining 0002 comment which were resolved.

      Reviewed comments from 0005.

      On_Delay, Off_Delay. Priority threshold, priority bit string, or
      Priority 6 mechanism? On_Delay really has no use cases for us.
      Reject, except as noted: On reflection, the functionality of on delay
      is no longer necessary in this object. Therefore, On_Delay will be
      removed from this object.

      Reviewed STK-024 (Priority 6 Blink Warn solution for BO/BV), and feel
      that this could be modified for LO object by referring to the
      Binary_Present_Value. This would eliminate the Blink Priority

      Reviewed 0005-003 and 0005-004, and discussed Watts versus Kilowatts
      and REAL versus unsigned. We decided to leave the responses as

      Reviewed 0005-005. David Ritter agreed to be resolved on the response
      as written.

      Reviewed 0005-006. We changed our response to be: Reject.
      It is difficult to be interoperable and represent the dimmest lighting
      level using the smallest REAL number greater than 0. We decided to
      use the value of 1.0 to represent the dimmest value to eliminate the
      issue. This prevents the values 0.0 to 1.0 to be used for the
      Min_Pres_Value and Max_Pres_Value.

      Reviewed 0005-007: We kept the Reject response, but changed the wording.
      The use of the BACnet Lighting Output object in both DALI-like and
      non-DALI remote applications has been discussed in our working group
      and as comments to our first public review of this object. These
      properties are required to make these configuration values network
      visible in a standard way when used with remote applications.

      Reviewed 0005-008, 009, 010, 011, 012, 013: We kept the responses as written.

      Reviewed 0005-014: Reject, except as noted. Changed the response wording to:
      DMF-011, the Lighting Output object proposal, had the time properties
      defined as Unsigned for 9 revisions, until discussion in the SSPC-135
      committee changed the properties to REAL prior to voting the proposal
      out for publication. This was the general consensus of the majority
      of the committee, even though there may have been a few companies that
      preferred to use something else. On reflection the LA-WG agrees that
      unsigned milliseconds is preferable. The use of REAL opens the door to
      negative numbers and ambiguous resolution requirements. For these
      reasons we will change back to unsigned milliseconds with explicit
      qualification of resolution requirements.

      We are also removing On_Delay property, as we cannot see a use case for it.

      Reviewed 0005-015,016: We kept the responses as written.

      Reviewed 0005-017:
      The language in the Elapsed_Active_Time property will be clarified.

      Reviewed 0005-018,017: We kept the responses as written.

      11.Develop the revised text for SSPC-135-2004 Addendum i PPR3 for the
      third public review for the Lighting Output object and its friends.

      David Fisher agreed to revise the text for PP3 by the end of November.

      12.Discuss Color and associated properties proposed for lighting
      (DMF-054). David Fisher presented DMF-054-3

      DAY2 - 8:30-9:30: Fisher revised DMF-054:
      [Karg] ASN.1 for XYColor should not have REAL range of 0-9999, use
      0-1. Also change 12.x 3rd paragraph reference.
      [Ritter] Progress_Color should be required if Present_Color is supported.
      [Fisher] Added color and level to GOTO LEVEL command. Change GOTO
      LEVEL to GOTO.
      [Ritter] What about writes to parameters that are optional but not
      present? Error code?
      [Fisher] That should already be addressed in Lighting Output object.
      Present_Value: Writes to Present_Value of values below 0 or above 100
      shall cause a Result(-) to be returned with an error class of PROPERTY
      and an error code of VALUE_OUT_OF_RANGE.
      Lighting_Command: If Lighting_Command is written with a value that
      specifies an unsupported operation, the write shall fail and a
      Result(-) returned with an error class of PROPERTY and an error class
      [Fisher] What happens with fade and you don't send a level? Added to
      Non-Agenda Items.

      13.Applications Working Group (AP-WG) request for Lighting
      Applications (Thursday)

      We were asked by the Applications working group to review our needs
      for any Applications Interfaces for Lighting. Here are the items that
      would make for interesting and useful interfaces.
      a) Scheduled occupancy for a room containing one or more Lighting
      Outputs, one or more occupancy sensors, and one or more daylighting
      b) Daylighting with open or close loop sensors
      c) Room Combination
      d) Scene control

      David Fisher presented his white paper about Lighting Control in BACnet.

      14.Discussion of Non-Agenda Items
      15.Schedule for future meetings.
      The group plans to meet at the next SSPC meeting in Chicago, Illinois,
      in January, 2008. The date and time of the meeting will be determined
      at a later date.

      Meeting minutes respectfully submitted by Robert Hick (Monday) and
      Steve Karg (Thursday).
    • Show all 9 messages in this topic