The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: TSC.cmd / id



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




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


xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.