RE: Topic 1: Base Level Status Schema

[Ian B]

>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?

>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?

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. 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=SVbtiTzi1SwTbTy1EyEfrf5eqcOASWira0hRoBbSqUrib3Xu3wlZBC37UY0CU1K9EzCcLQB0HLa1OWVDHQVuGzkr">lists@u...</a>]
>Sent: 01 September 2003 14:22
>To: <a
href="/group/xAP_developer/post?postID=Fit_XOQehrNHZ3SZlneLD-4idj2Hs9_Bv80B40tPOBFzBzx6AszVL-MgD5R7uSZh6yG3cr76PBgI_-qidJM-wTpMktS6c7Y">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=h_RushkRTACUHGpnajo8UX5NeuYnBUOYe_Ql4HvtXP7n14_3P-mVF_8BT3da4n1ydR32ArginBiXhPi-AzMOGuxKfPAvs4B82kbh6fvBqA">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>
>
>
>