Hi Mikko,

     I haven't myself had an opportunity to try your application but it
looks most useful.  However one user has done so and he has encountered
some problems with the xAP TSC implemenation.  I do appreciate that xAP
TSC is quite new and hence there are very few supportive applications
that you will have been able to test against so it's very
understandable.     I'd be very happy to work with you to try and get
the schema compliant with the draft TSC specification, the main issue
being the way separate sensors are identified.

     Also I've just put out a call to xAP Developers to try and improve
TSC support within their applications.   xAPBSC has almost ubiquitous
support and this has lead to near plug and play operation between xAP
applications.   It has also unfortunately lead to many people using
xAPBSC where in fact xAPTSC or some other schema is far more appropriate.

    The situation is a little bit 'chicken & egg' so I hope that we can
make some moves forward now and get more universal support as without it
your application will have found little adoption by the xAP community.
Let's see what happens, I shall also update my applications to support
TSC directly.

    Cheers Kevin


m.rintala wrote:
> Hi,
>
> I have released LogTemp (temperature etc. monitoring program) version with xAP
protocol. It's using TCS schema but still, I am not quite happy with this.
>
> Since there are quite a lot of different schemas available,
> no standardization will take place. Everybody is using own  schemas to
fullfill their own needs, therefore there are no markets for common tools etc.
>
> Anyway, you can find software http://www.mrsoft.fi/ohj01en.htm.
>
> Best regards,
>
> Mikko Rintala
> MR Soft
>
>
>
>

We have a bit of a Catch22 situation with xAP TSC.    Until we have
supporting applications then people don't want to write data sources and
vica versa and we can't ratify TSC into xAPTSC until it has some real
world experience...   Hence xAPBSC is being abused as non appropriate
data is shoehorned in, aprticularly by representing numeric data as a
text device.   So here's a call to xAP Developers to add support for TSC
within their existing applications and hopefully it will become as
successful as BSC.

Here's a copy of part of my response to a xAP Automation list post

    K

There is a bit of 'chicken & egg' here and so it is worth trying to see
if we can get better support for TSC within the key xAP applications -
especially the ones that already directly support BSC , as most of the
work is already done.

I know Daniel had mentioned he would look towards supporting TSC , and
it is particularly well suited towards 1-wire applications , although I
would recommend that BSC remains supported , at least transitionally.
Without such widespread adoption TSC will remain sidelined and BSC
abused instead.   Also there are few test applications to develop
against which doesn't help people like Mikko.   I remember KevinT has
some however and Lehane uses TSC extensively in his home project.

So I'll revisit my contributions and see what I can do here and
hopefully a couple of others will too.    Many applications will already
handle TSC as a generic schema as well but having the plug and play
integration in the same way that we have with TSC would be far preferable

Following Kevin's call-up request, I've revisited the TSC (v.42)
specification draft and have found some points that I would like to
discuss here:

1. TSC.query vs TSC.request
The document mixes both classes so I understand that it's an error.
Which is the correct class?

2. TSC for numeric values - BSC for states
I understand that BSC can still be used for many applications but I
believe that TSC should be able to manage binary states too.
Otherwise, we'll be force to do dual-implementations almost in any
device. BSC's main strengths are interoperability and the fact that
it's a common schema for all. I agree that TSC is a more complete
schema that could replace BSC for most applications but having to
manage TSC for numeric and BSC for binary is a nonsense in my opinion.
Why not using value=on/off in TSC too? From my point of view, we need
simple mechanisms capable to do complex things. One schema for all is
perfect for gateways and embedded controllers. Otherwise, we'll have
to manage with queries/commands from different schemas, send
duplicated events/infos, ... I also agree that we'll have to keep BSC
for backward compatibility in current designs but once TSC will be
widely adopted, TSC is a perfect candidate for becoming the main xAP
interoperable schema for control and telemetry applications.

3. Response to TSC.cmd resets
The specification states that the response to a TSC.cmd (counter)
reset has to be a TSC.info after having reseted the counter. This
breaks BSC's command/event query/info mechanisms and, will force us to
manage a exception when receiving RESET commands. Why not sending a
TSC.event after reseting the counter? Reseting a counter means that
the endpoint will change its value (if not 0 before that).

There are a lot of common points between BSC and TSC and I appreciate
this as it will simplify the adoption of the later schema. On the
other hand, all my suggestions are targeted to simplify the
implementation (lines of code and processing speed) and give more
power to TSC. Instead of creating a new schema, I'd have preferred to
enrich BSC with new fields but the creation of TSC is something good
because we have now the opportunity to customize this schema for M2M
apps. On the other hand, implementing new protocosl or schemas is
something time-costly so we'll have to be very precise and effective
in our work.

I vote for one schema for all in the M2M area. TSC for M2M and BSC for
basic home automation stuff. Isn't it too late for coming here with
such arguments?

Thanks for your time,

--
Daniel Berenguer
http://www.usapiens.com
http://www.opnode.org

Hi Kevin,

I can't speak for others but I was waiting for a wider adoption of TSC before
doing the jump :-)

Anyway, I agree that xAP applications will never adopt TSC if no device is using
this schema so it's maybe time to do something on this issue. I could try to
work on a TSC implementation for my new designs (opn-mbs, ...) as a way of
getting in touch with this new schema. Later, once TSC will be ratified, I could
port the work to older designs (opn-one and opn-max).

I believe that TSC brings some important improvements to the control&monitoring
scenario with regards to the old BSC schema. On the other hand, maintaining
multiple protocols/schemas in an embedded device is something costly in my
opinion. This was my case for the first versions of opn-one and opn-x10 where
xAP BSC, xAP X10 and xPL shared a common place in both gateways. Later, I
decided to switch to xAP BSC only because it was far easier to maintain and
simpler to understand by non-xAP people. This is the key in my opinion, xAP
needs to be something easy to understand and wasy to work with.

There are some other features about TSC that would need to be reconsidered IMHO
and I'll try to address these points from a different thread. I understand that
TSC (v42) is just a draft so I'll try to introduce my point of view (if it's not
too late...)

Regards,

Daniel.


--- In xAP_developer@yahoogroups.com, Kevin Hawkins <yahoogroupskh@...> wrote:
>
> We have a bit of a Catch22 situation with xAP TSC.    Until we have
> supporting applications then people don't want to write data sources and
> vica versa and we can't ratify TSC into xAPTSC until it has some real
> world experience...   Hence xAPBSC is being abused as non appropriate
> data is shoehorned in, aprticularly by representing numeric data as a
> text device.   So here's a call to xAP Developers to add support for TSC
> within their existing applications and hopefully it will become as
> successful as BSC.
>
> Here's a copy of part of my response to a xAP Automation list post
>
>    K
>
> There is a bit of 'chicken & egg' here and so it is worth trying to see
> if we can get better support for TSC within the key xAP applications -
> especially the ones that already directly support BSC , as most of the
> work is already done.
>
> I know Daniel had mentioned he would look towards supporting TSC , and
> it is particularly well suited towards 1-wire applications , although I
> would recommend that BSC remains supported , at least transitionally.
> Without such widespread adoption TSC will remain sidelined and BSC
> abused instead.   Also there are few test applications to develop
> against which doesn't help people like Mikko.   I remember KevinT has
> some however and Lehane uses TSC extensively in his home project.
>
> So I'll revisit my contributions and see what I can do here and
> hopefully a couple of others will too.    Many applications will already
> handle TSC as a generic schema as well but having the plug and play
> integration in the same way that we have with TSC would be far preferable
>

Hi Kevin,

I can't speak for others but I was waiting for a wider adoption of TSC before
doing the jump :-)

Anyway, I agree that xAP applications will never adopt TSC if no device is using
this schema so it's maybe time to do something on this issue. I could try to
work on a TSC implementation for my new designs (opn-mbs, ...) as a way of
getting in touch with this new schema. Later, once TSC will be ratified, I could
port the work to older designs (opn-one and opn-max).

I believe that TSC brings some important improvements to the control&monitoring
scenario with regards to the old BSC schema. On the other hand, maintaining
multiple protocols/schemas in an embedded device is something costly in my
opinion. This was my case for the first versions of opn-one and opn-x10 where
xAP BSC, xAP X10 and xPL shared a common place in both gateways. Later, I
decided to switch to xAP BSC only because it was far easier to maintain and
simpler to understand by non-xAP people. This is the key in my opinion, xAP
needs to be something easy to understand and wasy to work with.

There are some other features about TSC that would need to be reconsidered IMHO
and I'll try to address these points from a different thread. I understand that
TSC (v42) is just a draft so I'll try to introduce my point of view (if it's not
too late...)

Regards,

Daniel.


--- In xAP_developer@yahoogroups.com, Kevin Hawkins <yahoogroupskh@...> wrote:
>
> We have a bit of a Catch22 situation with xAP TSC.    Until we have
> supporting applications then people don't want to write data sources and
> vica versa and we can't ratify TSC into xAPTSC until it has some real
> world experience...   Hence xAPBSC is being abused as non appropriate
> data is shoehorned in, aprticularly by representing numeric data as a
> text device.   So here's a call to xAP Developers to add support for TSC
> within their existing applications and hopefully it will become as
> successful as BSC.
>
> Here's a copy of part of my response to a xAP Automation list post
>
>    K
>
> There is a bit of 'chicken & egg' here and so it is worth trying to see
> if we can get better support for TSC within the key xAP applications -
> especially the ones that already directly support BSC , as most of the
> work is already done.
>
> I know Daniel had mentioned he would look towards supporting TSC , and
> it is particularly well suited towards 1-wire applications , although I
> would recommend that BSC remains supported , at least transitionally.
> Without such widespread adoption TSC will remain sidelined and BSC
> abused instead.   Also there are few test applications to develop
> against which doesn't help people like Mikko.   I remember KevinT has
> some however and Lehane uses TSC extensively in his home project.
>
> So I'll revisit my contributions and see what I can do here and
> hopefully a couple of others will too.    Many applications will already
> handle TSC as a generic schema as well but having the plug and play
> integration in the same way that we have with TSC would be far preferable
>

It's certainly not too late Daniel,  I think we have to have a few real
implementations of TSC to see if it is actually fit for purpose and then
we can look to ratify and promote it more.

It was surprising how awkward even a simple schema like BSC became as
little nuances crept in , and of course this was partly due to people
trying to use it for purposes that it wasn't intended for.   TSC is very
heavilly based on BSC and so I'm kinda hoping that people who implement
TSC will also be able to support BSC without too much extra effort, and
vica versa. Certainly the core should be the same.  As to whether BSC
will, or should, eventually be replaced by TSC I'm not sure... maybe
over time but I had assumed they'd both continue to be used

There are some other aspects we need to address as well - including
implementing relative changes eg +10% and multiple choice / enumerated
devices and perhaps some sort of menu driven type mode, that may be
another schema derived from BSC.   Edward has a way of integrating
choice devcies within BSC which I use too - but it's non standard so we
haven't promoted it too much.

Whilst the true power of xAP comes from the ability to abstract complex
device functionality into schema I also recognise that the simple schema
- specifically BSC has been a great sucess and agree that we should
refine and expand this simple schema adoption to be both suitable and
easy to be adopted.

So let's get the discussion opened and get some devices and controllers
using the initial TSC proposal and see where we can refine it.

    K




tratosapiens wrote:
> Hi Kevin,
>
> I can't speak for others but I was waiting for a wider adoption of TSC before
doing the jump :-)
>
> Anyway, I agree that xAP applications will never adopt TSC if no device is
using this schema so it's maybe time to do something on this issue. I could try
to work on a TSC implementation for my new designs (opn-mbs, ...) as a way of
getting in touch with this new schema. Later, once TSC will be ratified, I could
port the work to older designs (opn-one and opn-max).
>
> I believe that TSC brings some important improvements to the
control&monitoring scenario with regards to the old BSC schema. On the other
hand, maintaining multiple protocols/schemas in an embedded device is something
costly in my opinion. This was my case for the first versions of opn-one and
opn-x10 where xAP BSC, xAP X10 and xPL shared a common place in both gateways.
Later, I decided to switch to xAP BSC only because it was far easier to maintain
and simpler to understand by non-xAP people. This is the key in my opinion, xAP
needs to be something easy to understand and wasy to work with.
>
> There are some other features about TSC that would need to be reconsidered
IMHO and I'll try to address these points from a different thread. I understand
that TSC (v42) is just a draft so I'll try to introduce my point of view (if
it's not too late...)
>
> Regards,
>
> Daniel.
>
>
> --- In xAP_developer@yahoogroups.com, Kevin Hawkins <yahoogroupskh@...> wrote:
>
>> We have a bit of a Catch22 situation with xAP TSC.    Until we have
>> supporting applications then people don't want to write data sources and
>> vica versa and we can't ratify TSC into xAPTSC until it has some real
>> world experience...   Hence xAPBSC is being abused as non appropriate
>> data is shoehorned in, aprticularly by representing numeric data as a
>> text device.   So here's a call to xAP Developers to add support for TSC
>> within their existing applications and hopefully it will become as
>> successful as BSC.
>>
>> Here's a copy of part of my response to a xAP Automation list post
>>
>>    K
>>
>> There is a bit of 'chicken & egg' here and so it is worth trying to see
>> if we can get better support for TSC within the key xAP applications -
>> especially the ones that already directly support BSC , as most of the
>> work is already done.
>>
>> I know Daniel had mentioned he would look towards supporting TSC , and
>> it is particularly well suited towards 1-wire applications , although I
>> would recommend that BSC remains supported , at least transitionally.
>> Without such widespread adoption TSC will remain sidelined and BSC
>> abused instead.   Also there are few test applications to develop
>> against which doesn't help people like Mikko.   I remember KevinT has
>> some however and Lehane uses TSC extensively in his home project.
>>
>> So I'll revisit my contributions and see what I can do here and
>> hopefully a couple of others will too.    Many applications will already
>> handle TSC as a generic schema as well but having the plug and play
>> integration in the same way that we have with TSC would be far preferable
>>
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

Hey - great James - it's amazing you go quiet for a few hours and then
great things happen :-)

     K

James wrote:
>
>
>
>
> http://mi4.biz/files/xapfloorplan/floorplantsctest.zip
>
>
> Hopefully this is a start.  It supports TSC pretty much the same way
> it does with BSC devices.
>>
>>
>
>
>
>

4. I'd prefer to do

unit=(unit designation)
-- desirable

rather than

unit=(unit designation)
-- mandatory

Thus, instead of doing unit=arb, the sender wouldn't include this field in the
body. This is a way of compacting information a little more, mainly if my second
suggestion gets somehow accepted :-)

Daniel.

--- In xAP_developer@yahoogroups.com, Daniel Berenguer <dberenguer@...> wrote:
>
> Following Kevin's call-up request, I've revisited the TSC (v.42)
> specification draft and have found some points that I would like to
> discuss here:
>
> 1. TSC.query vs TSC.request
> The document mixes both classes so I understand that it's an error.
> Which is the correct class?
>
> 2. TSC for numeric values - BSC for states
> I understand that BSC can still be used for many applications but I
> believe that TSC should be able to manage binary states too.
> Otherwise, we'll be force to do dual-implementations almost in any
> device. BSC's main strengths are interoperability and the fact that
> it's a common schema for all. I agree that TSC is a more complete
> schema that could replace BSC for most applications but having to
> manage TSC for numeric and BSC for binary is a nonsense in my opinion.
> Why not using value=on/off in TSC too? From my point of view, we need
> simple mechanisms capable to do complex things. One schema for all is
> perfect for gateways and embedded controllers. Otherwise, we'll have
> to manage with queries/commands from different schemas, send
> duplicated events/infos, ... I also agree that we'll have to keep BSC
> for backward compatibility in current designs but once TSC will be
> widely adopted, TSC is a perfect candidate for becoming the main xAP
> interoperable schema for control and telemetry applications.
>
> 3. Response to TSC.cmd resets
> The specification states that the response to a TSC.cmd (counter)
> reset has to be a TSC.info after having reseted the counter. This
> breaks BSC's command/event query/info mechanisms and, will force us to
> manage a exception when receiving RESET commands. Why not sending a
> TSC.event after reseting the counter? Reseting a counter means that
> the endpoint will change its value (if not 0 before that).
>
> There are a lot of common points between BSC and TSC and I appreciate
> this as it will simplify the adoption of the later schema. On the
> other hand, all my suggestions are targeted to simplify the
> implementation (lines of code and processing speed) and give more
> power to TSC. Instead of creating a new schema, I'd have preferred to
> enrich BSC with new fields but the creation of TSC is something good
> because we have now the opportunity to customize this schema for M2M
> apps. On the other hand, implementing new protocosl or schemas is
> something time-costly so we'll have to be very precise and effective
> in our work.
>
> I vote for one schema for all in the M2M area. TSC for M2M and BSC for
> basic home automation stuff. Isn't it too late for coming here with
> such arguments?
>
> Thanks for your time,
>
> --
> Daniel Berenguer
> http://www.usapiens.com
> http://www.opnode.org
>

Following my own considerations...

We could implement point 2 without altering the current spec as follows:

value=[0, 1]
min=0
max=1

Thus we get a nice binary signal through TSC.

Daniel.


--- In xAP_developer@yahoogroups.com, "estratosapiens" <dberenguer@...> wrote:
>
> 4. I'd prefer to do
>
> unit=(unit designation)
> -- desirable
>
> rather than
>
> unit=(unit designation)
> -- mandatory
>
> Thus, instead of doing unit=arb, the sender wouldn't include this field in the
body. This is a way of compacting information a little more, mainly if my second
suggestion gets somehow accepted :-)
>
> Daniel.
>
> --- In xAP_developer@yahoogroups.com, Daniel Berenguer <dberenguer@> wrote:
> >
> > Following Kevin's call-up request, I've revisited the TSC (v.42)
> > specification draft and have found some points that I would like to
> > discuss here:
> >
> > 1. TSC.query vs TSC.request
> > The document mixes both classes so I understand that it's an error.
> > Which is the correct class?
> >
> > 2. TSC for numeric values - BSC for states
> > I understand that BSC can still be used for many applications but I
> > believe that TSC should be able to manage binary states too.
> > Otherwise, we'll be force to do dual-implementations almost in any
> > device. BSC's main strengths are interoperability and the fact that
> > it's a common schema for all. I agree that TSC is a more complete
> > schema that could replace BSC for most applications but having to
> > manage TSC for numeric and BSC for binary is a nonsense in my opinion.
> > Why not using value=on/off in TSC too? From my point of view, we need
> > simple mechanisms capable to do complex things. One schema for all is
> > perfect for gateways and embedded controllers. Otherwise, we'll have
> > to manage with queries/commands from different schemas, send
> > duplicated events/infos, ... I also agree that we'll have to keep BSC
> > for backward compatibility in current designs but once TSC will be
> > widely adopted, TSC is a perfect candidate for becoming the main xAP
> > interoperable schema for control and telemetry applications.
> >
> > 3. Response to TSC.cmd resets
> > The specification states that the response to a TSC.cmd (counter)
> > reset has to be a TSC.info after having reseted the counter. This
> > breaks BSC's command/event query/info mechanisms and, will force us to
> > manage a exception when receiving RESET commands. Why not sending a
> > TSC.event after reseting the counter? Reseting a counter means that
> > the endpoint will change its value (if not 0 before that).
> >
> > There are a lot of common points between BSC and TSC and I appreciate
> > this as it will simplify the adoption of the later schema. On the
> > other hand, all my suggestions are targeted to simplify the
> > implementation (lines of code and processing speed) and give more
> > power to TSC. Instead of creating a new schema, I'd have preferred to
> > enrich BSC with new fields but the creation of TSC is something good
> > because we have now the opportunity to customize this schema for M2M
> > apps. On the other hand, implementing new protocosl or schemas is
> > something time-costly so we'll have to be very precise and effective
> > in our work.
> >
> > I vote for one schema for all in the M2M area. TSC for M2M and BSC for
> > basic home automation stuff. Isn't it too late for coming here with
> > such arguments?
> >
> > Thanks for your time,
> >
> > --
> > Daniel Berenguer
> > http://www.usapiens.com
> > http://www.opnode.org
> >
>

Greetings all,

Let me introduce myself; the name's Per Malmberg and I'm the author of MSure
(pronounced 'measure'), an application that serves as a foundation to a
Windows-based HA system.

I am happy to announce that MSure is currently in the process of gaining xAP
support, or at least partial support, which is the reason I'm posting here
today.

Although I am aware that the TSC schema wasn't finalized yet, I opted to use
that schema as it seemed to fit quite well with the data I'm publishing.

However, based on the recent discussions regarding this schema I am wondering
where it is headed, and if I should stay with it. I don't mind supporting this
schema although it is not finalized, but if there are major changes coming I
very much would like to know that so I can 'take a step back' and wait a while
with the release of my xAP Gateway module, or at least add support for another
schema, such as BSC.

Also, the specification isn't clear on all points as to what is required to be
compliant with the schema. For example, are .cmd and .query mandatory?

That's all for now. You can find the website here: http://www.msure.se and
specifics on the xAP Gateway module here:
http://www.msure.se/wiki/index.php5?title=Manual:Modules/xAP_Gateway

Regards,

Per

Welcome Per, nice to have you on board.

      As you say we are in early days re the adoption of TSC - we do need
some real world implementation feedback so that we know that the schema
meets the purpose it is designed for.   We also of course need more
applications to support it - but in turn they need data sources to test
against. Having your application available will be another helpful
part.  My recommendation would be to continue with TSC as I think you
will find it much more appropriate for your application than BSC.

     I hope that developers do add support for TSC and James has just
released a xAP Floorplan build that already does and I have provisional
support in my HomeVision/C-Bus/IHC gateway.  Most control applications
already have the ability to support custom schema so TSC data can be
recovered but more specific support makes this so much tidier.

     TSC is derived from BSC and so you may well find that you are able
to support BSC very easily alongside TSC which will maximise existing
support and adoption for your application.  BSC is pervasively supported
by nearly all xAP control applications and controllers.  It is possible
to report sensor data and their measurement units using BSC by abusing a
text device rather than a level device , and this approach has been used
by several developers, but this practice will I hope be superceded by TSC.

     From a database logging aspect then it looks like you are already
fairly able to support any schema which is great.  BSC would be one of
the key schema found here.

     Re Any major changes to TSC  - I am not aware of any.  I am acutely
aware there is still no formal xAP v1.3 specification out there but as
long as you are aware of the UID change for v1.3 that is essentially the
only aspect that has an impact on TSC.

     Re .cmd and .query support within TSC.   My view would be that any
TSC device that has listening ability and codespace should support
.query and any device that has controllable outputs should support .cmd
messages.   The  .query is required for any controller at startup to
synch it's status with your device and also has uses for device
discovery.   Wildcarding is another aspect that you need to consider and
although not so critical in terms of input only devices (as you can
return all sensor information regardless) it is most important that it
works correctly for outputs  .   Partial TSC/BSC implementations only
lead to confusion and frustration from users.

    Any questions I'm more than happy to try and help - and I'm sure
others who worked with TSC will chime in too....   TSC is an interactive
(bi-directional) schema which takes a little more care in getting it
just right but the results merit the investment.

   Looking forward to the results..

     cheers Kevin



per.malmberg@... wrote:
> Greetings all,
>
> Let me introduce myself; the name's Per Malmberg and I'm the author of MSure
(pronounced 'measure'), an application that serves as a foundation to a
Windows-based HA system.
>
> I am happy to announce that MSure is currently in the process of gaining xAP
support, or at least partial support, which is the reason I'm posting here
today.
>
> Although I am aware that the TSC schema wasn't finalized yet, I opted to use
that schema as it seemed to fit quite well with the data I'm publishing.
>
> However, based on the recent discussions regarding this schema I am wondering
where it is headed, and if I should stay with it. I don't mind supporting this
schema although it is not finalized, but if there are major changes coming I
very much would like to know that so I can 'take a step back' and wait a while
with the release of my xAP Gateway module, or at least add support for another
schema, such as BSC.
>
> Also, the specification isn't clear on all points as to what is required to be
compliant with the schema. For example, are .cmd and .query mandatory?
>
> That's all for now. You can find the website here: http://www.msure.se and
specifics on the xAP Gateway module here:
http://www.msure.se/wiki/index.php5?title=Manual:Modules/xAP_Gateway
>
> Regards,
>
> Per
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

Ok, I will stick with the TSC schema, and add .query and .cmd support.

I'll likey be back soon with more questions!



Cheers,

Per


--- In xAP_developer@yahoogroups.com, Kevin Hawkins <yahoogroupskh@...>
wrote:
>
> Welcome Per, nice to have you on board.
>
> As you say we are in early days re the adoption of TSC - we do need
> some real world implementation feedback so that we know that the
schema
> meets the purpose it is designed for. We also of course need more
> applications to support it - but in turn they need data sources to
test
> against. Having your application available will be another helpful
> part. My recommendation would be to continue with TSC as I think you
> will find it much more appropriate for your application than BSC.
>
> I hope that developers do add support for TSC and James has just
> released a xAP Floorplan build that already does and I have
provisional
> support in my HomeVision/C-Bus/IHC gateway. Most control applications
> already have the ability to support custom schema so TSC data can be
> recovered but more specific support makes this so much tidier.
>
> TSC is derived from BSC and so you may well find that you are able
> to support BSC very easily alongside TSC which will maximise existing
> support and adoption for your application. BSC is pervasively
supported
> by nearly all xAP control applications and controllers. It is possible
> to report sensor data and their measurement units using BSC by abusing
a
> text device rather than a level device , and this approach has been
used
> by several developers, but this practice will I hope be superceded by
TSC.
>
> From a database logging aspect then it looks like you are already
> fairly able to support any schema which is great. BSC would be one of
> the key schema found here.
>
> Re Any major changes to TSC - I am not aware of any. I am acutely
> aware there is still no formal xAP v1.3 specification out there but as
> long as you are aware of the UID change for v1.3 that is essentially
the
> only aspect that has an impact on TSC.
>
> Re .cmd and .query support within TSC. My view would be that any
> TSC device that has listening ability and codespace should support
> .query and any device that has controllable outputs should support
.cmd
> messages. The .query is required for any controller at startup to
> synch it's status with your device and also has uses for device
> discovery. Wildcarding is another aspect that you need to consider and
> although not so critical in terms of input only devices (as you can
> return all sensor information regardless) it is most important that it
> works correctly for outputs . Partial TSC/BSC implementations only
> lead to confusion and frustration from users.
>
> Any questions I'm more than happy to try and help - and I'm sure
> others who worked with TSC will chime in too.... TSC is an interactive
> (bi-directional) schema which takes a little more care in getting it
> just right but the results merit the investment.
>
> Looking forward to the results..
>
> cheers Kevin
>
>
>
> per.malmberg@... wrote:
> > Greetings all,
> >
> > Let me introduce myself; the name's Per Malmberg and I'm the author
of MSure (pronounced 'measure'), an application that serves as a
foundation to a Windows-based HA system.
> >
> > I am happy to announce that MSure is currently in the process of
gaining xAP support, or at least partial support, which is the reason
I'm posting here today.
> >
> > Although I am aware that the TSC schema wasn't finalized yet, I
opted to use that schema as it seemed to fit quite well with the data
I'm publishing.
> >
> > However, based on the recent discussions regarding this schema I am
wondering where it is headed, and if I should stay with it. I don't mind
supporting this schema although it is not finalized, but if there are
major changes coming I very much would like to know that so I can 'take
a step back' and wait a while with the release of my xAP Gateway module,
or at least add support for another schema, such as BSC.
> >
> > Also, the specification isn't clear on all points as to what is
required to be compliant with the schema. For example, are .cmd and
.query mandatory?
> >
> > That's all for now. You can find the website here:
http://www.msure.se and specifics on the xAP Gateway module here:
http://www.msure.se/wiki/index.php5?title=Manual:Modules/xAP_Gateway
> >
> > Regards,
> >
> > Per
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>

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
}

The spec has not been updated to reflect the extended UID in v1.3.
The ID is indeed the same as the sub part of the UID. ABDC in this case.
The same appiles to BSC.

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

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@yahoogroups.com, 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
> >
> >
> >
> >
> >
>

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@yahoogroups.com, 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
>
>
>
>
>

Per - I'm sure you already know - but you could use the 1-wire ID as the
end portion of the UID should you wish ..  and then use a name for the
device in the source= line.   1-wire devices like this that have
multiple endpoints within them could be expanded by a couple of digits -
if used as part of the UID.  It does mean you having to use the longer
value for ID= in TSC.cmd messages however.

Or you could keep an internal table for the 1-wire ID and hence use less
digits.  Using less digits in the UID is recommended if possible as some
small embedded devcies might not have enough space for 16 or 18 digit
values.    Your approach has advantages here as you were only using 4 digits

Source=MSure.xAPGateway.Bigboy:D100000003AE661F
Uid=FF.000001:ABCD


Source=MSure.xAPGateway.Bigboy:Fan
Uid=FF.000001:D100000003AE661F


Source=MSure.xAPGateway.Bigboy:Fan.main
Uid=FF.000001:D100000003AE661F01

    Cheers K


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

Ok, tanks for clearing that up, Edward.

--- In xAP_developer@yahoogroups.com, Edward Pearson <xap@...> wrote:
>
> The spec has not been updated to reflect the extended UID in v1.3.
> The ID is indeed the same as the sub part of the UID. ABDC in this case.
> The same appiles to BSC.
>

Kevin,

Ok, so as much as possible of the adressing in the header, which implies one
message for each separate endpoint - unless the target is using a wildcard, at
which time the ID pair is used to determine the final endpoint for each
individual block.

I'll have a go at implementing more strictly according to TSC, I'll likely be
back soon!

Cheers,

Per

--- In xAP_developer@yahoogroups.com, 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@yahoogroups.com, 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
> >
> >
> >
> >
> >
>

Actually, I've never thought of it. But as you say, using 4 instead of 16 or
more characters will make it more compatible with embedded devices.

Thanks

// Per

--- In xAP_developer@yahoogroups.com, Kevin Hawkins <yahoogroupskh@...> wrote:
>
> Per - I'm sure you already know - but you could use the 1-wire ID as the
> end portion of the UID should you wish ..  and then use a name for the
> device in the source= line.   1-wire devices like this that have
> multiple endpoints within them could be expanded by a couple of digits -
> if used as part of the UID.  It does mean you having to use the longer
> value for ID= in TSC.cmd messages however.
>
> Or you could keep an internal table for the 1-wire ID and hence use less
> digits.  Using less digits in the UID is recommended if possible as some
> small embedded devcies might not have enough space for 16 or 18 digit
> values.    Your approach has advantages here as you were only using 4 digits
>
> Source=MSure.xAPGateway.Bigboy:D100000003AE661F
> Uid=FF.000001:ABCD
>
>
> Source=MSure.xAPGateway.Bigboy:Fan
> Uid=FF.000001:D100000003AE661F
>
>
> Source=MSure.xAPGateway.Bigboy:Fan.main
> Uid=FF.000001:D100000003AE661F01
>
>    Cheers K
>
>
> Per 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
> >
> >
> >
> >
> >
>

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@yahoogroups.com, 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@yahoogroups.com, 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
> >
> >
> >
> >
> >
>

Hello again,

I got some minutes over last night and changed the output. They now looks as
follows. I would very much like some feedback :)

-- Switch-device with four I/O. Two out of four messages shown. Unique UID for
each. Currently using the the BSC schema since it supports on/off devices, but
that's not sufficient since these devices supports both in- and output mode,
with level and activity detection. Suggestions on how to handle them?

xap-header
{
v=13
hop=1
Source=MSure.xAPGateway.Bigboy:1-Wire.LCDSmallHallway.0
Uid=FF.000001:001F
Class=xAPBSC.info
}
info.state
{
ActivityDetected=0
DetectedLevel=On
LatchState=On
DateTime=20091125182957
}

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

--Temperature device
xap-header
{
v=13
hop=1
Source=MSure.xAPGateway.Bigboy:1-Wire.freshair
Uid=FF.000001:0009
Class=TSC.info
}
info.temperature
{
value=11,5
datetime=20091125182900
unit=c
name=freshair
}

--A/D converter, one of three messages shown. Unique UID for each.
xap-header
{
v=13
hop=1
Source=MSure.xAPGateway.Bigboy:1-Wire.humidityattic.0
Uid=FF.000001:0029
Class=TSC.event
}
event.voltage.0
{
Value=4,71
DateTime=20091125184000
}

And lastly, an issue I'm not sure how I should handle. The A/D converter also
has a temperature sensor which is currently being reported as:

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

As you can see, it is not marked as a subnode to the 1-Wire.humidityattic source
like the voltage-messages. Is this valid or do I have to make it a subnode too?
The reason it is not already, is that each device interface (temperature, A/D)
are internally published separately and thus translated into xAP separated from
each other.

Cheers,

Per

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@yahoogroups.com, 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@yahoogroups.com, 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
>
>
>
>
>

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@yahoogroups.com, 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@yahoogroups.com, 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@yahoogroups.com, 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
> >
> >
> >
> >
> >
>

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@yahoogroups.com, "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@yahoogroups.com, 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@yahoogroups.com, 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@yahoogroups.com, 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
> > >
> > >
> > >
> > >
> > >
> >
>