- BACnet - Lighting Applications Working Group Meeting Minutes September 23, 2002 Columbus, Ohio Participants - Affiliation - e-mail ... David Ritter - DeltaMessage 1 of 1 , Oct 7, 2002View Source
Meeting Minutes - 23 Sept 2002
BACnet - Lighting Applications Working Group
September 23, 2002
Participants - Affiliation - e-mail
David Ritter - Delta Controls - dritter@...
Steve Karg - Lithonia Lighting - skarg@...
Steve Treado - NIST - stephen.treado@...
Jerry Martocci - Johnson Controls - jerald.p.martocci@...
The following proposals were reviewed by the Lighting Applications working group:
Proposal STK-010-1 - BACnet Lighting Scenes and Presets
Concern was expressed about the level and fade time property arriving at the target in an atomic manner. Jerry Martocci noted that the high and low limits of an analog can go into alarm when then are set independently. The Utilities Interface working group has a similar problem. We will bring this issue before them.
Proposal DHR-002-1 - Physical Lighting Control Objects
Steve Karg asked that the proposal be split into a warn time proposal and a fade time proposal. We discussed the fade time algorithm, and Steve Karg brought up the use case of writing another fade time level if we press the wrong button and start fading to the wrong value. Since the current proposal uses the minimum time on/off algorithm, which prevents other levels from occurring during the minimum time limits, the fade proposal was deemed to be a mis-application of the algorithm by Steve Karg. Steve Karg and Dave Ritter are going to rethink the fade time issue.
Proposal STK-004-4 - Multiplexing a Commandable Property
The proposal was compared to the Command Object. Dave Ritter asked about Status_Flags. A question arose about the priority of the command, and whether the object needed a priority array. Steve Karg proposed that language be added that clarifies that the priority comes from the WriteProperty service that commands this object. Another property that may be missing or useful was All_Writes_Successful. We discussed whether the object could be used to write like objects, and we decided that it would be useful, although potentially harmful if configured incorrectly. We need to add language to the object specification to permit this. We discussed whether it should be allowed to continue to write if there was a write failure (similar to a sequence) and we decided that the command object was designed for that functionality, and this object was not. We decided to add text to clarify our position.
Proposal STK-009-3 - Automatic Relinquish
Dave Ritter questioned whether this technique was needed, and we discussed that the main reason for using this technique is for controlling lights at the same priority. The debate centered around the control architecture of the output object handling the timeout, or the source object controlling the timeout. It was decided that we review the next proposal, which includes Automatic Relinquish.
Proposal STK-011-1 - Warning Blink for Lighting
Dave Ritter suggested that this technique uses too much memory per object. He suggested changing the arrays to lists of time-priority pairs for the relinquish time and the warning time. This seemed to bring the group closer to consensus. Jerry Martocci wondered why this specialized functionality was being added to the existing output objects. Steve Karg explained that the existing output objects contain most of the functionality that the lighting objects need, and that these additional optional properties might be useful to others. It was suggested we request comments from SSPC prior to a formal submission to them.
The following ideas were discussed by the Lighting Applications working group:
Dawn, Dusk, and Twilight in the Schedule Object
We discussed having the ability to program the time value of Dawn, Dusk, or Twilight, along with an offset, and it was suggested that input from the SSPC or someone familiar with the Schedule object was needed before proceeding with a proposal.
Commanding a Lighting Output to Raise, Lower, Step or Goto Level
We discussed the necessity of controlling an output object that allows ramping up and down of the level without writing a specific level was discussed, and Steve Treado plans to produce an object that reflects the properties of DALI (which has these properties).