157Re: Meeting in Germantown, Maryland
- Jun 17, 2008Hello 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.
1.Opening remarks – by Steve Karg (8:30AM)
2.Circulation of attendance sheet, and introduction of those present
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
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
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:
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
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
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
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
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:
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
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
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).
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
12. The Power property would be more useful for load shedding if it
was the instantaneous power consumption rather than maximum power
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
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
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
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
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
Meeting minutes respectfully submitted by Robert Hick. Edits by Steve Karg.
- << Previous post in topic Next post in topic >>