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

Re: [BACnetLighting] Re: Feedback DMF-011

Expand Messages
  • 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 1 of 18 , Aug 9, 2006
    • 0 Attachment
      Hi Jörg,

      > > > o On_Delay (REAL, seconds) Off_Delay (REAL, seconds): If the
      > > > Present_Value is changed from 0 to some value greater than zero or
      > vice
      > > > versa the dim action is delayed for the time given in these
      > properties.

      These properties could be added, but I would suggest that they only
      affect the Present_Value via the Lighting_Command in order to be
      consistent. We should also consider:

      * the effect of client devices that write values constantly (i.e. update
      the value every 5 seconds), and the effect of multiple devices sending
      different values or commands.

      * can this feature also be accomplished from client device? Is there a
      case where it cannot?

      * what is the use-case for this?

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

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

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

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

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

      Regarding the "member of a group" idea, perhaps the DMF-030 and DMF-032
      proposals would be the better solution. The grouping suggested by those
      proposals allow grouping of any objects, not just Lighting Output
      objects. These have been discussed at the SSPC-135 BACnet committee,
      but did not gain consensus due to the similar STK-004 Multiplexer object
      that had been proposed by our working group. Can you review these
      proposals?

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

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

      Best Regards,

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

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

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

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

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

        Best Regards,

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

          please find my comments below ...

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

          I am not sure what you mean. As I understood the blink feature, it
          warns the occupants of a room that lights will go out soon, when the
          Present_Value was written to a value of zero.

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

          Best regards,

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

            > I am not sure what you mean. As I understood the blink feature, it
            > warns the occupants of a room that lights will go out soon, when the
            > Present_Value was written to a value of zero.

            The blink feature does warn the occupants of the room (or stairwell),
            but it also includes the auto-relinquish feature. If we add the ability
            to *not blink warn* then you get auto-relinquish without blinking.

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

            I guess it depends on the control paradigm that is used, and where the
            timeout timer resides.

            If the light switch is a smart BACnet light switch, it could command the
            lights on, and then command the lights off after a period of time.
            Nothing fancy is necessary on the lighting output device, only at the
            smart BACnet light switch. Multiple switches or other control devices
            could be used for that same lighting output by utilizing the
            auto-relinquish feature with or with out the blink warn.

            But what you are suggesting with auto-off is having a timer intrinsic to
            the Lighting Output object that will automatically relinquish after a
            period of time after the object is commanded on. Would the timer
            automatically reset when another non-zero Present-Value is received from
            the same switch or another device, perhaps another switch? What about
            the clients that write/poll a value continuosly for reliability? What
            about devices whose architicture only looks at change of value?

            I don't want to discourage necessary features. However, we should look
            at each feature and decide:

            1. Is there another way in BACnet (or in a proposal) to do this already?

            2. Minimal properties and services; duplication causes interoperiblity
            problems. If there are multiple ways to accomplish the same thing, then
            multiple ways will be used.

            3. For lighting control: can I create a distributed BACnet network and
            accomplish what I need? Can I do what I need to do using only BACnet
            objects, properties, and services? Will the components (switch, output)
            be interchangable, require minimal configuration, or only work if they
            are from the same vendor? (i.e. a smart BACnet light switch and a smart
            BACnet lighting output connected on a BACnet network)

            4. Can I do what I need to do in an economical manner? (i.e. forcing a
            RAM/ROM challenged device to implement WritePropertyMultiple in order to
            write several properties in a somewhat atomic manner)

            Best Regards,

            Steve
            --
            http://www.kargs.net/
          • jbroeker2712
            Hi Steve, Please find my comments below ... ... their ... Well, I guess all that is true for the Ramp_Rate (DALI Fade Rate) property as well. So why use REAL
            Message 5 of 18 , Aug 28, 2006
            • 0 Attachment
              Hi Steve,

              Please find my comments below ...

              --- In BACnetLighting@yahoogroups.com, Steve Karg <steve@...> wrote:
              > The lighting vendors in the working group felt that the fade_time value
              > as unsigned in seconds was plenty of resolution, and that was what
              their
              > existing systems did.
              >
              > Let's see what DALI offers. Fade Time in DALI is expressed as:
              > T=1/2(sqrt(2^x)) where x=1-15, 0=no fade.
              > 15 possible fade times:
              > 0.707, 1.0, 1.414, 2.00, 2.828, 4.000, 5.657, 8.000, 11.314, 16.000,
              > 22.627, 32.000, 45.255, 64.000, and 90.510.
              > DALI is using a value of 0 to 90 seconds.
              >
              > Practical issues (i.e. getting the output fade accurately to 3 decimal
              > places) and storage and encoding issues aside (i.e. REAL costs more in
              > bandwidth and storage than an unsigned in the range of 0-90), there is
              > no way to report the DALI Fade Time to 3 decimal places over BACnet
              > using the Lighting Output object unless the property is a REAL or a
              > proprietary property is used.
              >
              > I am not opposed to changing Fade_Time to REAL to be able to directly
              > support a DALI interface. Perhaps some other members of the working
              > group can express their opinions.

              Well, I guess all that is true for the Ramp_Rate (DALI Fade Rate)
              property as well. So why use REAL in one case and UNSIGNED in the
              other? I think this is kind of inconsistent.

              Further, I don't see the practical issues you mentioned above: The
              difference of the size of a REAL to UNSIGNED is how many bytes? If
              any? In any case compare to the size of a BACnet message/BACnet object
              its marginal. And there is no need to get the value accurately to 3
              decimal places. If the lighting object is mapped to a DALI device, the
              value has to be rounded to the next available DALI fade time value anyway.

              > > > > o On_Delay (REAL, seconds) Off_Delay (REAL, seconds): If the
              > > > > Present_Value is changed from 0 to some value greater than
              zero or
              > > vice
              > > > > versa the dim action is delayed for the time given in these
              > > properties.
              >
              > These properties could be added, but I would suggest that they only
              > affect the Present_Value via the Lighting_Command in order to be
              > consistent. We should also consider:
              >
              > * the effect of client devices that write values constantly (i.e.
              update
              > the value every 5 seconds), and the effect of multiple devices sending
              > different values or commands.
              >
              > * can this feature also be accomplished from client device? Is there a
              > case where it cannot?

              If there are multiple clients (like multiple smart switches), they do
              not know from each other. Thus the timers must run at the server, that
              is, the BACnet lighting object.

              > * what is the use-case for this?

              To be honest I don't know. I am not a light control expert. But I have
              some experience in the LonWorks field and I have looked at some
              controllers performing similar tasks in the LonWorks world. They
              usually have those configuration options (called SCPT in LonWorks). So
              I guess they must have some use? ;-) If you like I can try and find
              out ...

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

              I would say it applies to any situation where the present value
              changes from 0 to some value greater than zero (on delay) and vice
              versa (off delay).

              > Regarding the "member of a group" idea, perhaps the DMF-030 and DMF-032
              > proposals would be the better solution. The grouping suggested by
              those
              > proposals allow grouping of any objects, not just Lighting Output
              > objects. These have been discussed at the SSPC-135 BACnet committee,
              > but did not gain consensus due to the similar STK-004 Multiplexer
              object
              > that had been proposed by our working group. Can you review these
              > proposals?

              I will take a look at it.

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

              I will take a look at it.

              > > I am not sure what you mean. As I understood the blink feature, it
              > > warns the occupants of a room that lights will go out soon, when the
              > > Present_Value was written to a value of zero.
              >
              > The blink feature does warn the occupants of the room (or stairwell),
              > but it also includes the auto-relinquish feature. If we add the
              ability
              > to *not blink warn* then you get auto-relinquish without blinking.

              But "blink warn" is in effect BEFORE a transition TO 0 is eminent,
              while "auto-off" is in effect AFTER a transition FROM 0. So, confusing
              semantics asside, I don't understand how you want to use this feature
              for both.

              > I guess it depends on the control paradigm that is used, and where the
              > timeout timer resides.
              >
              > If the light switch is a smart BACnet light switch, it could command
              the
              > lights on, and then command the lights off after a period of time.
              > Nothing fancy is necessary on the lighting output device, only at the
              > smart BACnet light switch. Multiple switches or other control devices
              > could be used for that same lighting output by utilizing the
              > auto-relinquish feature with or with out the blink warn.

              How would this work with multiple switches, when the timer should be
              reset every time one of the switches is pressed (like in a typical
              staircase)? The different clients do not know about the timers in the
              other clients and have no means to reset those timers.

              > But what you are suggesting with auto-off is having a timer
              intrinsic to
              > the Lighting Output object that will automatically relinquish after a
              > period of time after the object is commanded on. Would the timer
              > automatically reset when another non-zero Present-Value is received
              from
              > the same switch or another device, perhaps another switch?

              Well I guess, for that purpose I would add a auto_off_mode property,
              which allows to configure the behavior in this case.

              > What about
              > the clients that write/poll a value continuosly for reliability? What
              > about devices whose architicture only looks at change of value?

              What kind of problems do you expect for those devices?

              > I don't want to discourage necessary features. However, we should look
              > at each feature and decide:
              >
              > 1. Is there another way in BACnet (or in a proposal) to do this already?

              No (multiple switches commanding same lighing object).

              > 2. Minimal properties and services; duplication causes interoperiblity
              > problems. If there are multiple ways to accomplish the same thing,
              then
              > multiple ways will be used.
              >
              > 3. For lighting control: can I create a distributed BACnet network and
              > accomplish what I need? Can I do what I need to do using only BACnet
              > objects, properties, and services? Will the components (switch,
              output)
              > be interchangable, require minimal configuration, or only work if they
              > are from the same vendor? (i.e. a smart BACnet light switch and a smart
              > BACnet lighting output connected on a BACnet network)

              Clients will become simpler. Configuration can be accomplished using
              standard BACnet mechanisms (properties) and not proprietory means
              (like in case the control mechanism is placed in the client). This
              allows to re-configure the system (e.g. staircase auto-off timer) in a
              standard way and thus using any standard operating workstation, which
              is a big benefit for the building owner/operator.

              > 4. Can I do what I need to do in an economical manner? (i.e. forcing a
              > RAM/ROM challenged device to implement WritePropertyMultiple in
              order to
              > write several properties in a somewhat atomic manner)

              Well, in the end every argument that justifies the blink warn feature
              can be put forward in favor of the auto off feature, since they both
              are a identical category of function.

              Maybe this function is rarely used in the US, but here in Europe it is
              a must-have-feature for any light control system (on the other hand I
              have never heard of blink warn) before. Having this heavily used
              standard function implemented in the lighting object has the
              advantange, that a very simple client without any controller
              functionality can be used to control the object.

              Best regards,

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

                Thank you for your insightful comments and discussion.

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

                1. change Fade_Time from Unsigned to REAL.

                2. add Power_On_Value

                From DALI:

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

                proposed BACnet:

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

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

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

                3. add System_Failure_Value

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

                From DALI:

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

                proposed BACnet:

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

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

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

                4. add On_Delay

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

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

                12.X.32 On_Delay

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

                [change 12.X.4 Present_Value]

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

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

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

                == Discussion ==

                > But "blink warn" is in effect BEFORE a transition TO 0 is eminent,
                > while "auto-off" is in effect AFTER a transition FROM 0. So, confusing
                > semantics asside, I don't understand how you want to use this feature
                > for both.

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

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

                > How would this work with multiple switches, when the timer should be
                > reset every time one of the switches is pressed (like in a typical
                > staircase)? The different clients do not know about the timers in the
                > other clients and have no means to reset those timers.

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

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

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

                Thoughts? Did I miss anything?

                Best Regards,

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

                  please find my comments below ...

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

                  OK with me.

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

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

                  I would add:

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

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

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

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

                  I would add:

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

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

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

                  > 5. Change Blink Warning Behavior to support an Off Delay:
                  >
                  > [add to 12.X.11.1 Blink Warning Behavior]
                  > When Blink_Time is zero and Present_Value becomes 0%, the lights shall
                  > remain on and not blink for up to Blink_Delay seconds.
                  >
                  > == Discussion ==
                  >
                  > > But "blink warn" is in effect BEFORE a transition TO 0 is eminent,
                  > > while "auto-off" is in effect AFTER a transition FROM 0. So, confusing
                  > > semantics asside, I don't understand how you want to use this feature
                  > > for both.
                  >
                  > To support Off Delay, set the Blink_Delay equal to the amount of time
                  > that you want Off_Delay to be. Set Blink_Time to zero. When the
                  > Present_Value transitions from non-zero to zero, then the lights remain
                  > on for Blink_Delay seconds, and automatically relinquish at the end of
                  > Blink_Delay.
                  >
                  > Perhaps changing the words Blink_Delay in DMF-011-9 to use the words
                  > Off_Delay would make things clearer. They are the same thing.

                  That is ok with me.

                  > > How would this work with multiple switches, when the timer should be
                  > > reset every time one of the switches is pressed (like in a typical
                  > > staircase)? The different clients do not know about the timers in the
                  > > other clients and have no means to reset those timers.
                  >
                  > I agree that the timer should reside in the Lighting Output objects.
                  >
                  > I would say that the switches would have to send to the Lighting Output
                  > a non-zero value followed by a zero value, similar to what a maintained
                  > switch input would send. Or, when the switch is pressed, a non-zero
                  > value is sent to the Lighting Output object; when the switch is
                  > released, a zero value is sent to the Lighting Output object.
                  >
                  > Or the wall switch could simply send a Lighting_Command with the
                  > Duration field populated.

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

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

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

                  Best regards,

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

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

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

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

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

                    Yes, it should.

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

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

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

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

                    Best Regards,

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

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

                      Best regards,

                      Jörg

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

                        > o On_Delay (REAL, seconds) Off_Delay (REAL, seconds): If the
                        > Present_Value is changed from 0 to some value greater than zero or vice
                        > versa the dim action is delayed for the time given in these properties.

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

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

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

                        Best Regards,

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

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

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




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

                          11/08/2006 10:45 AM

                          Please respond to
                          BACnetLighting@yahoogroups.com

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





                          Hi Jörg (and other interested parties),

                          > o On_Delay (REAL, seconds) Off_Delay (REAL, seconds): If the
                          > Present_Value is changed from 0 to some value greater than zero or
                          vice
                          > versa the dim action is delayed for the time given in these properties.

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

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

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

                          Best Regards,

                          Steve Karg
                          Lithonia Lighting


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

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

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

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

                            Best Regards,

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

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

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

                              Best regards,

                              Jörg

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

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

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

                                Hence, I see value in keeping this Property.

                                Best regards,
                                Hans J. Langels

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

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

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

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

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


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

                                Hi Steve,

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

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

                                Best regards,

                                Jörg

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

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





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

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

                                To subscribe to this group, send an email to:

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