Hi thereOriginally Posted by chris_j_hunter
Thanks for your thoughts! Really helpful.
RE the energy monitoring - I had a look at the pdf, and can understand how having this more accurate monitoring is of course much more useful, and I like the idea of that, but I'm afraid the terminology for products themselves totally lost me - I know very little about electricity as it stands, so don't really understand what these are & how they work...I'll get Googling!
As for everything else, Idratek looks fantastic - I've read through all the information on their website, and am now working through all the FAQ posts on the Idratek forum. The obvious problem is I've run all my Cat6 cabling already, and we've started plastering - and it looks like I can't even repurpose some of these runs as they're UTP, not STP/FTP... Shame, as I have plenty of the cable left too! I could still do new runs in the lounge, hall, stairs/landing & bedrooms, but not the kitchen/diner as it was plastered last week, and that's kind of our 'feature' room, so I suppose that wouldn't be great...Bummer!
The other problem I would forsee with Idratek is that it looks pretty complicated - the forum FAQ's simplify a lot of things, but when it comes to matters like earthing network cable, I'd have no idea where to start, and their simple price list on their website leaves me utterly confused - are you aware of any resources that show/explain what each item is, so I could work out what my starting points would be?
Rako - I love the look of this for the simple lighting control, the idea of 'scenes' is exactly what I was thinking, but it looks quite limited, without great web/iPhone/other control. Great how it can fit in existing socket back boxes though, and if I ultimately can't afford to go for one of the more comprehensive systems I might be forced into running separate systems - e.g. AlertMe for energy, Rako for lighting, etc. Not where I want to be, but better than nothing!
Oh...decisions decisions!
Here's a link to Caroline's new thread on this topic
http://www.automatedhome.co.uk/vbull...ead.php?t=2799
Could I ask that people try and post related replies within that thread - or if you want to stay xAP allied then by all means post a new thread within this xAP forum. I'm just trying to keep this thread 'on topic' for the Joggler project.
PS I used UTP for my IDRANet bits...
Documentation download link
For those just interested in seeing how this works and what you need to install here's a link to the documentation - which is an in progress thing...
http://tinyurl.com/3xzax2y
Lot's of screenshots inside - apologies for the size (4MB) as most are bitmaps
K
Quick questions
Hi Kevin,
Two^H^H^H One quickies.
Do you have copies of Rect_off_.png as used in the bottom menu? UPDATE: Ignore me, it works even though the file isn't external to the SWF.
How does the DoorBell functionality work? What xAP schema is it looking for and what status change? I notice in your XML config there isn't a schema but the button is named DoorBell....
Like most things, after a couple of hours of tinkering you really decide you need to sit down with a nice clean sheet of paper and do some planning on the menu structure :-)
Lehane
Last edited by g8kmh; 22nd July 2010 at 06:30 PM.
I do have the rectangle images should you want - they were a quickie thing but in the end I removed their use within the XML. They were a specific size for a layout such that when placed horizontaly they touched.
In the end I used the ordinary buttons stretched to touch as this illustrated a more general way of achieving it at any resolution. There should really be a background behind them to avoid those rounded corners. Interestingly on my 'development' Joggler these button press really easily yet on another one they are very difficult to press - maybe its a screen calibration issue.
The doorbell function is a bit of a kludge - basically I'm halfway (undecided) between using the <mode> tags or specific Name= values to alter the behaviour of specific buttons . The 'xAP' button and the 'Secure' one show this inconsistency.
If you name a button 'DoorBell' and set the mode to 'toggle'. then it becomes self toggling as you press the button allowing you to set or clear the doorbell mode. By adding a xAP <source> and a xAP <uid> tag then the association is created to a xAP BSX doorbell. ON as the bell is pressed and off when released. No xapbsc.cmd message is originated from the Joggler as the <mode> is not control. . So it's just using a BSC schema.
The only thing special about a 'DoorBell' button is that when the xAP event message is received (and if the doorbell button is on) then a sound is played, At the moment it's more just a 'see if it works' type thing. The sound is a truly awful and rather long Westminster chime. To alter this would require editing the source code (FLA) - I should add sound files as a tag - not sure if I can load sounds at runtime... but seems the best way to go.
One issue I have is that sounds seem to work for a while but then become clicks/crackles after a day or so... I am not sure if this is my code or the Joggler firmware/hardware . I need to see if they stay running OK on a PC.
Re the forward planning... I know exactly what you mean. The visual appearance possibilities are now very flexible by allowing any backgrounds and buttons.. and of course you have to choose a grid size . My initial approach was to go for the max possible grid sized and you can see how awfully ill thought out this is from my example XML is - but it is I hope illustrative of things you can do.
You definitely need to play a bit then step back and decide just how you would like things to work and I believe settle for smaller grids and pop up overlays or swap screens ... that look nice and are intuitive to users (not just mission control engineers).
I do need to add an ability to create rectangles and place static text (labels) on screen, as well as improving the display flexibility of the <mode>text</mode> button too... the BSC text= value supports basic html tags like colour and size when displayed on the Joggler. You could use a totally transparent button but the width/height and placement of the text is taken from the button sizing.
K
Last edited by Kevin; 22nd July 2010 at 11:22 PM. Reason: additional info
At the moment the application is not exiting properly via the Joggler home button. All seems well but the old applicaton remains running - and attached to iServer. Each time you relaunch the application a new version starts (and runs ok).
If you do swap in and out of the app quite a bit via the Joggler home menu then do periodically reboot the Joggler . If you launch the app via Telnet/SSH this doesn't happen.
I'll look into this for the next beta
K
Last edited by Kevin; 22nd July 2010 at 11:14 PM.
<source> <uid> <xapon> <xapoff> tags
The XML <source> tag is used to register with iServer the xAP devices it the Joggler is interested in. iServer adds these source address to it's filters and only passes matching messages back to the Joggler. This reduces traffic and increses speed. Additionally when a Joggler button controls a xAP device then it includes this <source> value in the target= line of the xAPBSC.cmd message. Please ensure the case used in the <source> tag exactly matches the xAP devices source= .
The <uid> tag is how the Joggler recognises incoming messages from xAP BSC devics (as they are more compact). It does not use the source= value in the message.
This means that the button state reflects the state= of the device matching the <uid> tag but will control the device matching the <source> tag. Typically these are the same device. A 'text' mode button uses the <uid> tag as the match. You can include the <uid> and/or <source> tag as you wish in any combination.
From beta 4 you can send any xAP message when a button goes 'on' or 'off' using the <xapon> and <xapoff> tags. Between the tags you include the complete 'raw' xAP message that you wish to be sent.
Intended enhancement: If you include a <uid> tag in a button that also has a <xapon> or <xapoff> tag then the button, rather than being self toggling will track the state of the <uid> matching xAP device and will also send the <xapon> or <xapoff> message when it changes state. I also intend to look at allowing multiple (cocatenated) xAP commands between the <xapon> and <xapoff> tags which will then provide an ability to trigger and send xAP macros. (The message content will be fixed however).
K
Last edited by Kevin; 23rd July 2010 at 01:02 AM.
More
OK Kevin,
Yes I find the bottom menu buttons difficult to press and work best at the the top area and not at all at the bottom area of each button.
I'll play some more with the DoorBell. It would be useful to have a tag that the device has inverse sense. I pull quite a lot of things to high and they go low (to ground) when activated.
I do notice the OSD seems broken - the Pages are in front of the image.
Must stop playing and look at the hub..........
Lehane
Yes - I wondered if perhaps the text label was masking the click passthrough .. I'll double check - and yet it works fine on one Joggler. They should really be larger buttons anyway and having both a horizontal and vertical 'menu' button list doesn't seem to offer anything useful.
Shouldn't the inversion happen at the hardware end and still report a State=on in BSC ? A quick tweak of the AS3 code would handle this though.I'll play some more with the DoorBell. It would be useful to have a tag that the device has inverse sense. I pull quite a lot of things to high and they go low (to ground) when activated.
Ahh OK.. Very likely due to the displaylist handling that pages has now created. I haven't checked it in a while as I've been intending to deprecate the fixed screen and replace it with a popup page activation. Then people can design whatever they want... I'll take a look.I do notice the OSD seems broken - the Pages are in front of the image.
K
Last edited by Kevin; 23rd July 2010 at 12:47 PM.
Screen
Hi,
Thought I'd show the current version, which is where I'll pause for now.
You are right in that it would be better if the h/w did the inversion but (a) Floorplan supports it and (b) the hardware is the xAP Netiom which (unless I missed something) doesn't support inverting an input state.
Lehane
Posting Permissions
