Re: xAP COM port interface?

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Hi Paul,

Paul Gale wrote:

>Hi Kevin,
>
>This is a similar request to the one I posted a while ago - I too, am
still interested :)
>
>Not sure I still understand the process of getting a serial product in
the land of BSC though?
>
>

BSC supports a TEXT device type which can be any string data eg serial
data. However most people dont want to just see the serial string FF6627
as it is sent to or received from a device so they would translate this
to a matching schema eg the xAP whole house audio one.

>For example, I have an amp, DVD and plasma that I'd like to xAP enable.
They report status changes and can be controlled by serial messages (quite
a large set of possible instructions).
>
>How would I go about doing this?
>
>

You learn some form of programming language or VB script and within that
you translate the codes to a schema  - there is no 'out of the box'
solution.

>I still think a generic Serial interface of some kind would be great -
where you can define the commands to be sent and received.
>
>

That's what the BSC skeleton app does - it handles all of the device
maintenance and control for you - all you have to do is open a serial
port and then write the code that translates between your devices and
BSC eg perhpas translating FF6627 to 'record' if you used a BSC text
device. That's is relatively easy. If however you are not using BSC (and
as some of your devices are not 'basic' you probably wont be) then you
would need to implement whatever schema you have chosen. By handle again
I mean translate the codes but add in whatever other information should
be provided within the one xAP message , and add handling for whatever
other states or interactions there might be. (eg to go to AV2 requires
first pressing 'external' then 'AV' twice - the same sort of thing that
a macro might do in HomeSeer.)

There really isn't a practical way around this without some programming
being involved somewhere.   Yes you could make a device that essentially
translated one 'string' into another  eg Play into FF1768 that could be
setup fairly simply but to go slightly beyond that (which will nearly
always be required) where you are required to maintain state information
and report it correctly ,for example if someone changes the input on a
plasma by the infra red control,  and to know that you can only enter
'pause' for example if you are in 'play' requires some logic which is
essentially programming of some form.  Additionally translating these to
a richer scema than BSC needs the schema to be created and maintained
somehwere.  As I mentioned before you could just attach a xAP Netiom to
your devices by it's serial port and get the serial data sent/received
available on xAP but I think you want more than that for it to be
useful.    Even if you had say 'play' stop' 'pause' etc say reflected as
a BSC device how would you go about linking this altogether in some form
of useful way ? You still need to have a macro or script that you can
triggered/run to perform a sequence of events and currently that is only
possible with a bit of scripting.

Various software applications like HomeSeer, xAP Floorplan etc offer
this inbuilt scripting language and they are usually based on VB
script.  Even HomeVision has it's own language (which I believe you use)
but that language is contained to handle just the inputs and outputs
present on the HomeVision controller. It is also somewhat picky in the
way you code things and isn't interrupt driven so can lose events if it
doesn't poll adequately fast (or teh event is fast). It could be made to
control a video recorder via say IR or serial ports and these actions
triggered by variable changes or macro triggers from xAP. Which would
ofer you that solution now with programming in HV's macro language.
(Ignoring FTTB the OCX issues).  I think realistically any automated
home with significant device interaction is going to need you to embrace
a PC based script language, probably VB.

As a product I guess it would be possible to provide a device (or PC
application) that has multiple serial ports  and a library of device
'templates' that contain the serial codes/ logic/schema definitions to
support  your 'ACME Amplifier' , - this would be sort of like a 'one for
all' for the xAP world but creating/maintaining  that library of tens of
thosands of templates for all different tasks is a huge undertaking and
you can't 'learn' them either. You could have a 'create your own device'
template editor and enter the raw serial commands but the logic/schema
side needs a very flexible template creator frontend which makes it
quite a programmatic challenge. Adapting a xAP framework app is much
easier...as a quick solution.


Kevin


>Paul.
>
>
>
>>-----Original Message-----
>>From: xap_automation@xxxxxxx
>>[mailto:xap_automation@xxxxxxx] On
Behalf Of Kevin Hawkins
>>Sent: 07 September 2005 01:03
>>To: xap_automation@xxxxxxx
>>Subject: Re: [xap_automation] xAP COM port interface?
>>
>>There is an outline BSC Skeleton application that has all the
structure
>>inbuilt to create devices as BSC v1.3 . Thus if your device was
mappable
>>to a few binary, level or text based devcies this could work for
you.
>>You could even reflect the whole serial data as a BSC text device
if you
>>wanted.  I never quite finished it although it is used for example
in
>>the TOM10 connector. If you wanted the source code for this - it is
in
>>VB6 then I can send you it .It works fine... apart from....
>>
>>There is one potential other issue and that is that we have
discovered a
>>memory leak in Patricks xAP OCX and it is taking a little while to
fix,
>>this causes an increasing memory footprint with every xAP message
>>received  :-(  but I am hoping we will see a new version soon.
>>
>>     Kevin
>>
>>garygfx wrote:
>>
>>
>>
>>>Does anyone know if such a thing exists please? This would be a
little
>>>app to monitor a COM port (rs232) for Windows and create xAP
msgs for
>>>any packets of data it finds. It wouldn't be masses of data,
we're
>>>talking bytes here and there for control and monitoring
purposes.
>>>
>>>It would be cool if it worked the other way around too and sent
data
>>>down the COM port when received via xAP.
>>>
>>>Thanks,
>>>Gary
>>>
>>>
>>>
>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>