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

Re: Feedback DMF-011

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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.