Re: TSC.cmd / id

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

Hm, the posting-page only gave a 'moderator-warning' for new threads,
nothing was indicated for replies. Ah well, I guess that's sorted now :)

The two-way I/O pin is a standard open drain I/O with added internal sensor
used in most ICs. See Figure 11 in http://datasheets.maxim-ic.com/en/ds/DS2406.pdf

You're right of course regarding the BSC block; shamefull I didn't get that
right.

// Per

--- In xAP_developer@xxxxxxx, Kevin Hawkins <yahoogroupskh@...>
wrote:
>
> 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
> >
> >
> >
> >
> >
>




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