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

General remarks about current topics (timeout of commands, fade and ramp times)

Expand Messages
  • 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 1 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 2 of 5 , Mar 1 11:22 AM
      • 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 3 of 5 , Mar 4 3:14 PM
        • 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.