Re: TSC.cmd / id

["Per" <per.malmberg@xxxxxxxxx>]

I'm not sure what happened to my reply I sent 10min ago, so sorry if this
is a double post.

I had some minutes left yesterday so I changed the output, it now looks as
follows:

--Temperature device
xap-header
{
v=13
hop=1
Source=MSure.xAPGateway.Bigboy:1-Wire.bathroom
Uid=FF.000001:0004
Class=TSC.info
}
info.temperature
{
value=19,875
datetime=20091125191200
unit=c
name=bathroom
}

--Switch device. Two of two messages shown. Currently using the BSC schema,
but although that one supports on/off devices there are some added pairs.
These devices also support both in- and output on the same pin...any
suggestions on best practice here?

xap-header
{
v=13
hop=1
Source=MSure.xAPGateway.Bigboy:1-Wire.D100000003AE661F.0
Uid=FF.000001:0027
Class=xAPBSC.info
}
info.state
{
ActivityDetected=1
DetectedLevel=On
LatchState=Off
DateTime=20091125191000
}

--Counter device, two of four messages shown.
xap-header
{
v=13
hop=1
Source=MSure.xAPGateway.Bigboy:1-Wire.counterboilerroom.0
Uid=FF.000001:002C
Class=TSC.event
}
event.Count
{
Value=0
DateTime=20091125192700
}

xap-header
{
v=13
hop=1
Source=MSure.xAPGateway.Bigboy:1-Wire.counterboilerroom.1
Uid=FF.000001:002D
Class=TSC.event
}
event.Count
{
Value=1
DateTime=20091125192800
}

-- A/D converter. Two of three messages shown.
xap-header
{
v=13
hop=1
Source=MSure.xAPGateway.Bigboy:1-Wire.humidityattic.0
Uid=FF.000001:0029
Class=TSC.event
}
event.voltage
{
Value=4,73
DateTime=20091125193500
}

xap-header
{
v=13
hop=1
Source=MSure.xAPGateway.Bigboy:1-Wire.humidityattic.1
Uid=FF.000001:002A
Class=TSC.event
}
event.voltage
{
Value=3,11
DateTime=20091125193500
}

Lasty, the A/D converter also has a temperature sensor, which is currently
not reported as a subnode as the voltages:

xap-header
{
v=13
hop=1
Source=MSure.xAPGateway.Bigboy:1-Wire.humidityattic
Uid=FF.000001:000F
Class=TSC.event
}
event.temperature
{
value=8,78125
datetime=20091125193900
unit=c
name=humidityattic
}

The reason is that the device interfaces (temperature, A/D) are read
separatly and thus translated separate from eachother. I'm not sure how to
best handle this, but had thoughts to add anotehr layer to all nodes;
<name>.temperature; <name>.analog etc. Any comments on this?

Cheers,

Per

--- In xAP_developer@xxxxxxx, Kevin Hawkins <yahoogroupskh@...>
wrote:
>
> Hi Per,
>
>     Using the BSC or TSC schema the issue with including several
blocks
> within one message  is that the identifier for the endpoint that is
> being reported is contained in the header,  as both a named sub
address
> (the portion of the address after the : ) and the last few digits of
the
> UID.  Hence all the block(s) content can only relate to this one
> endpoint and not more.     You had blocks for different endpoints in
one
> message.
>
>     This approach is strongly recommended in xAP now - i.e. as much
> addressing information as possible is contained in the header.  Some
> early schema were designed differently and the 'context' of the block
> was set by a parameter within the block, eg the device= in the X10 one
> below.    We found that this approach , whilst often understandable by
a
> person when they read the schema, was difficult for computers
> recognition without recourse to an electronic schema repository.  You
> can still design a schema this way should you wish of course, it's
just
> not so intuitive to interpret.
>
>     xap-x10.event
>     {
>     command=on
>     device=B3
>      }
>
>    example.event
>     {
>     light=red
>     ident=flashing
>     }
>
>        Not a brilliant example (still suffering from the wine last
> night)  but in the latter case it is unclear if the red light is now
> flashing or if the flashing light has been turned to a red colour
>
>    You will see that when we send xAPBSC.cmd  or TSC.cmd messages we
> support the target= address being wildcarded and then we support
> multiple indexed blocks within one message and each contains an ID=
> parameter to determine which endpoint is being addressed.  This was
> included to allow coincident changes to be made to a device and it
also
> means that all or none of the changes happen (should a cmd fail to
reach
> a destination).
>
>     So back to your point about the block indexing being 'recommended
> rather than mandatory' the point is that indexing is a recognised way
> for code to interpret the content of blocks as being identical.
> Additionally we do not (currently) apply any time based inference to
> parameters eg that earlier blocks or parameters within those blocks
> should be actioned before later ones.  This allows the message to be
> broken apart and stored in a structured way and just queried for
> parameter values.  Indexing identical blocks preserves some integrity
of
> order.
>
>     Lastly the comment about the schema specification and it's
> precedence over the v1.2 protocol specification.   The protocol spec
is
> defining  the allowable construction of all possible variants of a 
xAP
> message , however not all variants of a message are going to be useful
> or approriate in all schema .  For example many schema , including the
> X10 one above,  do not use sub addressing at all.    If the schema
uses
> sub addressing, as TSC does, then by definition that message content
> must only relate to the addressed endpoint from source=  .
>
>     Schema can just be seen as a higher layer protocol using xAP as a
> transport - nothing would actually break in xAP at the protocol layer
if
> you did add more blocks but it would not be logical or valid at the
> schema level.    The same is seen with high level protocols sitting on
> top of TCP for example.
>
>    cheers Kevin
>
>
> Per wrote:
> > Kevin,
> >
> > Regarding the naming of the message blocks the xAP protocol
specification, 1.2-9, states:
> >
> > Message Body Policy: ...Multiple message blocks may share the
same name if, and only if, they use the same schema. In array type
situations, it is recommended that message blocks are labelled with an
index...
> >
> > So, while it is recommended, it is not mandatory.
> >
> > You say that
> >
> > "However the BSC and TSC schema do not require (or support)
duplicate blocknames"
> >
> > All this makes me wonder about the relationship between the xAP
protocol specification and the different schemas. Correct me if I'm wrong,
but isn't the protocol spec. what defines how a xAP message is built and
parsed, and the schema defines which elements/block names that are to be
used?
> >
> > Based on your statement, one might make the conclusion that the
TSC schema takes precedence over the protocol specification. That can't be
right, can it?
> >
> > Regards,
> >
> > Per
> >
> >
> > --- In xAP_developer@xxxxxxx, Kevin Hawkins
<yahoogroupskh@> wrote:
> >
> >> Hi Per
> >>
> >>      I think you have two sensors reporting here , channel 0
and 1 ,
> >> although both are possibly within the same physical device. 
Best for
> >> TSC  if each sensor had a unique UID - and then the sub
address would
> >> perforce also be different for each , and so would the ID e.g
ID=ABCD
> >> ID=ABCE ... or ABCD01 ABCD02 or whatever
> >>
> >> You can't include two identically named blocks within one xAP
message
> >> either so as a rule these would have to be indexed as below
> >>
> >> info.state.1
> >> info.state.2   etc
> >>
> >> However the BSC and TSC schema do not require (or support)
duplicate
> >> blocknames so if you create separate sub addresses for these
endpoints
> >> they would then be sent as separate messages
> >>
> >> presence.status is not a defined part of the TSC schema
either but could
> >> be included should you wish  (as you can supplement whatever
custom
> >> blocks you like) but these might be better presented as an
additional
> >> xAP schema/message of your own design.
> >>
> >>  Late night Saturday work eh...  most impressed :-) - my
comments are
> >> post several wine bottles of wine and a party  so I hope they
are valid.
> >>
> >>     cheers  K
> >>
> >>  parameterPer wrote:
> >>
> >>> Hello,
> >>>
> >>> I'm a bit confused regarding the mandatory ID pair in the
TSC.cmd body.
> >>>
> >>> Based on the following xAP message, what would be the
correct ID value to set the latch on channel 1 to False be? I'd say ABCD,
but that'd be four characters and the spec limits it to two.
> >>>
> >>> Maybe I've missunderstood the sub addressing rules?
> >>>
> >>> xap-header
> >>> {
> >>> v=13
> >>> hop=1
> >>> Source=MSure.xAPGateway.Bigboy:D100000003AE661F
> >>> Uid=FF.000001:ABCD
> >>> Class=TSC.info
> >>> }
> >>> info.state
> >>> {
> >>> Channel=0
> >>> ActivityDetected=True
> >>> DetectedLevel=True
> >>> LatchState=False
> >>> DateTime=20091121233600
> >>> }
> >>> info.state
> >>> {
> >>> Channel=1
> >>> ActivityDetected=True
> >>> DetectedLevel=True
> >>> LatchState=True
> >>> DateTime=20091121233600
> >>> }
> >>> presence.status
> >>> {
> >>> connected=True
> >>> }
> >>>
> >>>
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>




------------------------------------