RE: FW: xAP configuration protocol

[Kevin Hawkins]

Ian - sounds like you've made some great progress here, pioneering stuff I
hadn't realised you got so far - well done - I very much look forward to
seeing whatever you can write up on this.


> -----Original Message-----
> From: <a
href="/group/xAP_developer/post?postID=3UhFoFbz-RvAoarDItwvxwGkREtSwbzeScf0fg2gVcOV5y8lxo3CP8st9SX31VRI4MGMnI5XmT1Y">i.bird@t...</a>
[mailto:<a
href="/group/xAP_developer/post?postID=oZzV7xr2DAzg6w5qxQXkMaCNJfjyAMEvxe_Zb36lYzHVsOjDMVIJcUtfJLxIPs0mE_ONrTFTzOK-">Ian@M...</a>]
> Sent: 12 August 2003 14:16
> To: <a
href="/group/xAP_developer/post?postID=rSEpTNrl9w9867ebhsOI9cN0rGqDSu9iOEmMG_cnSq7awJafptEfejZ4LjQlJfOpjO8gObFPSX3zGW9yRdoxi9iI9pDWmyk">xAP_developer@xxxxxxx</a>
> Subject: Re: FW: [xAP_developer] xAP configuration protocol
>
> Hi Alistair
>
> What micro are using out of interest? I use the Atmel AVR range and
> others
> here also use the Rabbit and PIC micros.
>
> My version of discovery is very easy to implement and essentially
> forces a
> heartbeat on demand from the micro. It only responds to a request from
> something that is aimed at my units i.e. as identified by the target
> string, something like target=IansINet.RB3_1Controller.* where
IansINet
> is
> my ID if you like. There is also a body to the message containing one
> value
> pair saying what is needed but for the life of me I cannot think what
> it
> says. My units will not respond to something like target=IansINet.*.*
>
> I will have to check how it is done and clarify back later. Don't take
> the
> above as gospel just yet.
>
> I know this a limited form of discovery but I plan to make a stand
> alone
> controller and as such it would need to be able to find out how many
of
> a
> particular device was on the network and offer the user the ability to
> configure them. I do actually think this works within the current
> schema
> boundary and does not cross over into 'proper' device wide discovery.
> As
> others have said this is a much thornier issue.

As you say - it's a nice contained environment to discover known devices
(eg
your own), let's refer to that as level 1 discovery for now - but expanding
that to say 'what light control do I have' 'what thermostats' etc is more
awkward when multiple vendors have xAP products. Perhaps ('level 5'
discovery for example should be able to say 'what irrigation valves are
there I can control'?? . Some might be on your IanB board but perhaps a
couple are on HomeVision outputs. Even more frightening 'what video
recorders are there that can receive Sky One" or 'What alarm sensors
are
there' - really awkward. So my thoughts now - to limit the thornier issues
are that perhaps just being able to discover what a device has in terms of
#inputs and #outputs (and how to control them) is all we could
realistically
aspire to in the near future. (gonna call that level2).
I need to take another look at Apple's 'Rendezvous' as this tackles
these issues - and has been well received and adopted and is also supposed
to be reasonable from a technical overhead.
For a xAP central control application for your own controllers that
might run on a PC say, what you have here is 'bang on' and realistically
most tailored or bundled applications will probably be implemented this way
- perhaps later if you need to support HV you add it specifically to your
app. I am sure we can build something here around your ideas so please do
write them up.
Recognising your relay board automagically (if we had discovery) say
in HomeSeer - with inputs and outputs allocated correctly and controllable
(scriptable) is probably a good level for xAP discovery for us to aspire
to.
I mean that this is achieved without a IANB plugin being necessary - just
trhough a xAP plugin. I think we should aim to have this 'level 2'
discovery - knowing what inputs and outputs a device has - perhaps whether
they are binary (ONOFF) or level (0-100%), or perhaps streaming (eg serial
data). This coupled with a base level control/Status schema would enable
99%
of the control model to be built up in typical 'today' controllers like
HomeSeer, ACE, Autom8it,Symphony, MisterHouse, HomeBrain, HV etc. They are
essentially all based around scripted 'simple device' control with a few
more complex devices shoehorned in (eg thermostats / TV listing guides
etc).
They all (except possibly HB) tend to have evolved from an X10 device type
as the norm.

>
> I do actually go one step further as once my devices are identified a
> targeted status message with a body type of detail (type=detail) will
> get a
> response from my unit giving all relevant details e.g. instance name,
> sub
> instance names * 8, serial number and other details. A similar thing
is
> done for the inputs on the board as well only using a different
schema.

Interesting stuff - do you perhaps have a few sample messages ?? This is
the
extended version of base status - we need to use similar name value pairs
and section names in order for this to work transparently(the Schema) and
also possibly to include a base status body in the message to.

>
> I am currently on RS232 exclusively but I have been looking at the
> possiblity of adding an xPort or Rabbit based Ethernet interface as
> well.

My C-Bus Rabbit (xAPtisor) will do this for you :-) - available without the
C-Bus SIM - btw do you use checksums I haven't yet supported them ?? I can
get one to you shortly if you would like to try....

>
> I currently do not support UID addressing or do anything with it
> inbound. I
> set it correctly (hopefully) outbound and that's it.

Inbound you can't target on UID - but you can target on the full target
address complete with the subID's on the end of that - the part after the :

Target=IANB.Relay.Outside:Lawn < should address one relay for the lawn
Target=IANB.Relay.Outside:Beds < should address the beds relay only

If you can do this then a base control schema should be able to control it
-
so a device in HS stood a chance of being able to turn it ON or OFF and to
accurately display its state realtime. (although we haven't defined base
yet
- but it only has ONOFF and Level in it - you would ignore level and report
it as NA ideally for a relay).

- although I think you have coded this another way too by enclosing
the target address relay ID within the message body...? doing it this way a
third party application may have difficulty controlling it and
interrogating
it for status though. Of course you can do it both ways too.

...
Target=IANB.Relay.Outside
...
}
{
...
relay=1 (or relay=Lawn perhaps)
...
}

The important one is the outgoing one which you have supported :-)
as now any xAP receiver can just monitor the UID to know when something
changes state - for example if the UID of the lawn sprinkler is FF121205
the
a xAP indicator light can just monitor this ID (rather than your full
source
address) to know the state of the sprinkler - perhaps lighting an indicator
inside somewhere.

Kevin