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

Re: [BACnetLighting] Feedback DMF-011

Expand Messages
  • Steve Karg
    Hi Joerg, ... Thanks for taking the time to look at our Lighting Output object. The group that put together the proposal for the Lighting Output object based
    Message 1 of 18 , Aug 8, 2006
    • 0 Attachment
      Hi Joerg,

      > I know this might be late in coming, but I got some feedback regarding
      > the proposal for the BACnet Lighting Object (DMF-011-9).

      Thanks for taking the time to look at our Lighting Output object. The
      group that put together the proposal for the Lighting Output object
      based alot of the properties and behaviors on DALI. However, we also
      wanted to be able to use the object with our existing systems, and so we
      did not make it strictly a DALI object. We also chose to implement the
      properties that we thought were needed for day to day operation, and not
      necessarily for configuration.

      > - Why do you specify the Fade_Time property to be of type Unsigned, not
      > REAL? To map the Lighting Object to a DALI ballast the type should be
      > REAL to reflect all the possible values (0.707, 1.0, 1.414, ...)

      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 their
      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.

      > - Further, I would suggest the following optional properties:
      > Power_On_Value (REAL) and System_Failure_Value (REAL), which should be
      > equivalent to the DALI registers "POWER ON LEVEL" and "SYSTEM FAILURE
      > LEVEL" respectively.

      Those seem okay to me.

      > o Auto_Off_Delay (REAL, seconds) Auto_Off_Priority (Unsigned): If
      > Auto_Off_Delay is set to a value greater 0, any Present_Value written at
      > a priority equal or lower than Auto_Off_Priority automatically
      > relinquishes after Auto_Off_Delay seconds. This feature is used for
      > staircase lighting (at least in Europe).
      > 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.
      > - A Dim_Mode property ("Ramp" or "Fade") could select the dim mode used
      > when the value is changed via the Present_Value property. This would
      > allow controller with no specific support for the Lighting Object to
      > control it like a simple Analog Output object.

      We had discussed having the Present_Value behave in the manners that you
      describe, but decided against it since those features could be created
      using the Lighting_Command. Any device that can control the
      Present_Value of the Lighting Output object *should* be able to control
      it using the Lighting_Command enumeration. In other words, if the
      device knows about the new object type, it would also know about the new
      properties of the object. This was also discussed at the SSPC-135
      BACnet committee.

      > - Last not least I would suggest a way to configure the DALI groups via
      > some BACnet property. This would allow to (re-)configure the DALI
      > network from the BACnet operating workstation

      This was only discussed briefly, if I recall correctly, as BACnet was
      assumed to be handling the day to day operations, and not the
      configuration of the system. However, changing the DALI groups on the
      fly for changing room configurations would be considered day to day
      operations. We need to think about what would be a good way to make the
      property support DALI, but not necessarily be restricted to DALI's 16
      groups. The same could be said about the DALI scenes.

      > Again, sorry for joining the process that late (I am sure you have
      > discussed at least some of the points mentioned here). Nevertheless, I
      > hope I can give some valuable feedback.

      Thanks for the feedback!

      > BTW, are there any plans for a BACnet Constant Light Controller object?

      I am not sure what Constant Light Controller means. If it means
      relay-based lighting, there is another proposal, DMF-019, that adds
      blink warn and timeout to the Binary objects. There have been other
      proposals to add automatic relinquish, but those have been dropped for
      now in favor of the Lighting Output object.

      Best Regards,

      Steve Karg
      Lithonia Lighting
      --
      http://www.kargs.net/
    • jbroeker2712
      Hi Steve, please find my comments below ... ... written at ... vice ... properties. ... used ... you ... new ... Does this comment also relate to the auto-off
      Message 2 of 18 , Aug 9, 2006
      • 0 Attachment
        Hi Steve,

        please find my comments below ...

        --- In BACnetLighting@yahoogroups.com, Steve Karg <steve@...> wrote:
        > > o Auto_Off_Delay (REAL, seconds) Auto_Off_Priority (Unsigned): If
        > > Auto_Off_Delay is set to a value greater 0, any Present_Value
        written at
        > > a priority equal or lower than Auto_Off_Priority automatically
        > > relinquishes after Auto_Off_Delay seconds. This feature is used for
        > > staircase lighting (at least in Europe).
        > > 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.
        > > - A Dim_Mode property ("Ramp" or "Fade") could select the dim mode
        used
        > > when the value is changed via the Present_Value property. This would
        > > allow controller with no specific support for the Lighting Object to
        > > control it like a simple Analog Output object.
        >
        > We had discussed having the Present_Value behave in the manners that
        you
        > describe, but decided against it since those features could be created
        > using the Lighting_Command. Any device that can control the
        > Present_Value of the Lighting Output object *should* be able to control
        > it using the Lighting_Command enumeration. In other words, if the
        > device knows about the new object type, it would also know about the
        new
        > properties of the object. This was also discussed at the SSPC-135
        > BACnet committee.

        Does this comment also relate to the auto-off and the delay features?

        > The same could be said about the DALI scenes.

        I implemented the DALI scenes using multi-state output objects. Each
        object is assigned to a DALI group. The states are "Recall scene x" (x
        = 0 to 15), "Store scene x", and "Remove scene x". Now, if the
        multi-state output object assigned to group 3 is set to recall scene 4
        the DALI command recall scene 4 is sent to group 3.

        > > BTW, are there any plans for a BACnet Constant Light Controller
        object?
        >
        > I am not sure what Constant Light Controller means. If it means
        > relay-based lighting, there is another proposal, DMF-019, that adds
        > blink warn and timeout to the Binary objects. There have been other
        > proposals to add automatic relinquish, but those have been dropped for
        > now in favor of the Lighting Output object.

        A constant light controller keeps the luminosity of a room constant.
        For this purpose it uses the input of a luminosity sensor and
        controlls the room lights accordingly.

        Best regards,

        Jörg
      • Steve Karg
        Hi Jörg, ... 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.
        Message 3 of 18 , Aug 9, 2006
        • 0 Attachment
          Hi Jörg,

          > > > 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. update
          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?

          * what is the use-case for this?

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

          > Does this comment also relate to the auto-off and the delay features?

          Auto Off - Yes, I think so. We had decided that when writing the
          Present Value directly that no funny business would occur. Setting the
          lights to a specific level with the optional delay and relinquish
          features would only occur when writing via Lighting_Command.

          > I implemented the DALI scenes using multi-state output objects. Each
          > object is assigned to a DALI group. The states are "Recall scene x" (x
          > = 0 to 15), "Store scene x", and "Remove scene x". Now, if the
          > multi-state output object assigned to group 3 is set to recall scene 4
          > the DALI command recall scene 4 is sent to group 3.

          Using Multi-state Output objects seems like a good idea for scenes.

          Regarding the "member of a group" idea, perhaps the DMF-030 and DMF-032
          proposals would be the better solution. The grouping suggested by those
          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 object
          that had been proposed by our working group. Can you review these
          proposals?

          > A constant light controller keeps the luminosity of a room constant.
          > For this purpose it uses the input of a luminosity sensor and
          > controlls the room lights accordingly.

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

          Best Regards,

          Steve
          --
          http://kargs.net/
        • Steve Karg
          Hi Jörg, ... I was discussing the DMF-011-9 proposal today and noticed that what I said earlier is not true. When the blink attributes are configured, the
          Message 4 of 18 , Aug 9, 2006
          • 0 Attachment
            Hi Jörg,

            > Auto Off - Yes, I think so. We had decided that when writing the
            > Present Value directly that no funny business would occur. Setting the
            > lights to a specific level with the optional delay and relinquish
            > features would only occur when writing via Lighting_Command.

            I was discussing the DMF-011-9 proposal today and noticed that what I
            said earlier is not true. When the blink attributes are configured, the
            Present_Value performs an automatic relinquish accompanied by a blink.

            So, the Auto_Off feature that you wrote about could be accomplished by
            setting the Blink_Time to 0. "A Blink_Time of zero shall disable this
            blink off effect."

            Perhaps we could clarify this Auto_Off without a blink feature by adding
            a sentence in the middle of 12.X.11.1 Blink Warning Behavior: "When
            Blink_Time is zero and Present_Value becomes 0%, the lights shall remain
            on and not blink for up to Blink_Delay seconds."

            Best Regards,

            Steve Karg
            Lithonia Lighting
            --
            http://www.kargs.net/
          • jbroeker2712
            Hi Steve, please find my comments below ... ... the ... adding ... remain ... I am not sure what you mean. As I understood the blink feature, it warns the
            Message 5 of 18 , Aug 10, 2006
            • 0 Attachment
              Hi Steve,

              please find my comments below ...

              --- In BACnetLighting@yahoogroups.com, Steve Karg <steve@...> wrote:
              > I was discussing the DMF-011-9 proposal today and noticed that what I
              > said earlier is not true. When the blink attributes are configured,
              the
              > Present_Value performs an automatic relinquish accompanied by a blink.
              >
              > So, the Auto_Off feature that you wrote about could be accomplished by
              > setting the Blink_Time to 0. "A Blink_Time of zero shall disable this
              > blink off effect."
              >
              > Perhaps we could clarify this Auto_Off without a blink feature by
              adding
              > a sentence in the middle of 12.X.11.1 Blink Warning Behavior: "When
              > Blink_Time is zero and Present_Value becomes 0%, the lights shall
              remain
              > on and not blink for up to Blink_Delay seconds."

              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 auto-off feature on the other hand would lead to a relinquish of
              the Present_Value if the value was NOT zero. This is heavily used in
              Europe for staircase lighting applications, where lights shall go out
              some time after they were switched on by someone (e.g. by pressing a
              light switch when entering the hallway). Or did I get something wrong
              here?

              Best regards,

              Jörg
            • Steve Karg
              Hi Jörg, ... The blink feature does warn the occupants of the room (or stairwell), but it also includes the auto-relinquish feature. If we add the ability to
              Message 6 of 18 , Aug 10, 2006
              • 0 Attachment
                Hi Jörg,

                > 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 ability
                to *not blink warn* then you get auto-relinquish without blinking.

                > The auto-off feature on the other hand would lead to a relinquish of
                > the Present_Value if the value was NOT zero. This is heavily used in
                > Europe for staircase lighting applications, where lights shall go out
                > some time after they were switched on by someone (e.g. by pressing a
                > light switch when entering the hallway). Or did I get something wrong
                > here?

                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 the
                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.

                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 from
                the same switch or another device, perhaps another switch? What about
                the clients that write/poll a value continuosly for reliability? What
                about devices whose architicture only looks at change of value?

                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?

                2. Minimal properties and services; duplication causes interoperiblity
                problems. If there are multiple ways to accomplish the same thing, then
                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, output)
                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)

                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)

                Best Regards,

                Steve
                --
                http://www.kargs.net/
              • jbroeker2712
                Hi Steve, Please find my comments below ... ... their ... Well, I guess all that is true for the Ramp_Rate (DALI Fade Rate) property as well. So why use REAL
                Message 7 of 18 , Aug 28, 2006
                • 0 Attachment
                  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
                  their
                  > 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.
                  update
                  > 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
                  those
                  > 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
                  object
                  > 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
                  Loop
                  > 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
                  ability
                  > 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
                  the
                  > 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
                  from
                  > 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,
                  then
                  > 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,
                  output)
                  > 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,

                  Jörg
                • Steve Karg
                  Hi Jörg, Thank you for your insightful comments and discussion. I would like to summarize where we are regarding potential changes to DMF-011-9, and see if
                  Message 8 of 18 , Sep 5, 2006
                  • 0 Attachment
                    Hi Jörg,

                    Thank you for your insightful comments and discussion.

                    I would like to summarize where we are regarding potential changes to
                    DMF-011-9, and see if you agree.

                    1. change Fade_Time from Unsigned to REAL.

                    2. add Power_On_Value

                    From DALI:

                    The interface signals shall be received properly 0.5 sec after
                    'Power-On'. Earliest after another 0.1 sec the ballast shall go to the
                    'POWER-ON LEVEL' via preheat- (if applicable) and ignition phase. The
                    ballast shall not go in the reset status. During the 0.1 sec interval
                    the ballast shall react on a possible command if this 'POWER-ON LEVEL'
                    is not desired.

                    proposed BACnet:

                    [add to Table 12-X Properties of the Lighting Output Object]
                    Power_On_Value REAL O

                    [add to 12.X, Lighting Output Object Type]
                    12.X.30 Power_On_Value

                    This optional property, of type REAL, shall specify the level that
                    output shall go to after power is applied and before going to the
                    Present_Value.

                    3. add System_Failure_Value

                    The levels are converted from REAL to 0-254 using the DALI logarithmic
                    dimming curve. MASK is 255. How is MASK set or reported? (perhaps -1.0
                    or 0.0 or NAN or INF?)

                    From DALI:

                    In case of the interface idle voltage is permanently below the specified
                    receiver high level range (see Appendix: Voltage ratings) during more
                    than 500 ms the ballast shall check the content of the 'SYSTEM
                    FAILURE LEVEL'. If 'MASK' is stored the ballast shall stay in the state
                    it is (no change of the arc power level, no switching on or off). In
                    case of any other value stored, the ballast shall go to this arc power
                    level immediately without fading. After the return of idle voltage the
                    ballast shall not change its state.

                    proposed BACnet:

                    [add to Table 12-X Properties of the Lighting Output Object]
                    System_Failure_Value REAL O

                    [add to 12.X, Lighting Output Object Type]
                    12.X.31 System_Failure_Value

                    This optional property, of type REAL, shall specify the value that
                    physical output shall go to if the interface to the output is deemed
                    inoperable. A value of NAN (not a number) shall specify that the
                    physical output remain in the state that it is in.

                    4. add On_Delay

                    [add to Table 12-X Properties of the Lighting Output Object]
                    On_Delay REAL O

                    [add to 12.X, Lighting Output Object Type]

                    12.X.32 On_Delay

                    This optional property, of type REAL, indicates the time in seconds that
                    the lights wait before turning on. When the Present_Value is changed
                    from zero to some value greater than zero, the action is delayed for the
                    time given in this property.

                    [change 12.X.4 Present_Value]

                    If the object supports fading (indicated by the presence of Fade_Time),
                    ramping (indicated by the presence of Ramp_Rate), or delaying (indicated
                    by the presence of On_Delay), then it is possible that Present_Value may
                    not indicate the actual state of the lighting output due to a fade,
                    ramp, or delay in progress.

                    5. Change Blink Warning Behavior to support an Off Delay:

                    [add to 12.X.11.1 Blink Warning Behavior]
                    When Blink_Time is zero and Present_Value becomes 0%, the lights shall
                    remain on and not blink for up to Blink_Delay seconds.

                    == Discussion ==

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

                    To support Off Delay, set the Blink_Delay equal to the amount of time
                    that you want Off_Delay to be. Set Blink_Time to zero. When the
                    Present_Value transitions from non-zero to zero, then the lights remain
                    on for Blink_Delay seconds, and automatically relinquish at the end of
                    Blink_Delay.

                    Perhaps changing the words Blink_Delay in DMF-011-9 to use the words
                    Off_Delay would make things clearer. They are the same thing.

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

                    I agree that the timer should reside in the Lighting Output objects.

                    I would say that the switches would have to send to the Lighting Output
                    a non-zero value followed by a zero value, similar to what a maintained
                    switch input would send. Or, when the switch is pressed, a non-zero
                    value is sent to the Lighting Output object; when the switch is
                    released, a zero value is sent to the Lighting Output object.

                    Or the wall switch could simply send a Lighting_Command with the
                    Duration field populated.

                    Thoughts? Did I miss anything?

                    Best Regards,

                    Steve Karg
                    Lithonia Lighting
                    --
                    http://www.kargs.net/
                  • jbroeker2712
                    Hi Steve, please find my comments below ... ... OK with me. ... Shouldn t it be: ... and before a new Present_Value is set ? I would add: If the lighting
                    Message 9 of 18 , Sep 13, 2006
                    • 0 Attachment
                      Hi Steve,

                      please find my comments below ...

                      --- In BACnetLighting@yahoogroups.com, Steve Karg <steve@...> wrote:
                      > Thank you for your insightful comments and discussion.
                      >
                      > I would like to summarize where we are regarding potential changes to
                      > DMF-011-9, and see if you agree.
                      >
                      > 1. change Fade_Time from Unsigned to REAL.

                      OK with me.

                      > 2. add Power_On_Value
                      >
                      > From DALI:
                      >
                      > The interface signals shall be received properly 0.5 sec after
                      > 'Power-On'. Earliest after another 0.1 sec the ballast shall go to the
                      > 'POWER-ON LEVEL' via preheat- (if applicable) and ignition phase. The
                      > ballast shall not go in the reset status. During the 0.1 sec interval
                      > the ballast shall react on a possible command if this 'POWER-ON LEVEL'
                      > is not desired.
                      >
                      > proposed BACnet:
                      >
                      > [add to Table 12-X Properties of the Lighting Output Object]
                      > Power_On_Value REAL O
                      >
                      > [add to 12.X, Lighting Output Object Type]
                      > 12.X.30 Power_On_Value
                      >
                      > This optional property, of type REAL, shall specify the level that
                      > output shall go to after power is applied and before going to the
                      > Present_Value.

                      Shouldn't it be: "... and before a new Present_Value is set"?

                      I would add:

                      "If the lighting output is a DALI ballast this value corresponds to
                      the DALI register 'POWER-ON LEVEL' of the ballast."

                      >
                      > 3. add System_Failure_Value
                      >
                      > The levels are converted from REAL to 0-254 using the DALI logarithmic
                      > dimming curve. MASK is 255. How is MASK set or reported? (perhaps -1.0
                      > or 0.0 or NAN or INF?)

                      I use -1.0, but I think NAN is just as good.

                      > From DALI:
                      >
                      > In case of the interface idle voltage is permanently below the specified
                      > receiver high level range (see Appendix: Voltage ratings) during more
                      > than 500 ms the ballast shall check the content of the 'SYSTEM
                      > FAILURE LEVEL'. If 'MASK' is stored the ballast shall stay in the state
                      > it is (no change of the arc power level, no switching on or off). In
                      > case of any other value stored, the ballast shall go to this arc power
                      > level immediately without fading. After the return of idle voltage the
                      > ballast shall not change its state.
                      >
                      > proposed BACnet:
                      >
                      > [add to Table 12-X Properties of the Lighting Output Object]
                      > System_Failure_Value REAL O
                      >
                      > [add to 12.X, Lighting Output Object Type]
                      > 12.X.31 System_Failure_Value
                      >
                      > This optional property, of type REAL, shall specify the value that
                      > physical output shall go to if the interface to the output is deemed
                      > inoperable. A value of NAN (not a number) shall specify that the
                      > physical output remain in the state that it is in.

                      I would add:

                      "If the lighting output is a DALI ballast this value corresponds to
                      the DALI register 'SYSTEM FAILURE LEVEL' of the ballast."

                      > 4. add On_Delay
                      >
                      > [add to Table 12-X Properties of the Lighting Output Object]
                      > On_Delay REAL O
                      >
                      > [add to 12.X, Lighting Output Object Type]
                      >
                      > 12.X.32 On_Delay
                      >
                      > This optional property, of type REAL, indicates the time in seconds that
                      > the lights wait before turning on. When the Present_Value is changed
                      > from zero to some value greater than zero, the action is delayed for the
                      > time given in this property.
                      >
                      > [change 12.X.4 Present_Value]
                      >
                      > If the object supports fading (indicated by the presence of Fade_Time),
                      > ramping (indicated by the presence of Ramp_Rate), or delaying (indicated
                      > by the presence of On_Delay), then it is possible that Present_Value may
                      > not indicate the actual state of the lighting output due to a fade,
                      > ramp, or delay in progress.

                      Shouldn't Off_Delay be mentioned as well ("...or delaying (indicated
                      by the presence of Off_Delay) ...")?

                      > 5. Change Blink Warning Behavior to support an Off Delay:
                      >
                      > [add to 12.X.11.1 Blink Warning Behavior]
                      > When Blink_Time is zero and Present_Value becomes 0%, the lights shall
                      > remain on and not blink for up to Blink_Delay seconds.
                      >
                      > == Discussion ==
                      >
                      > > 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.
                      >
                      > To support Off Delay, set the Blink_Delay equal to the amount of time
                      > that you want Off_Delay to be. Set Blink_Time to zero. When the
                      > Present_Value transitions from non-zero to zero, then the lights remain
                      > on for Blink_Delay seconds, and automatically relinquish at the end of
                      > Blink_Delay.
                      >
                      > Perhaps changing the words Blink_Delay in DMF-011-9 to use the words
                      > Off_Delay would make things clearer. They are the same thing.

                      That is ok with me.

                      > > 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.
                      >
                      > I agree that the timer should reside in the Lighting Output objects.
                      >
                      > I would say that the switches would have to send to the Lighting Output
                      > a non-zero value followed by a zero value, similar to what a maintained
                      > switch input would send. Or, when the switch is pressed, a non-zero
                      > value is sent to the Lighting Output object; when the switch is
                      > released, a zero value is sent to the Lighting Output object.
                      >
                      > Or the wall switch could simply send a Lighting_Command with the
                      > Duration field populated.

                      Well I guess the Lighting_Command duration field is what suites the
                      application best. Seems I overlooked that feature.

                      Do you attend the Plug-Fest in Vancouver in two weeks? Me and a
                      college of mine will be there. If so, maybe we can continue the
                      discussion over a nice beer ... :-)

                      BTW, maybe you can direct me to a manufacturer of DALI equipment in
                      the US. I need a 110V bus-power supply and ballast for the plug-fest.
                      The stuff I have is 230V only.

                      Best regards,

                      Jörg
                    • Steve Karg
                      Hi Jörg, ... I think that this kind of information is valuable, but should not be part of the Lighting Output object. We typically put this kind of mapping
                      Message 10 of 18 , Sep 16, 2006
                      • 0 Attachment
                        Hi Jörg,

                        > > 2. add Power_On_Value
                        > I would add:
                        >
                        > "If the lighting output is a DALI ballast this value corresponds to
                        > the DALI register 'POWER-ON LEVEL' of the ballast."

                        I think that this kind of information is valuable, but should not be
                        part of the Lighting Output object. We typically put this kind of
                        mapping in ANNEX H - COMBINING BACnet NETWORKS WITH NON-BACnet NETWORKS
                        (NORMATIVE). It will probably be similar to what was done with H.5
                        Using BACnet with EIB/KNX.

                        Since you are familiar with the top, perhaps you can create the "Annex
                        H.X Using BACnet with DALI" proposal. If you are able, use the Change
                        Proposal Style Guide for guidance on the document structure. It can be
                        found at:
                        ftp://SSPC:135@.../home/SSPC/Change Proposal Style Guide v15.doc
                        When you are finished you can post it here on this list for feedback,
                        and then we can submit to the BACnet committee. What do you think?

                        > > [change 12.X.4 Present_Value]
                        > >
                        > > If the object supports fading (indicated by the presence of Fade_Time),
                        > > ramping (indicated by the presence of Ramp_Rate), or delaying (indicated
                        > > by the presence of On_Delay), then it is possible that Present_Value may
                        > > not indicate the actual state of the lighting output due to a fade,
                        > > ramp, or delay in progress.
                        >
                        > Shouldn't Off_Delay be mentioned as well ("...or delaying (indicated
                        > by the presence of Off_Delay) ...")?

                        Yes, it should.

                        > Do you attend the Plug-Fest in Vancouver in two weeks? Me and a
                        > college of mine will be there. If so, maybe we can continue the
                        > discussion over a nice beer ... :-)

                        I am planning to attend the BTL meetings and the Plugfest in Vancouver.
                        We can certainly continue the discussion there!

                        > BTW, maybe you can direct me to a manufacturer of DALI equipment in
                        > the US. I need a 110V bus-power supply and ballast for the plug-fest.
                        > The stuff I have is 230V only.

                        I have some. I will plan to bring a 110V DALI ballast and a bus-power
                        supply along.

                        Best Regards,

                        Steve Karg
                        Lithonia Lighting
                        --
                        http://kargs.net/
                      • jbroeker2712
                        Hi Steve, No problem. I will try to write a Annex H.X. However, it might take a while, since currently I am pretty busy. Or do you think it is urgent? Best
                        Message 11 of 18 , Sep 18, 2006
                        • 0 Attachment
                          Hi Steve,

                          No problem. I will try to write a Annex H.X. However, it might take a
                          while, since currently I am pretty busy. Or do you think it is urgent?

                          Best regards,

                          Jörg

                          --- In BACnetLighting@yahoogroups.com, Steve Karg <steve@...> wrote:
                          >
                          > Hi Jörg,
                          >
                          > > > 2. add Power_On_Value
                          > > I would add:
                          > >
                          > > "If the lighting output is a DALI ballast this value corresponds to
                          > > the DALI register 'POWER-ON LEVEL' of the ballast."
                          >
                          > I think that this kind of information is valuable, but should not be
                          > part of the Lighting Output object. We typically put this kind of
                          > mapping in ANNEX H - COMBINING BACnet NETWORKS WITH NON-BACnet NETWORKS
                          > (NORMATIVE). It will probably be similar to what was done with H.5
                          > Using BACnet with EIB/KNX.
                          >
                          > Since you are familiar with the top, perhaps you can create the "Annex
                          > H.X Using BACnet with DALI" proposal. If you are able, use the Change
                          > Proposal Style Guide for guidance on the document structure. It can be
                          > found at:
                          > ftp://SSPC:135@.../home/SSPC/Change Proposal Style Guide v15.doc
                          > When you are finished you can post it here on this list for feedback,
                          > and then we can submit to the BACnet committee. What do you think?
                          >
                          > > > [change 12.X.4 Present_Value]
                          > > >
                          > > > If the object supports fading (indicated by the presence of
                          Fade_Time),
                          > > > ramping (indicated by the presence of Ramp_Rate), or delaying
                          (indicated
                          > > > by the presence of On_Delay), then it is possible that
                          Present_Value may
                          > > > not indicate the actual state of the lighting output due to a fade,
                          > > > ramp, or delay in progress.
                          > >
                          > > Shouldn't Off_Delay be mentioned as well ("...or delaying (indicated
                          > > by the presence of Off_Delay) ...")?
                          >
                          > Yes, it should.
                          >
                          > > Do you attend the Plug-Fest in Vancouver in two weeks? Me and a
                          > > college of mine will be there. If so, maybe we can continue the
                          > > discussion over a nice beer ... :-)
                          >
                          > I am planning to attend the BTL meetings and the Plugfest in Vancouver.
                          > We can certainly continue the discussion there!
                          >
                          > > BTW, maybe you can direct me to a manufacturer of DALI equipment in
                          > > the US. I need a 110V bus-power supply and ballast for the plug-fest.
                          > > The stuff I have is 230V only.
                          >
                          > I have some. I will plan to bring a 110V DALI ballast and a bus-power
                          > supply along.
                          >
                          > Best Regards,
                          >
                          > Steve Karg
                          > Lithonia Lighting
                          > --
                          > http://kargs.net/
                          >
                        • Steve Karg
                          Hi Jörg (and other interested parties), ... We are discussing DMF-011-10 in SSPC 135 BACnet committee today, and are discussing the use-case for On_Delay.
                          Message 12 of 18 , Nov 8, 2006
                          • 0 Attachment
                            Hi Jörg (and other interested parties),

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

                            We are discussing DMF-011-10 in SSPC 135 BACnet committee today, and are
                            discussing the use-case for On_Delay. The only use-case that we see is
                            using it for distributed start to keep the load from many Lighting
                            Output objects from creating a load spike.

                            The objections of having an On_Delay property is that this use-case
                            should really be a client feature, not an end-point object feature,
                            since scheduling a lot of Lighting Output objects would happen once, for
                            example, in the morning. Any subsequent accesses to the Ligthing Output
                            objects would probably not need the On_Delay, and so On_Delay creates
                            more problems than it solves.

                            Any discussion for or against having On_Delay property in the Lighting
                            Output object?

                            Best Regards,

                            Steve Karg
                            Lithonia Lighting
                          • craig.spangler@us.schneider-electric.com
                            Steve, We use the On_Delay in our lighting products. The main user of this feature is in large warehouses. It s not a real lighting application but here is
                            Message 13 of 18 , Nov 8, 2006
                            • 0 Attachment
                              Steve,

                              We use the On_Delay in our lighting products. The main user of this feature is in large warehouses. It's not a "real" lighting application but here is how it is used. The large exhaust fans in warehouses have louvers that need opened before a fan starts and needs to close only after the fan stops. Typically the user will open the louvers 10 seconds before turning the fan on and wait a certain period of time after turning the fan off before closing them. I am not sure if there are other similar applications that are not lighting apps, but are used with lighting devices.

                              Craig Spangler
                              Staff Firmware Engineer
                              Powerlink Group
                              Square D / Schneider Electric




                              Steve Karg <steve@...>
                              Sent by: BACnetLighting@yahoogroups.com

                              11/08/2006 10:45 AM

                              Please respond to
                              BACnetLighting@yahoogroups.com

                              To
                              BACnetLighting@yahoogroups.com
                              cc
                              Subject
                              Re: [BACnetLighting] Feedback DMF-011





                              Hi Jörg (and other interested parties),

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

                              We are discussing DMF-011-10 in SSPC 135 BACnet committee today, and are
                              discussing the use-case for On_Delay. The only use-case that we see is
                              using it for distributed start to keep the load from many Lighting
                              Output objects from creating a load spike.

                              The objections of having an On_Delay property is that this use-case
                              should really be a client feature, not an end-point object feature,
                              since scheduling a lot of Lighting Output objects would happen once, for
                              example, in the morning. Any subsequent accesses to the Ligthing Output
                              objects would probably not need the On_Delay, and so On_Delay creates
                              more problems than it solves.

                              Any discussion for or against having On_Delay property in the Lighting
                              Output object?

                              Best Regards,

                              Steve Karg
                              Lithonia Lighting


                              ________________________________________________________________________
                              This email has been scanned for SPAM content and Viruses by the MessageL
                              abs Email Security System.
                              ________________________________________________________________________

                            • Steve Karg
                              Hello Lighting Applications working group! DMF-011 - The BACnet Lighting Output object was voted out for public review today (13-0-2) at the SSPC 135 committee
                              Message 14 of 18 , Nov 8, 2006
                              • 0 Attachment
                                Hello Lighting Applications working group!

                                DMF-011 - The BACnet Lighting Output object was voted out for public
                                review today (13-0-2) at the SSPC 135 committee meeting in Atlanta,
                                Georgia. We included the "Tripped" reliability status from STK-015. We
                                still have some work to do adding the ANSI/ASHRAE 135.1 tests for this
                                object, and getting the document into the correct format for public
                                review. Thank you David Fisher of Polarsoft for continuing to work on
                                this object. Thank you to the members of this working group for putting
                                this object together and reviewing it.

                                We also discussed STK-004 - Multiplexer object, DMF-032 - WriteGroup
                                Service, DMF-030 - WriteGroupMode Service. The general consensus after
                                a long discussion was that the Lighting Applications working group needs
                                to re-convene to consolidate the three ideas into a single proposal.
                                Although we can collaborate online or meet to discuss these at another
                                venue, the next BACnet meeting is planned to be held January 27-31,
                                2007, in Dallas, Texas. More details about a specific date and time for
                                a meeting will be posted here as it becomes available. More details
                                about the ASHRAE meeting in Dallas can be found on their website:
                                http://www.ashrae.org/dallas

                                Best Regards,

                                Steve Karg
                                Lithonia Lighting
                              • jbroeker2712
                                Hi Steve, as I mentioned in a previous discussion, I personally do not know of any specific application for On_Delay. The reason, why I suggested it is, that I
                                Message 15 of 18 , Nov 10, 2006
                                • 0 Attachment
                                  Hi Steve,

                                  as I mentioned in a previous discussion, I personally do not know of
                                  any specific application for On_Delay. The reason, why I suggested it
                                  is, that I have taken a look at lighting controllers for LonWorks and
                                  at least the ones I looked at have this feature. So I thought they
                                  must have a reason to implement that. Maybe that was naive ... ;-)

                                  Seriously, I do not have any objection if this property is removed.

                                  Best regards,

                                  Jörg

                                  p.s.: Did not find the time to review the current/new proposal. Since
                                  I am on vacation starting next week, I will have to take a look at it
                                  when I come back.

                                  --- In BACnetLighting@yahoogroups.com, Steve Karg <steve@...> wrote:
                                  >
                                  > Hi Jörg (and other interested parties),
                                  >
                                  > > 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.
                                  >
                                  > We are discussing DMF-011-10 in SSPC 135 BACnet committee today, and
                                  are
                                  > discussing the use-case for On_Delay. The only use-case that we see is
                                  > using it for distributed start to keep the load from many Lighting
                                  > Output objects from creating a load spike.
                                  >
                                  > The objections of having an On_Delay property is that this use-case
                                  > should really be a client feature, not an end-point object feature,
                                  > since scheduling a lot of Lighting Output objects would happen once,
                                  for
                                  > example, in the morning. Any subsequent accesses to the Ligthing
                                  Output
                                  > objects would probably not need the On_Delay, and so On_Delay creates
                                  > more problems than it solves.
                                  >
                                  > Any discussion for or against having On_Delay property in the Lighting
                                  > Output object?
                                  >
                                  > Best Regards,
                                  >
                                  > Steve Karg
                                  > Lithonia Lighting
                                  >
                                • Langels, Hans-Joachim
                                  Hello Steve, an On-Delay is not uncommon for output devices in the industry. Hence, I see value in keeping this Property. Best regards, Hans J. Langels Siemens
                                  Message 16 of 18 , Nov 11, 2006
                                  • 0 Attachment
                                    Hello Steve,

                                    an On-Delay is not uncommon for output devices in the industry.

                                    Hence, I see value in keeping this Property.

                                    Best regards,
                                    Hans J. Langels

                                    Siemens AG
                                    A&D ET BC PM
                                    Product Management
                                    Siemensstrasse 10
                                    93055 Regensburg
                                    GERMANY

                                    FON: +49 (941) 790-2992
                                    FAX: +49 (941) 790-2603
                                    MOBILE: +49 (151) 121-32281
                                    EMAIL: Hans-Joachim.Langels@...

                                    Technische Dokumentation instabus EIB und Produktdatenbankeinträge für ETS
                                    http://www.ad.siemens.de/et/gamma/html_00/support/techdoku.htm

                                    Technical Documentation instabus EIB and productdatabase for ETS
                                    http://www.ad.siemens.de/et/gamma/html_76/support/techdoku.htm

                                    > Support Request: http://www.siemens.de/automation/support-request
                                    > Internet: http://www.siemens.de/automation/service&support
                                    > FAQ http://www.siemens.de/automation/csi/product
                                    >
                                    >
                                    > Hinweis: Diese Information ist für den Gebrauch durch die Personen oder die Firma/Organisation bestimmt, die in der Empfängeradresse benannt ist. Wenn Sie nicht der angegebene Empfänger sind, nehmen Sie bitte zur Kenntnis, daß Weitergabe, Kopieren, Verteilung oder Nutzung des Inhalts dieser EMail-Übertragung unzulässig ist. Falls Sie diese EMail irrtümlich erhalten haben, benachrichtigen Sie den Absender bitte unverzüglich telefonisch oder durch eine EMail.
                                    > Note: This e-mail may contain confidential information. If you have received this e-mail without being the proper recipient, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Any views or opinions presented are solely those of the author of this e-mail and do not necessarily represent those of Siemens AG, unless otherwise specifically stated.
                                    >


                                    -----Ursprüngliche Nachricht-----
                                    Von: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] Im Auftrag von jbroeker2712
                                    Gesendet: Freitag, 10. November 2006 10:18
                                    An: BACnetLighting@yahoogroups.com
                                    Betreff: [BACnetLighting] Re: Feedback DMF-011

                                    Hi Steve,

                                    as I mentioned in a previous discussion, I personally do not know of
                                    any specific application for On_Delay. The reason, why I suggested it
                                    is, that I have taken a look at lighting controllers for LonWorks and
                                    at least the ones I looked at have this feature. So I thought they
                                    must have a reason to implement that. Maybe that was naive ... ;-)

                                    Seriously, I do not have any objection if this property is removed.

                                    Best regards,

                                    Jörg

                                    p.s.: Did not find the time to review the current/new proposal. Since
                                    I am on vacation starting next week, I will have to take a look at it
                                    when I come back.

                                    --- In BACnetLighting@yahoogroups.com, Steve Karg <steve@...> wrote:
                                    >
                                    > Hi Jörg (and other interested parties),
                                    >
                                    > > 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.
                                    >
                                    > We are discussing DMF-011-10 in SSPC 135 BACnet committee today, and
                                    are
                                    > discussing the use-case for On_Delay. The only use-case that we see is
                                    > using it for distributed start to keep the load from many Lighting
                                    > Output objects from creating a load spike.
                                    >
                                    > The objections of having an On_Delay property is that this use-case
                                    > should really be a client feature, not an end-point object feature,
                                    > since scheduling a lot of Lighting Output objects would happen once,
                                    for
                                    > example, in the morning. Any subsequent accesses to the Ligthing
                                    Output
                                    > objects would probably not need the On_Delay, and so On_Delay creates
                                    > more problems than it solves.
                                    >
                                    > Any discussion for or against having On_Delay property in the Lighting
                                    > Output object?
                                    >
                                    > Best Regards,
                                    >
                                    > Steve Karg
                                    > Lithonia Lighting
                                    >





                                    ======================================================
                                    To view the message archive, set user options, or view
                                    files in our archive, visit the following web page:

                                    http://www.yahoogroups.com/group/BACnetLighting/

                                    To subscribe to this group, send an email to:

                                    BACnetLighting-subscribe@yahoogroups.com
                                    Yahoo! Groups Links
                                  Your message has been successfully submitted and would be delivered to recipients shortly.