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

Anaheim Meeting Minutes

Expand Messages
  • Steve Karg
    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
    Message 1 of 2 , Feb 13, 2004
    • 0 Attachment
      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
    • Baselici
      Yall Please note, my new business email address is pete_baselici@wattstopper.com Regards Pete ... From: Steve Karg To:
      Message 2 of 2 , Feb 19, 2004
      • 0 Attachment
        Yall

        Please note, my new business email address is pete_baselici@...

        Regards

        Pete


        ----- Original Message -----
        From: "Steve Karg" <SKarg@...>
        To: <BACnetLighting@yahoogroups.com>
        Sent: Friday, February 13, 2004 12:15 PM
        Subject: [BACnetLighting] Anaheim Meeting Minutes


        > 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
        >
        >
        >
        >
        > ======================================================
        > To view the message archive, set user options, or view
        > files in our archive, visit the following web page:
        >
        > http://www.yahoogroups.com/group/BACnetLighting/
        >
        > To subscribe to this group, send an email to:
        >
        > BACnetLighting-subscribe@yahoogroups.com
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.