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: xPLDiag



What if the hubs reply includes whatever info it has about its clients? So
even if the
apps are not aware of this type of message, you can still get some
information about every
connected app.

I'm not familiar enough with the details of this to know whether the
requestor would be
able to work out what each of the hubs ip addresses are and which hubs each
app was
talking to. Would be good to build a map showing the layout of the xpl
network from the
replies.

Paul
----- Original Message -----
From: "Mal Lansell" <mal@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Thursday, September 22, 2005 10:38 PM
Subject: [ukha_xpl] xPLDiag


> Aside from all the hub confusion, I've been thinking about the xPL
> Diagnostics app (and I'll start writing it soon if no-one has any
> objections).
>
> It would be easy enough to detect the presence or lack of a hub, spot
> potential firewall issues and issue appropriate advice.
> However, it would also be useful to be able to display information
about
> the applications on the xPL network.  To this end, I propose the
> following schema - "about.basic" - comments would be very
welcome...
>
> The diagnostic tool would send the following message:
>
> xpl-cmnd
> {
> hop=1
> source=mal-xpldiag.default
> target=*
> }
> about.basic
> {
> remote-ip="192.168.0.4"      // ip and port are the same as
in the
> tool's heartbeats.  The reason for including them is outlined below.
> port="50002"
> }
>
> Applications would respond to this with (using my W800 service as an
> example):
>
> xpl-stat
> {
> hop=1
> source=vendor-device.instance
> target=*
> }
> about.basic
> {
> application="xPLW800 Service"                         //
Long version of
> application name
> version="4.0.1"                                             
     //
> Version number - just a string for the diag tool to display, not
parse.
> url="http:\\www.xplmonkey.com"                         //
URL linking to
> web page related to the application.
> description="The xPLW800 service blah blah"      //can have
multiple
> description fields, each no longer than 128 chars.
> description="blah blah blah"
> }
>
> In addition, I think the hubs should also respond to about.basic
> commands.  Being able to include the active hubs in the report would
be
> extremely useful - especially when trying to work out what version is
> being run.  Unfortunately, it wouldn't be sufficient for the hub to
> respond by sending about.basic stat messages only to its clients - if
> they did that, the diagnostic tool would not hear back from hubs on
> other machines.  This the reason for including the ip and port of the
> diagnostic tool in the original command - the hub can then send it's
> about status directly to the tool.
>
> Although most apps won't support the schema at first, if we adopt this
> then eventually the frameworks will have built-in support and the apps
> will too.  This should go a long way to solving a lot of issues with
> versions etc, and provide a handy way for the user to obtain up to
date
> information about just what is running in their system.
>
> Thoughts?
>
> Mal




___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com



  • References:
xPL Main Index | xPL Thread Index | xPL 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.