O2 Joggler and my broken light in living room

Sample configuration for a very basic HAH joggler screen along with its xml file.

To make nice screenshots of the joggler I have this alias setup on my linux box.

It remotely connects to the "joggler" runs a command to dump the screen and converts the XWD file format into PNG dropping into a directory for me to grab.

alias grabjoggler='ssh joggler '\''xwd -root -display :0'\'' | convert xwd:- /u02/public/out.png'

Brett

Just getting ready post beta 5 for download by anyone ...    and was just looking over the current beta test list and I couldn't find your name Dean (G7PKF)  ...  I maybe have the wrong email address for you... When did I send you the beta link and to what email address ? It is very possible you didn't get the incremental updates either..   The instructions you didn't have (another post)  were included with the beta. 

Also - I'm keen to get feedback on any issues that there are with beta 5 so that I can fix them in later builds / documentation - so if you can post them to the main thread on AutomatedHome then I'll definitely see them there rather than mixed in on this forum - although depending on how many HAH Joggler users emerge then some section here for xAPFlash might become useful and will be easier for me to monitor. 

http://www.automatedhome.co.uk/vbulletin/showthread.php?t=2854

HAH specific things obviously belong here and Brett has kindly written an iServer implementation that runs on both HAH and the Joggler itself so that's better supported here.  The Joggler version can be installed with beta 5.

 Yes as Brett says the documentation isn't up to the great level that HAH has - although it is better than a lot that I've seen.  I'm an electronics engineer embracing software now as quick as I can learn ... I wouldn't class myself as a 'hacker' which was the term used.  xAPFlash was a project for my own use that people seemed interested in so I released it. It was my first ever experience of Flash (awful IDE !)  and was never intended as a release quality application. 

I had many offers to write up improved docs, installation experiences and example configurations but in the end only one user did some formatting and typo correction to the orginal documentation.  Brett provided some of his own install experience notes too and has been a great help recently in moving towards easier installation and fuller documentation.  I'm anxious to imrove all these things but the best source for improving this will be users experience and feedback....   keep it coming.

   Kevin

 "As for the documentation yes its very scant this stuff is written by hackers who only write code, the problem with that is nobody can use it or figure it out so it ends up on the software trash heap.  Which is sad."

I've posted elsewhere re this and am looking to improve it , particularly with feedback , experiences and 'how to's' from users ....  I wouldn't call it scant but certainly the XML documentation needs imrovement. GUI examples will help considerably too.  This was a 'for me' project that I released for others - warts and all.

"If you are getting no data it could be that your UID does not match... the configuration is a little NAFF in that both the SOURCE and the UID must be correctly defined.  Personally I would relax the UID"

NAFF eh ... actually it was done this way for good reason.

1) The XML file maybe be used by different clients with different capabilities - some may have the resources to parse incoming source addresses and some may not and instead have to use UID's. The fact that both are present avoids issues should you move between such clients. I accept that less capable clients are unlikley to be able to run a GUI or parse XML.

2) Recognising UID's is much easier and faster than source addresses and this is in fact how xAPFlash works. In heavy xAP traffic environments (like mine) this does make a difference.

3) The <source> address is included so that you have something that immediately associates the <uid> with a xAP device in a readable way, documentation if you like.

4) If in a later version of xAPFlash the recognition is moved to source address rather than UID then the XML will still work without change.

5) Allowing registration of UID's with iServer was another possible way of defining which traffic might be passed between iServer and xAPFlash.  As iServers might be implemented on a very small memory embedded device (and xAP source lengths are not restricted lengthwise) this was pre-emptive of that need.

6) You require the <source> address to be able to send (target) a message back to that device, for example to control a relay on HAH. You can not target a xAP endpoint by UID. 

Just for completeness .. it is possible to recover source address from xAP BSC devices but it can take up to a minute from startup , sometimes longer, for that to happen

K

Dean -     You say xAP has been updated on the HAH and that the xAP 'old' code is hence broken.   Which is the old code you mean - I assume it's a XML file.  Is it my basic example that I included with the original beta 5 distribution ?  If so I wasn't aware it's broken but it could be - would the Joggler not load it or what was the issue ?

- . -

A fellow Marconi man.  I was Draughtsman at Command & Control!

Did all my onc, hnc stuff but that was a few years back now, bit like my French, didn't get used much and withered a lot.

Hi Dean

I've emailed elsewhere the reasons for my absence, but I'm keen to get back on the horse!!!  How did you get on with the Joggler/HAH...reading the above looks like you had fun....

I was at the point of waiting for the arrival of the Joggler Beta 5 stuff...looks like you're way ahead of me now...how was it - and where is it (do you have an URL location?)....

I've got a Joggler on my desk, my HAHHub is feeding my Pachube site nicely (visit feed 34982) and i'm keen to integrate the two....would you oblige with hints and tips?...

Hope to hear from you soon

EJ