iPad App

Hi Guys

Is there any plan to release an updated wiser app that properly supports the iPad?


Does anyone know of any alternative native iPad apps for CBUS control?


Thanks
Warren

 

There is one under development. Cannot provide a release date tho

 

I am asked by clients about this every week, so I have to ask again: any information about ipad version and climate control support?

this made us lose some projects already. competitor just says "they do not even have a native ipad app, you'll have to use iphone version with big pixels. also you won't be able to control temperature" - and he wins...

 

i'm in the process of developing something using php and javascript to do just that. I had a couple of hours testing live feedback using c-gate's port 20025 and everything seems promising. only issue will be that it will require a netbook or something running windows on the network to run as a web server.

 

I just upgraded (downgraded???) from a Nokia phone to an iPhone and noticed that there are no thermostat widgets. Do I assume from Nicks response above that the thermostat widget is not supported by the iPhone. It's all getting a but depressing rerally. The last 3 or 4 new CBus products I have installed have been somewhat underwhelming, paticularly considering peoples expectation with most other areas of technological advances.

 

Hi Ashley

The thermostat widget will be in the next update to the iPhone app which (hopefully) will be available soon. I 'd like to think we can lift our game to better meet expectations.

 

iPad app is a must !! i am putting in iPads in every Cbus home i'm doing and the current iPhone app is really poor for the ipad..

 

Rather than start a new thread I thought I'd post in here.

I'm trying to control my CBUS lighting using an iPad, however I've run into an issue which I don't understand, hence hope the forum "brains trust" can help me out with this one.

By way of background I have my Pronto Pro remote controlling CBUS over a PCI and it is rock solid, I'm trying to replicate that capability now with the iPad, again using the PCI as my gateway onto the CBUS.

The hardware I'm using to get the iPad connected to CBUS is a Global Cache GC-100-06 and a CBUS PCI. The GC-100 has a static IP (10.1.1.10) and serial comms happen over TCP port 4999. The required command structure is "sendstate, 1:1, <command>". There is an App on the iPad which I use to send an ASCII string to 10.1.1.10:4999.

Say for example with the Pronto, I send "\\0538007918232g\r" and the lights come on, and I send "\\0538000118AAg\r" and the lights go off. However with the iPad I send "sendstate,1:1,\0538007918232g\r" and the lights go on (as expected), and then "sendstate,1:1,\0538000118AAg\r" and the lights go off (as expected). However after that, nothing! The iPad method is only giving me one shot at an on/off event, any subsequent "lights on" or "lights off" commands and CBUS doesn't respond. That's what I don't understand, why CBUS won't carry out the "lights on/off" commands a 2nd time.

The only clue I have is, if I reboot the GC-100 CBUS will respond to another on/off cycle, but then nothing. I can't switch the lights on, then off, then on again unless I reboot the GC-100 after the first on/off cycle. I'm not sure what to try next, any clues?

So at this point I have only had partial success in getting the iPad to turn on my lights...I want it to turn the lights on and off as required without having to reboot the GC-100 after each on/off cycle.

UPDATE:
I have plugged the GC-100 serial output into my PC and run a PuTTY (terminal application) log session (eventually I worked out you need a null modem cable to make the connection and not a straight cable). The GC-100 is sending out all commands received from the iPad (except I'm not seeing the \r on the end of the command string?). So I think this tells me this is a CBUS issue...why is CBUS only reacting to the first "lights on" command?

 

I dropped the /r from the command and the lights don't come on. I then put the /r back in, reset the GC-100 however the lights don't come on. So I installed a 2nd PCI and with /r the lights came on, but would not go off with the lights off command. Now I can't get CBUS to respond to any commands from either PCI, which has me wondering whether I've just bricked two PCI's?
I do know that the GC-100 is sending the commands to CBUS because I am seeing those during the PuTTY logging session.
UPDATE: Toolkit can connect to both PCI's so I guess they're not bricked, assuming of course Toolkit connecting is a positive sign that all is well with the PCI's...

 

Ahhhh...Ashleigh was actually meaning the lowercase g in your example not the \r (carriage return) which is always required on the very end.

Also your Pronto commands start \\ which is a way of sending a single '\' character if the string is using '\' as an escape character, Not sure if this is how your iPad app is encoding strings as there you have only used one starting \ but have still used \r for carriage return at the end .... worth checking what is actually been sent. There should only be one \ at the start of each command as actually sent from the GC to the C-Bus PCI.

K

PS Actually hang on - your first command string is wrong - it has an uneven number of hex digits,
Try this instead ( I haven't validated the checksum so it's likely one of these, probably the first one)

"sendstate,1:1,\053800791823\r" or maybe this
"sendstate,1:1,\053800791822\r"

 

I first tried using \\ at the start of the iPad command string (because that format worked with the Pronto), however that didn't work. So on a hunch I changed it to the single \ and it worked, to the extent that I can only get it to work for the one on/off cycle.

I have checked using the PuTTY terminal application and the command strings being sent from the GC-100 to CBUS are exactly what the iPad is telling it to.

Next as per suggestion I tried changing g\r at the end of the command string to just \r and the response behavior of CBUS was no different.

To explore things a little further I've put a 2nd lighting group in my command list. So now I have "Lights1 ON", "Lights1 OFF", "Lights2 ON", and "Lights2 OFF". What I'm seeing now is CBUS will respond to the first 2 commands but nothing after that.

I can turn "Lights1 ON" and then "Lights1 OFF", and CBUS won't respond to any commands after that (although the GC-100 is sending them to the PCI); or I can turn "Lights1 ON" and then turn "Lights2 ON", and again CBUS won't respond any more after than (so I can't turn off the lights). It seems that CBUS or the PCI is shutting down after receiving 2 commands (whatever those might be), and won't respond to any more commands until the GC-100 is rebooted again. At which time the same thing happens again.

 

Perhaps...I suspect the PCI is sending a response to the GC-100 after every command received, and the GC-100 doesn't know what to do with it and the interface is just locking up. Although having said that, when the system is in this state I do know that the GC-100 is sending out the required commands because I'm seeing them in the PuTTY terminal window. I'm exploring some other options but haven't found a fix yet.

 

UPDATE. I gave CIS Tech Support a call today and they suggested forcing the PCI to simple mode. So I changed the commands, to turn lights ON:
<~~~> WAIT <Lights ON>
and to turn the lights OFF:
<Lights OFF> WAIT <~~~>
And bingo, it works! The interface doesn't hang after two commands any more, I can turn the lights on and off as required!
So can I throw this to the forum...is this a final solution to my problem, or is resetting the PCI using ~~~ in every command not a good idea?
p.s. A big thanks to Darren at CIS for the tip...

 

+1 for looking forward to the iPad app. We seem to be moving away from installing Touch-screens running HomeGate and installing more and more iPads with apps for Lights, Sonos, Cameras and our distributed TV system.

Are there any developments on any type of GUI like the C-Touch or HomeGate for the iPad Wiser?

 

...just to close out my issue.

It seems that what was causing the interface to hang was the "sendstate,1:1.." part of the command. I don't understand why because I thought the GC-100 was stripping this off and only sending everything that follows out the serial port without translation (I wasn't seeing sendstate,1:1 in the PuTTy terminal window when logging the output of the GC-100).

I was to understand from the GC-100 API that to direct incoming commands out its serial port this structure was required, in practice its not...all you need is to specify the IP of the GC-100 and port 4999. So, for example, to turn my lights ON I just send \053800791832\r to 10.1.1.10:4999, and to turn them OFF \0538000118AA\r.

After stripping out the sendstate,1:1 the interface doesn't hang up after receiving 2 commands, so I've dropped the ~~~ PCI reset. Everything now works as advertised.

My next task is to get this working with C-Gate or a CNI and drop the need for the PCI/GC-100 gateway....how to do that I'm not sure...

 

You can look at CommandFusion, but they have very basic release of C-Bus driver

We test a version of Iridiummobile now: http://www.iridiummobile.net/ Probably Automn will give us non-beta version

They both work with IP interfaces, not Wiser.

 

Thanks to brodricj, he excited me to waste 3 hours tonight...

Dug up some old doco, and did what I wanted to do ages ago - but never got around to it... to play with my CNI.

For the first time I have been able to sit at my laptop and issue a command easily to turn my lights on and off (yep I know I could ramp / dim - but thats for another night!)

My biggest effort was to do the calculations correct each time - 2's compliment - its easy - but you can make a mistake easily in the evening being distracted while watching tv... So I created an excel spreadsheet to perform the calcs for me, and able to copy the result to the clipboard.

Using putty, in telnet mode - connecting to my CNI, I can just past the command in by a right mouse click - and get really excited in watchin the light go on and off... Of course after a couple of times, the wife gave in asking was that you or something else (ghost?)

So the excel spreadsheet might be of interest to someone else - thought it time to give back... so here it is, maybe of use to someone.

No time for bed - now I want to play with Touch IR+ and other ipad type apps to see how much damage I can do.... hehhehe

 

Oh man - its so simple now... Here goes the next week.

I used the appstore product touch IR+ downloaded the PC server product, defined my clipsal network as a TCP network with the correct IP and port address.

Created some buttons for turning lights on and off, plugged in some values that I knew worked;
Turn Dining Room light on was
\053800791b2f
To turn it off
\053800011ba7

Told it to use carriage returns.... and voilla - flashing lights as I turn it on and off.

$6 for touch IR+ - but to communicate to a TCPIP address you also need the event trigger module which is another purchase inside the app. Another $2 down the drain - yippee!

So I can now design nice remote screens for the iphone and larger ones for the ipad, control my cbus gear, display web pages (gotta get weather radar for sure, control my media center, set up the live camera feeds, remote control tv's and other gear - even have a mouse controller working - all in the one application... I think I will be busy for the next few weeks.

It supports feedback from devices too - so eventually Ill try and get sliders working showing dimming levels.

Im loving it...


Preview of the app -> http://itunes.apple.com/us/app/touch-ir/id360139270?mt=8

You dont need to purchase it to try it - you can download the server app that runs on windows and test everything from there before spending the (less than) $10 for the purchase. The PC server app is used for the design of the ipad screens, and does not need to be running when you are actually executing it. You can use globalcache and other IR devices, or have the PC server running and get that to do IR commands with a IR dongle...

I know there are other similar apps around that may be more powerful - but they are a lot more expensive.