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

RE: [BACnetLighting] Channel object and WriteGroup

Expand Messages
  • 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 1 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,




      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





      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




      412-683-5228 fax



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