CommandFusion: iPhone control with customizable interface

[CommandFusion]

Yes correct. You enter the connection details for your EventGhost server in the Project properties.

Now start the upload service and it will give you a URL, something like http://192.168.1.72:8019

Now enter that URL into the iViewer settings on your iPhone for the 'GUI File URL'
Set 'Reload GUI File' on.

Start iViewer and it will load the GUI file if you entered all details correctly.

If it still does not work, please list every step you are taking, and all the settings you are entering.
This works for thousands of people, so please be assured it does work, you must just be entering a setting incorrectly somewhere.

The 'connection join' is a digital join which will go high when the connection is open and low when the connection closes. You can assign this same join (any number, up to you) to buttons, etc, so that when the connection takes place you can see it visually by the button changing state.

[Jostein]

Hi Jarrod.

I can see that you mensioned making a cheaper version for just having the interaction with eventghost. Doe you have a time frame for this?

Alsow is the light controlling with the dim sliders and fedback suporting the tellstick plugin?

I have a S60V5 celphone(n97) is there any plans to port the app to work on those or do i then have to use the web viewer. There is not any info on the web viewer as i can find.

Is there any difference in the preformence when running on iphone supost to ipod touch?

Regards Jostein

[CommandFusion]

We have no plans for the cheaper version just yet, more looking for ideas on how we can limit the app, whilst still making it useable.

I am not familiar with the tellstick plugin, but iViewer can interface with anything so long as you integrate it correctly.

We have no plans to support nokia devices directly, but if they support flash or flash lite in web browser, they will work with webViewer.

webViewer is not yet ready for release, so please check back at our website or sign up an account and we will inform you when new products are available.

The latest iPod Touch is slightly faster in performance. But hardly any noticeable difference.

[peter]

Will there in future be any version of this iViewer client for the Window Mobile Platform / devices ?

I have a HTC HD2, and was looking for exactly the capabilities of this iViewer, but then on WM6.x instead of iPhone ...
(f.e. as alternative for "Promixis - NetRemote". Also, this looks nicer and more flexible from GUI perspective then f.e. "Salling Clicker" which is another potential alternative solution)

[CommandFusion]

We may release a version for windows mobile, but nothing is in the pipeline just yet.

[Livin]

Jarrod,
If you do consider a "lite" version for EG users here's what I'd consider purchasing...

Client-side:
*Clients for Windows Mobile, iPhone, Android (have WinMo & iPhone now, getting Android soon - will keep all 3).
*Auto-generated screens
- based upon server-side info
- could still add custom screens in case they are needed for specific things
* All-In-One (all items on one large scrolling screen) and Hierarchical screen options
* Trigger loading of other apps (on the client) with a button press
- example: when I press the "Watch Movie" button in CF (on iPhone), CF triggers EG event and then loads 'XBMC Remote'

Server-side:
*Properties on each EG object to tell CF what screen, enable/disable auto-generated display, etc
- similar to the Floor/Room/Device concept for Home Automation, creating a hierarchy for nesting screens
- the user could "filter" what objects are is shown and where
- ability to have objects assigned to multiple screens
- Only objects with the extra properties are used for auto-generated screens
- Both All-In-One and Hierarchical properties for all objects
- specify other apps (on the client) to load with triggering object (button press)


Benefits of this method...
All config is stored with EG, making backup and restore simple.
Users that do not want to build a GUI do not need to
Very little work, not all objects need to be modified by the user


What would make it almost a must have is the above items AND Homeseer + XBMC integration - this would lock it in for me... and likely hundreds of others as the Homeseer GUI builder is crap.

[CommandFusion]

Client-side:
*Clients for Windows Mobile, iPhone, Android (have WinMo & iPhone now, getting Android soon - will keep all 3).
Andriod is on our todo list.
*Auto-generated screens
- based upon server-side info
The server side info would still need to be defined in some way, so its never 'auto generated' really. You would still have to give a list of buttons you want (position not necessary, but a basic list would be). Apps which auto-generate the GUI are made to work with one set of hardware, eg. sonos app. I'm open to any ideas you have on how auto-generation could work across the thousands of systems and devices we support. Keep in mind that the GUI File XML format is quite basic and you could even have the EG plugin generate this data via a Python script, and serve it via a built in web server if someone is a good enough Python coder.
- could still add custom screens in case they are needed for specific things
* All-In-One (all items on one large scrolling screen) and Hierarchical screen options
We are adding an option to embed large subpages within a page and you can then scroll the subpage, giving you the large scrolling screen effect. Hierarchical screens are already possible, just link a page to another page, etc. There is no benefit in actually designing them as hierarchical in the project tree. Auto generated pages would be different however, and this would be needed I guess when using the default app navigation methods of the title bar and tab bar.
* Trigger loading of other apps (on the client) with a button press
- example: when I press the "Watch Movie" button in CF (on iPhone), CF triggers EG event and then loads 'XBMC Remote'
Not possible with the current SDK releases, maybe Apple will allow this in future. Its a feature many have requested. The only way to do it is if the app you want to launch supports URL Schemes, eg. the Phone app supports tel://123456. This has to be defined and registered by each app however and is not something we can control.

Server-side:
We don't plan on spending much time on the EG plugin, it was released open source and the plan was for other EG developers to take it further. Any changes that would need to be made on the client side could simply be suggested to us and we would work together. We aren't Python coders, so it took a lot of hacking other peoples plugins to get our plugin released in the first place. I'm not even sure what you mean by 'Event Ghost Objects'.

We support control of Homeseer and XBMC I believe (Fiasco has controlled XBMC with his setup I think). Anything that is controllable via TCP or UDP we can control using custom messages, macros and feedback parsing via powerful regex engine. And of course anything that EG can control, we can therefore control and receive feedback from when using iViewer with EG.

[Livin]

Client-side:
*Clients for Windows Mobile, iPhone, Android (have WinMo & iPhone now, getting Android soon - will keep all 3).
Andriod is on our todo list.
*Auto-generated screens
- based upon server-side info
The server side info would still need to be defined in some way, so its never 'auto generated' really. You would still have to give a list of buttons you want (position not necessary, but a basic list would be). Apps which auto-generate the GUI are made to work with one set of hardware, eg. sonos app. I'm open to any ideas you have on how auto-generation could work across the thousands of systems and devices we support. Keep in mind that the GUI File XML format is quite basic and you could even have the EG plugin generate this data via a Python script, and serve it via a built in web server if someone is a good enough Python coder.

The UI generated would be defined by the EG properties. Yes, unless someone mod'd it, it would be somewhat generic but that is fine 99% of the time.
It should work the same on all devices, this is why you keep the UI simple so it will scale easily and only need to know the screen size, which it gets from running the client. Millions of web pages can do this today using the "intelligence" in both the browser and HTML/Scripts. Same reason my home automation UI (ASP code) works perfectly in IE8 on my PC or Opera on my WinMo or Safari on my iPod Touch.
I think the best way is to add properties to the EG objects, this way, CF and any other app could leverage them. I will discuss with some python gurus

* All-In-One (all items on one large scrolling screen) and Hierarchical screen options
We are adding an option to embed large subpages within a page and you can then scroll the subpage, giving you the large scrolling screen effect. Hierarchical screens are already possible, just link a page to another page, etc. There is no benefit in actually designing them as hierarchical in the project tree. Auto generated pages would be different however, and this would be needed I guess when using the default app navigation methods of the title bar and tab bar.

The AIO screen I talk about is just one large (long) screen. Nothing fancy.

The aforementioned object properties in EG should define the hierarchy then the client simply reads and displays.

* Trigger loading of other apps (on the client) with a button press
- example: when I press the "Watch Movie" button in CF (on iPhone), CF triggers EG event and then loads 'XBMC Remote'
Not possible with the current SDK releases, maybe Apple will allow this in future. Its a feature many have requested. The only way to do it is if the app you want to launch supports URL Schemes, eg. the Phone app supports tel://123456. This has to be defined and registered by each app however and is not something we can control.

Yeah, the iPhone OS has a ton of holes. They focused so much on the aesthetics they hose us on "real" functionality.

We support control of Homeseer and XBMC I believe (Fiasco has controlled XBMC with his setup I think). Anything that is controllable via TCP or UDP we can control using custom messages, macros and feedback parsing via powerful regex engine. And of course anything that EG can control, we can therefore control and receive feedback from when using iViewer with EG.

I did not see anything in your Wiki or modules pages about Homeseer support?
As for the XBMC integration, I'm talking again about a pre-created UI, like Collect3's 'XBMC Remote' has.
... for both of these I'm looking for true integration, not something where I need to build each button and tell it what commands to use or create parsing or script code. True integration is more then just sending/receiving a via IP... it is understanding what is being sent/received and doing something meaningful with it without the user needing to give input for each item.


The whole point is to not require the user to 'program' the remote/UI ... at would be true integration IMO.

Once an app such as CF gets to the point of seamless integration and the only thing I need to so is minor setup and/or tweaking of the UI then I'm all in. Until then there are 100 apps that allow me to build a UI and define the buttons and how it communicates with other apps... they are all decent but not one I have found gives what most of us want - true integration, no programming or UI creation or button command'ing needed.
- with exception of the apps build for specific tasks... XBMC Remote (Collect3), RiverMote (Mellowware), etc

[Fiasco]

Client-side:
*Clients for Windows Mobile, iPhone, Android (have WinMo & iPhone now, getting Android soon - will keep all 3).
Andriod is on our todo list.
*Auto-generated screens
- based upon server-side info
The server side info would still need to be defined in some way, so its never 'auto generated' really. You would still have to give a list of buttons you want (position not necessary, but a basic list would be). Apps which auto-generate the GUI are made to work with one set of hardware, eg. sonos app. I'm open to any ideas you have on how auto-generation could work across the thousands of systems and devices we support. Keep in mind that the GUI File XML format is quite basic and you could even have the EG plugin generate this data via a Python script, and serve it via a built in web server if someone is a good enough Python coder.

The UI generated would be defined by the EG properties. Yes, unless someone mod'd it, it would be somewhat generic but that is fine 99% of the time.
It should work the same on all devices, this is why you keep the UI simple so it will scale easily and only need to know the screen size, which it gets from running the client. Millions of web pages can do this today using the "intelligence" in both the browser and HTML/Scripts. Same reason my home automation UI (ASP code) works perfectly in IE8 on my PC or Opera on my WinMo or Safari on my iPod Touch.
I think the best way is to add properties to the EG objects, this way, CF and any other app could leverage them. I will discuss with some python gurus

* All-In-One (all items on one large scrolling screen) and Hierarchical screen options
We are adding an option to embed large subpages within a page and you can then scroll the subpage, giving you the large scrolling screen effect. Hierarchical screens are already possible, just link a page to another page, etc. There is no benefit in actually designing them as hierarchical in the project tree. Auto generated pages would be different however, and this would be needed I guess when using the default app navigation methods of the title bar and tab bar.

The AIO screen I talk about is just one large (long) screen. Nothing fancy.

The aforementioned object properties in EG should define the hierarchy then the client simply reads and displays.

* Trigger loading of other apps (on the client) with a button press
- example: when I press the "Watch Movie" button in CF (on iPhone), CF triggers EG event and then loads 'XBMC Remote'
Not possible with the current SDK releases, maybe Apple will allow this in future. Its a feature many have requested. The only way to do it is if the app you want to launch supports URL Schemes, eg. the Phone app supports tel://123456. This has to be defined and registered by each app however and is not something we can control.

Yeah, the iPhone OS has a ton of holes. They focused so much on the aesthetics they hose us on "real" functionality.

We support control of Homeseer and XBMC I believe (Fiasco has controlled XBMC with his setup I think). Anything that is controllable via TCP or UDP we can control using custom messages, macros and feedback parsing via powerful regex engine. And of course anything that EG can control, we can therefore control and receive feedback from when using iViewer with EG.

I did not see anything in your Wiki or modules pages about Homeseer support?
As for the XBMC integration, I'm talking again about a pre-created UI, like Collect3's 'XBMC Remote' has.
... for both of these I'm looking for true integration, not something where I need to build each button and tell it what commands to use or create parsing or script code. True integration is more then just sending/receiving a via IP... it is understanding what is being sent/received and doing something meaningful with it without the user needing to give input for each item.


The whole point is to not require the user to 'program' the remote/UI ... at would be true integration IMO.

Once an app such as CF gets to the point of seamless integration and the only thing I need to so is minor setup and/or tweaking of the UI then I'm all in. Until then there are 100 apps that allow me to build a UI and define the buttons and how it communicates with other apps... they are all decent but not one I have found gives what most of us want - true integration, no programming or UI creation or button command'ing needed.
- with exception of the apps build for specific tasks... XBMC Remote (Collect3), RiverMote (Mellowware), etc

I don't know how CF could possibly make their remote "programming free". Any remote that attempts to control more then one specific device or system is going to require setup and programming. You are either going to have to do programming on the commandfusion side or your going to have to do programming on the controlled side.

[Livin]

I don't know how CF could possibly make their remote "programming free". Any remote that attempts to control more then one specific device or system is going to require setup and programming. You are either going to have to do programming on the commandfusion side or your going to have to do programming on the controlled side.

I explained how in my post. Nothing is 100% free of 'setup', but I define setup different than programming (scripting, defining all buttons on a screen, etc).

What I discuss happens everyday with many applications... it takes a set of defined parameters (in our case, info from EG) and created a UI.

I've done it with ASP code for my Homeseer (Home automation app) which runs on any browser and auto generates the UI on the browser (formateed for iPhone screen size)...


I also did it with python running on XBMC for Homeseer.

An EG web interface example...
This jscript/html code from a nice community member is a good example of a very basic version of what I'm discussing... http://www.eventghost.org/forum/viewtop ... 194#p12194

I'm not a coder, just a hack and I can do it... surly a professional coder like Jerrod can makes easy work of what I'm discussing?

[CommandFusion]

This can all be done already by an experienced python programmer - our GUI file format is very easy to understand and could easily be automatically generated if someone spends some time working on a solution that generates the GUI file based on properties set within EG. But Fiasco is right, either way you need to do some sort of 'programming' on the server or client side.

I think that the amount of time needed to create a setup to automatically generate a GUI for any conceivable devices being controlled is simply not a good time investment. Why not just create a standard GUI look that everyone would be happy to use within the EG community and develop example GUI files for each device. Then its just a matter of copy pasting what you want from a device into your own multi-paged project and you have control of all those devices setup in the same time as it would take to 'configure' your setup (tick all the boxes, define properties, etc for auto GUI generation).

Our webViewer solution (under development) uses javascript libraries to generate the GUI, which is the exact same GUI file being rendered on iViewer. I dislike how pages are simply made up of 'cells' and use layouts which are inefficient. Even if they do resize to fill any screen, they still look ugly and are hard to navigate because everything looks the same.

[Livin]

I dislike how pages are simply made up of 'cells' and use layouts which are inefficient. Even if they do resize to fill any screen, they still look ugly and are hard to navigate because everything looks the same.

Everyone has their own tastes, of course, but I think my interface is nice to look at and VERY easy to understand and navigate... every guest I have handed my iPod Touch to has not asked a single question and intuitively knew how to use it.

to each his own I guess

[bongolf]

Hi!
I┬┤m using Iviewer toghether with Eventghost and it works very good.
But the limitation to just 1+1 screens is starting to be a problem...

So I was wondering, any news about this:

but we are looking at releasing a version of the app at a much lower price point than our current licensing scheme, which is simplified for use with software such as EventGhost.

Regards

/Bongolf

[CommandFusion]

Currently the only option is to purchase a full license from our website if you want to expand beyond the free 2 pages.

We are planning to release a cheaper license which will limit to say 6 pages (3 landscape, 3 portrait), but this is not going to happen for a while yet.
I can't give a timeframe just yet because we are busy working on other features for the moment.

[Fiasco]

Created a special theme for my wifes iviewer tonight.