Re: HA Object Model or Taxonomy?

[alan.trevennor@xxxxxxxxxx]

--- In ukha_d@xxxxxxx, Gavin Sallery <gavin@...> wrote:
>
> And now to the detail...
>
>>> There are very few general questions which could be asked of
any object in an automation system and generate a meaningful, uniform
response across all participants

Indeed, a getState() method would probably have general applicability in
all appliance objects, so it could be inherited by everything that falls
under there, but only be applied patchily elsewhere. The cushion would not
be under appliances, it would probably be somewhere under
\fittings\furnishings\accessories or some such.


>>> better to break things down and have a getPlumpness method for
the cushion, and a getIntensity for the light.

Yes.


>>> The model should definitely be able to represent (or codify)
any object which is likely to become involved in a home automation system;
for practical reasons, this is likely to be limited to that subset of
objects which can be controlled remotely via some sort of electronic means.

Yes, but a lesson of the last couple of decades is that technology appears
in previously unexpected realms. For examples, heated gloves, clothing with
built in power collectors, motorised seating, pens with cameras in, digital
paper etc etc. To me, that means that although it may not be a current
requirement, nothing should be out of scope for an HA object model, even
though it may not be made explicit in current versions. I think that's
pretty much what you meant too?

>>>Representation of these objects should include exposing
attributes which can be queried or manipulated, for any properties of the
object which are relevant to a home automation use case.

Agree again, with the same reservation, that things that previously were
out of scope could be brought in to reflect developments we may not even be
able to guess at now. Someone designing this in the 1970s would not have
given a phone a currentGPSLocation property for example - we used to call
places, now we call people.

>>> The question of ontology is less straightforward. Does an
object in an automation model have significance (or indeed reality?) only
because of its relationships with other objects in the model? For some
items such as light switches, these are clearly meaningful only once you
know to which light they are connected - so perhaps a reference to the
light should be included in the model of the switch.

Yes, there is a tightrope to walk in this regard, and falling either side
of it means certain death to the model! Like all object models, I think the
trick is to focus much more on what things ARE, not what they currently DO.
This maxim seems to me especially true for HA objects.

To continue your example, an instance of a dumb light switch should really
only have a few properties such as canOperateManually, currentState
physicalLocation and perhaps if it's a fancy fitting, stuff like
switchSurroundIlluminationState.

It should generate just a few events such as manualStateChangeRequest (when
a human presses the button to make it go on or off), lightOn (a response to
a setOnState method invocation to automatically turn on the lights) and
lightOff.

It should have minimal methods like setOnState(true or false),
setSwitchSurroundIlluminationState and perhaps setManualOperationEnable

>>> ...in a real home automation system based upon the object
model there would probably be a need for something to maintain a list of
objects which were "listening" to the state of the light sensor,
but I would argue that this is a property of the implementation, not of the
model itself.

Yes,in a lot of HA kit at the moment relationships between elements are
hard wired or handled in highly proprietary ways. If an object model like
the one we envisage existed, compliant HA devices from multiple
manufacturers would generate and respond to model-compliant messages which
could be dynamically coordinated by open source management applications
(probably some of the already existing ones). This would mean that the only
relationship between an instance of the light switch and the light (or
lights) it controls would be in the control application's database.

The object model would have nothing to say about whether this particular
light switch object type was for controlling one or multiple lights. The
management application would essentially map event notifications from
objects into calls to other object's action methods.

>>>This is particularly true given the language-agnostic nature of
the model; different mechanisms may be used for communication in different
(machine) languages.

Yes.

>>> Back to ontology - I'm also not sure that the relationships
are as clear-cut as you are imagining. In the case of your illuminated
house sign, is it clear that this belongs in
"fittings.illumination.lighting.outdoor", rather than
"fittings.lighting.signage" or even
"fittings.outdoor.lighting"?

No, it's not 100% clear - and neither can it be; however, a model must try
to take a view on these kinds of issues. I would say, applying the maxim of
classification by what things ARE rather than what they DO, an illuminated
house sign is just an outside light he fact that it for a sign is
immaterial for the purposes of the object model. But, if the sign light has
a on/off timer that can be remotely set by software, then that makes it a
different object type.

Where there is genuinely no single right classification (and, once you
apply the maxim, the incidence does diminish) it should be permissible to
have identical (or mostly identical) objects in different locations in the
ontology hierarchy - but it should be fairly rare.

>>>This is before we even consider the problem of composition;
take the Logitech Squeezebox (a fine music player). This is a music player
(which is clearly an object which we would like described in our model),
but it is also an alarm clock. Modelling an alarm clock also seems like a
sensible thing to do, but then do we build a Squeezebox model under
"media.players.music" or "timers.alarm"? The only
sensible answer is that the Squeezebox is an instance of both an alarm
clock and a music player, which forces us away from a simple hierarchy and
into a more complex inheritance-based graph. This is not a problem, and in
fact suggests that we should be thinking in terms of traits rather than
objects.

I see no problem with single devices registering themselves as instances of
multiple object types provided, in the implementation, there is a mechanism
for them to pre-declare a nailed-up relationship between those objects.
Alternatively, provision could be made in the model (probably at the top
level) for "compound object" types, which is pretty much your
suggestion, I think?

>>>This would be the case with all the various TV implementations
- the model's representation of a TV would contain only a common subset of
the features of all televisions, but a TV manufacturer would be free to
extend their implementation of the TV object with their own particular
bells and whistles - though the hope would be that once a feature became
common, it would be incorporated back into the model...

Yes, as well as providing the means for custom extensions (which would not
be part of the standard, just per-manufacturer expediencies) the model
would be totally open to properly justified new additions. That more or
less dictates that it would have to be maintained by a single entity of
some kind.

IMO this is precisely the sort of thing that an organisation such as DLNA
should have been doing - and to some extent they have, but in a highly
exclusive paying-members-only kind of way; but that's not what the HA
market needs to allow it to attain universal take-off - as previously
discussed 8-)

Anyhooo - I'm uploading with this post, the top-level view of the object
hierarchy that I have developed so far. Don't get too excited, it's only my
incomplete start point! It has all the major areas that I envisage would be
needed, and I have assigned node codes to it for reference.

I'd be very happy to received any comments from you, Gavin, or anybody else
on this.

One comment of my own, after much agonising I decided it was sensible to
differentiate between things that are fittings (i.e that which would remain
in place if you moved out) and appliances, things that would disappear if
you moved out. This means that central heating, for one example, sits in a
different branch than portable space heaters. I still can;t definitively
decide if that is a worthwhile distinction?

Best regards
Alan T




------------------------------------

<*> Join the Automated Home Forums
http://www.automatedhome.co.uk/vbulletin/