RE: xAPFloorPlan & Room Temperatures

["Neil Frost" <neil@xxxxxxxxxxxxx>]

------_=_NextPart_001_01C6D116.A881F2F6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Thanks Kevin,

I did read it... ;) It all makes sense, looks like I'll be moving to  xAP
TOM10 app then...

Any recommendations?

Thanks Neil

-----Original Message-----
From: xap_automation@xxxxxxx on behalf of Kevin Hawkins
Sent: Tue 05/09/2006 17:41
To: xap_automation@xxxxxxx
Subject: Re: [xap_automation] xAPFloorPlan & Room Temperatures

Hi Neil,

This isn't going to answer your question on 'how to' - I'll leave
that to James but it will explain why this is awkward and how different
originating schema design can avoid the problem . xAP  already includes
some features that achieve this, and, at the very end I extol the
virtues of the xAP BSC schema which illustrate this nicely.  BTW this
reply has turned into a classic case of KH waffle so only read on if
you're curious !!

Basically, it is a design issue about trying  to keep all
addressing and context information outside of a data block and in a
header, either the blockname or the source address.  Your example is one
of those nasty situations that keep cropping up where the 'context' of
one parameter in a block is set by the value of another parameter(s) .
In this case the context of 'current' (25.18) in the xPL block is set by
the value of 'device' (bathroom), maybe even by 'type' too.  To
understand what 'current' refers to you have to interpret 'device' and
'type'.  A listener has to know that 'device' acts as a 'context
identifier' , and probably in this case 'type' too because a humidity
sensor in the bathroom would likely just change the type value to
=humidity .   The result is that any hardware/software controllers ,
like xAP Floorplan for example,  need specific schema knowledge to
recover and interpret values from such schema, requiring that the
interpretation is inbuilt , or that the schema is defined in and
accessible from an available repository .  Popular schema like
sensor.basic are so frequent they can be accommodated by specific code
support but other less popular schema create real problems.  This often
happens where schema are rapidly designed and all parameters are just
reported in one block.  Human understanding allows you to guess that
'type' and 'device' set the context of 'value' , but machines can't
apply this meaning. The schema definition does of course IF it is
available in suitable form.

This isn't a good example as I hope nobody could create such an
ambiguous schema but take a look at....

{
Reading=Temperature
Sensor=Barometer
Input=WaterLevel
Value=22.52
State=Alarm
}

Now...what 'Value' and 'State' is the above schema actually
reporting ?  Indeed how would a controller know 'Value' and 'State' are
the reported values, people only guess by parameter name interpretation.
The reported values could be temperature, or pressure or even water
level .  The 'context' of Value and also State is apparently being
established by other parameters but you can't tell which ... nor could a
controller unless it knows about the schema definition which is
obviously really problematic.   Indeed Value and State may relate to
different contexts eg WaterLevel=22.52 and Temperature=Alarm.

Fortunately xAP tends to suffer much less from this as we permit
longer addresses with more hierarchies, including the naming of
(multiple) blocks within one message.   This allows some identification
of different devices outside of the block data .  There are still schema
in xAP that exhibit this problem though.  In  xAP v1.2 we added  an even
more powerful feature called sub addressing where we segment a master
'device' into multiple endpoints, each which can be named and
addressed.  In xAP as an example the reported message might look like ..
(note the : in the source address which identifies 'Bathroom' as the sub
address)
...
Source=ACME.Sensor.machine:Bathroom
...
}
current
{
temp=25.18
humidity=65.2
}
average
{
temp=23.1
humidity=55.8
}


Here you see that the endpoint 'Bathroom' includes temp and humidity
values with both current and average values and crucially the 'Bathroom'
context and actually also say 'current' and 'average' are separated from
the actual data block  - parameter names are also more descriptive.  We
could alternatively have used blocknames like 'temp'   and maybe
reported current=25.18 and average=23.1 as an alternative which creates
generic parameter names.

Alternatively this could be a single sensor value reported something like
..

Source=ACME.Sensor.machine:Bathroom.Humidty        (Bathroom.Humidty is
the endpoint/sub address)
and another
Source=ACME.Sensor.machine:Bathroom.Temperature
(Bathroom.Temperature is the endpoint/sub address)

again reported with current and average values.

Huge benefit :-)   It now makes it so much easier for a controller to
recover the vales as "Source + blockname + parameter" are unique
eg "ACME.Sensor.machine:Bathroom + average + humidty" ie no other
parameter changes the context of that value.

xAP BSC is a simple but powerful schema that utilises this sub
addressing to great effect - and offers other benefits like wildcard
addressing permitting things like

Target=>:Bathroom.>  to solicit responses from

ACME.Sensor.machine:Bathroom.Humidty
ACME.Sensor.machine:Bathroom.Temperature
but not from
ACME.Sensor.machine:Lounge.Temperature

or

Target=>:*.Temperature  to solicit responses from

ACME.Sensor.machine:Bathroom.Temperature
ACME.Sensor.machine:Lounge.Temperature
but not from
ACME.Sensor.machine:Bathroom.Humidty

You can choose your own number of hierarchies in xAP - both before and
after the :

The xAP TOM10 conduits use BSC to report their temperatures , actually
using a 'text' device rather than a 'level' one.  TOM10 presents itself
as one xAP device segmented into 10 endpoints, one for each sensor.
Ideally such a device might also report using a richer telemetry schema
too , providing extra information like averages, min, max, units etc ;-)

Discovery is also inbuilt in BSC - allowing the TOM10 to be identified
as a 10 sensor device - and even more complex devices like the xAP
Netiom to be identified as a 104 endpoint device (guessing here) with
each endpoints capabilities declared .  Inputs and Outputs are
separately identified and also their type as either BINARY (on/off)
LEVEL ( 0-whatever in any # steps) or STREAM ( a sequence of data eg
text values or serial data).  The end result is that BSC devices become
almost plug and play within xAP and third party controllers, both
hardware and software, can use such devices instantly.


Kevin




Neil Frost wrote:
>
> Thanks James,
>
> I had a look, the xPL message i am getting is:
>
> xpl-stat
> {
> hop=1
> source=gshed-tom10.thefrosts
> target=*
> }
> sensor.basic
> {
> device=Bathroom
> type=temp
> current=25.18
> }
>
> I translated that to be:
>
> Alias=Bathroom Temp
> Source=gshed-tom10.thefrosts
> Class=sensor
> Section=basic
> Item=current
>
> but how do I specify the device? i.e. that its the bathroom
> temperature and not another one?
>
> thanks
> Neil
>
> ________________________________
>
> From: xap_automation@xxxxxxx
> <mailto:xap_automation%40yahoogroups.com>
on behalf of James
> Sent: Mon 04/09/2006 19:28
> To: xap_automation@xxxxxxx
> <mailto:xap_automation%40yahoogroups.com>
> Subject: Re: [xap_automation] xAPFloorPlan & Room Temperatures
>
> If the data is already in an xPL message and you have xPL support
turned
> on in Floorplan (bridging can be on or off, it doesn't matter) Then
you
> can just add xPL raw devices in the same form that you enter raw xAP
> devices.
> If you look here:
> http://www.mi4.biz/modules.php?name=Content&pa=showpage&pid=54
> <http://www.mi4.biz/modules.php?name=Content&pa=showpage&pid=54>
>
> and look at the *'Ability to receive xPL data and display on a
> floorplan' section
>
> hth
>
> James
> *
> Kevin Hawkins wrote:
> > Yes - you could forward the information via a suitable schema
(even say
> > an OSD message) from xPL to xAP and then display that info in
Floorplan,
> > (or you could use one of the xAP connectors for TOM10).
> > I don't know which xPL schema is used for TOM10 but it maybe that
it's
> > an already supported one in the bridge ( 'sensor' to BSC perhpas
?) -
> > have you tried it ?
> >
> > Kevin
> >
> > Neil Frost wrote:
> >
> >> Hi,
> >>
> >> Is it possible for xAPFloorPlan to display the room
temperatures?
> >>
> >> I have a TOM10 with a couple of sensors and I'm currently
capturing
> >> the temperatures to SQL database using xPL and was wondering
if
> >> Floorplan could display this, or have it's own plug in???
> >>
> >> thanks
> >>
> >> Neil
> >>
> >>
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
> Yahoo! Groups Links
>
>