RE: Slimp3 as a xAP display & controller

[Kevin Hawkins]

Hi Max

I may have some good news for you.

Stuart wrote the SliMP3 xAP as a display function however Patrick
wrote a SliMP3 connector to support full control of the unit.
P's implementation treats the SliMP3 very much as a xAP mp3 device -
it handles music selection, play, pause, volume etc, playlist management.
However - the bad news - I don't think he ever published it - and more bad
news - I never got my SliMP3 back.
Now the CLI interface that xAP uses to SliMP3 is truly an event
interface. Anytime that anything changes on the SliMP3 the xAP connector
knows about it and can report it - for example the vol changing or a track
changing etc etc - this even extends to what is currently being displayed
and what IR remote keys are being pressed - Dean added this last bit
especially for xAP. I don't know how much of this event reporting made it
into P's SliMP3 xAP. So...looking at what you're trying to do here..

A lot of the bi-directional control and event side is fixed by this
-and you could achieve what you want in a couple of ways.

1) You could simply hijack the IR remote and the display - this way
you have an input and an output device that can (sort of) operate
independently of the SliMP3 music function. You would create a dummy holder
for a plugin (that is easy it just puts the text into the menu hierarchy).
Then when the user selects this with the remote you actually implement all
the plugin within xAP - you watch for remote presses and you return display
messages - all you have to be careful about is that you don't use keys that
are recognised by the SliMP3 server at this point in its menu hierarchy
causing you to come out of the plugin hierarchy - for example the left
arrow. Voila - SliMP3 plugins in whatever programming language you want -
via xAP - and no modes to the SliMP3 server !
I used this approach in two areas. Currently I can select an ALARM
plugin (not an alarm clock) - when this is selected the display displays
every PIR activation as it happens in my house - sort of comforting when
you
wake up at night and you think you've hear something - I can see the last
PIR activation on the bedside SliMP3 display. I used to have a xAPp that
picked up the xAP CID message, looked up the number in Outlook and
displayed
it on the SliMP3 display - as well as time of last call etc . This is a
v1.1
xAP and uses the older SliMP3 http protocol (before plugins) and also was
written in VB - I do intend to rewrite this for xAP 1.2 sometime. I may
have
the (somewhat messy) source code for this if someone wants to adapt it.
When
I rewrite it I will probably move to Patricks OCX or Stuarts Framework and
VB - or maybe even C given my latest learning triumphs for Rabbit.

2) xAP on the SliMP3 server. Again in two forms either as a plugin
or more neatly as a true core function within the SliMP3 server software .
SlimDevices are very keen for us to do the latter - they see it as a great
way of bridging their product to the HA world. However you will have an
ongoing responsibility to maintain the code in line with SlimDevices server
revisions. I guess some xAP Perl code already exists as xAP is in
MisterHouse which is written in Perl and source code is freely available.
I think from a learning perspective a plugin is safer and then
migrating to a server module if you feel comfortable with what that
involves. I bought a Perl book too - for this purpose but I only got to
chapter 2 I think !
Now integrating xAP at the server allows much more intelligent use
of the display, for example - meaning you could include xAP data within
existing menus - eg putting the temp in the display permanently rather than
superimposing it, perhaps on the OFF clock display - plus allowing xAP
commands to insert at char position 20 say on line 1 for 5 characters -
much
better than simply rewriting the whole display as the existing xAP is
forced
to.
A couple of other comments - there is an existing SliMP3 plugin for
a phone book I believe that reads data from a file and displays it on the
SliMP3 , you use the arrow keys on the remote to move through the file- you
can adapt this very easily to step through a file and display data - eg a
temperature and a pressure and a light status. This really only means
updating the file in realtime - again keeping the process away from SliMP3
server mods. I use this to step through my alarm log file.

One last comment - one of the fundamentals of xAP is its decoupled
nature. Nothing really relies on anything else - it eavesdrops and uses
information from many sources - nothing is bound to anything.
I like the analogy of xAP being a 'boardroom table' - everything to
do with the company gets discussed here and everybody can hear everybody
else - but may choose to ignore them. To that extent trying to centralise a
database of many different bits of information doesn't sit well as it
creates a dependency - (but it also solves a problem). What really you
would
be doing is creating a xAPp that listened to all the sources and created a
central repository - and your plugin on the SliMP3 would pull data from
here
- you have created a dependency to the extent that temperature information
could be being transmitted but you were unable to display it on the SiMP3
if
you DB app was unavailable - in fact all sources become unavailable if this
DB app was N/A - in a way it's the same sort of app as the telephone book
plugin on the existing SliMP3 but working against a structured file rather
than a flat file. What I'm trying to emphasise is that loosely coupled is
good - (in some more critical cases it can be bad too) .
My Outlook CID lookup for example worked as follows . xAP CID
message received - xAP message sent saying can 'anything' give me more info
on tel no 01234 567890 - Outlook responds with a name - another databases
responds with the call history and the STD database responds with the town
where the call is from, perhaps another xAPp recognises the double glazing
company and immediately stops the internal phones ringing and diverts to
answerphone - I see the xAP responses and choose to pick up the data of
interest and display it on the SliMP3 display. If any of the DB's aren't
there then I only lose that part of the info - if they all weren't there
then I display just the CID. As I display it I send an instruction to the
call history database to log the incoming call (although maybe this xAP
call
history DB did this as an inbuilt function anyway) - when I finish the call
I send another to log the duration.
Lots of food for thought here - and I would love to see some great
xAP usage for the SliMP3 display, and I know SlimDevices are very keen on
xAP being supported within their server - but in a way some of these xAPp's
can also be broadened to work on any display - such that you write
something
& don't care whether the user has a SliMP3, an Audiotron, a Tivo or
a
HomeVision with TV display - it just works. A little more focussed from the
input side I agree but I could for example parallel the IR remote on SliMP3
with many other xAP devices that could report IR remote keypresses eg other
AV gear - or a Pronto perhaps - or just a 'keypress received' xAP message.
Beauty of xAP - so many ways to do things.

Kevin

> -----Original Message-----
> From: max_adamiec [mailto:<a
href="/group/xap_automation/post?postID=6hSulMeVqTDZwS3ZKKZxWpyzIOHgk3L32w_VQMBxrx8C0C5v534v2iM4BNTmoInap0d4LC1KpdoOAoMOFf4M">max@v...</a>]
> Sent: 16 August 2003 17:30
> To: <a
href="/group/xap_automation/post?postID=MkqEWG_2DCkKMirZXI3ffdEnUnOqtrkESh2dMPV3DnrNWBNVIRP65cm1XvRI9WnDy8ALJuyQosrC4zS5-S-PXyTnQXc">xap_automation@xxxxxxx</a>
> Subject: [xap_automation] Slimp3 as a xAP display &amp; controller
>
> I've spent the last couple of weeks thinking about the possible
> functionality the slimp3 could provide in a xAP environment.
>
> Currently Stuarts slimp3 conector only controls the slimp3, one way
> communication from xAP to slimp3, there is no way for the slimp3 to
> interact with the xAP network.
>
> This is all well and good in a "push" situation. The slimp3
can be
> controlled as a specified event occurs eg. muting the sound when the
> doorbell/phone rings.
> It's no good for when the user wants to check if he has new mail, or
> check the status from a weather station.
> Basically the slimp3 can be controlled BY the xAP network but the
> xAP network cannot be accessed/controlled/influenced at will by the
> slimp3's user.
>
> The slimp3 server software is open source, written in perl and open
> to plugin modules:)
> How about a slim plugin which can poll xAPp's, retrieve information
> and display it?
>
> You could expect the interface to go somthing like this
>
> xAP information-->email-->inbox has x new messages-->message
from.
> -->message from.
> -->weather station-->current temprature = 20'c
> -->current humidity = damp
> -->forecast = rain
> -->comfort-->alarm state = away mode
>
>
>
> I'm not a programmer (yet) but I suspect that the above is achievable
> easily enough by making the final right push on the slim remote
> activate a xAP message (with the relevant information) directed back
> at the slims display (Stuarts connector comming into play here).
>
> Pros-if you can launch a xAP message back to the slimp, you can send
> one anywhere. The slim has just become an IR input device.
> Cons- this sounds like an awful lot of programming for the plugin.
> Each final right click/activation would need addressing to a
> different xAPp. A lot of work for my first perl project.
>
> Another way, this ones a bit of guesswork by the way, could we have
> a xAPp database? POP3 pollers, weather station data, alarm states
> could all be periodically sent and stored in the database. The
> plugin would then be retrieving information from one xAPp instead of
> several different ones. I'm guessing the coding for this would be
> similar for each segment reducing the amount of debugging required
> for individual components.
>
> Personally, I like the idea of a database. Although this may change
> as I learn about the plugin limitations.
>
> I will have a go at a simple xAP message sending plugin as a
> learning exercise. (Hopefully create a heirarchy, with the final
> right step launching a xAP file. All .xap files are associated with
> Stuart's Send App, so shouldn't have to include the body of the
> message in the plugin, just refer to it location in a directory).
>
> I'm not a programmer, don't know anything (yet) about perl. So,
> please give me some pointers, wish lists, advice, heckle, anything
> really:) Do you think I'm on the right track?
>
> Max
>
>
> ------------------------ Yahoo! Groups Sponsor
---------------------~--
> >
> Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
> Printer at Myinks.com. Free s/h on orders $50 or more to the US
&amp;
> Canada. <a href="http://www.c1tracking.com/l.asp?cid=5511";>http://www.c1tracking.com/l.asp?cid=5511</a>
> <a href="http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/dpFolB/TM";>http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/dpFolB/TM</a>
>
---------------------------------------------------------------------~-
> >
>
> To unsubscribe from this group, send an email to:
> <a
href="/group/xap_automation/post?postID=v-_N122WbQ-6SxpdI0mTnag4d6bk8CCjpdiN2Mq7zZpgjuoVh-0g__pA3DVtf5hUYwpgm6TUwpPNwxb-caG8pqHvYz0ZIv0ZVSiwYwWDL19B">xap_automation-unsubscribe@xxxxxxx</a>
>
>
>
> Your use of Yahoo! Groups is subject to
> <a href="http://docs.yahoo.com/info/terms/";>http://docs.yahoo.com/info/terms/</a>