Loading ...
Sorry, an error occurred while loading the content.

209Comments on Addendum i Draft 7

Expand Messages
  • Christoph Zeller
    Jan 14, 2010
      Dear 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
      next paragraph).
      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
      expected:
      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
      resolved!

      - 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
      Regards
      Christoph



      Christoph Zeller
      Abt. NT
      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

      DISCLAIMER:
      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.




      Von:
      Steve Karg <steve@...>
      An:
      BACnetLighting@yahoogroups.com
      Datum:
      13.01.2010 18:13
      Betreff:
      Re: Re: RE: [BACnetLighting] Re: Meeting in Orlando, Florida
      Gesendet von:
      BACnetLighting@yahoogroups.com




      Hello Christoph,

      > the RLH-001.pdf is dated 15 June 2009.
      > This is significantly older than our last meeting.
      > Is it still the valid one?

      We have not discussed this proposal in a long time, and there have
      been no revisions posted by Rick or Robert. The RLH-001 posted on
      Yahoo Groups is the latest file that I have.

      Best Regards,

      Steve
      --
      http://steve.kargs.net/
    • Show all 13 messages in this topic