Concerns specifying ranges in Light Output Objects
- Hi folks,
as announced in the last Telco a few comments about my concerns.
Whatever we specify as a lighting output object it has to meet a few things.
- When using the object it has to match the expectations (Otherwise the use-cases won't work)
- Coupling with a DALI backend should not be prohibited
- When looking to analog objects we have properties for announcing both range and resolution (CZ-009 for value objects)
- In the Lighting Output, the range is specified with 0 to 100 (So the range is specified)
However the resolution is not mentioned anywhere and can be as low as on/off.
Even if we have dimmable lights, neither the number of steps nor the transfer characteristic is known.
So in case of a DALI output, the transfer characteristic is logarithmic and a resolution à la analog output cannot be given.
Even worse, we sometimes call the unit being percent % which is definitively not true. Setting 50% means give me something between dimmest and brightest.
In the case of binary outputs, I can live with the limitation as it is very obvious (given by the lamp)
For dimmable lamps, we can safely assume that best effort is good enough (give me closest value to the desired one)
For timing issues we mention no requirements and this puzzles me.
We specify an integer in milliseconds for fade-time.
Do we really care if 234ms are matched and to which degree. (DALI has a 40% step between 2 neighbouring values, factor 1.414)
For short fade-times I assume that choosing the next available value is best effort enough (And as an End-user we don't care)
If we go for long fade times, do we want a linear or logarithmic fading behaviour (or do we don't care)
I assume that DALI had a reason to specify the dimming curve as being logarithmic (seems to be adjusted to the human eye)
Basically there are 2 qeustions that needs to be answered:
- Is it OK to assume best effort for the target level? (I think we agree on this one)
- Is it OK to assume best effort for Fadetime, Ramprate? (not yet discussed)
- If we wan't to use long FADE-times (usecase Energy saving fade down over 1 hour) does every BACnet lighting object has to support it?
- If we want to mandate support for this times we have to state it.
- If not, we cannot assume correct execution
- What should be the error code if one of the optional parameters is out of range (FADE-time, Ramp-rate, ...)
- Value out of Range? (Then how can you know with one, we now have multiple fields)
- Optional Service not Supported? (What caused the service to fail?)
- Truncate to nearest possible value?
I really fear that just assuming that the server will execute a service will not be enough (Too many options to fail for whatever reason)
Fr. Sauter AG
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
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 whether
it is really necessary to do so.
Using less paper helps the environment.