209Comments on Addendum i Draft 7
- Jan 14, 2010Dear all,
I was rereading the draft 7 for the Addendum i.
As follow the concerns I found in the document:
- Chapter 12.X.9 paragraph 2 (just under the table 12-Y)
... or the priority field of the LIghtingCommand if present
The concept I see is that if this field in the lighting command is
present its this content to be used, if the field is not present in the
lighting command then
the property priority is used. Which one of the two has the priority
might not be clear enough (although you should be able to correclty guess
from the context).
I would suggest add a paragraph generally describing this behaviour and
not repeating it on all occasions (with slightly different language in the
It should be considered to change the language for all such fields of
the lighting command.
One possible solution to make it even more clear is to rename the
corresponding properties to Default_xxx.
- Chapter 12.X.15.1 Blink Warning Behaviour
I guess that the description of auto-reliquish is not behaving as
Example: We have a priority Array with one populated Entry of 100% at
priority 12. All other entries are NULL.
Now we are writing 0% to priority 8 which triggers blink warning. Blink
Warning is inserting 0% to priority 6 for Blink-Time.
Next 100% is written to priority 6 to restore the previous level for
Warn-Delay seconds. Then priority 6 should be relinquished.
Unfortunately with the language written we are relinquishing priority 8
which results in 100% (Why did we had a Blink-Warning?)
There might be more ambiguities with auto-relinquish I was not checking
all occurences so far.
The critical point with interference with COV-Notifications is still not
- Chapter 12.X.30/31
introducing a new concept of automatically readjust min_pres_value and
max_pres_value if they are commanded to opposite directions.
In all other objects this is not done and potentially controversal
during public review (Analog Output Objects are not mentioning it).
If we introduce it here, we should consider introducing the same
mechanism to all other opjects as well.
See you soon in Orlando
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
it is really necessary to do so.
Using less paper helps the environment.
Steve Karg <steve@...>
Re: Re: RE: [BACnetLighting] Re: Meeting in Orlando, Florida
> the RLH-001.pdf is dated 15 June 2009.We have not discussed this proposal in a long time, and there have
> This is significantly older than our last meeting.
> Is it still the valid one?
been no revisions posted by Rick or Robert. The RLH-001 posted on
Yahoo Groups is the latest file that I have.
- << Previous post in topic