RE: [BACnetLighting] Channel object and WriteGroup
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.
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.
914 South Aiken Ave
Pittsburgh PA 15232-2212