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

Meeting in Germantown, Maryland

Expand Messages
  • 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 1 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 2 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 3 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.