The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

RE: receiving serial data/email alerts?


  • Subject: RE: receiving serial data/email alerts?
  • From: "Paul Gale" <groups@xxxxxxxxxxxxxxxx>
  • Date: Fri, 15 Jul 2005 14:53:47 +0100

Thanks for the short novel Kevin :)

That really helped. As you can see, I'm still not comfortable with what
BSC=
does and have not installed floorplan yet. Maybe I should have a play with=
both of them next and understand what they can really do :)

Cheers,

Paul.



> -----Original Message-----
> From: xap_automation@xxxxxxx
> [mailto:xap_automation@xxxxxxx] On
Behalf Of Kevin Hawkins
> Sent: 15 July 2005 14:24
> To: xap_automation@xxxxxxx
> Subject: Re: [xap_automation] receiving serial data/email alerts?
>=20
> Paul Gale wrote:
>=20
> > Thanks Mark,
> >
> > xAPHomeVision sounds good :)
> >
> xAP HomeVision has been released for a while - but the great news is
> that the updated version Mark is about to release supports the latest
> xAP BSC v1.3 - this makes it ideal to integrate in an almost plug and
> play way with other BSC apps/devices.  Nice one Mark...
>=20
> > I've got several devices that either report status or are
controllable
> > via RS232. My current (remembered) list includes:
> >
> > =B7       Extron MAV128 video matrix switcher - at the heart of
my AV
> > switching system
> > =B7       Panasonic plasma TV
> > =B7       Onkyo Amp
> > =B7       Onkyo DVD player
> > =B7       Aquarium computer
> >
> > All of these devices have been 'on my list' to integrate with my
HA
> > system but I've never got around to doing yet!
> >
> > If there was some kind of xAP application, using a PC's standard
> > serial ports, USB to serial or serial add-in card, that could
> > communicate with a serial device and have a set of logic to do
> > something with that data, that would be great. I'm thinking of
the
> > kind of logic that HV allows and the resultant actions would be
xAP
> > messages. Does that make sense?
> >
> Yep - xAP BSC Framework - but you will always have to write code for
> handling the specific protocol the device uses.  HV can't form custom
> xAP messages as it has no network connection and insufficient memory
and
> limited macro capabilities in the string handling area.
>=20
> > I wonder whether broadcasting the serial data via xAP would also
be
> > desirable? - would I really want to do this I wonder?
> >
> The reason is that xAP is broadcast - everything should hear
everything
> else. - abstracting the serial protocol to a xAP schema is the ideal
way
> so instead of getting 0D1A492C<cr>  you see
"Source=3DFishtank" "Temp=3D2=
6"
> in a xAP message  (simplified a little)  and/or an equivalent BSC
> message like  Level=3D26.
>=20
> > I guess an easier(?) xAP approach to dealing with serial data is
to
> > pass it all into HV and let HV's logic deal with it.
> >
> Maybe 'easier' in the sense it's only handing the responsibility for
> implementing the protocol elsewhere, a sort of 'cop out' .   At some
> stage the protocol of the device has to be supported, if you have ever
> tried implementing checksums etc on HV you will soon hit limitations,
> (he said having had to do this for C-Bus).  Also you have to be able
to
> form and react to xAP messages sent directly to the device.  Crucially
> HomeVision does not sit on a network and hence can't (indeed
shouldn't)
> do this.  HV does not have the speed, memory, language capability or
> hardware (Ethernet) to do this.
>=20
>  I think the reason you are persuing this is that you are comfortable
> with HV's macro language and would like to control a whole xAP HA
system
> via that, unfortunately that isn't going to be possible as HV is not a
> xAP controller, it can set flags and trigger events that get
transferred
> to xAP but it will require a 'helper app' to fully interact with xAP.
> Let me clarify that...  xAP HomeVision using BSC v1.3 can create links
> with other BSCv1.3 devices.  So when HV input 1 goes ON then your
> Bedroom lamp goes ON.  Also (I believe) flags can do the same and
> variables presumably map to BSC level devices eg a dimmer.  You can do
> this really simply (no programming) by using BSC Mapper or a similar
> functionality that xAP Floorplan offers.  So yes HV can work very well
> this way with xAP with no programming required....(for simple devices
ie
> BSC)
>=20
>  However serial protocol handling is more complex...  crucially the
> serial architecture in HV is rather basic in that it does not handle
> buffering or concurrent processing of data from multiple serial ports,
> and get's stalled by X10 etc. It is really only intended for low speed
> data from a few sources , pushing many serial streams into HV will
only
> cause data to be missed or received incorrectly and impact the
stability
> and realtime responsiveness of HV , which is very undersireable as the
> beauty of HV is that it is so rock solid.  BTW I use two HV's (one std
> one pro)  as my core engine im my home for exactly this 'always works'
> reason. PC crashes - lights still work.
>=20
> So what  you should be looking for is how to get the logic/scheduling
> setup in HV and then an application that you enlist to handle the xAP
> side.   ......  and :-) we have HomeSeer,  BSC Mapper, xAP Desktop and
> xAP Floorplan, the latter two being free.  For direct  links then BSC
> Mapper is ideal and if you need some more 'smarts' but still want ease
> of understanding then xAP Floorplan is the likely candidate (for more
> power and realtime PC display then xAP Desktop).  HomeSeer is a very
> polished and popular end user HA application and many people are
> comfortable with that , and it supports direct scripting (VB) for
> multiple serial ports for example.  It fully interacts with BSC and
the
> vast library of HS devices become 'xAP' devices automatically.
>=20
> > I'm thinking of a direct xAP replacement for ACE's serial
handling
> > capability (mapping and passing through to HV). In this case, it
would
> > be great if the xAP application could combine several serial
sources
> > and pass them on to HV. Maybe also with some kind of identifier
as to
> > which serial source the data has come from (although most of my
kit
> > has unique protocols) i.e. appending a couple of characters to
the
> > beginning of the message and a termination character at the end?
This
> > approach would be fantastic as it would allow easy addition of
> > multiple serial ports to HV.
> >
> > The reverse flow of data from HV out to the serial ports may also
have
> > a couple of designator characters as well, which the xAP
application
> > would strip off before sending the data to the relevant port.
> >
> > Does that all sound feasible?
> >
> Yes, I understand what you are tring to achieve, but it really isn't
xAP
> as you are not presenting the data to other nodes (ie is not
broadcast)
> and you are not ultimately abstracting it as a schema even when
received
> and decoded.   xAP isn't the way to get reformatted (escaped) serial
> data into HV.      Additionally HV is not very capable at handling
> protocols (eg checksums or timing) and has relatively little memory
and
> this would impact it's speed and stability. HV also can't hear,
process
> or form xAP messages.   If such an app was written then it wouldn't be
a
> xAP app as such - more a HV expansion app. (which is sort of where ACE
> came from).
>=20
> To a limited extent the xAP HomeVision conduit could support a feature
> where you configured a few 'template' messages that were sent in
> response to HV triggers and perhaps populated with string data from
HV,
> likewise it could receive a few of these and pass data to HV.  But  I
> feel (and I don't want to speak on behalf of someone else who wrote
this
> app) it moves in the wrong direction doing this.  You end up with
multi
> function applications rather than distributing function .  HV should
be
> a 'peripheral' for xAP that has extensive I/O and can schedule and
> receive/ issue triggers.  Where there is more than a direct 'linkage'
> required , ie parameters/messages have to be formed from text strings
or
> in your case serial protocols handled then a helper application  - a
xAP
> engine if you like would perform this and HV just isnt capable of
> that.     A serial protocol handler in xAP would take say your
amplifier
> and present as a xap-audio device on xAP.
>=20
> > It's one of the next biggest hurdles for me to integrate xAP even
> > further into my HA system.
> >
> I think you have to take the leep into learning a bit of VB script to
> realise your goal here.   You have so many serial devices (10+ ..wow)
> that having a PC handle them is probably the right way (ACE ?) - or
> certainly you will need a more powerful and capable embedded solution
> than HV - this is sort of where products like HomeBrain were
focussing.
> Or maybe a couple of HomeVisions even ??   Also some protocols are
just
> too complex for HV - for example the serial protocol on my TagMclaren
> HiFi (TagTronic) or true C-Bus  .   As you delve further into things
> like say music (mp3) then the memory & string handling
capabilities of
> HV just aren't adequate.
>=20
> HV is an excellent ON OFF or LEVEL based solution (which is why I use
> it) but wasn't engineered for richer devices.  For me it is an engine
> for C-Bus lighting and X10, some IR, and mostly importantly an
embedded
> scheduler and logic engine that always works so key functions in my
> house are rock solid.
>=20
> > Oh, and is there a xAP scheduler available yet - something that
can
> > rival the power of the HV scheduler?
> >
> Yep...
>=20
> xAP Floorplan
>=20
> HomeSeer
>=20
>=20
> > Cheers,
> >
> > Paul.
> >
> Kevin
>=20
>=20
>=20
>=20
>=20
> Yahoo! Groups Links
>=20
>=20
>=20
>=20
>=20



=20

xAP_Automation Main Index | xAP_Automation Thread Index | xAP_Automation Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.