RE: Renaming of instances and SubInstances?

[Kevin Hawkins]

> -----Original Message-----
> From: Ian B [mailto:<a
href="/group/xAP_developer/post?postID=yCtw_85TGsQvJ5DzfTKZKdc305ItDUCEhpZDqFgJ52-F7qz3TD0E8WGcwW7X7fXRfYeKyaIo-WRUqAit2g">Ian@M...</a>]
> Sent: 31 August 2003 21:16
> To: <a
href="/group/xAP_developer/post?postID=EtJ0xcSDyr8mbMepr-n3A2VHd2ZYpvwApt2C7_O67NWsVPSeki98MzLh6w4vauCPXCok3nOBEtswTQ4sqOKDNKLtNrZbeghV">xAP_developer@xxxxxxx</a>
> Subject: RE: [xAP_developer] Renaming of instances and SubInstances?
>
> >Yep - I do think the single messages are important - and although
you
> might
> >need to send 8 it is really only a loop - actually there could be
more
> >because if for example a combination of inputs caused all the
outputs
> to
> >change state then you would be reporting all the inputs that
> >changed and all
> >the outputs too.
>
> No problems. I will put in the loop and see how it goes.
>
> > The latter may not be as a result of anything changing state but
> could be
> >just a periodic update message that went out every 15 mins say or
more
> >likely would be in response to another 'request for status' xAP
> message.
>
> Purely request for status for me. I don't plan to broadcast this sort
> of
> thing for all my I/O.

I don't think many will but it's an option I guess..

>
> >Hence something like HomeSeer (at launch) would send a tragetted
> 'request
> >for status' message (to the whole device) and could then know the
> state of
> >all that devices inputs &amp; outputs, returned in one
message;
>
> Hmmm, I have done status as that of the outputs and separately of the
> inputs. Do you think that bearing in mind I have an inputs schema and
a
> relays schema that status should be dealt with as something else.
Since
> I
> cannot currently tell whether something is an input or an output other
> than
> the schema used to talk to it then returning them all in one message
> would
> be tricky requiring more description of its abilities. Couple to this
> the
> different capabilities of outputs (and inputs) e.g. percentages of
> output
> etc. the resulting message would be rather complex.

What I was proposing in 'Topic 1' was that there was a simple status
- a way in which every xAP device with I/O could respond to a request in a
basic fashion such that things would have some element of plug and play.
How I feel xAP should work at this level is that something like
HomeSeer as an example , although HomeBrain is another good one, should
become aware of things (by listening) on the xAP network and be able to
build a state model for them , knowing for example how many inputs and
outputs a device has and whether they have a 'level' associated with them.
It should also be able to control the outputs and set them to an
appropriate
level and to ask of their state at any time. This is really a simple
adaption of an X10 model. This is what "Topic 1" addresses and
there are a
lot of open points in that - although no-one has responded on any :-( .
One of the points there is should we divide the inputs and outputs
into sections such that they can be differentiated. I think we should - and
you're sort of doing this anyway.

> Homeseer
> etc. would have a plugin for a device like my I/O controller so it
> would
> know how to communicate with it and hey presto.

One of the key benefits of you using xAP rather than your own
command structure is that you must hope for some degree of leverage from
other xAP devices, an ability for other devices to control your relays and
your inputs to control other devices - to do this requires a certain
agreement on these basic schemas. HomeSeer should be able to minimally
recognise and control your device without any prior knowledge. On top of
that you layer the more complex functions and control of your device in
more
possible name/value pairs within the schema or more body parts - the simple
devices understand the simple bits and the more capable may use everything.
To that extent yes you may have/need some form of plugin for HomeSeer and
Symphony and Autom8it and HomeBrain and ACE and... you see my point - it's
never ending -s os the base functionality is key - people can then use your
device 'out of the box' - however all they would know perhaps is that
setting output 7 to 50 will create a 50 second timer for relay 1 - not a
good example I know as timers probably aren't outputs - but if they were
they could do it.


What I am trying to avoid is this dependency on a powerful script
based central controller to even connect two devices - and part of that is
allowing controller applications to pick up and link inputs and outputs,
part of it is a direct point to point connection - a switch to a light for
example.



...If HomeBrain for example can accomplish the following...

I see a device called "Ian's Relay Board"
It appears to have:
8 outputs that are binary ONOFF numbered 01-08
8 inputs that are binary ONOFF numbered 09-16 (although
hex)
4 inputs that are level based numbered 17-20
Let me find out what state they are in:
"Ian's Relay Board - tell me all your I/O states"
.... board replies
Great I now have an internal model and I can keep it up to date

I see a device called "Kevin's switch"
It appears to have:
1 input that is binary ONOFF - 01
1 output that is binary based ONOFF - 02
I'll check it's status
..... Kevin's switch responds
Great I have a model

That's great progress !!!

An example... well sort of - I forewarn you now that I've downed two
bottles of wine so take this next bit with a pinch of salt...- in fact I
would hit the 'delete' button now if I were you...

HomeBrain knows that output 04 on Ian's relay is called 'sprinkler'
and output 05 is called 'flowerbed' . Kevin's 01 input is called 'water'
and 02 output is called 'watering done'

Programmer now links (even draws a line maybe) between Kevin's
switch 'water' to Input 10 on Ian's Relay
HomeBrain says - are you sure ?? - both of these are inputs
Duh.. that's wrong so...
Programmer links Kevin's 'water'switch to Ian's 'sprinkler'relay
HomeBrain says - OK whenever Kevin's switch 'water' goes ON
I will switch Ian's Output 'sprinkler' ON - and HomeBrain is capable of
doing this due to basic control and status schemas.
Programmer also links Ian's relay 'sprinkler' to internal timer
"sprinkle time" in HomeBrain
Programmer sets timer 'sprinkler time' to 15 minutes
Programmer sets timer 'flowerbed' to 10 mins
Programmer links 'flowerbed' timer op to Ians relay 'flowerbed'
Programmer links output of HomeBrain's timer 'sprinkler time' to
relay op 'sprinkler' on Ian's board in a 'turn off' mode
Programmer links Ian's relay 'sprinkler' OFF to input of HomeBrain
timer 'flowerbed'
Programmer links relay 05 (Flowerbed) to 'watering done' light on
Kevin's switch
- HomeBrain may caution again that this is two outputs being connected
together but this time it is correct


Now when switch one is pressed on Kevin's switch - relay 04
(sprinkler) goes ON and 15 mins later goes OFF too. Then the flowerbed goes
ON for 10 mins and then OFF and the lamp on the switch lights. Note in the
above that it is possible to switch the flowerbed on (from another xAP
source or locally on the relay board) for any length of time but it is
impossible to turn the sprinkler on for more than 15 mins, even locally
(but
the flowerbed will always come on after the sprinkler finishes).

Now don't ask me why you want this setup but what we have achieved
is a fairly complex linking of components just by joining the points
together - and no custom plugins - HomeBrain or HomeSeer could do this out
of the box.

Of course the power user would know that he can set Ians on-board
timers up to achieve this and if he had the custom plugin for HomeBrain or
was more competent he might do it another way..

The above is what happens after a crap night on TV with 2 bottles of
wine - so apologies but I hope it illustrates a point that is one of the
main reasons for using xAP in the first place - getting two different
devices talking to each other.

Hic zzzzzzz

K