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

56Re: [BACnetLighting] Anaheim Meeting Minutes

Expand Messages
  • Baselici
    Feb 19, 2004
    • 0 Attachment

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



      ----- 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
    • Show all 2 messages in this topic