RE: Topic 1: Base Level Status Schema

[Kevin Hawkins]

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