HA Technology Comparison Spreadsheet

[upstatemike]

I notice there is not much participation on the Example Systems page. Is this something that is not useful? Should I consider eliminating that sheet?

I also see little or no information for some products. Should products that generate no interest be removed to make the sheets easier to read?

 

[TonyNo]

I was going to add my system config, but wasn't sure if you wanted new columns added.

 

[upstatemike]

I was going to add my system config, but wasn't sure if you wanted new columns added.

Yes go ahead and add them. The columns I put in were just examples with no data and I am going to delete those when we get a few more actual entries. The one David put in is the only real entry so far.

If someone trying to plan a system just looks at "what is supported" among the different products it still doesn't give a feel for how things all work together.

Example: Sombody kind of likes the idea of a system that will pause their music, make an announcement, and then resume the song where it left off. They are thinking of using a Hometroller with the SONOS plugin and getting a SONOS whole-house music system. Maybe they see a lot of posts about the Elk M1 and decide to go that way for security and hard wired inputs. Now that they have a starting point they need to picture how the whole thing is going to go together... Should they use TS07 touch screens with the Elk for simplicity or go with HSTouch or MainLobby screens driven from the Hometroller? Do they connect their thermostats to the M1 or directly to the Hometroller? Maybe they are thinking of using INSTEON. Is it better to go with the tight firmware level support between the Elk and an ISY99 for INSTEON control or should they plan on using the beta INSTEON plugin for Homeseer?

Hopefully this sheet can provide enough examples to help folks picture HOW the products that they are interested in might work together as a complete system.

 

[AnthonyZ]

I popped in and added some to the HAI controller file. I also added Convergent Living and a sample system.

 

[Captain Caveman]

Changes for Centralite Jetstream:

• Lamp modules are available
• The 3 button dimmer can control local dimmer and relay loads.
• Car visor type remotes are available.
• Device firmware is field upgradeable.
• Pre-configurable scenes include vacation, alarm, all on
• The rs-232 bridge has an astronomical time clock.

 

[upstatemike]

Changes for Centralite Jetstream:

• Lamp modules are available
• The 3 button dimmer can control local dimmer and relay loads.
• Car visor type remotes are available.
• Device firmware is field upgradeable.
• Pre-configurable scenes include vacation, alarm, all on
• The rs-232 bridge has an astronomical time clock.

I'll leave it to the CentraLite contributors to bring this up to date.

 

[echostats]

Am I missing something or is this a sticky thread already? This is extremely useful information!

 

[echostats]

Sorry for the double post but should there really be that many NO's for CentraLite? It seems like several of those are wrong.

 

[echostats]

Yes, third post, sorry.

Would it be a bad thing to add Web to the Software sheet to indicate that the software supports a web interface? In my opinion Web means complete compatibility. We all know that PCs can be built for cheap so for the avid Mac user (like myself) this would work best. Build a PC server and then manage it remotely via your browser of choice on any OS.

 

[123]

I think it would be a good idea to indicate if the HA software provides a web-based UI. Unfortunately, a Yes/No response would not adequately explain the capabilities.

For example, some HA software provides an Administrative web-interface ... that's a great feature for remote administration but may not be the UI you'd want to use on a daily basis. Others provide an API to create web-interfaces ... but it exposes only a subset of the program's capabilities.

The other "gotcha" is the belief that if it is "browser-based" it will run on all computers and operating systems. Not really. If it relies on an ActiveX object to do its magic, it means it will only run under Internet Exporer/Windows/PC. More than likely the ActiveX object will be constrained to a Windows PC device that has an Intel "8086 family" processor ... and won't run on a Windows Mobile device powered by some other processor.

I'll give you an example, I use Premise Home Control and it provides a web-based UI for the end-user (auto-generated). When using IE, you must register an ActiveX object (sysconnector) in order to acquire real-time updating of all devices ... meaning if someone turns on a device, its status is immediately updated in the browser ... the browser doesn't use polling ... the ActiveX object permits "subscribing" to a device's changes. Very slick!

You lose all of that magic if you try to use a device and/or browser that can't use ActiveX objects. BTW, this is also true for many IP cameras that rely on an ActiveX object to provide streaming video.

To get around the whole ActiveX issue, Premise provides something called a MiniBrowser web-interface that displays many (but not all) of your home's devices in a simplified manner for use on web-enabled phones, etc ... but you need to hit the Refresh button to update the on-screen status of all devices (i.e. you're back to polling).

So just indicating "Yes" to "Browser Interface?" doesn't give you the whole story ...

 

[echostats]

Well, I see your point. I guess the ideal would be to have a row specifically for "universal" web control interface out of the box. I guess that spreadsheet probably wouldn't be the best place for that.

Side note, what's the best "universal" web interface you've come across? Or the best API so that I can build it for multiple devices (PC, Mac, iPhone, etc)?

I think it would be a good idea to indicate if the HA software provides a web-based UI. Unfortunately, a Yes/No response would not adequately explain the capabilities.

For example, some HA software provides an Administrative web-interface ... that's a great feature for remote administration but may not be the UI you'd want to use on a daily basis. Others provide an API to create web-interfaces ... but it exposes only a subset of the program's capabilities.

The other "gotcha" is the belief that if it is "browser-based" it will run on all computers and operating systems. Not really. If it relies on an ActiveX object to do its magic, it means it will only run under Internet Exporer/Windows/PC. More than likely the ActiveX object will be constrained to a Windows PC device that has an Intel "8086 family" processor ... and won't run on a Windows Mobile device powered by some other processor.

I'll give you an example, I use Premise Home Control and it provides a web-based UI for the end-user (auto-generated). When using IE, you must register an ActiveX object (sysconnector) in order to acquire real-time updating of all devices ... meaning if someone turns on a device, its status is immediately updated in the browser ... the browser doesn't use polling ... the ActiveX object permits "subscribing" to a device's changes. Very slick!

You lose all of that magic if you try to use a device and/or browser that can't use ActiveX objects. BTW, this is also true for many IP cameras that rely on an ActiveX object to provide streaming video.

To get around the whole ActiveX issue, Premise provides something called a MiniBrowser web-interface that displays (many but not all) of your home's devices in a simplified manner for use on web-enabled phones, etc ... but you need to hit the Refresh button to update the on-screen status of all devices (i.e. you're back to polling).

So just indicating "Yes" to "Browser Interface?" doesn't give you the whole story ...

 

[123]

... what's the best "universal" web interface ... Or the best API so that I can build it for multiple devices ...?

Does such a thing exist? If so, I'm not aware of it.

There are plenty of frameworks for developing web apps ... but that doesn't mean they'll work with the HA program of your choosing. It really depends on how much of the HA app's architecture is exposed via an API. For example, many HA apps provide a COM object that exposes some functionality to external programs. Sounds great until you look closer and discover you must use polling to monitor changes in a device's properties or that only a subset of its properties are accessible via the API. Ideally, it should expose its architecture via a set of web services ... that seems to be the best bet to ensure cross-platform compatibility.

The HA Comparison Spreadsheet could include a checkbox for "API" but, like "Browser Interface", a simple Yes/No doesn't give you a complete picture of how much (or how little) you can do with the HA app's API.

 

[paulw11]

Hi,

I have updated the Clipsal C-Bus data in the spreadsheet - I added an extra column as C-Bus has a Cat-5 and a wireless retrofit solution. There are some significant differences between the two so I thought it was worth documenting.

I thought it might also be a good idea to add a row to the spreadsheet that lists the interface technologies available (ethernet, serial, usb). What does everyone else think?

Paul

 

[upstatemike]

I updated the HA Technology Comparison Spreadsheet link to a view that supports the full formatting features. This should make it easier to scroll around while still being able to see the column headings. I also suggest you close the "Discuss Pane" that comes up on the right side so you can see more of the actual spreadsheet on your screen.

 

[upstatemike]

If you contribute to the HA Technology Comparison Spreadsheet but have not visited it lately, you might want to do a quick review of your entries. Folks have been real good about adding new fields for comparison and expanding the sheet but if those fields did not exist when you last visited, chances are there are a lot of blank spaces under the product you were working on.

At some point I will have to make a "best guess" or just put question marks in some of the blanks but having somebody who is familiar with the technology enter the correct information would definitely be better.

Thanks again to everybody who has helped out with this project!