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

RE: [BACnetLighting] Two general questions for Lighting Control

Expand Messages
  • David Ritter
    Hi All, Those are good questions Rene. Let me see if I can shed some light on the issues. 1) BACnet Schedule: First, as pointed out by Bernhard Isler in
    Message 1 of 5 , Feb 28, 2011
    • 0 Attachment

      Hi All,

       

      Those are good questions Rene. Let me see if I can shed some light on the issues.

       

      1) BACnet Schedule:

      First, as pointed out by Bernhard Isler in comment BI13  (Critical: The Schedule Object Type does not allow to write constructed data! It can deal with primitive data types only. See 12.24.4 BACnetTimeValue. So it cannot write to Lighting_Command properties! All Schedule operations have to go to Present_Value!) the schedule cannot directly write to the lighting object Lighing_Command property. It can write to the Present_Value of the lighting output object but will be unable to send a blink warn or send a command that can auto relinquish.

       

      Assuming that the BACnet schedule writes to the Present_Value of the Lighting Output object it would be unlikely that a single schedule would write to every lighting output object especially if the lighting outputs were distributed over multiple devices – you would expect significant propagation delays resulting in the lighting turning on in a sequential manner. For this reason we came up with the Channel object (addendum 135 2008aa – not yet in public review) which allows a single write to propagate to multiple objects.

       

      Alternatively, the schedule could write to a BV or AV object which could then be translated into a lighting command such as GOTO, FADETO, RELINQUISH, etc. This would be a proprietary mapping.

       

      2) Switches:

      We have discussed this briefly in the meetings. There are a number of different scenarios depending on the type of switch and the environment.

       

      In my office there is a light switch with two buttons; one of for OFF and one for ON which is fairly typical in office situations.  If I press the ON button during the day it may have no effect since the lights are already in an ON state. However, it may always write ON (100%) for a period of 2 hours at a higher priority than the current scheduler is writing at. If this is the case it will have no visual effect since it is not changing the state of the physical lights. Your switch may have a mode associated with it (i.e., Normal and After Hours modes) which will cause it to operate differently. If I press the OFF button during the day it may send an OFF (0%) at a priority higher than the schedule for 8 hours to ensure the lights will remain off for the remainder of the day.  Again, this switch may use modes to have it operate differently at different times of the day.

       

      You may also have a single switch that toggles the lights between  the ON and OFF states (or cycles the lights through different presets). In this case the switch must read the current value of the lighting output to know which command to send.

       

      If the switch did have a mode it would likely get changed by a schedule according to the time of day.

       

      There are a number of things to discuss at tomorrows telco so I will add these issues to the list.

       

      Regards,

      David

       

      From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] On Behalf Of Kaelin, Rene
      Sent: Monday, February 28, 2011 6:28 AM
      To: BACnetLighting@yahoogroups.com
      Subject: [BACnetLighting] Two general questions for Lighting Control

       

       

      Hello all

      In the next Telco I would like to discuss two general questions which came up to me reading DHR-019-02.

      1) Assuming the Scheduler on Priority 9 is a BACnet scheduler object on a central device in a building.
      Is it supposed that this schedule object has an entry in the property List_Of_Object_Property_Reference for each of the (e.g. several hundred) Lighting Output objects in the building?

      If not, what does a BACnet scheduler object control exactly?

      2) Assuming the lights in a room are controlled by a modern lighting control system.
      Is it really true that after a blink warning the user has to press the 'Timer-Switch' to keep the lights on and for normal use it has to use an 'OnOff-Switch' to control the lights? Are there really different kind of switches for different situations in a room?

      If not, who does change the meaning of 'the switch was pressed'?

      Regards

      René Kälin

    • Christoph Zeller
      Hi folks, as I am not in the office I will not be able to take part in the telco. Thougs about using automatic relinquish for handling the case with multiple
      Message 2 of 5 , Feb 28, 2011
      • 0 Attachment
        Hi folks,
        as I am not in the office I will not be able to take part in the telco.

        Thougs about using automatic relinquish for handling the case with multiple switches.

        The lighting output object is analog by nature, so if you you want to be able to model scenes basically a lighting output object per physical output is required.
        If you are modelling multiple outputs with only one lighting output you cannot control different light levels in this zone.

        If you have multiple switches controlling the same lights I assume that in almost all cases you will have a larger zone and therefore using multiple lights.
        (This is the case because a simple light will only allow a small zone, where a single switch seems enough)

        What does this mean.

        If you hae a room consisting of 20 lights and 4 "parallel" switches as an example:

        You have 20 light outputs (most likely distributed over only a few controllers (1-2)).
        You have 4 switches controlling these lights.

        If a switch is pressed, the switch would have to write to 20 lights (how many targets can you program into a switch?)
        20 writes on a slower network creates two additional problems.
        a) you will most likely see a delay (on MSTP you might only be able to send a few commands per second).
        b) you are consuming (wasting) a lot of bandwith that would not be needed if the receiving devices had an internal control logic.
        c) in the receiving device you are monitoring 20 timers that all expire simultaneously (so only one timer is actually required)
        d) you pay the price in each lighting output object even so you still need a external (non standardized control logic)
        e) using a external control logic overrides any internal control logic.


        Using light fades and ramps

        If you mandate to support long fade and ramps I'd like to consider the following:
        - The longer your fades and ramps are taking, the less timing critical they are.
        - The longer your fades and ramps the more you see the difference when aborting commands (and thus jumping to the end immediately).
        - This is not a real problem if the fade would have taken 10 seconds, but if you try to simulate a whole day you are now jumping from 7AM to 1PM because
        of a higher priority interrupt.
        - In areas that really long fades are needed you will most likely simulate a normal day.
        - But the day is not linear, so additional logic would be needed
        - Fades longer than a few seconds are not used frequently
      • David Fisher
        LA-WG This morning s conference we discussed the Channel object and WriteGroup service in the context of using them to write to the LO object Lighting_Command
        Message 3 of 5 , Mar 1, 2011
        • 0 Attachment

          LA-WG

           

          This morning's conference we discussed the Channel object and WriteGroup service in

          the context of using them to write to the LO object Lighting_Command property.

          I was tasked with researching this.

           

          In reviewing Add-135-2008aa-PPR1-6 it is clear that the Channel object, as currently

          crafted, only supports writing to Primitive datatyped properties. So the constructed

          datatype needed for Lighting_Command, as currently written, cannot be used

          with the proposed Channel object.

           

          Similarly, the WriteGroup service, as currently written, now only supports

          primitive data for the written value(s).

           

          I think on reflection that this is a problem that we must reconsider. There are various

          ways to handle this. Although the Channel object and WriteGroup could be

          reformulated to allow broader datatypes, it's my belief that this will meet

          stiff resistance as there is already a consensus that lead to the current proposals.

           

          We could, of course, not attempt to make any change to the LO object which

          would mean that Channel object and WriteGroup could only be used to

          write to Present_Value. I think this would be a major compromise in the

          ability of this suite of objects and service to meet the needs and use cases

          for Lighting however.

           

          So I believe that a better direction would be to rethink the concept of the

          Lighting_Command to allow it to be served by Channel object and WriteGroup,

          as already proposed in 135-2008aa. To that end, the Charstring and Octetstring

          datatypes come to mind. We could define a fixed position datatype (like Date and Time)

          as an Octetstring and use it for Lighting_Command instead of the new

          constructed datatype currently proposed. However, this is awkward and inflexible.

          The Charstring seems more naturally suited to this task.

           

          I know this is going to be controversial, but it may be the best compromise.

          I raise these issues because now that we are revising the LO object for its

          public review, it would be better to introduce this idea now instead of later.

          I'd like to add this to our crowded agenda for the 15th telecon.

           

          David Fisher

          PolarSoft® Inc.

          914 South Aiken Ave

          Pittsburgh PA 15232-2212

          dfisher@...

          www.polarsoft.biz

          412-683-2018

          412-683-5228 fax

           

          _,_._,___

        • David Ritter
          Hi All, I ve been thinking about this issue for the last couple of days and would concur with Dave Fisher that we need to make changes to allow a write to the
          Message 4 of 5 , Mar 4, 2011
          • 0 Attachment

            Hi All,

             

            I’ve been thinking about this issue for the last couple of days and would concur with Dave Fisher that we need to make changes to allow a write to the lighting command to propagate throughout a site using the Channel object and the WriteGroup service. It will be much easier to change the Lighting Command datatype than to change the Channel and WriteGroup.

             

            Writing to the lighting command directly from a BACnet schedule object will be a challenging task as most implementations of schedules and the UI’s to configure them will only accept a reduced set of primitive data types – generally not CharacterString nor OCTET STRING datatypes. However, a schedule could write to a Command object (or some other entity) which in turn could write to the Lighting Output object. As Rene has pointed out, it is unlikely that a single BACnet schedule would write to every lighting output object individually in the site. Rather, it is more likely that a schedule would write to a Channel object which would then propagate the command to all the affected lighting output objects.

             

            With regards to the previous discussion there are a couple of options that we can consider:

             

            1. Pack the Lighting Command into an Unsigned32:

             

            This could be done in the following way:

                            Bits 1..5 (5 bits) – lighting command operation (32 possible operations)

                            Bits 6..10 (5 bits) – priority (1…16, except 6)

                            Bits 11..20 (10 bits) – operation value (level, Ramp Rate, Fade Time, Step Increment – depending on operation)

                            Bits 21..30 (10 bits) – duration in minutes (max 17.8 hours)

                            Bits 31, 32 (2 bits) – transition (00 = normal, 01 = ramp, 10 = fade)

             

            This method would work and has the advantage that it could be written by any legacy BACnet schedule as it is simply a 32 bit unsigned. The downside is that this is essentially a hack and the actual command would be cryptic until it was deconstructed into its component parts. This method would also require that you have a specific command whenever you wanted a blink warn (e.g., GOTO, GOTO_WARN, RAMP_TO, RAMP_TO_WARN, etc). The operation value would only be 10 bits which would work well for Level, Ramp Rate and Step Increment but would limit the Fade Time to a maximum of 1000 tenths of seconds (unless the default fade time was used).

             

            2. Use the OCTET STRING datatype:

             

            If we change the Lighting_Command datatype to use be an OCTET STRING of size 9, then we can accommodate all the fields of the lighting command as it is specified now.

             

            It would be done as follows:

                            Octet 1:  lighting command

                            Octet 2: priority (1..16, except 6), X’FF’ = use default priority

                            Octet 3 + 4: operation value ( level, ramp rate, fade time, step increment) , X’FFFF’  = use default value for operation

                            Octet 5+ 6: duration in seconds (18.2 hours max), X’FFFF’ = use default duration

                            Octet 7+8: warn time in seconds (18.2 hours max), X’FFFF’ = use default warn time

                            Octet 9: transition when value relinquished

             

            This method would make all lighting commands have a fixed size but it would give the same functionality as the current lighting command has. More importantly, it would be useable by the Channel object and WriteGroup service without having to change either. The operation values would all be integer values rather than real (Level = tenths of percent, Ramp Rate = tenths of percent, Step Increment = tenths of percent). These would have to be converted to a real number when applied to the Present Value, but the resolution should be sufficient to achieve the desired functionality.

             

            I  will make changes to DHR-019 to incorporate method 2 and send it out to the group before the next telco.

             

            Best Regards,

             

            David

             

            From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] On Behalf Of David Fisher
            Sent: Tuesday, March 01, 2011 11:22 AM
            To: BACnetLighting@yahoogroups.com
            Subject: [BACnetLighting] Channel object and WriteGroup

             

             

            LA-WG

             

            This morning's conference we discussed the Channel object and WriteGroup service in

            the context of using them to write to the LO object Lighting_Command property.

            I was tasked with researching this.

             

            In reviewing Add-135-2008aa-PPR1-6 it is clear that the Channel object, as currently

            crafted, only supports writing to Primitive datatyped properties. So the constructed

            datatype needed for Lighting_Command, as currently written, cannot be used

            with the proposed Channel object.

             

            Similarly, the WriteGroup service, as currently written, now only supports

            primitive data for the written value(s).

             

            I think on reflection that this is a problem that we must reconsider. There are various

            ways to handle this. Although the Channel object and WriteGroup could be

            reformulated to allow broader datatypes, it's my belief that this will meet

            stiff resistance as there is already a consensus that lead to the current proposals.

             

            We could, of course, not attempt to make any change to the LO object which

            would mean that Channel object and WriteGroup could only be used to

            write to Present_Value. I think this would be a major compromise in the

            ability of this suite of objects and service to meet the needs and use cases

            for Lighting however.

             

            So I believe that a better direction would be to rethink the concept of the

            Lighting_Command to allow it to be served by Channel object and WriteGroup,

            as already proposed in 135-2008aa. To that end, the Charstring and Octetstring

            datatypes come to mind. We could define a fixed position datatype (like Date and Time)

            as an Octetstring and use it for Lighting_Command instead of the new

            constructed datatype currently proposed. However, this is awkward and inflexible.

            The Charstring seems more naturally suited to this task.

             

            I know this is going to be controversial, but it may be the best compromise.

            I raise these issues because now that we are revising the LO object for its

            public review, it would be better to introduce this idea now instead of later.

            I'd like to add this to our crowded agenda for the 15th telecon.

             

            David Fisher

            PolarSoft® Inc.

            914 South Aiken Ave

            Pittsburgh PA 15232-2212

            dfisher@...

            www.polarsoft.biz

            412-683-2018

            412-683-5228 fax

             

            _,_._,___

          Your message has been successfully submitted and would be delivered to recipients shortly.