AW: Multiple properties to control 'command priorisation'
RE: Multiple properties to control 'command prioritsation'Bernhard, CarlThanks for the feedback. I have the following remarks to your feedback.It is intended to use Lighting_Commands in a Schedule object. With this, the priority included in Lighting_Command will conflict with the Priority_For_Writing property. This is also true for the Command object where in the property Action the Priority field will conflict.(The mentioned sentence in 12.10.8 is not realy needed; using 188.8.131.52.5 a commandable property with no Priority in an action-list will go to prio 16).If we want to be so strikt, that changes in the priority-array are only allowed by writes to the the commandable property (Present_Value), the priority field and the relinquish command should not be in the Lighting_Command property at all.By using the Priority service parameter instead of the priority-field, the property Lighting_Command_Default_Priority should be removed. So no changes are needed in 184.108.40.206.5 & 220.127.116.11.4.RenéVon: Carl Neilson [mailto:cneilson@...]
Gesendet: Mittwoch, 16. März 2011 17:07
An: Isler, Bernhard; Kaelin, Rene
Betreff: RE: Multiple properties to control 'command prioritsation'
Rene & Bernhard,
I believe that use of priority is pretty clear and that the proposed use would violate the current specification.
But I would not necessarily be against making the change that is proposed as I believe that it effectively equivalent. Such a change would require changes to the common language in the standard that describes the priority mechanism thus making a lot more work and decreasing the chance of agreement by others.
Is the desire to use the priority instead of having the priority in the lighting_command related to the use of lighting_command within schedule objects?
From: Isler, Bernhard [mailto:bernhard.isler@...]
Sent: Wednesday, March 16, 2011 7:08 AM
To: Kaelin, Rene
Cc: Carl Neilson
Subject: RE: Multiple properties to control 'command prioritsation'
As per my interpretation of 19.2, there is a distinct link between the Commandable Property, the Priority_Array, the Relinquish_Default property and the write service that uses the Priority parameter.
As per 19.2.1 and sub-clauses, a command is sent to the Commandable Property, the commanded value is stored in the respective slot of the Priority_Array, determined by the Priority parameter, and then the resulting value of the Commandable Property is evaluated based on content in Priority_Array and Relinquish_Default.
Given this, the Priority parameter has effect in write services to a Commandable Property. But I question if the Lighting_Command property can be called a Commandable Property, since its value is not evaluated by a command prioritization scheme. If it is not a Commandable Property, the Priority parameter would have to be ignored in write services since not on a Commandable Property, as per 18.104.22.168.5 & 22.214.171.124.4.
Also, note that when the Priority parameter would be used despite, there are conflicts on the default priority used when the write service does not convey the Priority: In the write services, a priority of 16 is used in this case, as per 126.96.36.199.5 & 188.8.131.52.4. In the Lighting Output object, the priority defined by the Lighting_Command_Default_Priority has to be used as currently proposed.
If a lighting command would be issued by a Command object, a Priority is required for Commandable Properties, as per 12.10.8, 2nd-last paragraph, sentence starting on 4th line. This would require appropriate setup restricted to what the Lighting_Command_Default_Priority value is if the Lighting Output object's default should be used.
Given this, I recommend not to mess up the command prioritization scheme and write services, just for shrinking the BACnetLightingCommand by one octet (as per DHR-019-6). The lighting command functionality is too different from regular commanding, thus justifying an other way to convey the priority and relinquishing that affects other properties.
Siemens Switzerland Ltd
Industry Sector, Building Technologies Division
From: Kaelin, Rene
Sent: Wednesday, March 16, 2011 11:10 AM
To: Isler, Bernhard; Carl Neilson
Subject: Multiple properties to control 'command prioritsation'
In the Addendum 135-2008i for the Lighting Output object the Present_Value is commmandable. The execution of WriteProperty to the Present_Value property changes the priority-array. The service parameter 'Priority' is evaluated and the value NULL for 'Property Value' is allowed for relinquish. The result of 'command priorisation' is according clause 19.2 and visible on the Present_Value.
The execution of WriteProperty to the Lighting_Command property also changes the priority-array and sets a specific slot (value <> NULL) or relinquish a slot (value = NULL). This is accomplished by having a priority field in the data type of the Lighting_Command and also a specific command-value to relinquish. The result of command priorisation is still visible on Present_Value but the behaviour is different.
Alternate it could be specified that the slot in the priority-array which is changed by executing a WriteProperty to the Lighting_Command property is also selected by the service parameter 'Priority' and that 'Property Value = NULL' relinquish a slot.
This has the advantage that set and relinquish a slot in the priority-array is always done in the same manner independent of the selected property.
The LA-WG is asking if there is any principle in BACnet which would prohibit such a specification?