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

55Anaheim Meeting Minutes

Expand Messages
  • Steve Karg
    Feb 13, 2004
      Hi Lighting Applications working group,

      I have produced a draft of the meeting minutes, and converted it to
      text so I can post it here. The DOC version LA011.DOC will go into
      the SSPC folder for our working group. Let me know about any error or
      omissions.

      Thanks!

      Steve

      --------------

      BACnet - Lighting Applications Working Group
      Meeting Minutes
      January 25, 2004
      Anaheim, California

      DRAFT

      Participants - Affiliation
      --------------------------
      David Ritter - Delta Controls
      Steve Karg - Lithonia Lighting
      Steve Treado - NIST
      Robert Hick - Leviton Lighting
      Jon Williamson - Andover Controls
      Drew Reid - Square D / Schneider
      Jack Neyer - Polarsoft
      David Fisher - Polarsoft
      Pete Baselici - The Wattstopper

      The proposal STK-001-2-draft.DOC, "Lighting Output object.," was
      discussed.
      Dave Fisher had 7 questions about it, most of which were disussed in
      some detail throughout the meeting.
      1. Why is the present value only indicating status, and is not
      writable?
      2. Why is Luminance optional and not writable?
      3. Why are relinquish and warn arrays?
      4. Power off requires a return to previous on level. Why is this
      required?
      5. Ramping commands do have an exposed rate property - why not?
      6. Stepping commands do have an exposed fade rate property - why not?
      7. How is the priority array of the command property handled? For
      example, ramping and then relinquishing.

      Steve Karg responded to question 1, and explained that the proposal
      style was similar to the Life Safety Objects.

      We discussed Luminance, and decided that Level was a better name, and
      also discussed that Level would even be better as the Present_Value.
      We discussed use-cases for priority writing, and also for ramping. We
      acknowledged that DALI is not prioritized and doesn't have to deal
      with issues of ramping, stepping, and then reqlinquishing at
      priorities.

      We discussed using Priority 6, like the Minimum On-Off Time mechanism,
      for handling the blink of the light, and also using it for ramping the
      light. David Ritter had proposed using the priority 6 mechanism for
      something similar (see DHR-002).

      Dave Fisher suggested adding definitions for ramping, fading, and
      stepping so that those not familiar to lighting would gain
      understanding. He also suggested adding to SJT-001 details about all
      the different models that we have tried to use for the varying aspects
      of lighting.

      We discussed the command property, and came to the conlusion that the
      command property should be a structure. This would allow the level
      setting operation to be completed atomically. It should have at least
      3 members:
      -- Command enumeration
      -- Target level or relative level
      -- rate or time (in seconds)
      The priority of the command could be transmitted via the write
      property, but if this command property is added to the Analog Output
      object, then it would have 2 commandable properties. We decided to
      add an additional member to the command property structure, the
      command priority.

      There was a suggestion by Dave Fisher to add properties to existing
      objects, rather than create new objects. The lighting manufacturers
      in the meeting agreed that they would rather add properties to the
      existing Analog Output or Analog Value object since it means smaller
      code changes.

      We discussed using existing objects for ramping, stepping or fading,
      and it was concluded that the ramping, stepping, and fading operations
      are impossible to do correctly outside of an object, since the network
      is not deterministic enough.

      Rate of ramping was defined as the number of seconds to go from 0 to
      100%. Fade rate was defined as the number of seconds to go from one
      level to another level. If the fadetime or ramp rate was a fixed
      value, then we need to define how those properties are shown.
      Regarding stepping, for example, say what to do when a 0.01 step is
      received, or what to do when a higher priority level/command exists in
      the object. We agreed that whether or not a second command interrupts
      the first command is a local matter.

      Discussion eventually led us to conclude that we should just add some
      optional properties to the Analog Output / Analog Value objects.
      Steve Karg will draft a new proposal to add properties supporting
      lighting to the Analog Output and Analog Value objects.

      The proposal JLW-001-2, "DateTime Object," was discussed.
      DMF suggested that this feature be included in his DMF-005 proposal,
      Simple Value Object. Dave Fisher will revise DMF-005 to include a
      DateTime data type.

      The proposal JLW-002-1, "String Object," was discussed.
      DMF suggested that this feature be included in his DMF-005 proposal,
      Simple Value Object. Dave Fisher will revise DMF-005 to include a
      String data type.

      We discussed the problem of scheduling dynamic time values, such as
      sunrise, sunset, optimal start, optimal start, and others. DMF
      suggested that we could:
      1. Redefine the Time Value definition in the Schedule Object.
      2. Create a new Schedule Object
      3. Use a wildcard or other flag in the existing time value to say
      "read the time from another object."
      The third option may be the least intrusive, and require the fewist
      changes to existing implementations.
      Dave Fisher will research this option and report to this group.

      The proposal STK-011-2, "Warning Blink for Lighting," was not
      discussed.

      The proposal STK-004-9, "Multiplexor Object.," was not discussed.

      We discussed future meetings and agreed to meet at the SSPC meetings
      in Nashville, held June 26-30, 2004. The most likely date will be
      June 28. We may also meet at an interim SSPC meeting, but no specific
      date or place has been set. Meanwhile, the work should be posted to
      the YahooGroups site for this working group, and discussion will occur
      on the YahooGroups list for this working group.

      Respectfully Submitted,

      Steve Karg
      Lithonia Lighting
    • Show all 2 messages in this topic