--- In email@example.com
, "Bernhard Isler"
> What was the reasoning to make Command Prioritization of Output
> Objects required, while it is optional for the respective Value
> Is there any objection on attempting to change the command
> prioritization to be optional for the Output objects?
> Any reasons such an attempt is hopeless anyway?
At the time that our core object types were being conceived, there
was a strong bias in favor of having a synchronization mechanism.
Robertshaw had used a 16 level mechanism in their products and
proposed it for inclusion in BACnet. Despite the cries of those
implementing smaller devices, there was consensus that the
complex Robertshaw proposal would be robust and therefore "better."
Since some implementations had outputs that did not require
synchronization, or "low cost" implementations that would be
taxed by the RAM requirements of prioritization, we invented
the "Value" objects AV and BV (and later MV). These could act
as inputs or outputs and further made the prioritzation
optional. So an AV or BV can do the same functions as AO or BO
but does not require commandability.
This accord has been the doctrine of BACnet for 15 years or more.
IMHO, it would be hopeless to propose the changing of AO/BO/MO
objects to eliminate commandability as a requirement for
1. Our colleagues will say that you can accomplish this same
goal by using AV/BV
2. Much confusion could result since this has long been the
sole distinction between the object types. This is deeply
entrenched in documentation and implementations perhaps
in the millions of controllers.
By the same reasoning, we could eliminate AO/BO/MO/AI/BI/MI
and just have AV/BV/MV objects, thereby simplifying the standard.