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.
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)
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)
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
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.
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.
- 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.
6301 Zug, Switzerland
Tel direct: +41 41 724 56 13
Fax: +41 41 723 55 58
Mobile: +41 79 260 58 47