RE: Topic 1: Base Level Status Schema

[Kevin Hawkins]

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=o2GX4mELTFG_auqd1sGBGY2qsCqKRxohhzMuggcPsNjkPyqewBR-iV8HsuiPh5lxhdlVlo05FyWXpd06tqCjsORU">lists@u...</a>]
> >Sent: 01 September 2003 14:22
> >To: <a
href="/group/xAP_developer/post?postID=71WE4l9LOrZKUvVBs9s_l68YlEx9e3xbVozCzUl33cpPz2HWC-9VaN2B3MZEnfzTH2SZLf5ubK_acFMcV4A4ABgFBhP5fhg">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=QzZFp-XptC5eTm3xnkrrzOUUeDZbMF_vVhZzso6JHoeY5ytGDLvq3dV6j3xvEzRh0gg6WWf5MYfb1DMF4SnQRK4zqs4do-tA37EE1N0myGFsLQ">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=QzZFp-XptC5eTm3xnkrrzOUUeDZbMF_vVhZzso6JHoeY5ytGDLvq3dV6j3xvEzRh0gg6WWf5MYfb1DMF4SnQRK4zqs4do-tA37EE1N0myGFsLQ">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>