The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: FW: xAP configuration protocol


  • Subject: Re: FW: xAP configuration protocol
  • From: i.bird@xxxx
  • Date: Tue, 12 Aug 2003 14:16:00 +0000

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.

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.

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.

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

Ian



Original Message:
-----------------
From: Alistair Watkins <a
href="/group/xAP_developer/post?postID=xEA3vZyO6PF2zJtAEFIJFGVjVYO4eJbAUwVR0Gu6mtG3KylbqHBjZ9d_NGHgzWhPIS1pvZc2ZwJyBmMKj4qdYbkJBQ">ukha@a...</a>
Date: Tue, 12 Aug 2003 13:13:46 +0100 (BST)
To: <a
href="/group/xAP_developer/post?postID=5K0eTF5-ljL6RoCid1QLqTUEcKw8V2xNuLhmnHmzt-RljqiYPNwhcBoriQCzllnm9EDMUwsm6OCVm8PQYhIcZ7lUs_oANQ">xAP_developer@xxxxxxx</a>
Subject: Re: FW: [xAP_developer] xAP configuration protocol


Hi,

I don't really know that much about xAP or your exact 'target
applications' but as I see it implementing service discovery is going to
be a complex thing, that I know would not fit onto my micro controllers
that I have been experimenting with.
A simple way of implementing an auto-config type system would surely be to
use the heartbeat messages? It may be slow, if all the beats are hourly,
but when the device turns on it can check its UUID against all the HB
messages it receives over the hour, if it matches any it will have to
(randomly?) pick another.

Another way could be that if a device receives a heartbeat from the same
UUID (but not sent from itself) it sends some sort of collision message
back to the UUID and the other device reconfigures..
This may not be an ideal or even the best solution, but the first bit
would fit in with the current spec, would it not?

Always willing to learn more,

Alistair


--------------------------------------------------------------------
mail2web - Check your email from the web at
<a href="http://mail2web.com/";>http://mail2web.com/</a> .







xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.