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

Re: Meeting in Long Beach, California

Expand Messages
  • Steve Karg
    Hi Lighting Applications Working Group! Here are the meeting minutes from the LA-WG meeting in Long Beach, California. They have also been sent to the BACnet
    Message 1 of 2 , Jul 6, 2007
    • 0 Attachment
      Hi Lighting Applications Working Group!

      Here are the meeting minutes from the LA-WG meeting in Long Beach,
      California. They have also been sent to the BACnet committee as
      LA020.doc.

      Best Regards,

      Steve Karg
      --------------------------------------------
      BACnet - Lighting Applications Working Group
      Meeting Minutes
      June 24, 2007
      Long Beach, California

      Agenda
      1.Opening remarks – working group (8:30AM - 5 minutes)
      2.Circulation of attendance sheet, and introduction of those present
      (8:35 - 5 minutes)
      3.Meeting role assignments (8:40 - 5 minutes)
      time keeper (break at 10:30AM for 7 minutes) - Christoph Z.
      scribe - Sharon D.
      non-agenda item attendant - David F.
      4.Approval of the minutes from the previous meeting. (8:45 - 5 minutes)
      5.Discussion and approval of the agenda for this meeting. (8:50 - 5 minutes)
      6.Liaison updates (NEMA, IESNA, DALI) (8:55 - 5 minutes)
      7.Create responses to SSPC-135-2004 Addendum i public review comments (9:00)
      8.LA-WG proposal discussion / resolution via consensus (10:37 - 1 hour)
      Review DMF-032 WriteGroup service with Multiplexor object internals
      Color lighting output object
      9.Discussion of Non-Agenda Items (11:37 - 18 minutes)
      10.Schedule for future meetings.(11:55 - 5 minutes)
      11.Adjournment (Noon)

      Attendees
      Name - Affiliation
      David Fisher - Polarsoft
      Steve Karg - The WattStopper
      Bob Johnson - Siemens Building Technology
      Christoph Zeller - Sauter
      David Ritter - Delta Controls
      Rene Quirighetti - Siemens Building Technology
      Sharon Dinges - Trane
      Barry Bridges - Sebasta Blomberg
      Pete Baselici - The WattStopper

      Meeting Minutes
      LA019.doc
      Reviewed the meeting minutes from the Germantown meetings in April
      DF: several items in the meeting minutes that we may want to
      incorporate in the Lighting Output Object second public review. After
      receiving feedback on the procedural question, DF volunteered to
      aggregate these changes to be considered and incorporated into the
      second public review document.
      DF: Procedural Issue question: several changes have come up since the
      first public review. Can we add these changes to a second public
      review draft?
      WS: Yes, the second public review draft can definitely be used as a
      vehicle for these changes, even if they were not the result of
      reviewer comments.
      DF: moved to approve minutes, DR: seconded the motion
      Agenda Review
      No changes were made to the agenda

      Liaison Reports
      No liaisons in attendance

      Public Review Comments [Lighting Output Object]
      135-2004-Add-i-CommentTracking-3.doc
      0001/003:
      Discussion: DH researched the use of the IN_ALARM status flag being
      set when there is a fault. This was discussed somewhat in Germantown.
      Since there is not an event state, this comment is correct, and will
      be accepted.
      The committee response remains "accepted".
      0002/001:
      Discussion: where does the burden reside? Binary Lighting Objects
      would use the BO, Analog Lighting Objects would use the Lighting
      Output Object.
      CZ: in Europe, the Blink function is typically not used; "the lights
      just go off".
      Network latency makes communication too slow to turn off and turn on
      using standard means. Instead, being able to write INACTIVE / ACTIVE
      provides this functionality.
      DF: The rational for keeping it in the BO object was that the vast
      majority of lighting objects that are in the field use the BO object.
      CZ: Pointed out that regardless of whether we add properties to the BO
      or the new LO, it still requires reprogramming if we want to
      incorporate the new functionality into the existing device. DF:
      chances are, I already have these properties in my object, as
      proprietary objects. SK: from a BACnet stack point of view – there is
      less overhead with the additional properties of the BO, than if you
      were to implement the LO object.
      SD: From an applications standpoint, would prefer to add these
      properties to the BO object because then I do not need to add the LO
      object to my BACnet stack to use the Blink warn functionality.
      Lighting control is a typical application that is integrated into the
      system.
      CZ: Need to be careful about overloading the BO object. If we keep
      putting new properties into the BO, pretty soon we have a BO that is
      the same size as the Device object. Short term, additional properties
      are not a big deal, but long term, it can be a problem.
      DR: agree with DF about the backward-compatibility advantages of
      adding these properties to the BO.
      This issue was brought before the SSPC several years ago: Consensus
      was that there were probably more reasons for going with the BO route.
      At the time, there were also additional properties proposed on the
      AOs, but the committee decision was that these properties should be
      stripped off, and put into an actual LO object.
      Do we create a Binary Lighting Output object? Still need to have all
      of the runtime, starts, and other counters because binary lighting
      applications still have many of the constraints that exist with analog
      lighting applications. For instance: stadium lights, can only have so
      many "strikes" before the bulb burns out… stadiums want to replace the
      lights before the maximum number of strikes has been reached.
      Profiles: Discussion about the brainstorming going on about rewriting
      Clause 12 into "objects and features", where "features" are a
      collection of properties that constitute a feature. Together, these
      xx properties are needed to implement this feature – such as Intrinsic
      Alarming. This could be extended to Binary Lighting… DF, Dave Robin,
      and Carl Neilson have been kicking this around for some time… This
      should not have a huge impact on the code in people's devices… This
      discussion needs to be held in a different working group… no question
      that this is the right thing to do, but how does this rate with
      respect to the other priorities that exist within BACnet?
      DF: If we find ourselves wanting to add even one more feature to an
      object such as a BO, that may be our signal that it is the time to
      rewrite Clause 12.
      It was noted that this comment does not deal with BVs, but that these
      same properties were being added to the object, as well.
      Discussion about the subtleties between the use of BO and BV, and the
      relative advantages and disadvantages of each
      Straw Poll [1-2-4]: Do we create a new Binary Lighting Object:
      Discussion: Went back to the discussion of Clause 12 rewrite. RJ: now
      have a solid use case to force some solid action on this point. We
      could actually put these functional groupings into an Annex, or a new
      Clause, and leverage the existing Profile_Name property.
      Straw Poll [7-0-0]: Approval of the modified committee response
      DF modified the committee response to this comment, including changing
      the status to: "rejected – except as noted".
      0002/002:
      Modified the response to "accepted".
      Response was re-written to reflect that "power" will be moved to its
      own section in this addendum prior to PPR2
      Discussion about what the proper units should be for power: Watts, kW.
      Could argue that there should be a "units" property so that this
      could be in I-P or S-I units.
      In Atlanta, there was an overwhelming vote that we should match the
      units used in the [now-published] Load Control Object.
      This is a BACnet issue, not a lighting application issue.

      0003/001 & 0003/002:
      Dave Ritter clarified for us that these comments were accidentally
      submitted and are not actual comments. The committee response was
      then modified accordingly.

      0003/003:
      Discussion about whether the human eye could differentiate between 100
      steps between 0-100. The answer is "yes". 255 becomes a bit more
      challenging, and 1000 steps is not discernible.
      Discussion about using Present_Value and commandability.
      CZ may possibly create a "proposal" to how this is handled with the
      intent that if the committee agrees, this could be added to the PPR2
      prior to being submitted for publication public review.
      This is slightly different from the other referenced objects because
      the LO has both a Present_Value and a Progress_Value property, whereas
      these other objects have only Present_Value.
      The concept to keep in mind is that the LO may be sending a command to
      a DALI ballast and simply issues the command. The DALI ballast could
      then handle the algorithm. Alternatively, the algorithm could be
      handled completely within the LO. It all depends.
      Consensus that the committee's response, wording as amended, will
      remain the same for all three parts of this comment.
      0003/004:
      Question about why we did not simply use "Feedback_Value":
      Feedback_Value property already exists and has a very different
      context (alarming), so it is not desirable to use Feedback_Value in
      this context.
      Consensus that the committee response is acceptable, as written.
      0003/005:
      Discussion about command priorities and lighting applications. DH: we
      debated this at length and could not come up with compelling use case
      scenarios that would require this feature.
      Consensus that the committee response is acceptable, as written, but
      the status will be changed to "Rejected – except as noted". The more
      substantial part of this comment deals with the portion of what was
      rejected, rather than the much smaller portion of the comment that was
      accepted.
      0003/006:
      12.X.7 is very clear in defining the TRUE and FALSE states for
      In_Process. Response wording was revised to indicate that this is
      already in the proposal.
      Consensus that the comment status is acceptable
      0003/007:
      Consensus that the comment status and responses are acceptable
      0003/008:
      Consensus that the comment status and responses are acceptable
      0003/009:
      Consensus that the comment status and responses are acceptable
      0003/010:
      Consensus that the comment status and responses are acceptable
      0003/011:
      Consensus that the comment status and responses are acceptable, as
      amended during the working group session.
      0003/012:
      Consensus that the comment status and responses are acceptable.
      0003/013:
      These are "clamping" values, rather than "scaling" values. Use Case:
      Some fluorescent fixtures you clamp the max value at 85% for a period
      of time, and then perhaps bumped up to 100%, for lamp life.
      Additionally, these properties map directly to DALI, as well.
      Consensus that the comment status and responses are acceptable, as
      amended during the working group session.
      0003/014:
      Consensus that the comment status and responses are acceptable.
      0003/015:
      This is essentially the same comment as submitted by John Hartman in
      0002/001. The wording from this comment can be used as a response to
      this comment.
      Consensus that the comment status and responses are acceptable.
      0003/016:
      Discussion about whether the response should be changed to "accepted"
      and these properties should be added to the LO object. However, the
      Binary Output object has sufficient features to handle the use
      scenario for HID lamps, which is the primary use case scenario that
      was stated by Corey.
      Consensus that the comment status and responses are acceptable.
      0004/001:
      Consensus that the comment status and responses are acceptable.
      0004/002:
      Consensus that the comment status and responses are acceptable.
      0005/001:
      Discussion that the work being performed in the AP-WG covers some of
      what has been listed by the commenter: VFD application profile, etc.
      Consensus that the comment status and responses are acceptable.
      0005/002:
      Consensus that the comment status and responses are acceptable.
      0005/003:
      The value to which is will be commanded on power-on should be what is
      currently in the priority array. The other concept is whether a
      relinquish default should have the special value of NULL to indicate
      "go to the value before power fail"…
      Do not always want to go back to the state that you were in… the
      longer the power out, the less likely you may be to want to go to the
      pre-powerfail state… this is very application specific, and can have
      adverse effects when extended to HVAC applications.
      Consensus that the comment status and responses are acceptable.
      0005/004:
      Consensus that the comment status and responses are acceptable.

      LA-WG proposal discussion:
      Due to the amount of time needed to generate responses to the public
      review comments, we did not discuss DMF-032 WriteGroup service and
      DMF-043 Channel object. DMF-032-4 and DMF-043-2 are available on the
      LA-WG website and are included in the BACnet meeting updates folder.
      We did not discuss Color and associated properties for lighting during
      the meeting.

      Next Meeting:
      Tentatively scheduled for the week of 17 September, 2007 at Georgia
      Tech in Atlanta.

      Meeting minutes respectfully submitted by Sharon Dinges. Edits by Steve Karg.
    Your message has been successfully submitted and would be delivered to recipients shortly.