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

Feedback DMF-011

Expand Messages
  • Joerg Broeker
    Hi all, I know this might be late in coming, but I got some feedback regarding the proposal for the BACnet Lighting Object (DMF-011-9). I am currently
    Message 1 of 18 , Aug 8, 2006
      Hi all,

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

      I am currently implementing a BACnet/DALI gateway and for this purpose the BACnet Lighting Object would come handy. However, there are some details, which I think could be improved:

      - 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, ...)
      - 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.
      - In addition to the Blink feature I would also suggest the following optional features:
      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.
      - 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

      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.

      If some of you are not familiar with the DALI protocol see http://www.dali-ag.org/.

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

      Best regards,

      Jörg

      --
      Joerg Broeker
      LOYTEC electronics GmbH
      Stolzenthalergasse 24/3
      A-1080 Wien
      Austria/Europe
      jbroeker@...
      www.loytec.com
      Phone: +43-1-4020805-16
      FAX: +43-1-4020805-99

      Networks under control!
      LOYTEC and NEC Electronics Join Forces in Building Automation!
    • 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 2 of 18 , Aug 8, 2006
        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/
      • 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 3 of 18 , Aug 8, 2006
          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 4 of 18 , Aug 9, 2006
            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 5 of 18 , Aug 9, 2006
              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 6 of 18 , Aug 9, 2006
                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 7 of 18 , Aug 10, 2006
                  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 8 of 18 , Aug 10, 2006
                    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 9 of 18 , Aug 28, 2006
                      Hi Steve,

                      Please find my comments below ...

                      --- In BACnetLighting@yahoogroups.com, Steve Karg <steve@...> wrote:
                      > The lighting vendors in the working group felt that the fade_time value
                      > as unsigned in seconds was plenty of resolution, and that was what
                      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 10 of 18 , Sep 5, 2006
                        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 11 of 18 , Sep 13, 2006
                          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 12 of 18 , Sep 16, 2006
                            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 13 of 18 , Sep 18, 2006
                              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 14 of 18 , Nov 8, 2006
                                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 15 of 18 , Nov 8, 2006
                                  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 16 of 18 , Nov 8, 2006
                                    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 17 of 18 , Nov 10, 2006
                                      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 18 of 18 , Nov 11, 2006
                                        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.