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

Re: Feedback DMF-011

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