Re: HA Object Model or Taxonomy?

[Gavin Sallery <gavin@xxxxxxxxxxxxx>]

On 20 Mar 2012, at 10:48, alan.trevennor@xxxxxxx wrote:

>
>
> --- In ukha_d@xxxxxxx, Gavin Sallery <gavin@...> wrote:
> >>> 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.
>
>
I'm not even sure that all appliances have a meaningful and specific
getState(); the most general would be something like isOn(), but even that
becomes ambiguous when considering things with (perhaps multiple) standby
modes. My preferred approach is to take specific devices on a case-by-base
basis, and then if any commonality becomes apparent, move this up to an
object further up the inheritance hierarchy. This seems more constructive
than trying to over-generalise too early.

>
> >>> 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?
>
>
Yeah, pretty much - extensibility is one of the joys of open source, so
opening the model up in this way should it become necessary will not
require any complicated re-licensing or agreement by a bureaucratic
standards body...

> >>>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 way I'm imagining this working is that if the core model is lacking
something useful (such as a current GPS location, in this example), users
of the system will extend the model to support the missing feature. If we
get the licensing and community right, changes like this would tend to get
pushed back toward the model repository, and the useful ones accepted into
subsequent versions of the model.

> >>> 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
>
>
I definitely need to think about the event model. In an ideal world, any
exposed property could be observed for changes in value, rather than having
the object itself responsible for generating events. This really belongs in
the next layer up from the domain model per se, but needs sorting out...
it's on my list!

Physical location is also interesting - in some ways it is obvious that
every device will have a physical location, but quite often enquiries
relevant to location will be aimed at the collection of devices in a
particular location, so perhaps the location should be held elsewhere in
the model. Again, this needs thought. I think it will become more apparent
when I start writing some example code - I will be putting together a test
harness for this stuff, so that people can play with ideas.

> >>> ...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.
>
>
Yep, that's exactly how I see it.

> >>> 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.
>
>
The diamond problem rears its ugly head. I intend to sidestep this as much
as possible by using multiple traits, rather than a strict hierarchy.

> >>>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?
>
>
Close; I think the model defines the types of devices (or more accurately,
device traits), then a particular instance such as the Squeezebox object
would just say "I implement the alarm clock and music player
traits". Thus, clients looking for music players can treat it as a
music player, clients needing alarm clock functionality could treat it as
an alarm clock, and a simple inspection of the Squeezebox object itself
would reveal that it is both an alarm clock and a music player.

> >>>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-)
>
>
Yes - I'm surprised at how little DLNA seemed to grasp that point!

> 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.
>
>
Still waiting to get to grips with 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?
>
I think this is a property, rather than a hierarchical classification, as
two devices could be identical apart from whether they are fittings or not
(this could be confusing and redundant). I have incorporated an
"isHardwired" property into some of the traits, which roughly
reflects this distinction - it's something which it might be useful to
display through a user interface, as it indicates which parts a casual user
may wish to reposition or reconfigure...

This is fun! Anybody else care to dive in?

Cheers,

Gavin



[Non-text portions of this message have been removed]



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

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