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

106Re: Feedback DMF-011

Expand Messages
  • jbroeker2712
    Aug 28, 2006
      Hi Steve,

      Please find my comments below ...

      --- In BACnetLighting@yahoogroups.com, Steve Karg <steve@...> wrote:
      > The lighting vendors in the working group felt that the fade_time value
      > as unsigned in seconds was plenty of resolution, and that was what
      > existing systems did.
      > Let's see what DALI offers. Fade Time in DALI is expressed as:
      > T=1/2(sqrt(2^x)) where x=1-15, 0=no fade.
      > 15 possible fade times:
      > 0.707, 1.0, 1.414, 2.00, 2.828, 4.000, 5.657, 8.000, 11.314, 16.000,
      > 22.627, 32.000, 45.255, 64.000, and 90.510.
      > DALI is using a value of 0 to 90 seconds.
      > Practical issues (i.e. getting the output fade accurately to 3 decimal
      > places) and storage and encoding issues aside (i.e. REAL costs more in
      > bandwidth and storage than an unsigned in the range of 0-90), there is
      > no way to report the DALI Fade Time to 3 decimal places over BACnet
      > using the Lighting Output object unless the property is a REAL or a
      > proprietary property is used.
      > I am not opposed to changing Fade_Time to REAL to be able to directly
      > support a DALI interface. Perhaps some other members of the working
      > group can express their opinions.

      Well, I guess all that is true for the Ramp_Rate (DALI Fade Rate)
      property as well. So why use REAL in one case and UNSIGNED in the
      other? I think this is kind of inconsistent.

      Further, I don't see the practical issues you mentioned above: The
      difference of the size of a REAL to UNSIGNED is how many bytes? If
      any? In any case compare to the size of a BACnet message/BACnet object
      its marginal. And there is no need to get the value accurately to 3
      decimal places. If the lighting object is mapped to a DALI device, the
      value has to be rounded to the next available DALI fade time value anyway.

      > > > > o On_Delay (REAL, seconds) Off_Delay (REAL, seconds): If the
      > > > > Present_Value is changed from 0 to some value greater than
      zero or
      > > vice
      > > > > versa the dim action is delayed for the time given in these
      > > properties.
      > These properties could be added, but I would suggest that they only
      > affect the Present_Value via the Lighting_Command in order to be
      > consistent. We should also consider:
      > * the effect of client devices that write values constantly (i.e.
      > the value every 5 seconds), and the effect of multiple devices sending
      > different values or commands.
      > * can this feature also be accomplished from client device? Is there a
      > case where it cannot?

      If there are multiple clients (like multiple smart switches), they do
      not know from each other. Thus the timers must run at the server, that
      is, the BACnet lighting object.

      > * what is the use-case for this?

      To be honest I don't know. I am not a light control expert. But I have
      some experience in the LonWorks field and I have looked at some
      controllers performing similar tasks in the LonWorks world. They
      usually have those configuration options (called SCPT in LonWorks). So
      I guess they must have some use? ;-) If you like I can try and find
      out ...

      > * does this also apply to ramping, stepping, or fading down?

      I would say it applies to any situation where the present value
      changes from 0 to some value greater than zero (on delay) and vice
      versa (off delay).

      > Regarding the "member of a group" idea, perhaps the DMF-030 and DMF-032
      > proposals would be the better solution. The grouping suggested by
      > proposals allow grouping of any objects, not just Lighting Output
      > objects. These have been discussed at the SSPC-135 BACnet committee,
      > but did not gain consensus due to the similar STK-004 Multiplexer
      > that had been proposed by our working group. Can you review these
      > proposals?

      I will take a look at it.

      > I know that term as "Daylight Harvesting." I anticipated using the
      > object for that purpose, but have not implemented it or tried it. Will
      > that work for you?

      I will take a look at it.

      > > I am not sure what you mean. As I understood the blink feature, it
      > > warns the occupants of a room that lights will go out soon, when the
      > > Present_Value was written to a value of zero.
      > The blink feature does warn the occupants of the room (or stairwell),
      > but it also includes the auto-relinquish feature. If we add the
      > to *not blink warn* then you get auto-relinquish without blinking.

      But "blink warn" is in effect BEFORE a transition TO 0 is eminent,
      while "auto-off" is in effect AFTER a transition FROM 0. So, confusing
      semantics asside, I don't understand how you want to use this feature
      for both.

      > I guess it depends on the control paradigm that is used, and where the
      > timeout timer resides.
      > If the light switch is a smart BACnet light switch, it could command
      > lights on, and then command the lights off after a period of time.
      > Nothing fancy is necessary on the lighting output device, only at the
      > smart BACnet light switch. Multiple switches or other control devices
      > could be used for that same lighting output by utilizing the
      > auto-relinquish feature with or with out the blink warn.

      How would this work with multiple switches, when the timer should be
      reset every time one of the switches is pressed (like in a typical
      staircase)? The different clients do not know about the timers in the
      other clients and have no means to reset those timers.

      > But what you are suggesting with auto-off is having a timer
      intrinsic to
      > the Lighting Output object that will automatically relinquish after a
      > period of time after the object is commanded on. Would the timer
      > automatically reset when another non-zero Present-Value is received
      > the same switch or another device, perhaps another switch?

      Well I guess, for that purpose I would add a auto_off_mode property,
      which allows to configure the behavior in this case.

      > What about
      > the clients that write/poll a value continuosly for reliability? What
      > about devices whose architicture only looks at change of value?

      What kind of problems do you expect for those devices?

      > I don't want to discourage necessary features. However, we should look
      > at each feature and decide:
      > 1. Is there another way in BACnet (or in a proposal) to do this already?

      No (multiple switches commanding same lighing object).

      > 2. Minimal properties and services; duplication causes interoperiblity
      > problems. If there are multiple ways to accomplish the same thing,
      > multiple ways will be used.
      > 3. For lighting control: can I create a distributed BACnet network and
      > accomplish what I need? Can I do what I need to do using only BACnet
      > objects, properties, and services? Will the components (switch,
      > be interchangable, require minimal configuration, or only work if they
      > are from the same vendor? (i.e. a smart BACnet light switch and a smart
      > BACnet lighting output connected on a BACnet network)

      Clients will become simpler. Configuration can be accomplished using
      standard BACnet mechanisms (properties) and not proprietory means
      (like in case the control mechanism is placed in the client). This
      allows to re-configure the system (e.g. staircase auto-off timer) in a
      standard way and thus using any standard operating workstation, which
      is a big benefit for the building owner/operator.

      > 4. Can I do what I need to do in an economical manner? (i.e. forcing a
      > RAM/ROM challenged device to implement WritePropertyMultiple in
      order to
      > write several properties in a somewhat atomic manner)

      Well, in the end every argument that justifies the blink warn feature
      can be put forward in favor of the auto off feature, since they both
      are a identical category of function.

      Maybe this function is rarely used in the US, but here in Europe it is
      a must-have-feature for any light control system (on the other hand I
      have never heard of blink warn) before. Having this heavily used
      standard function implemented in the lighting object has the
      advantange, that a very simple client without any controller
      functionality can be used to control the object.

      Best regards,

    • Show all 18 messages in this topic