Re: xAPFloorPlan & Room Temperatures

["JamesTraynor" <james@xxxxxxx>]

It then gets more awkward, especially for Floorplan, as xPL put
context throughout messages in most schemas and this was one of the
original reasons for me going xAP rather than xPL, but that's also
another story.
Anyways, don't worry Floorplan to the rescue.  When you define a raw
device you will see 3 'Item Value Pairs', these are entered in the
form item=value, so in your example:

xpl-stat
{
hop=1
source=gshed-tom10.thefrosts
target=*
}
sensor.basic
{
device=Bathroom
type=temp
current=25.18
}

becomes:

Alias=Bathroom Temp
Source=gshed-tom10.thefrosts
Class=sensor
Section=basic
Item=current
ItemValuePair1=device=Bathroom

The only thing to bare in mind is that the itemvalue pairs only refer
to the message block where the item is stored. This, of course,
doesn't matter to xPL as it only uses one block but it does matter for
xAP.

I'll be on xAP Talk later if you have any questions

James
--- In xap_automation@xxxxxxx, Kevin Hawkins <lists@...> wrote:
>
> 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
> >
> >
>