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

Re: [BACnetLighting] Feedback DMF-011

Expand Messages
  • 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 1 of 18 , Sep 5, 2006
    View Source
    • 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 2 of 18 , Sep 13, 2006
      View Source
      • 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 3 of 18 , Sep 16, 2006
        View Source
        • 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 4 of 18 , Sep 18, 2006
          View Source
          • 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 5 of 18 , Nov 8, 2006
            View Source
            • 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 6 of 18 , Nov 8, 2006
              View Source
              • 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 7 of 18 , Nov 8, 2006
                View Source
                • 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 8 of 18 , Nov 10, 2006
                  View Source
                  • 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 9 of 18 , Nov 11, 2006
                    View Source
                    • 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.