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

Meeting in Albuquerque

Expand Messages
  • Steve Karg
    Hello Lighting Applications Working Group! As proposed at our last meeting, the next scheduled meeting of the Lighting Applications working group will be at
    Message 1 of 3 , Jun 15, 2010
    • 0 Attachment
      Hello Lighting Applications Working Group!

      As proposed at our last meeting, the next scheduled meeting of the
      Lighting Applications working group will be at the Summer SSPC
      meeting, which is being held in Albuquerque from June 24, 2010,
      through June 28, 2010. The Lighting Applications working group will be
      meeting on Thursday, June 24, 2010, from 8am to 5pm in Enchantment C
      room of the Hyatt Regency. Keep in mind that there are rooms named
      "Enchantment" in both the Convention Center and Hyatt Regency.

      As usual, the plenary meetings for SSPC 135 will be on Saturday and
      Monday, with working group meetings on Thursday, Friday, and Sunday.

      The Lighting Applications working group Agenda will include the following items:
      1. SSPC-135-2008 Addendum i PPR4 comment responses.
      2. SSPC-135-2008 Addendum i PPR5 draft

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

      Best Regards,

      Steve Karg
      WattStopper
      --
      http://steve.kargs.net/
    • SKarg
      Hello Lighting Applications Working Group! The Lighting Applications working group met at the Summer SSPC meeting, held in Albuquerque on June 24, 2010, and
      Message 2 of 3 , Jul 6 9:41 AM
      • 0 Attachment
        Hello Lighting Applications Working Group!

        The Lighting Applications working group met at the Summer SSPC meeting, held in Albuquerque on June 24, 2010, and June 25, 2010.

        Below are the minutes, which will be posted to the BACnet committee as LA032.

        Best Regards,

        Steve Karg
        WattStopper
        --
        Minutes
        BACnet Lighting Applications Working Group
        BACnet Summer Meeting
        Albuquerque, New Mexico

        8:00AM – 5:00 PM on Thursday, June 24, 2010 - Enchantment C, Hyatt Regency
        3:15PM– 5:00 PM on Friday, June 25, 2010 - Sandia, Convention Center
        --------------------------------
        1. Opening remarks - working group (8:00PM - 5 minutes)
        2. Circulation of attendance sheet, and introduction of those present (8:05 - 5 minutes)
        Name Organization
        Bernhard Isler Siemens
        Klaus Waechter Siemens
        Sharon Dinges Trane-Ingersoll Rand
        Scott Ziegenfus Lutron Electronics
        Chariti Young ALC
        Christoph Zeller Sauter
        Duane L. King Acuity Brands Controls
        Rick Leinen Leviton
        Steve Karg Watt Stopper
        René Kälin Siemens
        Dana Petersen Johnson Controls
        David Fisher Polarsoft

        3. Meeting role assignments (8:10 - 5 minutes)
        • time keeper: (breaks: 10AM, 2PM, 3PM, 4PM) – Rick Leinen
        • scribe – Chariti Young
        • non-agenda item attendant – Cristoph Zeller
        4. Approval of the minutes from the previous meeting. (8:15 - 5 minutes)

        Some discussion of the previous minutes.
        Corrected misspelling of Rene's name and "idea".
        Refer SSPC 135 minutes for details on RK-006 presentation and discussion

        >> David Ritter moved that the minutes be accepted as amended. Seconded by Duane King. Unanimously approved.

        Updated minutes posted to server.

        5. Discussion and approval of the agenda for this meeting. (8:20 - 5 minutes)

        Added action item from SSPC 135 to clarify how lighting output object should work within a BACnet system as part of the bigger picture - develop a design and usage guide for object.

        Added action from SSPC 135 to sort through proposals in terms of what is still valid or not. Continue, table, reject, completed.

        >> Revised agenda approved..

        6. Liason updates (NEMA, IESNA, DALI) (8:25 - 5 minutes)
        No updates

        7. Action Items – Proposals and Responses (8:30 – 7 hours)
        8. Clarify how lighting output object should work within a BACnet system as part of the bigger picture – develop a design and usage guide for object. Discuss Use Cases developed in Germantown (STK-029-3.doc).

        Began with discussion of Rene's proposal for a Design and Usage guide. (Design_And_Usage_Lighting_Output_Object_EN.ppt)

        Proposal was coordinated among Siemens control and lighting resources.

        Slide 12: In = information sent to lamp. Out = information provided from lamp.

        Slide 15: If we can make the assumptions that control logic always exists outside of the lighting output object and that there is no direct interaction between input and output, then the resolution of multiple inputs (perhaps with the exception of priority arbitration) should be handled by the control logic, not by the output object.

        If we remove the control logic type specifications from the output object specification (e.g. handling of input chatter, how to handle timeout switches), other objects could be added in the future if needed to standardize the way that control logic and interface are handled. May have difficulty deciding what's an important interface to the control logic and what's an integral piece of the output object – where is the line? Need to discuss and decide which pieces of the control logic truly belong in the output (perhaps minimum on/off), and which can be better or more appropriately handled external to (above or before) the output object.

        If compare Addendum I to design and usage guide proposal, most of the contents fall within the proposed paradigm. A few properties may need some further discussion to either provide a more abstract interface specification (rather than a specific output object specification) or to determine that the specified property is indeed control logic that should be exposed in the output object. Per comments received, blink behavior is one area that may need to be revisited, as well as the resolution of command, priority arbitration, and blink. Expected behavior should also be considered as part of the specification. If integrate multiple BACnet systems, could vendor-unique implementation and behavior cause a problem for the end-use customer? Agreement on the paradigm may help the committee come to consensus on contentious inclusions to the specification.

        Blink Warn: Should blink warn be part of this object? Primary objection is the coupling of the blink warning functionality with the priority array. There is a day-to-day need for blink warning. Decision re: whether or not to blink warn could be source-dependent, application-specific, device-specific, and/or time-sensitive. Network latency issues require that blink happen at the output device.

        Possible needs identified:
        1. An inherent property (output object supports/performs blink or doesn't)
        2. A command-included property that specifies blink/not
        3. Property to auto-trigger blink when present value transitions to zero

        In the case of (3), interleaved commands can cause unexpected behavior. "Blink" is tied to "off." But "off" is not necessarily tied to "blink."

        History: having a zero present value write trigger blink allows legacy client devices to treat the output object as an analog object, yet enable this lighting-specific behavior to occur.

        9. SSPC-135-2008 Addendum i PPR4 comment review and response
        add-135-2008i-ppr4-draft
        LAWG-135-2008i-PPR4-Comment-Detail

        0002-001: How do we handle blink? Much discussion. Resolution over whether we need to allow legacy scheduler a way to achieve a blink warning directly: it is acceptable to require some external control logic that can consume a signal from a legacy scheduler and convert it to a command to the lighting output object. Concern over removing the entire blink sequence from the output object, because if non-atomic, execution and interruption becomes unreliable. Remove "present value (0) = blink." Replace with a lighting command (blink and off). Blink occurs via the lighting command only, and the language re: interaction between blink and priority array goes away. If default behavior is no blink, need Relinquish and Blink_ and_Relinquish. The lighting output object should only require one timer, although more are allowed (and may be required, depending on the implementation).

        If blink and relinquish is commanded to a priority and a higher priority is in effect, the command never writes a value to the priority array, it just relinquishes the slot. If blink and relinquish is commanded to a priority, then something happens at a higher priority, cancel the command and execute higher priority command. (Should the value at the lower priority slot be relinquished? Behavior must be defined.)

        Need to be able to interrupt blink and begin a timeout with a switch input. And an input from a second switch should interrupt the original timeout and begin a second timeout. All BACnet clients that can write are also responsible for relinquishing.

        Having only one priority allowed for lighting commands is problematic – multiple priorities are used regularly to decide which lighting command to execute. They provide a way to have a fade to value and fade to relinquish happen on exceptional situations. For example, a lighting test in a board room that allows both the on and off command to fade rather than jump to a value.

        Other primary objection with existing proposal is with the concept of auto-relinquish after a delay/duration. Also, what to do with stale commands.

        Next steps:
        Dave F to draft resolution of removing present value (0) = blink and add new blink commands by 7/31.
        Dave R to comb review comments, add any open issues to those raised at this meeting
        * automatic relinquish
        * stale commands
        * need for lighting command at multiple priorities
        * Need for binary properties, or can the object just be analog
        * Blink warning
        and send email to LA-WG on yahoo group by 6/30.

        10. Discuss Annex H clause H.X "Using BACnet with DALI"
        RLH-001-3b – Not discussed.
        11. Discuss Lighting Application BIBB and 135.1 Testing additions.
        STK-021-1 – Not discussed.
        12. Discussion of Non-Agenda Items (4:45PM - 10 minutes)
        13. Sort through proposals in terms of what is still valid or not. Continue, table, reject, or completed. – Not completed.
        14. Schedule for future meetings.(4:55PM - 5 minutes)

        6/25 3-5pm CC Sandia

        Once we have a draft to discuss, Steve K will publish an agenda and schedule one or more teleconference(s).

        Steve K to publish minutes to yahoo group by 6/30

        If another interim meeting is not scheduled, the next meeting will be in conjunction with the SSPC 135 interim fall meeting in October.
      • Klaus Waechter
        Howdy Steve I am missing David Ritter at the participant list. As far as I remember we talked about a telco where we then decide if a Lighting Application
        Message 3 of 3 , Jul 7 1:11 AM
        • 0 Attachment
          Howdy Steve

          I am missing David Ritter at the participant list.
          As far as I remember we talked about a telco where we then decide if a 'Lighting Application Summit' is needed or not.
          My expectation is to have this telco mid of August when most people are back from holidays.

          Kind Regards
          Klaus Waechter

          Siemens
          Gubelstrasse 22
          6301 Zug, Switzerland

          Tel direct: +41 41 724 56 13

          Fax: +41 41 723 55 58
          Mobile: +41 79 260 58 47
          Mailto: waechter.klaus@...




          From: SKarg <steve@...>
          To: BACnetLighting@yahoogroups.com
          Sent: Tue, July 6, 2010 6:41:52 PM
          Subject: [BACnetLighting] Re: Meeting in Albuquerque

           



          Hello Lighting Applications Working Group!

          The Lighting Applications working group met at the Summer SSPC meeting, held in Albuquerque on June 24, 2010, and June 25, 2010.

          Below are the minutes, which will be posted to the BACnet committee as LA032.

          Best Regards,

          Steve Karg
          WattStopper
          --
          Minutes
          BACnet Lighting Applications Working Group
          BACnet Summer Meeting
          Albuquerque, New Mexico

          8:00AM – 5:00 PM on Thursday, June 24, 2010 - Enchantment C, Hyatt Regency
          3:15PM– 5:00 PM on Friday, June 25, 2010 - Sandia, Convention Center
          --------------------------------
          1. Opening remarks - working group (8:00PM - 5 minutes)
          2. Circulation of attendance sheet, and introduction of those present (8:05 - 5 minutes)
          Name Organization
          Bernhard Isler Siemens
          Klaus Waechter Siemens
          Sharon Dinges Trane-Ingersoll Rand
          Scott Ziegenfus Lutron Electronics
          Chariti Young ALC
          Christoph Zeller Sauter
          Duane L. King Acuity Brands Controls
          Rick Leinen Leviton
          Steve Karg Watt Stopper
          René Kälin Siemens
          Dana Petersen Johnson Controls
          David Fisher Polarsoft

          3. Meeting role assignments (8:10 - 5 minutes)
          • time keeper: (breaks: 10AM, 2PM, 3PM, 4PM) – Rick Leinen
          • scribe – Chariti Young
          • non-agenda item attendant – Cristoph Zeller
          4. Approval of the minutes from the previous meeting. (8:15 - 5 minutes)

          Some discussion of the previous minutes.
          Corrected misspelling of Rene's name and "idea".
          Refer SSPC 135 minutes for details on RK-006 presentation and discussion

          >> David Ritter moved that the minutes be accepted as amended. Seconded by Duane King. Unanimously approved.

          Updated minutes posted to server.

          5. Discussion and approval of the agenda for this meeting. (8:20 - 5 minutes)

          Added action item from SSPC 135 to clarify how lighting output object should work within a BACnet system as part of the bigger picture - develop a design and usage guide for object.

          Added action from SSPC 135 to sort through proposals in terms of what is still valid or not. Continue, table, reject, completed.

          >> Revised
          agenda approved..

          6. Liason updates (NEMA, IESNA, DALI) (8:25 - 5 minutes)
          No updates

          7. Action Items – Proposals and Responses (8:30 – 7 hours)
          8. Clarify how lighting output object should work within a BACnet system as part of the bigger picture – develop a design and usage guide for object. Discuss Use Cases developed in Germantown (STK-029-3.doc).

          Began with discussion of Rene's proposal for a Design and Usage guide. (Design_And_Usage_Lighting_Output_Object_EN.ppt)

          Proposal was coordinated among Siemens control and lighting resources.

          Slide 12: In = information sent to lamp. Out = information provided from lamp.

          Slide 15: If we can make the assumptions that control logic always exists outside of the lighting output object and that there is no direct interaction between input and output, then the resolution of multiple inputs (perhaps with the exception of priority arbitration) should be handled by the control logic, not by the output object.

          If we remove the control logic type specifications from the output object specification (e.g. handling of input chatter, how to handle timeout switches), other objects could be added in the future if needed to standardize the way that control logic and interface are handled. May have difficulty deciding what's an important interface to the control logic and what's an integral piece of the output object – where is the line? Need to discuss and decide which pieces of the control logic truly belong in the output (perhaps minimum on/off), and which can be better or more appropriately handled external to (above or before) the output object.

          If compare Addendum I to design and usage guide proposal, most of the contents fall within the proposed paradigm. A few properties may need some further discussion to either provide a more abstract interface specification (rather than a specific output object specification) or to determine that the specified property is indeed control logic that should be exposed in the output object. Per comments received, blink behavior is one area that may need to be revisited, as well as the resolution of command, priority arbitration, and blink. Expected behavior should also be considered as part of the specification. If integrate multiple BACnet systems, could vendor-unique implementation and behavior cause a problem for the end-use customer? Agreement on the paradigm may help the committee come to consensus on contentious inclusions to the specification.

          Blink Warn: Should blink warn be part of this object? Primary objection is the coupling of the blink warning functionality with the priority array. There is a day-to-day need for blink warning. Decision re: whether or not to blink warn could be source-dependent, application-specific, device-specific, and/or time-sensitive. Network latency issues require that blink happen at the output device.

          Possible needs identified:
          1. An inherent property (output object supports/performs blink or doesn't)
          2. A command-included property that specifies blink/not
          3. Property to auto-trigger blink when present value transitions to zero

          In the case of (3), interleaved commands can cause unexpected behavior. "Blink" is tied to "off." But "off" is not necessarily tied to "blink."

          History: having a zero present value write trigger blink allows legacy client devices to treat the output object as an analog object, yet enable this lighting-specific behavior to occur.

          9. SSPC-135-2008 Addendum i PPR4 comment review and response
          add-135-2008i-ppr4-draft
          LAWG-135-2008i-PPR4-Comment-Detail

          0002-001: How do we handle blink? Much discussion. Resolution over whether we need to allow legacy scheduler a way to achieve a blink warning directly: it is acceptable to require some external control logic that can consume a signal from a legacy scheduler and convert it to a command to the lighting output object. Concern over removing the entire blink sequence from the output object, because if non-atomic, execution and interruption becomes unreliable. Remove "present value (0) = blink." Replace with a lighting command (blink and off). Blink occurs via the lighting command only, and the language re: interaction between blink and priority array goes away. If default behavior is no blink, need Relinquish and Blink_ and_Relinquish. The lighting output object should only require one timer, although more are allowed (and may be required, depending on the implementation).

          If blink and relinquish is commanded to a priority and a higher priority is in effect, the command never writes a value to the priority array, it just relinquishes the slot. If blink and relinquish is commanded to a priority, then something happens at a higher priority, cancel the command and execute higher priority command. (Should the value at the lower priority slot be relinquished? Behavior must be defined.)

          Need to be able to interrupt blink and begin a timeout with a switch input. And an input from a second switch should interrupt the original timeout and begin a second timeout. All BACnet clients that can write are also responsible for relinquishing.

          Having only one priority allowed for lighting commands is problematic – multiple priorities are used regularly to decide which lighting command to execute. They provide a way to have a fade to value and fade to relinquish happen on exceptional situations. For example, a lighting test in a board room that allows both the on and off command to fade rather than jump to a value.

          Other primary objection with existing proposal is with the concept of auto-relinquish after a delay/duration. Also, what to do with stale commands.

          Next steps:
          Dave F to draft resolution of removing present value (0) = blink and add new blink commands by 7/31.
          Dave R to comb review comments, add any open issues to those raised at this meeting
          * automatic relinquish
          * stale commands
          * need for lighting command at multiple priorities
          * Need for binary properties, or can the object just be analog
          * Blink warning
          and send email to LA-WG on yahoo group by 6/30.

          10. Discuss Annex H clause H.X "Using BACnet with DALI"
          RLH-001-3b – Not discussed.
          11. Discuss Lighting Application BIBB and 135.1 Testing additions.
          STK-021-1 – Not discussed.
          12. Discussion of Non-Agenda Items (4:45PM - 10 minutes)
          13. Sort through proposals in terms of what is still valid or not. Continue, table, reject, or completed. – Not completed.
          14. Schedule for future meetings.(4:55PM - 5 minutes)

          6/25 3-5pm CC Sandia

          Once we have a draft to discuss, Steve K will publish an agenda and schedule one or more teleconference(s).

          Steve K to publish minutes to yahoo group by 6/30

          If another interim meeting is not scheduled, the next meeting will be in conjunction with the SSPC 135 interim fall meeting in October.


        Your message has been successfully submitted and would be delivered to recipients shortly.