RE: Topic 1: Base Level Status Schema

[i.bird@xxxx]

Hi Kevin

Not a good night last night with a headache and screaming family hence the
slightly garbled message (or that's my excuse anyway).

Quoting
I was half way through replying to the original Topic 1 thread when you
send in the summary. This meant the quoting was from that message not the
summary one which would cause confustion - sorry.

> The jury is out here on these but I would like to see it as a schema
in
> its
> own right which the developer can choose to support or not.

>This I see as a problem - what I am advocating here is a mechanism to
allow
>xAP devices to inter operate in a basic fashion and to have a very
basic
>form of discovery of the inputs and outputs a device has, and their
>capability eg ONOFFLEVEL - if developers chose not to support it then
we

Erm, wrong end of the stick a little here. I was thinking of two of my
projects with this. The current I/O controller would support it for the
reasons you give. I am also thinking about a display device which would
simply show menus and return menu options etc. No input or output so no
need to support the current basic schema as we are talking about it so far.
I did not mean I have an I/O board and I am going to ignore the Basic
schema and go my own way. Sorry, bad wording on my part.

>What can I do to convince you of
>the need to do this, and how simple it is - and what exactly is the
area of
>concern in the implementation ?

No problems here as I hope above explains. The simplicity bit we are
working on and time will tell but there are no major problems I can see at
the moment. I think a phone call between us would help me at this point in
the development cycle. If that is OK let me know off list and we can
arrange a time and numbers.

One of my older areas of concern was the code space required to implement
all this. As an example my I/O board has gone from a 2K PIC to an 8K PIC
and I now on a 32K Atmel chip and at 35% code space used. This has pushed
up the price of any hardware by at least 10 quid on chip cost only. I don't
have a problem with this as I love the new development environment and am
pleased with the way xAP is going but it has moved the bottom line hardware
requirements slightly. Again I don't have a problem with this as I think it
is the best thing all round at the moment.

I have also had a little feedback from a couple of guys who want to use my
board but are doubting their ability to do the programming needed. Because
of this interest it would be great to get this sorted sooner rather than
later (this is NOT a nag) and then I can help them.

Thanks

Ian


Original Message:
-----------------
From: Kevin Hawkins <a
href="/group/xAP_developer/post?postID=RyCKIQVWubqDk2hSCEq6nWrIm6BerzgZw6-B2YRFyYsH-HONA1T7XhsRTcYDRoGh4DKAOGT92WrufF0ZtHLw4Q">lists@u...</a>
Date: Tue, 2 Sep 2003 00:00:47 +0100
To: <a
href="/group/xAP_developer/post?postID=e2gUTjg23lPwFFKRPDc3iIuDPl1-RJZOsmugrIAMFpclJ2GDx7QxZCgIrShbsUkZP-NCAaY_lbDZtL9i3r9X4m798Go">xAP_developer@xxxxxxx</a>
Subject: RE: [xAP_developer] Topic 1: Base Level Status Schema


I'm a little bit lost on the context quoting here but....

> -----Original Message-----
> From: Ian B
> Sent: 01 September 2003 22:17
>
> >situations, firstly in response to a status.request message -
(from
> the
> original mail)
> Hmmm. I currently have my status reporting under the two message
> schemas I
> am using e.g. class=relaycontrol.status and class=inputs.status. I
> guess if
> there was a 'basic' schema this could implement status as well but in
> addition to my current schemas. A low power device could use just the
> basic
> schema to cut down on overhead?

Yes you could have your own status schemas as well - or just add body
sections into the basic schema to offer the more complete version - they
key
is supporting the basic one. This actually may be no more than including
the
basic body section n your own schema - but then I know you are adverse to
multi section bodies.

>
> >section which is shared also by the status.change schema (used
when -
> (from
> the original mail)
> >something changes) and the status.instruct schema (used to ask a -
> (from
> the original mail)
> Status.change is OK (for reporting a change) but to my mind a status
> request
> or notification should be just that. A status.instruct message goes
> against
> the grain and logic and I am not particularly comfortable with it.
This
> could simply be a name issue or maybe we need something like 'command'
> in
> addition to 'status'. Kevin - what do you think as the mail below is
> not too
> clear?

I think it is my terminology here - I am not happy with status.instruct
either - it should be a command type wordage

>
> Anyway, onto the message below. I like the solutions on offer and
> everything
> seems to have a list of plus points as well as minus points. The
latter
> solution with each body referring to a separate SubInstance makes for
> easy
> serial in line processing (minor point really) but the overall message
> size
> is quite large. No repeating name value pairs ;-))
>
> Having said that I also like the bit where each SubInstance is named
as
> part
> of a name value pair.
>
> The jury is out here on these but I would like to see it as a schema
in
> its
> own right which the developer can choose to support or not.

This I see as a problem - what I am advocating here is a mechanism to allow
xAP devices to inter operate in a basic fashion and to have a very basic
form of discovery of the inputs and outputs a device has, and their
capability eg ONOFFLEVEL - if developers chose not to support it then we
wouldn't have any benefit and the 'xAP experience' would be harmed. If you
chose not to support this area I really don't see the advantage of using
xAP
in the first place - you could really use any serial protocol like VIOM
say.
The choice to use xAP must be surely be based on the ease with which it can
interact with other xAP devices.. and this status issue allows you to layer
your own more complex status on top . It is truly KISS based as you say
below. If we end up with many different devices that 'support this bit' but
not 'that' and lengths may be no longer than 'this' and I don't support
'that' then it will be quite frustrating to the user. Of course the user
may
accept the lack of feature and still use the product - to an extent the
market can decide - if there had been X10 modules with status and also
without I know which I would have chosen. What can I do to convince you of
the need to do this, and how simple it is - and what exactly is the area of
concern in the implementation ?


KISS is
> also a
> good principal here although I am sure we will lose some versatility
> along
> the way. It is called BASIC though so there we are.
>
> What do others think?
>
> Ian
>
> >-----Original Message-----
> >From: Kevin Hawkins [mailto:<a
href="/group/xAP_developer/post?postID=RyCKIQVWubqDk2hSCEq6nWrIm6BerzgZw6-B2YRFyYsH-HONA1T7XhsRTcYDRoGh4DKAOGT92WrufF0ZtHLw4Q">lists@u...</a>]
> >Sent: 01 September 2003 14:22
> >To: <a
href="/group/xAP_developer/post?postID=e2gUTjg23lPwFFKRPDc3iIuDPl1-RJZOsmugrIAMFpclJ2GDx7QxZCgIrShbsUkZP-NCAaY_lbDZtL9i3r9X4m798Go">xAP_developer@xxxxxxx</a>
> >Subject: RE: [xAP_developer] Topic 1: Base Level Status Schema
> >
> >
> >This sort of summarises what I'm proposing on the status response
side
> -
> >plus I have been thinking about my 'interfaces' body section as
part
> of the
> >status reporting schemas and I think (as Ian suggested) it should
> >be divided
> >into two, one for inputs and one for outputs, it's the only way to
> >tell them
> >apart - now this could be done with two messages - a
> status.report.inputs
> >one and then a status.report.outputs one or there could be two
bodies
> in
> >each message as follows....
> >
> >Body sections now named perhaps 'inputs' and 'outputs' or
> 'interfaces.in'
> >and 'interfaces.out'
> >
> > A quick example for the following 'xAPper' example device -
> >something with a binary mode input and output, and an analogue
input
> and
> >output -
> >
> > Acme.xAPper.node0 FF111100 The controller itself
> > Acme.xAPper.node0:OutA FF111101 Analogue (eg dimmer) - Out A
> > Acme.xAPper.node0:OutB FF111102 Binary (eg appliance)- Out B
> > Acme.xAPper.node0:InA FF111103 Analogue (eg volume)- In A
> > Acme.xAPper.node0:InB FF111104 Binary (eg switch) - In B
> >
> >This would be the response to a targeted status request sent to
> >Acme.xAPper.node0:OutA - the analogue output
> >
> >
> >xap-header
> >{
> >...
> >uid=FF111101
> >class=status.report
> >source=Acme.xAPper.node0:OutA
> >}
> >outputs
> >{
> >OutA=50%
> >}
> >
> >OR if we named the body sections with the sub instance name
> >
> >xap-header
> >{
> >...
> >uid=FF111101
> >class=status.report
> >source=Acme.xAPper.node0:OutA
> >}
> >outputs.OutA
> >{
> >State=On
> >Level=50%
> >}
> >
> >and this would be the 'compound' response if a status request was
sent
> to
> >the whole device ie Target=Acme.xAPper.node0
> >
> >xap-header
> >{
> >...
> >uid=FF111100
> >class=status.report
> >source= Acme.xAPper.node0
> >}
> >outputs
> >{
> >OutA=50%
> >OutB=Off
> >}
> >inputs
> >{
> >InA=0%
> >InB=ON
> >}
> >
> >
> >the alternative if we named the body parts and used multiple
bodies
> would
> >look like...
> >
> >xap-header
> >{
> >...
> >uid=FF111100
> >class=status.report
> >source= Acme.xAPper.node0
> >}
> >outputs.OutA
> >{
> >Level=50%
> >State=On
> >}
> >outputs.OutB
> >{
> >Level=NA
> >State=Off
> >}
> >inputs.InA
> >{
> >Level=0%
> >InA=Off
> >}
> >inputs.InB
> >{
> >Level=NA
> >InB=ON
> >}
> >
> > Also a last option was to index the body name by the UID so for
> >example inputs.inB would become inputs.04.
> >
> > Does that clarify it a bit ? One of the big differences is that
> the
> >subinstance name is used as a name value pair in one option but
not
> the
> >other - conversely both level and state can't be reported if this
> >is done so
> >we would have to assume 0% = OFF and anything else = ON - a level
> device
> >should respond (be able to be controlled) by an ONOFF command
though.
> > Another way of looking at this is that Level= is used to report
> the
> >level of many different devices in one option - based on which
body
> part it
> >sits in whereas in the other option each sub has it's own unique
name
> value
> >pair - this has ramifications in repeating name value pairs within
a
> body
> >section - not unworkable - just needs consideration. MY thoughts
are
> now
> >moving towards NOT using State= and Level= but the sub instance
name.
> This
> >allows it's appearance in other body sections to be rapidly
> recognised, but
> >you still need to differentiate between setting it 'OutB=ON' and a
> status
> >report 'OutB=ON' based on context of the class.
> >
> >
> >
> > Kevin
> >
> >
> >
> >To unsubscribe from this group, send an email to:
> ><a
href="/group/xAP_developer/post?postID=MydAXyBDKxP7BdDH4d06xpmTpaUuBebs-SoPs2sBWWYea8wy1Z8UwZe0sypt6FYm7Mw75kOXFgV1lHnSAtv_Gm4vTKMYhODW1q2TL6jERM1i0w">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>
> >
> >
> >
>
>
>
> ------------------------ Yahoo! Groups Sponsor
---------------------~--
> >
> Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
> Printer at Myinks.com. Free s/h on orders $50 or more to the US
&amp;
> Canada. <a href="http://www.c1tracking.com/l.asp?cid=5511";>http://www.c1tracking.com/l.asp?cid=5511</a>
> <a href="http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/dpFolB/TM";>http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/dpFolB/TM</a>
>
---------------------------------------------------------------------~-
> >
>
> To unsubscribe from this group, send an email to:
> <a
href="/group/xAP_developer/post?postID=MydAXyBDKxP7BdDH4d06xpmTpaUuBebs-SoPs2sBWWYea8wy1Z8UwZe0sypt6FYm7Mw75kOXFgV1lHnSAtv_Gm4vTKMYhODW1q2TL6jERM1i0w">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>




To unsubscribe from this group, send an email to:
<a
href="/group/xAP_developer/post?postID=MydAXyBDKxP7BdDH4d06xpmTpaUuBebs-SoPs2sBWWYea8wy1Z8UwZe0sypt6FYm7Mw75kOXFgV1lHnSAtv_Gm4vTKMYhODW1q2TL6jERM1i0w">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>



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