RE: Antwort: Re: RE: [BACnetLighting] New file uploaded to BACnetLighting
Hi Paul and welcome to the BACnet community.
I would agree with you that blink-warn is an essential feature of a lighting control system so we don’t have the option to remove it. I don’t think anyone in the LA-WG will vote for that option to fix this problem.
There are really only two reasonable solutions to the COV problem; either do nothing and get COV notifications on each blink-warn (Option 1) or make the blink-warn mechanism internal and not externally visible through the priority array (option 4). Personally, I prefer the latter as the blink warn mechanism is getting rather complex.
David Ritter M.Sc.
Delta Controls Inc.
17850 56th Ave
For those that don't know me, I've been involved with controls for some time and have monitored the BacNet working group with interest as I see more and more users asking me to have our lighting control system 'talk' to the Building Management System. I think BacNet is the way to go.
As such, Option 2, Delete the Blink Warn, should NOT be an option. This is a critical feature of any ltg control system.
Paul K. Ericson, PE
VP-Lighting Design, Syska Hennessy Group
San Diego, CA
--- On Fri, 10/23/09, Christoph Zeller <christoph.zeller@...-bc.com> wrote:
From: Christoph Zeller <christoph.zeller@...-bc.com>
Subject: Antwort: Re: RE: [BACnetLighting] New file uploaded to BACnetLighting
Date: Friday, October 23, 2009, 5:50 AM
Hi Steve and all,
as Steve mentioned here the plain text of my new file for those thtat are
not able to read it.
Critical Points in Lighting Output Objects
1. Blink Behaviour
Critical Points in Lighting Output Objects
In current objects of the BACnet standard 2008 we have 2 dependencies from
the present-value in Output Object Types.
Both, the level of physical output and the trigger for COV reporting are
directly attached to the present-value. This means that every change in
the present value is immediately transferred to the physical output.
1.3 Problem Description:
In the lighting Output Object, there is a strong wish to add blink-warning
functionality which indicates the fact that the output is going to go off
in near future.
To accomplish this, the blink generator is hooked to priority 6 of the
During a defined time, the lamps are going on and off repeatedly (how
often depends on the implementation) . Doing this we get the connection to
the hardware for free.
Unfortunately this has an implication on COV-reporting.
Because the COV-Reporting is directly coupled we see plenty of messages of
the type I'm on, I'm off, I'm on … . This potentially generates a lot of
network traffic. Additionaly it fills the Trend-Log Buffer if one is
Option1 (Do nothing):
- Live with the limitation that COV reporting and BLINK Warning
cannot be used simultaneously
Option 2 (Remove Blink warning feature)
- Feature not available
- (Unfortunately this was one of the major goals for the "Inventor")
Option 3 (Remove COV capability from Lighting Output Object)
- This option does not really work because there is an additional
COVP service which causes the same problems (I guess it's not wanted to
disallow devices supporting Blind-Outputs to use COVP services!)
Option 4 (Move the blink warning behind the priority array):
- Blinking is no more visible in the present-value property
- Problem with COV-reporting is solved
- How to detect weather blink warning is executed?
- Output is no more directly coupled to present-value.
2. Further Comments on Addendum
2.1 Rename misleading properties
I suggest to rename the properties Fade_Time and Ramp_Rate to
Default_Fade_ Time and Default_Ramp_ Rate respectively to emphasize in the
name, that those properties are used when no Ramp_Rate or Fade_Time is
sent with the corresponding Lighting_Command_ Request.
2.2 Clarify the behaviour of Lighting Command
In the case of a lighting command is currently executed, it is not clear
what to send if a read-property request is received for the priority
If the intention is, that the entry in the priority array reads the target
level immediately, then please say so. It might be the current level
calculated by the dimm state-machine as well.
What shall be the level read when reading pv?
When to trigger the COV notifications?
When the PV reaches a certain difference or should it be based on the
2.3 Controlling a Light_Dimmer using a Wall Switch
If a wall-switch is used a source of ramp commands, the conditions for
turning it on might not be as clear as expected.
If the current level is OFF, then we have to define with which level we
want to start.
From the current addenda, I assume that this is a local matter (do all
It might be better to add a property DEFAULT_ON_VALUE to the standard
which would define the level at which ramping starts when coming from off.
We then might add the special value 0.0 to indicate start with the level
the lamp was previously turned off (This is the behaviour of old-fashioned
Fr. Sauter AG
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
http://www.sauter- controls. com
This communication, and the information it contains is for the sole use of
the intended recipient. It is confidential, may be legally privileged and
protected by law. Unauthorized use, copying or disclosure of any part
thereof may be unlawful. If you have received this communication in error,
please destroy all copies and kindly notify the sender.
Before printing out this e-mail or its attachments, please consider
it is really necessary to do so.
Using less paper helps the environment.
This email message is a notification to let you know that
a file has been uploaded to the Files area of the BACnetLighting
File : /Add-135-2012be-PPR2-Draft-1.docx
Uploaded by : stephenkarg <steve@...>
Description : Lighting BIBBs - PPR2 - Draft 1
You can access this file at the URL:
To learn more about file sharing for your group, please visit: