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

Meeting in Germantown, Maryland

Expand Messages
  • 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 1 of 12 , Mar 17, 2007
    • 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 2 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 3 of 12 , Mar 18, 2008
        • 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 4 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 5 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.