Re: TSC.cmd / id

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

I got an idea this evening, on how to handle the 1-Wire-to-xAP conversion
without restricting the support for one single schema for published
messages (much like the xAP-to-database feature). xAP commands will of
course still need to follow the respective schema. A discussion is
currently taking place on the forum here: http://www.msure.se/forum/index.php/topic,618.msg5635.html#msg5635

Feel free to join in.

Cheers,

Per

--- In xAP_developer@xxxxxxx, "Per" <per.malmberg@...>
wrote:
>
> 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
> > >
> > >
> > >
> > >
> > >
> >
>




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