Re: Re: TSC.cmd / id

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

Hi Per,

The first few posts by new members of the group are moderated on
Yahoo groups - and I was out tonight - I guess the other moderators were
too.   I think it's the first five posts but regardless I have manually
changed you to non moderated now so your posts should appear fairly
quickly in the future.

It's very late tonight now so I'll look over the TSC messages  in
the morning .

Just quickly I did look at the BSC message and  the block must be
named input.state.  Within that block it is mandatory to have a state=
parameter and then none or either (but not both) of level= or text= .
Lastly you can include an optional DisplayText= parameter.    Extra
parameters will not break anything in xAP but also will not be
recognised by most devices or software.

If you have a device that has input and output on the same pin then
it will have to be an output device as otherwise you can't control
it.    Not quite sure how such a pin works but if it is either/or then
you could report according to it's mode - or alternatively break it into
two endpoints (even though it is actually only one phsical pin) .

Cheers Kevin

Per wrote:
> 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
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>



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