Re: Re: Putting it all together and XAp in a box ??????

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

markttay wrote:
> Maybe I am reading this wrong, but does this imply that to do (say)
> scripting that includes inputs and output to and from CBus you can
> either purchase Homeseer and Kevin's xAP CBus interface board and do
> it or you can download the xPL software and CGate interface free and
> achieve the same result?
>

My (longterm) goal at home is to have no dependence on PC's for the main
functionality of my automation - hence the move to embedded control.
This  has been a key reason why HomeVision (and say Crestron/AMX) are
fantastic solutions for control. I still use HomeVision (for some
residual X10 and some scheduling) although I'm moving slowly away from
that. I want all the core functionality to run embedded and only the
frills to require a PC, so if I'm away from home I know the house just
works for everyone.
> I appreciate that Homeseer does a lot more and is a commercial
> product, and Kevin's board is an excellent piece of embedded
> microprocessor engieering that will operate without a PC, but
> ultimately do these different approaches achieve the same thing with
> CBus?
>

Yes - (mostly ...), but the architecture is quite different...

C-Gate is essentially an IP socket based interface to C-Bus , written in
Java.  It is used as a centralised control point for almost all of
Clipsals' software and offers a protocol conversion between the IP based
(textual) commands and C-Bus. Some of the C-Bus protocol is not
reported/accessible  by C-Gate (or not documented) . The xPL C-Bus
conduit (application) attaches over Ethernet to C-Gate and does the
protocol conversion from xPL to C-Gate which then converts again to
C-Bus protocol. Additionally to action something a script has to run in
xPL HAL and then xPL HAL and the C-Bus conduit communicate and then
onwards to C-Gate and onwards again to C-Bus.  As such a few steps are
involved and a few PC based interactions. However speed is not really an
issue in this applications except for the situation of an xPL trigger
(perhaps a switch) turning on a light. This switch is itself another PC
based application (AFAIK) so another step .  However even in this
situation and with the 'extra' steps the response should be really
quick  (I haven't tried it - perhaps someone from xPLand could comment
?). Main issue for me though is the PC dependence (they crash/go slow)
and particularly if that involves Windows (as I believe it has to in the
above scenario).

The xAP to C-Bus gateway eliminates a few of these steps (but not all) -
it attaches directly to C-Bus and pumps xAP out the other side on
Ethernet. (no PC required).  Additionally you can use some hardware (xAP
Netiom) that is also an embedded device that has 16 inputs and 16
outputs - direct to xAP - so an extra 16 switches for say C-Bus and 16
loads that can be controlled via C-Bus.  However the 'logic' between
these needs to be setup and maintained somewhere - and currently this
requires using either one of the scriptable xAP applications like xAP
Desktop or xAP Floorplan , or some other commercial HA application that
can interact with xAP (HomeSeer - Misterhouse - etc).    To specifically
address this  is also an application called xAP BSC Mapper that simply
'maps' endpoints to each other (eg switch(s) to light(s)). It's a super
fast single xAP application that does what it says on the tin. ( caveat
- currently I believe this is being re-written to swap the OCX it is
based upon to improve performance even further).  Now obviously if it
were possible to get the 'mapper' functionality operating in an embedded
device wouldn't that be nice ;-) - no PC at all in the equation and
super fast/reliable.  That is something I have working here currently
but needs adapting to be useful to everyone ( I hope to include it to
the C-Bus xAP gateway, space permitting)

To remove the PC totally but still have more complex logic interactions
or schedules etc then some form of embedded script engine is required
and we step back to either HomeVision  which is not capable enough to
speak xAP (or xPL) directly so needs an xPL or xAP conduit (both
available) , or a C-Bus PAC/touchscreen on C-Bus or perhaps one of the
bigger (=expensive) controllers like Crestron or AMX.  Actually both
these companies offer an Ethernet based controller circa the same price
as HomeVison Pro - and both could potentially run xAP embedded.   There
is a slight bug in the Crestron firmware re handling broadcast UDP - but
I am hoping that will be fixed soon - on the AMX side another bug
(length of UDP packets ) - has just been fixed - interesting ;-)
>
> I am not trying to reignite the xAP / xPL debate as I know there is
> merit in both.
>
As always there's no simple answer so this next bit gets long I'm
afraid...  and bear in mind I'm xAP biased but I've tried to be
objective...

I think its important to consider the purpose of both xAP and xPL here.
They are both protocols - they are not a suite of end user fully
polished products with companies at the end of the support phone line -
oh.. and most importantly they are free.  The raison d'etre of xAP and
xPL is to enable things to be 'automated' using a simple, fast,
expandable lightweight protocol, accessible by even novice programmers.
Liken xPL/xAP to the internet and specifically say IP if you want.  IP
is a protocol on which a suite of applications have been built by
independent companies - web browsers - news readers - file servers -
streaming audio/video etc. Within these categories many independent
companies have product offerings but the inventors of 'IP' don't - they
just standardise the protocol which allows the applications and devices
to communicate. Once a protocol becomes 'adopted' it almost vanishes
behind the applications and interfaces/devices that utilise it. Hence IP
is not well known but the 'web' is. That's where xAP and xPL should be
but obviously we are not a standard yet and some work has to be done
evangelising the protocol which of necessity means trying to get people
to write applications and build devices that use the protocol. To kick
start this you have to demonstrate capability which is where the
protocol developers are positioning the peppering of applications
available today. What we really need is more independent
developers/individuals creating their own applications and helping the
snowball effect. What the developers don't have resources for is the
frequent Q "Is there an xPL/xAP application that does this and if not
why not ?" or "Your application is almost what I need but I would
like
these changes" - there is no commercial reward , resource or time
available really to support these. Even documenting what we have is a
huge task, and using xAP/xPL is far more fun than writing docs.  Sadly
there's a sort of mindset in both camps that says ' lets get my own bits
sorted before I focus on others' - but there are great development tools
available for the more ctechnical adoptees. It's the 'end users' who are
left a bit dangling still, but it's improving day by day.

xPL differs slightly from xAP in that the initial purpose was for the
personal needs of the developers - they wanted something that worked for
them in their own homes. xAP was a little more 'worldly' in trying to
offer something that would address the needs of many , and as such has
extra capabilities in teh core protocol. This led to a common
misconception that xPL is more lightweight than xAP - this is really
untrue - both sit in the same row of seats in the arena - there are
leaner seats (binary, VSCP, SNAP, C-Bus etc) and there are considerably
more complex seats (UPnP etc) - but in order to achieve human
readability, ease of use, transport independence and expandability both
xAP and xPL are about as lean as they come.  Both protocols can be
expanded by higher level 'layers' on top of the core protocol and both
xAP and xPL have done this - actually causing their divergence and
interoperability.

Here's where I think people need to focus rather than any xAP/xPL
issues....
++++++++++++++++++++++++++++++++++++++++++++++++++++

What I'm trying to say here is that xAP and xPL are 'enablers' for other
applications and devices to interoperate - neither xAP nor xPL are
products and when you choose to automate your home then you must select
applications and devices that will actually integrate and provide the
desired interface that you are seeking . For some it may simply be
switches and lights, for others infra red remotes, and for others touch
screens etc.  You must find the applications and devices that work for
you. xAP's goal is to help tying these disparate devices together. If
you have some programming ability then xAP and xPL make this achievable
to you now with almost any device , if you don't then you are dependent
on the products that others offer - and in general they only support
devices that they themselves own (as getting your own system up and
running is sooo much more fun -and pacifies SWMBO).    So take a look at
the way that the users of your system will interact and see if the
functionality is achievable standalone (embedded) or requires a PC. If
using a PC then use an application that offers you the functionality and
interface you need - particularly true for home automation software.
Critically focus on the user interface if you are going for touchscreens
or PC control.  Design flexibility and speed of response on touchscreens
or PC based interfaces is absolutely critical to a comfortable
integration at home or you alienate the household. xAP offers some very
strong integration with 'eye candy' type interfaces - including XLobby,
Main Lobby, HomeSeer, MisterHouse, xAP Desktop, xAP Floorplan and
perhaps even  AMX/Crestron . For me a critical decision was the
touchscreen vs web browser choice.  I wanted realtime (push) based
displays ie touchscreens and not the 'refresh' (pull) type operation of
a web based interface.   A realtime interface achieved using a  web
browser is possible using either Active X controls or AJAX technologies.
In fact xAP Floorplan has moved to the latter.   Active X controls
require you to be running Windows/IE of course.

So here's where I'm at currently - I have essentially automated
lighting, heating, security, telephony and AV. I run my 'logic/mappings'
and 'schedules'  totally embedded using a mixture of AMX/HomeVision ,
plus a C-Bus PAC controller and xAP wherever I can implement it.After a
power cut my control is restored within seconds (no PC to boot and no
crashes). I am fortunate in that I can 'map' xAP using an embedded
controller. I do intend to polish and release this  eventually.
Supplementing mechanical (C-BUS/xAP) switches I use touchscreens - some
dedicated (embedded/immediate ON) and some are PC based or linked. The
frills like 'weather' 'TV listings' 'email' etc all use a Windows PC and
corresponding applications, likewise I have some 'whizzo' scripts
running in HomeSeer and doing xAP extras (OSD etc) . Yes I would prefer
to run Linux here but it's just out of my comfort zone I'm afraid. I do
have two PC's running embedded XP - they seem to run forever (touches
wood)  - the thought eventually is one will be fallback for the other
although currently it runs music streaming / NAS.

Kevin