On Fri, Jan 29, 2016 at 11:33 AM Vick, Matthew <mvick(a)jaguarlandrover.com>
wrote:
On Thu, Jan 28, 2016 at 3:29 PM, Kevron Rees
<tripzero.kev(a)gmail.com>
wrote:
> On Thu, Jan 28, 2016 at 3:02 PM Vick, Matthew <mvick(a)jaguarlandrover.com>
> wrote:
>
2. There will be no AMB Object in a zone not valid for that object and
>> exactly one AMB Object in each valid zone. (NOTE: This would deprecate
>> FindObjectsForZone, since there would only ever be one object within that
>> zone.)
>>
>
> Isn't this already the case? FindObjectsForZone is a way to find a
> property that shows up in multiple zones. For example, you could have
> Climatecontrol in driver and passenger zones. To get the driver one, you'd
> call FindObjectForZone with the driver zone.
>
> We may need to throw an error if someone tries to register multiples of
> the same property in the same zone.
>
Perhaps I'm just mis-remembering the method (I haven't worked with AMB
since before the holidays), but I thought I remember a FindObjectsForZone
method to find all instances of an object within a zone. For example,
multiple plugins causing multiple objects to appear within the same zone to
account for multiple properties. That note can be dropped if it's
inapplicable/my memory is awful since the spirit of the requirement is
really "There's guaranteed to be only one object to represent some
functionality in a zone. For example, only one ClimateControl in zone 5."
FindObjectsForZone only returns one object. So if there is two instances
of ClimateControl in zone 5, the source plugin is doing somethings screwy
(or perhaps two source plugins with the same uuid? That shouldn't happen).
Suggestion 3 got snipped, but instead of adding a "Supported" call, 0.15
has the concept of Value Quality. One of the possible values for this is
"UncertainInitialValue" which seems appropriate to use for dbus properties
that show up but are not really supported.