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

Comments regarding Lighting Output Object proposal

Expand Messages
  • Joerg
    Hi all, I had a look at the current draft of the Lighting Output Object (Add-135-2008i-PPR5-Draft_rk_1.doc). First of all I d like to say I really like what
    Message 1 of 5 , Dec 1, 2010
    • 0 Attachment
      Hi all,

      I had a look at the current draft of the Lighting Output Object
      (Add-135-2008i-PPR5-Draft_rk_1.doc).

      First of all I'd like to say I really like what you have done so far. Specifically the solution for the commands using the extended command priorization sounds like a great idea.

      However, I have a few points, where I do not understand the rational behind the proposal or where I think something is missing from my perspective (in no particular order):

      1) When the Object is mapping to a DALI ballast the standard DALI registers should be available via properties (Min_Level, Max_level, Power_On_Level, System_Failure_Level, Group Configuration). I have seen Power_On_Level and System_Failure_Level were in the previous
      version of the proposal, but were removed.

      2) There should be means to provide detailed errors. Besides the standard dali errors lamp failure and ballast failure the new DALI device types have a lot additional error states (e.g. battery failure or failed function and duration tests for self-contained emergency,
      overload, thermal shutdown, etc.).

      3) There should be means to provide scene control. One way would be to extend the Lighting_Command property (store_scene, recall_scene, delete_scene with scene number as argument).

      4) What is the rational for using a normalized range? Why not define 0 as off and everything between Min_Actual_Value and Max_Actual_Value as on? DALI lights can have a Min_Actual_Value below 1%.

      5) There should be a property to select the dimming mode when writing to Present_Value (ramping or fading), possibly even for each priority slot. Fade_Time and Ramp_Rate respectively should be used when writing to Present_Value.

      6) What is the purpose of the Binary_Present_Value and Binary_Active_Level? In DALI a light not capable of dimming is defined by Min_Actual_Value equal to Max_Actual_Value.

      7) For Fade_Time and Ramp_Rate on DALI devices only certain values are allowed (e.g. fade time = no fade, 0.7 s, 1.0 s, etc.). To allow mapping this should be considered.

      8) As for self-contained emergency lights, there should be means to trigger the build in self-tests (function/duration). Further, the battery charge should be available. This is a requirement I have seen recently with our DALI controllers.

      9) Another requirement I often get is accumulated energy usage similar to the Elapsed_Active_Time property (incl. option to reset).

      10) There should be means to trigger a Burn-In feature, where the lamp must not be dimmed for a certain time. That is, it can be only switched to off or to 100% until a certain run-hours is reached (typ. ~100h).

      11) A feature often required is an Auto-Relinquish after certain time (for applications like staircase lighting).

      12) One question that arises when it comes to DALI is how to deal with "DALI local control" (e.g. DALI buttons, etc.). One way would be to "reserve" a certain priority for that: If the active priority is higher the BACnet device instantly overrides the command issued by some other DALI master. The concept could be extended to any kind of "local" override. In any case I think this needs further consideration.

      I hope my explanations are good enough to understand what I mean (I kept them as short as I could possibly do).

      What do you think?

      Best regards,

      Jörg
    • Kaelin, Rene
      Jörg, Thanks for the positiv feedback for the extended command priorisation. At the moment there is no consensus in LA-WG about integration of extended
      Message 2 of 5 , Dec 2, 2010
      • 0 Attachment
        [BACnetLighting] Comments regarding Lighting Output Object proposal

        Jörg,
        Thanks for the positiv feedback for the extended command priorisation. At the moment there is no consensus in LA-WG about integration of extended command priorisation. So Add-135-2008i-PPR5-Draft_rk_1.doc is not in discussion in the LA-WG. It was intended so show how the Lighting Output object would look like with extended command priorisation.

        My answers to your questions:
        In general, the lighting output object shall allow to control a dimmable lamp. It is not the 'Dali-gateway' object. Also other controls for dimmed lamps shall be represented by the Lighting-Output object even a not dimmable (binary) lamp could be an option. This allows to control lights by a generalized/abstract interface over BACnet, the Lighting Output object .

        1) 'Dali registers' could be made available if the information is common for lighting.
        2) Dali errors could be specified if they are common for lighting
        3) Yes, specific commands to store and recall several light levels could be considered
        4a) The normalize range allows to be independent of the physical dimming range. 50% could be 60% for a specific ballast of control. To control multiple lamps the value should not depend on the specific lamp.
        4b) It could be considered also to use the range >0 to 1% for the normalized range.
        5) A write to PresentValue is in general independent of the command which is sent to the ballast. It is in discussion to have a property to specify a default command (e.g. fade, ramp, goto).
        6) If a binary actuator is controlled by the object this property allows to specify the behavior. At the moment this properties are removed from the object.
        7) The mapping of the object fade time to the Dali fade time is local matter and should happen in the 'driver' to the ballast.
        8) This should be done by additional objects. In general a light has no battery state or a test.
        9) To have properties which shows accumulated energy could be considered
        10) To have a Burn-In feature coupled with Eleapsed_Active_Time could be considered. At least the state 'Burn-In-Phase' should be available.
        11) It is in discussion to include an 'Auto-Relinquish'-Parameter in the Lighting-Command.
        12) This is out of scope for a general Lighting Output object. This mixes input and output and makes specific DALI control logic visible in the object.

        I hope that my (very) short answers are also understandable.
        Mit freundlichen Grüssen
        René Kälin
        Siemens Switzerland Ltd.
        Industry Sector
        Building Technologies Division
        International Headquarters
        Control Products & Systems
        I BT HVP CPS GDT EU SSE SD
        Gubelstrasse 22
        6301 Zug

        Tel +41 41 724 32 32
        rene.kaelin@...


        Hi all,

        I had a look at the current draft of the Lighting Output Object
        (Add-135-2008i-PPR5-Draft_rk_1.doc).

        First of all I'd like to say I really like what you have done so far. Specifically the solution for the commands using the extended command priorization sounds like a great idea.

        However, I have a few points, where I do not understand the rational behind the proposal or where I think something is missing from my perspective (in no particular order):

        1) When the Object is mapping to a DALI ballast the standard DALI registers should be available via properties (Min_Level, Max_level, Power_On_Level, System_Failure_Level, Group Configuration). I have seen Power_On_Level and System_Failure_Level were in the previous
        version of the proposal, but were removed.

        2) There should be means to provide detailed errors. Besides the standard dali errors lamp failure and ballast failure the new DALI device types have a lot additional error states (e.g. battery failure or failed function and duration tests for self-contained emergency,
        overload, thermal shutdown, etc.).

        3) There should be means to provide scene control. One way would be to extend the Lighting_Command property (store_scene, recall_scene, delete_scene with scene number as argument).

        4) What is the rational for using a normalized range? Why not define 0 as off and everything between Min_Actual_Value and Max_Actual_Value as on? DALI lights can have a Min_Actual_Value below 1%.

        5) There should be a property to select the dimming mode when writing to Present_Value (ramping or fading), possibly even for each priority slot. Fade_Time and Ramp_Rate respectively should be used when writing to Present_Value.

        6) What is the purpose of the Binary_Present_Value and Binary_Active_Level? In DALI a light not capable of dimming is defined by Min_Actual_Value equal to Max_Actual_Value.

        7) For Fade_Time and Ramp_Rate on DALI devices only certain values are allowed (e.g. fade time = no fade, 0.7 s, 1.0 s, etc.). To allow mapping this should be considered.

        8) As for self-contained emergency lights, there should be means to trigger the build in self-tests (function/duration). Further, the battery charge should be available. This is a requirement I have seen recently with our DALI controllers.

        9) Another requirement I often get is accumulated energy usage similar to the Elapsed_Active_Time property (incl. option to reset).

        10) There should be means to trigger a Burn-In feature, where the lamp must not be dimmed for a certain time. That is, it can be only switched to off or to 100% until a certain run-hours is reached (typ. ~100h).

        11) A feature often required is an Auto-Relinquish after certain time (for applications like staircase lighting).

        12) One question that arises when it comes to DALI is how to deal with "DALI local control" (e.g. DALI buttons, etc.). One way would be to "reserve" a certain priority for that: If the active priority is higher the BACnet device instantly overrides the command issued by some other DALI master. The concept could be extended to any kind of "local" override. In any case I think this needs further consideration.

        I hope my explanations are good enough to understand what I mean (I kept them as short as I could possibly do).

        What do you think?

        Best regards,

        Jörg

      • Joerg
        Hi Rene, Thanx for your reply. Please find my responses below... ... I think the extended command priorisation is a good idea, since such an extension is also
        Message 3 of 5 , Dec 3, 2010
        • 0 Attachment
          Hi Rene,

          Thanx for your reply. Please find my responses below...

          --- In BACnetLighting@yahoogroups.com, "Kaelin, Rene" <rene.kaelin@...> wrote:

          > Thanks for the positiv feedback for the extended command priorisation. At the moment there is no consensus in LA-WG about integration of extended command priorisation. So Add-135-2008i-PPR5-Draft_rk_1.doc is not in discussion in the LA-WG. It was intended so show how the Lighting Output object would look like with extended command priorisation.

          I think the extended command priorisation is a good idea, since such an extension is also required for other applications, like e.g. sunblinds.

          > My answers to your questions:
          > In general, the lighting output object shall allow to control a dimmable lamp. It is not the 'Dali-gateway' object. Also other controls for dimmed lamps shall be represented by the Lighting-Output object even a not dimmable (binary) lamp could be an option. This allows to control lights by a generalized/abstract interface over BACnet, the Lighting Output object.

          I am well aware, that it is not a DALI gateway object, but
          a) I guess it will be used with DALI quite often and therefore should be suitable for such applications and
          b) the configuration options and features defined for DALI are based on requirements from the lighting industry and have proven to be suitable for such applications (well, I know you can discuss that).
          I gave the references to DALI mainly to show what features/properties a DALI system offers.

          Further, I think, if it is a simple non dimmable light (relay?) it could be represented by a binary output object, since in this case most (all?) of the extensions the lighting object provides will not be used. So from my point of view, the lighting object should be geared more towards applications/features which cannot be covered by existing objects.

          > 4a) The normalize range allows to be independent of the physical dimming range. 50% could be 60% for a specific ballast of control. To control multiple lamps the value should not depend on the specific lamp.

          I still do not see the point for a normalized range. Specifically since 0%-100% always is a "relative" value as it does not give you the "light output" of the lamp. Sometimes even different dimming curves are used (logarithmic vs. linear). So if you have different lamp types (wattage/technology) in one group they will not show the same luminosity at a certain percentage value. I think a normalized range will only make things more complicated, less intuitive for the system integrator, and takes away the option for the ballast/lamp/controller vendor to define the dimming behavior.

          > 5) A write to PresentValue is in general independent of the command which is sent to the ballast. It is in discussion to have a property to specify a default command (e.g. fade, ramp, goto).

          I am not think in terms of command, but in terms of the dimming mode used (fixed time or constant rate).

          > 7) The mapping of the object fade time to the Dali fade time is local matter and should happen in the 'driver' to the ballast.

          Understood. I just wanted to point out, that this fact should be considered in the description of that properties (e.g. "If the configured Fade_Time value is not supported by the output, the closest available Fade_Time value must be used." instead of "The minimum resolution of Fade_Time shall be 100ms.").

          > 12) This is out of scope for a general Lighting Output object. This mixes input and output and makes specific DALI control logic visible in the object.

          OK, I guess here my rational was too short :-). What I wanted to point out, that in general there often is a "local" way to control the light (e.g. a hard wired switch or similar). Other than override, this usually should take place at a certain (BACnet) priority. Local DALI control is just one way of such a "local" control. I just wanted to add this to the discussion, to be aware of this application scenario and to consider it when defining the Lighting Output Object.

          > I hope that my (very) short answers are also understandable.

          Yes they were.

          Best regards,

          Jörg

          --
          Dipl.-Ing. Jörg Bröker

          Phone: +43 (1) 4020805-0
          Fax: +43 (1) 4020805-99

          LOYTEC electronics GmbH
          Blumengasse 35
          1170 Wien
          Austria/Europe
          www.loytec.com

          Sitz: Wien, FN182801a HG Wien
        • Isler, Bernhard
          Hi all, Let me throw the following into this discussion: Those that attended the last couple of SSPC and WN-WG meetings saw lengthy debates on the purpose and
          Message 4 of 5 , Dec 3, 2010
          • 0 Attachment
            Hi all,

            Let me throw the following into this discussion:

            Those that attended the last couple of SSPC and WN-WG meetings saw lengthy debates on the purpose and usefulness of standard mappings of other protocols to BACnet. In the Atlanta meeting end of October this year, there was consensus that there should not be standard mappings of such protocols. The directions to follow are to finalize and release gateway best practices, and to define application profiles for standard application functionality.

            Gateway best practices is intended to cover some general topics on how to build gateways. This is on a generic level, not related to a particular foreign protocol. For reference see the current draft CN-088-5 (see Files section of this group).

            Application profiles is a new level of standardization of application functionality interfaces. This is in work since a while in the AP-WG. The purpose is that applications represent their functionality in a standardized way. And very important, applications can use these interfaces, no matter how this functionality is implemented. The implementation may be a native BACnet product, or a gateway to some non-BACnet protocol. Today both types of implementations just provide an arbitrary set of objects and properties, and it is up to the client to be engineered accordingly to make meaningful use of these. Another effect of application profiles is that they provide highler level semantic information. As an example, a Variable Frequency Drive becomes visible as this, not just through some vendor defined set of objects and properties.

            Why do I bring this up here?

            It appears to me that some points brought up are a clear sign that lighting should consider the definition of application profiles. It does not really help to put more and more stuff into a single object, until it bursts. This would be an attempt to make a single standard object type to represent products that are continuously evolving with more and different features added. An object is not the proper container for this. Multiple objects should be used, as per the effective set of the functions of the product.
            In order to facilitate the integration, application profiles should be defined. There may be a number of abstract and standardized lighting application profiles. Object types should be used to define elementary abstract functionality only. There may be reuse of such elementary functionality in other domains even.

            I can see two groups of potential application interfaces:

            1) Standardized application interfaces such as Binary Lights, Dimmable Lights, Color Lights, Emergency Lights, etc. These are completely agnostic to the underlying implementation. May they be wire controlled lights, DALI ballasts, DMX lamps, KNX lights, or even native BACnet lights (if in the market ever). The standardization of these profiles should be in the scope of the BACnet committee, and its LA-WG.

            2) Standardized application interfaces that define access through BACnet to functionality that is specific to the underlying implementation, such as DALI configuration profiles. The standardization of such may be done by the respective alliance.

            To conclude: Any extra features of a particular lighting system or product should not be added to the Lighting Output object type. The Lighting Output should be reduced and focused as far as reasonable to dimmable single color lighting functionality that is not feasible using current object types. Any additional features should be represented using additional objects. Application profiles should be made available and implemented for simplified and implementation-agnostic integration.

            Comments and dicussion is very welcome.

            Best,
            Bernhard



            Bernhard Isler
            Siemens Switzerland Ltd
            Building Technologies Division


            -----Original Message-----
            From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] On Behalf Of Joerg
            Sent: Wednesday, December 01, 2010 11:55 PM
            To: BACnetLighting@yahoogroups.com
            Subject: [BACnetLighting] Comments regarding Lighting Output Object proposal

            Hi all,

            I had a look at the current draft of the Lighting Output Object
            (Add-135-2008i-PPR5-Draft_rk_1.doc).

            First of all I'd like to say I really like what you have done so far. Specifically the solution for the commands using the extended command priorization sounds like a great idea.

            However, I have a few points, where I do not understand the rational behind the proposal or where I think something is missing from my perspective (in no particular order):

            1) When the Object is mapping to a DALI ballast the standard DALI registers should be available via properties (Min_Level, Max_level, Power_On_Level, System_Failure_Level, Group Configuration). I have seen Power_On_Level and System_Failure_Level were in the previous
            version of the proposal, but were removed.

            2) There should be means to provide detailed errors. Besides the standard dali errors lamp failure and ballast failure the new DALI device types have a lot additional error states (e.g. battery failure or failed function and duration tests for self-contained emergency,
            overload, thermal shutdown, etc.).

            3) There should be means to provide scene control. One way would be to extend the Lighting_Command property (store_scene, recall_scene, delete_scene with scene number as argument).

            4) What is the rational for using a normalized range? Why not define 0 as off and everything between Min_Actual_Value and Max_Actual_Value as on? DALI lights can have a Min_Actual_Value below 1%.

            5) There should be a property to select the dimming mode when writing to Present_Value (ramping or fading), possibly even for each priority slot. Fade_Time and Ramp_Rate respectively should be used when writing to Present_Value.

            6) What is the purpose of the Binary_Present_Value and Binary_Active_Level? In DALI a light not capable of dimming is defined by Min_Actual_Value equal to Max_Actual_Value.

            7) For Fade_Time and Ramp_Rate on DALI devices only certain values are allowed (e.g. fade time = no fade, 0.7 s, 1.0 s, etc.). To allow mapping this should be considered.

            8) As for self-contained emergency lights, there should be means to trigger the build in self-tests (function/duration). Further, the battery charge should be available. This is a requirement I have seen recently with our DALI controllers.

            9) Another requirement I often get is accumulated energy usage similar to the Elapsed_Active_Time property (incl. option to reset).

            10) There should be means to trigger a Burn-In feature, where the lamp must not be dimmed for a certain time. That is, it can be only switched to off or to 100% until a certain run-hours is reached (typ. ~100h).

            11) A feature often required is an Auto-Relinquish after certain time (for applications like staircase lighting).

            12) One question that arises when it comes to DALI is how to deal with "DALI local control" (e.g. DALI buttons, etc.). One way would be to "reserve" a certain priority for that: If the active priority is higher the BACnet device instantly overrides the command issued by some other DALI master. The concept could be extended to any kind of "local" override. In any case I think this needs further consideration.

            I hope my explanations are good enough to understand what I mean (I kept them as short as I could possibly do).

            What do you think?

            Best regards,

            Jörg




            ------------------------------------

            ======================================================
            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.comYahoo! Groups Links
          • Steve Karg
            Hi Joerg, Thank you for reviewing our continuing work on Lighting Applications. Your insightful comments have spawned some interesting discussions which I hope
            Message 5 of 5 , Dec 3, 2010
            • 0 Attachment
              Hi Joerg,

              Thank you for reviewing our continuing work on Lighting Applications.
              Your insightful comments have spawned some interesting discussions
              which I hope will lead to some fast solutions.

              I just wanted to answer your questions about one item.

              > 4) What is the rational for using a normalized range? Why not define 0 as off and everything between Min_Actual_Value and Max_Actual_Value as on? DALI lights can have a Min_Actual_Value below 1%.

              A normalized range allowed us to remove a lot of confusing and extra
              language in PPR3 that defined the various lighting features. As for
              1% - it makes a single minimum value that can be the lowest value the
              output can go (i.e. 0.1 or 0.001, or 0.00001 - which do I use for each
              vendor?).

              Some problems with a non-normalized range happen when you try to ramp
              or fade. For example, if you have a High Limit value at 80%, and the
              fade starts at 100%, finally at 80% actually begins to fade the light
              level. With a normalized range, the fade begins immediately at the
              100% (which is really 80%).

              DALI escapes this complexity by using steps instead of a floating value percent.

              There are probably more details about this particular idea from the
              BACnet - Lighting Applications Working Group Meeting Minutes of
              January 21, 2010, in Orlando, Florida (LA030-1.doc).

              Best Regards,

              Steve
              --
              http://steve.kargs.net/
            Your message has been successfully submitted and would be delivered to recipients shortly.