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

Re: [BACnetLighting] Meeting in Germantown, Maryland

Expand Messages
  • Steve Karg
    Hi Lighting Applications Working Group! Here are the draft minutes of our meeting in Germantown, Maryland. Please post any corrections to this list:
    Message 1 of 12 , May 16, 2005
    • 0 Attachment
      Hi Lighting Applications Working Group!

      Here are the draft minutes of our meeting in Germantown, Maryland.
      Please post any corrections to this list:
      mailto:BACnetLighting@yahoogroups.com

      Steve

      =======================

      Meeting Minutes (DRAFT)
      28 April 2005
      Germantown, Maryland

      Participants - Affiliation
      --------------------------
      Steve Karg - Lithonia Lighting
      Craig Spangler - Square D
      Robert Hick - Leviton Lighting
      Jack Neyer - Polarsoft
      David Fisher - Polarsoft
      Bill Jennings - NAVFAC MIDLANT
      Ernie Bryant - NAVFAC MIDLANT
      Don Gottschalk - Johnson Controls
      Pete Baselici - The WattStopper
      Bob Johnson - Siemens Bldg. Tech.
      Steve Treado - NIST

      The meeting was called to order at 1pm.

      A timekeeper (Pete Baselici) and a scribe (Robert Hicks) were assigned.
      Don Gottschalk was volunteered to track the non-agenda items.

      Review of minutes - approved

      Meeting agenda approved

      Liason Reports
      Robert Hick reported no NEMA DALI activity since last meeting:

      LA-WG proposal discussion:

      DMF028-02 Famous Times
      David Fisher reported that problems have been discovered with DMF028-02
      and requested that we withdraw and table this proposal until we enlist
      help from other working groups, such as the OS group. All agreed.

      DMF030-3 WriteGroup Service
      David Fisher presented this revision to his original proposal as a
      partial solution to the requirement in lighting systems to change a
      large number of values quickly.

      Primary change was the addition of an acknowledgement mechanism and
      supporting services. Whereas, if the sender required an acknowledgement
      from the group members, the sender would include a REPLY REQUESTED ID.
      The group members would be required to reply through a WriteGroupAck
      service.

      It was noted that control mode is similar to activating "presets" in a
      lighting control system and that a device may have membership in
      multiple groups. The broadcast may be sent locally, to a remote BACnet
      network number, or using the global BACnet network address.

      There was a question about returning error codes. It was decided that
      error codes may be difficult to define and may be unnecessary.

      There was discussion about why the current Command Object could not be
      modified to accomplish the same. The conclusion was that the Command
      Object was unsuitable.

      There was also a question concerning how long to wait for replies. The
      decision was to leave it unspecified and a local matter.

      Motion to move DMF030-3 to SSPC committee, as is, was seconded and
      passed with no opposed and one abstaining.

      Speed of Lighting Control on the Wire.

      Furthering the discussion from last meeting.

      There is still a need in the lighting community for a service that would
      allow many individual values to be set to individual levels in one
      packet, similar to DMX512.
      David Fisher presented his notes on a concept for a GroupWriteMultiple
      service. David’s concept involved "slots" that may be configured in
      each dimmer or switching device.

      Three possible methods were described:
      Method 1 - Typical BACnet tagged approach.
      Method 2 - Use only one datatype, map is local matter.
      Method 3 - Octet string, canonically encoded.

      The third method was most efficient, but was furthest from BACnet norms.
      It was noted that MSTP networks would limit the packet size to 480
      bytes, so efficiency was very important. It was suggested that the
      service needs to address at least 100 values in a packet.

      It was also suggested that a separate priority need not be sent with
      each value, and that 8 bit data may be sufficient for lighting control
      but may not be sufficient for other uses.

      Steve Karg and Robert Hick presented an example of a typical case for
      the use of this service where a ballroom may be serviced by partial
      number of outputs from several dimmer cabinets. The "slot" concept was
      questioned and a more global "channel" assignment similar to DMX was
      discussed. Whereas, each output of dimmer or switching devices would be
      configured locally with an identifier, commonly referred to as a
      "channel number" in the lighting community. The identifier may be
      unique, or several outputs may have the same identifier if the outputs
      were designed to always operate in tandem. The GroupWriteMultiple
      service would utilize Method 3 and encode the Values as "GroupChannel,
      Value, GroupChannel, Value, etc".

      Further discussion resolved that both the GroupChannel and GroupValue
      should be an unsigned 16bit. It was also decided that a single priority
      should be included as an overall priority for the packet. Relinquish
      would be handled as a specially encoded value such as 0xFFFF indicating null

      David agreed to cast the new WriteGroupMultiple service and present a
      proposal to be discussed at the next meeting. David requested email
      discussion prior to the meeting.

      Other needs of lighting community.

      Steve asked what were the other needs for the lighting community. A
      method for "Room Combining" was suggested. It was noted that the
      mechanics of this may be kept a local matter, although there may be a
      way of supervising using current BACnet objects and services. This may
      be discussed in future meetings.

      Future Meeting.

      It was decided that the next meeting would be held in Denver, possible
      on Sunday, June 26th , 2005. Steve will confirm the date and time
      through email.
    • Steve Karg
      Hi Lighting Applications Working Group! As proposed at our last meeting, next scheduled meeting of the Lighting Applications working group will be at the
      Message 2 of 12 , Mar 17 6:41 AM
      • 0 Attachment
        Hi Lighting Applications Working Group!

        As proposed at our last meeting, next scheduled meeting of the Lighting
        Applications working group will be at the Spring interim SSPC meeting,
        which is being held at Montgomery College Germantown Campus. The
        Lighting Applications working group will be meeting on Tuesday, April
        24, 2007, from 1PM to 5PM. Other working groups will be meeting as
        well. More information about the other working groups can be found at
        the BACnet.org website:
        http://www.bacnet.org/WG/

        Montgomery College is served by three major international airports in
        the Washington, DC area, Baltimore-Washington International(BWI), Dulles
        International(IAD) and Reagan National (DCA).

        Our host arranged a block of rooms at the nearby Hampton
        Inn which is within easy walking distance of the meetings.

        Hampton Inn
        20260 Goldenrod Lane
        Germantown, MD 20876
        Contact: John Jordan
        Phone: +1 (301) 428-1300
        Fax: +1 (301) 428-9034
        http://www.hampton-inn.com/hi/germantown-gaithers
        Group/Convention Code: ASH
        Rate: $109.00 + tax
        Location: The Hampton Inn is located on property adjacent to the
        Germantown Campus and is a 2 block walk through parking lots that adjoin
        the campus. Maps and directions can be found on the website.

        Meeting Schedule and Location:
        High Technology Sciences Center (HTSC), Room 216
        Humanities and Social Sciences (HSS), Room 007
        Montgomery College Germantown Campus
        20200 Observation Drive
        Germantown, Maryland 20876
        Contact: Mike Whitcomb, P.E.
        Office Phone: +1 (301) 251-7375
        http://www.montgomerycollege.edu/maps/gcamp.html

        Monday, April 23
        8AM-3PM HTSC 216 Applications
        3PM-5PM HTSC 216 Internet Protocol
        Noon-5PM HSS-007 BACnet Testing Labs

        Tuesday, April 24
        8AM-5PM HTSC 216 Life Safety and Security
        1PM-3PM Life Safety and Security / Network Security joint session
        8PM-Noon HSS-007 Testing and Interoperability
        1PM-5PM HSS-007 Lighting Applications
        6:30 PM Group Dinner

        Wednesday, April 25
        8AM-5PM HTSC 216 SSPC 135 BACnet

        Thursday, April 26
        8AM-10AM HTSC 216 Wireless Networking
        10AM-11AM HTSC 216 Master-Slave/Token-Passing
        11AM-Noon HTSC 216 XML Applications
        1PM-3PM HTSC 216 Utility Integration
        3PM-5PM HTSC 216 Objects and Services

        Friday, April 27
        8AM-Noon HTSC 216 Objects and Services

        Please send Bill Swan <mailto:Bill.Swan@...> a courtesy e-mail
        to let him know if you plan on attending.

        The Lighting Applications working group Agenda will include the
        following items:
        1. Review DMF-032 WriteGroup service with Multiplexor object internals
        2. Review any Addendum i public review comments
        Please post any additional LA-WG agenda items to this list.

        Best Regards,

        Steve Karg
        Lithonia Lighting
        --
        http://steve.kargs.net/
      • Steve Karg
        Hi Lighting Applications Working Group! Here are the meeting minutes from our last meeting. The meeting minutes have also been submitted to the BACnet
        Message 3 of 12 , May 25, 2007
        • 0 Attachment
          Hi Lighting Applications Working Group!

          Here are the meeting minutes from our last meeting. The meeting
          minutes have also been submitted to the BACnet committee chair as
          LA019.doc.

          Best Regards,

          Steve Karg

          --------------------------------------------
          BACnet - Lighting Applications Working Group
          Meeting Minutes
          April, 24 2007
          Germantown, Maryland

          The minutes from the last meeting, LA018.doc, were approved without
          changes.

          The agenda for the meeting was modified to include a discussion of the
          "Color" property that was recently removed from the Lighting Output
          object.

          There were no Liaison reports.

          Status of unpublished work:
          Addendum i to 135-2004 went out for public review in March. This
          addendum defines a new Lighting Output Object. David Fisher was asked
          about the status of the "Famous Times" feature, but the status is
          unknown.

          Simple Value Objects (Famous Times for Dawn and Dusk): David Fisher
          said that he has been given a mandate [not during this meeting] to
          write a proposal that makes almost all of the properties of the
          "Value" objects optional, to create the opportunity for very
          "lightweight" objects.

          Hand-Off-Auto feature: Some of this is included in Addendum i, but
          some people are interested in a property that indicates the H-O-A
          switch position separately from the Present_Value. This proposal is
          in front of the Objects and Services working group.

          David Fisher said that there is a flaw in Addendum i related to the
          fact that the Blink behavior does not map onto Binary Value objects
          well because Binary Value objects are not required to have a
          Priority_Array property. David then presented proposal DMF-019-10.doc
          to the LA-WG meeting attendees as a solution to this problem. The
          basis of the solution is that the Blink_Priority_Threshold property is
          not required in non-commandable Binary Value objects. A question
          was raised as to how this change would affect the blink behavior.
          David answered that this is detailed in section 12.8.29.1 of
          DMF-019-10.doc.

          Pete stated that a local switch would typically override the off delay
          (which is the whole point of the off delay, to give occupants the
          chance to prevent the lights from going out), so could a sentence be
          added about cancelling the off delay if PV becomes Active? The group
          agreed that a sentence like the following should be added:

          "During off delay, if PV becomes Active, off delay should be canceled
          and the output should remain Active".

          Pete raised the issue that the maximum ON time of manual overrides
          should not be applicable when the area is occupied. David said that
          this would need to be an additional feature. Pete said that the same
          end result could be accomplished by "sweeping" areas with an OFF
          command at regular intervals during unoccupied times, and this seemed
          to satisfy the application requirements without requiring changes to
          the proposal.

          The discussion returned to the changes proposed related to the blink
          feature and non-commandable BV objects. Did the group want to submit
          this as a change to the standard AFTER Addendum i is approved, or
          should this be submitted as a comment to Addendum i during the public
          review period to get the changes incorporated before Addendum i is
          approved for publication? The general consensus was that it would be
          better to submit a comment during the public review to get Addendum i
          modified before publication. David Fisher agreed to submit this
          comment to ASHRAE as part of the Addendum i public review.

          New issue. Steve asked "What is returned by ReadProperty when reading
          the Lighting_Command property? What if Lighting_Command has never
          been commanded, i.e. what is its initial value?" The group decided
          that when Lighting_Command is read by ReadProperty, it should return
          the value last commanded and the command parameters, or STOP if it has
          never been commanded.

          Steve suggested that the sentence prior to Table 12-Z in Addendum i
          needed to be reworded. The group agreed on the following change to
          that sentence:

          "Optional fields of the BACnetLightingOperation value that are
          allowable as indicated by table 12-Z for each operation are shown in
          bold." David Fisher agreed to submit Steve's comment to ASHRAE as part
          of the Addendum i public review.

          Review of proposal DMF-043-1:
          David Fisher explained that the objective of this proposal is to take
          Steve Karg's original Multiplexer object and cast it as a Channel
          object. This fixes a problem with the original idea of the "Channel"
          command: no network visibility. Writing the PV of the Channel object
          causes writes to all objects in the List_Of_Object_Property_References
          at the same priority. The Channel object can also coerce the data
          between different datatypes. The Channel object itself is not
          commandable but the command priority is passed down to the target
          objects. The Channel object's instance number is the same as the
          channel number.

          There was a lengthy discussion about the need for a channel number
          that is independent of the channel object Object_Identifier. David
          Fisher proposed that a property be added to the Device object to
          indicate which control groups it belongs to. Bob said that he wanted
          each application to have its own group association, and that group
          association should not be tied to the hardware which is what would
          happen if the list of control groups was a property of the Device
          object.

          It was noted that since the proposed Write Group service is
          unconfirmed by design so that it can be used as a sort of multicast,
          there is no way to verify whether a Device is responding to Write
          Group or not.

          After the lengthy discussion of various uses of Channels and Groups in
          lighting applications, a vote was taken on the following: "Should
          Channel number be decoupled from the Channel Object instance number?"
          The result of the vote was 5 to 1 in favor of decoupling.

          David explained that the Transition Time service parameter was removed
          from the Write Group service because the concept of transition time is
          not easy to apply to all of the objects that could be in the
          List_Of_Object_Property_References.

          Steve suggested the idea of a randomized command delay, to prevent
          power surges. After some discussion, the group agreed to the
          following proposal: Write Group has a delayed execution flag, but the
          amount to delay is a local matter. David Fisher will incorporate this
          into the next revision of DMF-043.

          Bob asked a couple of questions:
          Q:"Does Write Group have to be sent as a broadcast?"
          A: "No, it can be unicast".

          Q:"Can it be confirmed?".
          A: "No."

          Discussion of the Color property:

          David Fisher explained that the Color property originally had 2 purposes:
          1.Indication of fixed color lights, like lights with filters,
          2.controllable color, like RGB LEDs.

          Some of the problems that arose:
          1.BACnet needed a new datatype for RGB values.
          2.It would be nice if the Lighting Output indicated support for
          commandable color.
          3.Multiple commandable properties in the same object is a problem.
          4.Min and Max level don't apply well to color.

          For these reasons, David thought it might be better to create a
          different Lighting Output specifically intended for color lights,
          complete with new services such as Ramp to Color, Go to Color, and
          Step Color (no - stepping color doesn't make sense).

          So the question is, do we want a separate object for color lights?
          The group decided that this was the right direction, but that we
          should also include support for other advanced lighting control
          features that are beyond the capabilities of the greyscale Lighting
          Output object, such as those used in theatrical lighting like pan,
          zoom, and tilt. David also would like to collect input on which color
          space we should use. RGB24 would be simple, but is it adequate?
          Steve Karg to provide David Fisher with a list of theatrical lighting
          features and properties. David Fisher to create a proposal based on
          the input he receives.

          Next Meeting
          ------------
          The next meeting of the LA-WG will be in Long Beach, CA, on Sunday,
          June 24, 2007, from 8:30am to noon in the Long Beach Convention
          Center, Seaside Section, Room 306A.

          Thank you to Mike Danner for taking meeting notes, to Coleman Brumley
          for keeping time, and David Fisher for keeping track of non-agenda items.

          Attendees
          ---------
          Note: The list of attendees is probably not correct as I created it
          from memory. I seemed to have misplaced the sign in sheet during my
          recent change in employers from Lithonia Lighting to The Wattstopper.
          Any error or omissions are unintended and corrections are welcome. -
          Steve

          Name, Organization
          ------------------
          David Fisher, Polarsoft
          Coleman Brumley, Polarsoft
          Pete Baselici, The WattStopper
          Steve Karg, Lithonia Lighting
          Bob Johnson, Siemens Building Technology
          Steve Treado, NIST
          Mike Danner, Automated Logic
          Dave Robin, Automated Logic
          Rolf Hunt, Automated Logic
        • Steve Karg
          Hello Lighting Applications working group! As suggested in our last meeting, our next scheduled meeting will be at the interim SSPC meeting, which is being
          Message 4 of 12 , Mar 18 8:24 AM
          • 0 Attachment
            Hello Lighting Applications working group!

            As suggested in our last meeting, our next scheduled meeting will be
            at the interim SSPC meeting, which is being held at Montgomery College
            Germantown Campus.

            The Lighting Applications working group meeting is scheduled during
            the morning for two days (8am-noon) on Monday, April 21, 2008 and
            Tuesday, April 22, 2008, in room HS-007.

            Our major agenda items include:
            1. Discuss Color and associated properties for lighting. What needs to
            be included in an object or profile for BACnet interoperabilty?
            Specifications for the Chromaticity of Solid
            State Lighting Products developed by ANSI may apply:
            http://www.nema.org/stds/ANSI-ANSLG-C78-377.cfm

            2. Discuss Addendum H clause H.X "Using BACnet with DALI"

            3. Lighting Application BIBB? 135.1 Testing additions?

            See you there!

            Steve
            ====================================
            ASHRAE SSPC 135 BACnet Interim Meeting
            April 21 - April 25, 2008

            Location:
            Montgomery College Germantown Campus
            20200 Observation Drive
            Germantown, Maryland 20876

            Building:
            High Technology Sciences Center (HT)
            Humanities and Social Sciences Building (HS) (cafeteria)
            http://www.montgomerycollege.edu/maps/gcamp.html

            Directions:
            http://www.montgomerycollege.edu/
            Look under information for: visitors and community: maps & directions:
            Germantown campus. They are located just Northwest of Washington, DC,
            directly off of Interstate I-270 North, not far from the National
            Institute of Standards and Technology (NIST).

            Parking:
            Park in any white line space.

            Contact:
            Mike Whitcomb, P.E.
            Mike Whitcomb, P.E.
            Energy Manager
            Montgomery College
            40 West Gude Drive, Suite 200
            Rockville, Maryland, 20850
            Office Phone: +1 (240) 567-7375
            Mobile Phone: +1 (301) 509-3723
            mailto:mike.whitcomb@...

            Airports:
            Montgomery College is served by the three major airports in the
            Washington, DC area:
            Baltimore-Washington International(BWI)
            Dulles International(IAD)
            Reagan National(DCA)

            Metro:
            Montgomery College is located just North(approximately 10 miles) of
            the Red Line, Shady Grove Metro Station. The Metro is the subway rail
            system serving the DC metro area. A shuttle service is available from
            the Hampton Inn. Taxi service is also available.

            Hotel:
            Hampton Inn Germantown
            20260 Goldenrod Lane
            Germantown, MD 20876
            Contact: Elijah Hammonds
            Phone: +1 (301) 428-1300
            Fax: +1 (301) 428-2870
            http://www.hampton-inn.com/hi/germantown-gaithers
            Block: ASHRAE Rate: $115.00 + tax
            Location: Get maps and directions from website. The Hampton Inn is
            located on property adjacent to our Germantown Campus and is a 2 block
            walk through parking lots that adjoin the campus.

            Booking online (please note: the Group Code does not appear to work –
            call the hotel):
            1) Log onto www.hamptoninngermantown.com and click on the upper right
            hand corner in the box labeled "Book Now!"
            2) Click on link that reads, "Need to Book Multiple Group Reservations?"
            3) Type in dates of stay and room preference and then scroll down to
            Special Accounts and enter ASHRAE in the Group/Convention Box and
            click "continue."
            4) Your rates (both for standards and suites) will appear and you can
            continue with the reservation as normal

            Meeting Schedule
            --------------------------
            Monday April 21
            BTL WG (HT216 8am-noon)
            LA-WG (HS-007 8am-noon)
            Lunch (noon-1pm)
            TI-WG (HT216 1pm-5pm)
            AP-WG (HS-007 1pm-5pm)

            Tuesday April 22
            XML WG (HT216 8am-noon)
            LA-WG (HS-007 8am-noon)
            Lunch (noon-1pm)
            MSTP-WG (HT216 1pm-3pm)
            IP-WG (HT216 3pm-5pm)
            AP-WG (HS-007 1pm-5pm)

            Wednesday April 23
            SSPC-135 (HT216 8am-noon)
            Lunch (noon-1pm)
            SSPC-135 (HT216 1pm-5pm)

            Thursday April 24
            OS WG (HT216 8am-noon)
            LSS-WG (HS-007 8am-noon)
            Lunch (noon-1pm)
            NS/LSS-WG (HT216 1pm-3pm)
            NS-WG (HT216 3pm-5pm)
            WN-WG (HS-007 1pm-3pm)
            UI-WG (HS-007 3pm-5pm)

            Friday April 25
            OS WG (HT216 8am-noon)
            --
            http://steve.kargs.net/
          • Steve Karg
            Hello Lighting Applications Working Group! We met in Germantown for two days, and had some fantastic discussion. Appended are the meeting minutes, which are
            Message 5 of 12 , Jun 17, 2008
            • 0 Attachment
              Hello Lighting Applications Working Group!

              We met in Germantown for two days, and had some fantastic discussion.
              Appended are the meeting minutes, which are also in the LA023.doc file
              which has been uploaded to the BACnet FTP server.

              Best Regards,

              Steve
              ===============
              1.Opening remarks – by Steve Karg (8:30AM)
              2.Circulation of attendance sheet, and introduction of those present
              Name, Affiliation
              David Fisher, Polarsoft
              Coleman Brumley, Polarsoft
              Steve Karg, The Watt Stopper
              Robert Hick, Leviton
              Duane King, Acuity Brands Lighting
              Dana Peterson, Johnson Controls
              Christoph Zeller, Sauter
              David Ritter, Delta Controls

              3.Meeting role assignments
              time keeper - David Fisher
              scribe - Robert Hick, Steve Karg
              non-agenda item attendant - Coleman
              4.Approval of the minutes from the previous meeting.
              5.Discussion and approval of the agenda for this meeting.
              6.Liaison updates (NEMA, IESNA, DALI)

              Robert Hick reported on progress of NEMA 243 DALI protocol standard
              and harmonization with IEC 602386 DALI protocol standard. Hope was to
              have a final draft for IEC voting by summer.

              7.Status of SSPC-135-2004 Addendum i PPR2

              PPR2 ends on May 9. Steve Karg submitted one comment due to initial
              PPR2 document not matching the draft submitted. Current PPR2 document
              matches the draft, and the public review period was extended. Steve's
              comment is now mute.

              8.LA-WG proposal discussion / resolution via consensus

              DMF-051-1: Color Lighting Object

              David Fisher presented DMF-051-1 and a discussion ensued.
              DMF-051-1 proposed a new color object with separate properties for
              control of fading and luminance.

              There was another proposal that color should be merged into the
              current lighting object since it already has the Luminance properties
              built in.

              David Ritter also suggested that we should reference the color object
              with the light object instead.

              After much discussion there was a consensus to add color functionality
              to the existing light object. David F agreed to create a proposal to
              amend the Light object to incorporate the color properties and
              commands.

              There was also discussion on how to best define color?

              It was noted that there were several ways to define color.
              RGB values – used in entertainment lighting and combines luminance
              CIE xy coordinates – Precise color only, used to define LED's
              Color Temperature Tc– Used to define white light – warm to cool

              After much discussion, it was determined that all three methods have
              specific benefits for different applications of color in lighting.
              There was a consensus to use the Lighting Command to command the color
              in any of the 3 different ways. David F suggested that the xy
              coordinates be expressed in integers.

              Another issue discussed was how to present the current color value and
              should the device only present the color method being used or be
              required to calculate values for all methods.

              David Ritter also expressed a need for a light weight object for
              lighting control. There was a brief discussion about adding Color to
              BO, however it was decided that color would rarely be used with Binary
              devices. The subject of the need for Blink Warn in the BO resurfaced
              and the group is considering reviving the past proposal.

              References in Clause 25:
              CIE 13.3
              ANSI, NEMA ASNL6C78-377-2008

              Discussion of Delta Comments on SSPC 135-2004 Addendum i PPR2

              David Ritter and his team at Delta Controls reviewed Addendum I and
              provided a number of comments that were submitted to the Lighting
              Applications working group and discussed. Concern was raised that the
              time it takes for PPR to happen would delay the publication at least
              another year.

              1. In_Process property should be a required property since the
              lighting command property is required and its purpose is to show the
              progress of the lighting command.
              Discussion: There are no objections from the working group to making
              In_Process a required property, except that this comment on its own
              should not be cause to have a PPR3. This would be a substantive
              comment.
              2. In the Lighting_Command property the sentence "..the write shall
              fail and a Result(-) with an error class of PROPERTY and a error class
              of OPTIONAL_FUNCTIONALITY_NOT_SUPPORTY." the second "error class"
              should be "error code".
              Discussion: This item is an erratta.
              3. In the Lighting_Command property should there be a subset of
              operations which are required to be supported?
              Can a device not support any lighting command operations? If a device
              is not required to support any operations the sentence "Devices are
              not required to support all BACnetLightingOperations" should be
              changed to "Devices are not required to support any
              BACnetLightingOperations".
              Discussion: The working group agreed that it was assumed to be at
              least one command. STOP, GOTO_LEVEL, and RELINQUISH should be
              required. Seems that this potential ambiguity could eventually receive
              an interpretation request and we should address it now. It would be
              substantive.
              Can vendors extend the Lighting_Command enumeration? Working group
              decided that extending the enumeration for vendors would be okay, and
              agreed that the values be 16-bit, 0-255 reserved for ASHRAE. This may
              promote non-interoperability, however.
              4. In the Lighting_Command property there are 6 different ramp
              commands defined. This is an excessive number of similar commands. The
              commands can be reduced to two choices:
              RAMP_TO
              RAMP_TO_AT_RATE
              The other 4 commands can easily be achieved by these two commands.
              Discussion: While it may be better to be simpler, the Addendum is not
              unclear by having them. However, it may result in more
              interoperability problems having more choices. Simplifying the number
              of commands would be a substantive change.
              5. In the Lighting_Command property the commands RAMP_UP and RAMP_DOWN
              should be changed to RAMP_MAX and RAMP_MIN respectively to better
              denote the function of the commands.
              Discussion: If we accept #4 comment to simplify, then this comment is
              mute. Yes, these may be better names. The change would be
              substantive.
              6. The Blink_Time property should be changed to tenths of a second
              rather than hundredths. Specifying a blink time in hundredths of a
              second is excessive.
              Discussion: The only sub-seconds defines in BACnet are currently
              milliseconds or hundredths or REAL seconds. Adds complexity for
              clients to have an additional time conversion. Should use milliseconds
              to be SI compliant, but resolution a local matter. Blink is probably
              only visible if it is longer than 50ms, so tenths of seconds may be
              not enough resolution. The change to milliseconds would be
              substantive.
              7. There is a type inconsistency among the properties that specify
              time duration. Some properties specify the duration in seconds as a
              REAL (Lighting_Command.fade-time, Fade_Time, Off_Delay, On_Delay)
              while other specify the duration in seconds as an Unsigned
              (Lighting_Command.Duration, Elaspsed_Active_Time). It would be
              preferable to have a consistent measure and unit of duration
              throughout the object type.
              Discussion: The non-REAL are consistent with other objects similar
              properties. The REAL were changed from non-REAL during SSPC and
              working group discussion prior to PPR1.
              8. On_Delay/Off_Delay property should specify that the value cannot
              take on negative values. It should specify what error code to return
              if an invalid value is attempted to be written.
              Discussion: Time values in this object should never be negative.
              Should we specify this as affecting all time properties in this
              object? Which Error class/code?
              9. The property name "Off_Delay" should be changed to "Blink Warn
              Delay" as it is only used when a blink warning is in effect.
              Discussion: Permits Off_Delay when Blink_Time is zero - see
              Blink_Time. Perhaps some language is needed to define this ability
              clearly. Perhaps a diagram would be useful - see David's white paper.
              Note that most of the diagrams from David Fisher's white paper would
              be useful in this object.
              On_Delay does not utilize a priority threshold, and this behavior
              seems to be an omission. Perhaps use Blink Priority Threshold, but
              change the name to Delay_Priority_Threshold.
              10. The order of properties in the property descriptions should match
              the order given in the table (i.e., Profile Name should be last).
              Discussion: editorial
              11. Power should be specified in watts not kilowatts as most lighting
              fixtures would be significantly less than 1 kilowatt. The value may
              also be changed to Unsigned from REAL.
              Discussion: The Power units and datatype are consistent with Load
              Control object Full_Duty_Baseline property. Perhaps the Power
              property name should be changed to be consistent with the Load Control
              object property.
              12. The Power property would be more useful for load shedding if it
              was the instantaneous power consumption rather than maximum power
              consumption.
              Discussion: It might make it more useful, but it doesn't make it
              invalid or bad by keeping it the way it is. We could add another
              property.
              13. The Binary_Active_Value, Binary_Inactive_Value and Polarity
              properties should be removed from this object.
              13a. Adding these properties adds significant confusion to the object
              as it is unclear whether the object is an analog or binary lighting
              object. It would be much more clear to have different objects for
              binary and analog lighting.
              13b. If these optional properties are in the object then the object
              must behave as a binary lighting object. For manufacturers who have
              static object definitions per device this is a problem as it means
              that you cannot controller both analog and binary lights from a single
              device.
              Discussion: The language seems to prescribe the behavior even in the
              case of analog lighting. What of the case of a dimmer which includes a
              relay and could be used in either case? Change the language? The
              functionality is necessary - whether it is necessary to expose and
              define it is really the question. Should this functionality be moved
              to a Binary Lighting object, or just add blink warn into Binary Output
              as in Addendum i PPR1?
              14. In the Elapsed_Active_Time property the statement "…that the
              Present_Value has been ACTIVE since this property was most recently
              set to a zero value" should be replaced with "…that the Present_Value
              has been ACTIVE. This value is reset when a value of zero is written
              to this property.". As it is written there may be confusion concerning
              whether "this property" refers to the Present_Value property or the
              Elapsed_Time_Property.
              Discussion: Perhaps the language should be more clear and refer to
              Present_Value by name.
              15. Property descriptions of 12.x.22 – 12.x.26 should state "This
              optional property…" to be consistent with the property table.
              Discussion: yes, the table is correct.
              16. The Min_Pres_Value property should have a value range of 0...100
              rather than 1...100. What is the reasoning for restricting it to
              non-zero values? The default for this should be 0.
              Discussion: Minimum on value cannot be zero - but why? The default
              value is currently undefined when this property is present. Is there a
              use case for 0? Yes, it could be 0 if the property is present but the
              functionality is not used. Perhaps 0 should be default, and allowed.
              17. The Max_Pres_Value property should value a value range of 0...100.
              The default value should be 100.
              Discussion: The default value is currently undefined when this
              property is present. Why is the range not using the full range? Is
              there a use case for 100? Yes, it could be 100 if the property is
              present but the functionality is not used. Perhaps 100 should be
              default, and allowed.
              Are Max_Pres_Value and Min_Pres_Value both really required to be
              present? No, it seems they are not coupled, and there could be a use
              case for having one and not the other. Are they really required to be
              writable? There seem to be cases where it might be desirable to have
              this property Read-Only when limiting outside applications.
              18. The Power_On_Value and System_Failure_Value properties are
              problematic because both are only used in the special case when
              communication to a remote lighting device, which is being controlled
              by this object, is lost. Neither of these properties has anything to
              do with the functionality of this object and should be considered to
              be outside of the scope of BACnet.
              Discussion: We received PPR1 and comments from vendors who want to use
              these in non-DALI remote systems, along with pre-PPR1 comments that
              desired these properties to adequately model their DALI systems via
              BACnet. Removing the DALI like properties would disenfranchise these
              vendors.
              18a. When communication is lost to the remote device should the object
              take on the System_Failure_Value value? If so, at what priority should
              it be written at in the priority array?
              Discussion: These values are used as configuration values that the
              output device uses before it sets the value from the Priority_Array)
              In addition, Power_On_Value is confusing because its name implies that
              this is the value the object will take on when the device starts up.
              Discussion: The name is derived from the DALI property of the same name)
              BACnet does not specify what the values of the Priority_Array are
              after a power failure, and these values might be useful in that case
              (for example, when Out of Service is TRUE and non-volatile). We could
              also define a value that gets written to Priority_Array (at a specific
              priority) upon power up when the Priority_Array is volatile. This
              property might or might not be this property.

              Discuss Addendum H clause H.X "Using BACnet with DALI"
              Robert agreed to continue working towards providing a draft later in the year.

              Lighting Application BIBB? 135.1 Testing additions?
              This discussion was tabled until next meeting.

              9.Discussion of Non-Agenda Items
              10.Schedule for future meetings.
              The group plans to meet at the next SSPC meeting in Salt Lake City in
              June, 2008. The date and time of the meeting will be determined at a
              later date.
              11.Adjournment

              Meeting minutes respectfully submitted by Robert Hick. Edits by Steve Karg.
              --
              http://steve.kargs.net/
            • Steve Karg
              Hi Lighting Applications Working Group! As proposed at our last meeting, the next scheduled meeting of the Lighting Applications working group will be at the
              Message 6 of 12 , Apr 12, 2010
              • 0 Attachment
                Hi Lighting Applications Working Group!

                As proposed at our last meeting, the next scheduled meeting of the
                Lighting Applications working group will be at the Spring interim SSPC
                meeting, which is being held at Montgomery College Germantown Campus
                from May 10, 2010, through May 14, 2010. The Lighting Applications
                working group will be meeting on Monday, May 10, 2010, from 1pm to 5pm
                in GB105, and Tuesday, May 11, 2010, from 8am to 10am in GB106. Other
                working groups will be meeting during the week as well, and SSPC 135
                BACnet will meet on Thursday and Friday, May 13-14, 2010, in GB105.

                The Lighting Applications working group Agenda will include the following items:
                1. SSPC-135-2008 Addendum i PPR4 comment responses.
                2. Discuss Annex H clause H.X "Using BACnet with DALI"
                3. Discuss BACnet Schedule for Dawn Dusk (removed from 2008 Addendum W)
                4. IESNA Computer Committee XML standard for photosensors - BACnet
                applicability?
                5. Discuss Lighting Application BIBB and 135.1 Testing additions.

                Please post any additional Lighting Application working group agenda
                items to this mailing list.

                Best Regards,

                Steve Karg
                Lithonia Lighting
                --
                Montgomery College is served by three major international airports in
                the Washington, DC area, Baltimore-Washington International(BWI),
                Dulles International(IAD) and Reagan National (DCA).

                Our host arranged a block of rooms at the nearby Hampton Inn which is
                within easy walking distance of the meetings.

                Hampton Inn
                20260 Goldenrod Lane
                Germantown, MD 20876
                Contact: Richard Petras, General Manager, e-mail: GermantownDOS@...
                Phone: +1 (301) 428-1300
                Fax: +1 (301) 428-9034
                www.hamptoninngermantown.com
                Group/Convention Code: ASH
                Rate: $117.00 + tax (May 8, 2010 -May 16, 2009)
                Location: The Hampton Inn is located on property adjacent to the
                Germantown Campus and is a 2 block walk through parking lots that adjoin
                the campus. Maps and directions can be found on the website.

                Meeting Location:
                Goldenrod Building (GB), Rooms GB105 & GB106
                Goldenrod Lane
                Germantown, Maryland 20876
                Note: Goldenrod Building is across the street from the Hampton Inn on
                Goldenrod Drive.
                Contact: Mike Whitcomb, P.E.
                Office Phone: Office Phone: +1 (240) 567-7375, Mobile Phone: +1 (301) 509-3723
                e-mail: mike.whitcomb@...
                http://www.montgomerycollege.edu/maps/gcamp.html
              Your message has been successfully submitted and would be delivered to recipients shortly.