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: xAP Serial Class (Second Attempt)


  • Subject: Re: xAP Serial Class (Second Attempt)
  • From: mark_harrison_uk2
  • Date: Mon, 17 Nov 2003 22:59:00 +0000

Ian,

I'm very much going into this to test MY understanding, rather than
try to explain anything to you. I hope that someone (Paul?) will
either confirm that I've got a handle on things, or explain where I'm
misunderstanding.

The xAP specification contains three things. For what it's worth,
I've argued for a while that they should be in three separate
documents, but as of 1.2 they are all part of a single such:

- Definition of what a xAP message looks like

- Definition of how to transmit this over an IP network (ie - each
message as a UDP packet on the xAP IANA port)

- Definition of how to frame this over a serial network

My understanding of xAP 1.2 is that a bridge should propogate ALL xAP
messages EXCEPT that hop count may be used to "time out" messages
to
prevent loops. Configuration of the "maximum hop count" on a
bridge
is an INSTALLER function, as opposed to a developer function, since
it depends on the topology of the xAP network installed.

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

My view is that the xAP world needs two, completely different things,
and we musn't get them confused:

1: A xAP schema that defines the payload of messages that would be
passed RAW onto a serial device.

The key advantage of doing this as a schema is that it would allow
Rabbit-type devices to listen for (targetted) ethernet messages in
this schema, and pass the payload out... Then, rather than connecting
directly to a Homevision on the local PC, my Homevision control app
could have a "connection mode - xAP serial message" (at present
the
connection modes are "local serial port" and "DDE to
HomeVision's own
server software". This message could then be picked up by a Rabbit
attached to Homevision WITHOUT the Rabbit needing a "homevision / X-
10"-aware firmware.

The advantage here is that it allows the "business logic" of
converting from a xap-X10 message into a Homevision serial command to
be run on a PC (where processing power is cheap and development is
easy), but still to have the Rabbit device next to Homevision in a
small cupboard, or other location where a PC would be obtrusive.

There is a second advantage in that it allows a single manufactured
board to act as a controller for different classes of devices WITHOUT
reprogramming to listen for different schema. For example, the
RSC/TES Meridian controller could listen for a xAP-serial message,
and not need know whether it had a Meridian processor, or a
HomeVision to which it was passing the payload.


2: A set of tools to ensure that xAP bridges all deliver the same
base-line functionality - ie that they wrapper the xAP-handling of
serial comms in a simple programatic class. In practice, this class
would, on its own, deliver 90% of the functionality of a xAP
bridge... but make it easy for another programmer to develop a
combined hub/bridge or a more sophisticated piece of xAP
infrastructure.

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

It is my understanding from reading the spec, that Paul is aiming for
number 2 here?

Regards,

Mark


--- In <a
href="/group/xAP_developer/post?postID=oypKEdkEkol6s83hiAi13cUPtMP1ozUKNbdxTyWmxDhKHGmJMecwRz48dUDknHOah1hfh0pMxKbmKHL0-hWUv7sJPLo1coDs">xAP_developer@xxxxxxx</a>,
"Ian B" <Ian@M...> wrote:
> Hi there
>
> This is most definitely the wrong thing to do but I thought I would
throw
> this in anyway (that'll be commenting without reading first).
>
> I remember seeing Patrick's Ethernet to serial adapter once. This
would
> receive Ethernet based messages and I assume simply add the 02 and
03
> terminators and propagate onto a serial network which may or may
not be 485
> based. The whole thing ran on a Rabbit micro so no Windows to get
in the
> way. If the message is well formed to the spec then white space
etc. will be
> deliberate and allowable/desirable for sending onto the serial
network.
> I am just concerned that we aren't alienating other gateways onto a
serial
> network with this serial class. Maybe I am being a little
> simplistic/judgemental here - please correct me if I am wrong.
>
> I did like Kevin's suggestion of a 'flag' saying whether the
message was
> bound for a serial network which would aid in filtering. However,
this
> implies quite a lot of brains in the sending application and would
maybe
> knobble cross network messages? As seems to be the case at the
moment I have
> not had too much time to think this one through either.
>
> I have not had time at the moment to read your docket yet so my
apologies if
> this is not relevant.
>
> Thanks
>
> Ian
>
> >-----Original Message-----
> >From: Paul Barrett [mailto:pbarrett@r...]
> >Sent: 16 November 2003 20:57
> >To: <a
href="/group/xAP_developer/post?postID=oypKEdkEkol6s83hiAi13cUPtMP1ozUKNbdxTyWmxDhKHGmJMecwRz48dUDknHOah1hfh0pMxKbmKHL0-hWUv7sJPLo1coDs">xAP_developer@xxxxxxx</a>
> >Subject: [xAP_developer] xAP Serial Class (Second Attempt)
> >
> >
> >Hi Guys
> >
> >Right, I've had another go at this proposal.
> >
> >Let me know what you think :-)
> >
> >Paul
> >
> >
> >
> >To unsubscribe from this group, send an email to:
> ><a
href="/group/xAP_developer/post?postID=R3bcUsh8bKZ22squYAJNNQxfJ8n-vHyYNtQRtVV3JKdq2kEN1cKEMtNDUUHW_6XeMxV-lUBdiTRxgMpEhUR8t2b7lFJOy5Hsgf5gHYJytf8">xAP_developer-unsubscribe@xxxxxxx</a>
> >
> >
> >
> >Your use of Yahoo! Groups is subject to
<a href="http://docs.yahoo.com/info/terms/";>http://docs.yahoo.com/info/terms/</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.