How many years out are we from a single standard to rule them all?

The new Belkin Wemo Light Switch and LIFX LED Bulb are steps in this direction since they are both WiFi devices. Proprietary networks are not really a deal-breaker as long as they have proxy-gateways available with an API. They can also bring added benefits to customers such as cost-savings and efficiency while also benefiting manufacturers with a degree of customer lock-in, reduced costs, and manufacturing flexibility. The real key to a system of any decent complexity is a flexible central controller which can easily support any subsystem and will make you forget there are any compatibility issues. It is also important to support a wide variety of customer needs including extremely simple systems (control one plug/switch from a smartphone app) and scale up to complex automation and intelligence. If you only need to change your central controller when you want to improve your system then there is no real problem to fix (other than improving products in that space). The things that are the most disappointing in the current marketplace are companies that go out of their way to differentiate product lines for price separation (Lutron, Legrand) and products that limit interoperability (Nest, etc.). Compare that to something like Insteon, where there are not multiple product lines with reduced functionality (ok to be fair there was an Icon line, but it did not eliminate core features).
Edited by az1324 - 1/12/13 at 5:34pm

Lutron chose to use their own RF standard to make their system better than zwave and zigbee. The Lutron controller can communicate with any other HA controller out there. Don't bash Lutron because they are years ahead of Insteon, and hold the patents.

az1324, if you work for Insteon/SmartHome, you should put it in your signature.

You are kind of mixing metaphors there. The fact that two devices communicate using the same technology is no the same as their being integrated. Even if you can call another person's phone, if you can't understand their language then you may not get much benefit from it. There's a LOT more to having real integration of these devices than just having them be able to phone each other. Someone still needs to understand all the types of devices out there and how to make them work together. So, ultimately, you will still need an automation system or controller of some sort to integrate them into a real system. Given that, then it matters less that they all use the same technology, becaus the automation system provides that translation for you already.

That is basically marketing spiel taken straight from their whitepaper.

You don't mention which product line, which controller, etc... which goes back to the point about forced product line differentiation. Lutron products are not even compatible with each other. Even when referring to a specific line, you're leaving out a lot of important details such as open access to software and APIs, relative cost of gateways, need of repeaters, etc...

It is completely fair and appropriate to point out valid criticisms of any company, especially an industry leader when the discussion is about ideal market conditions for end users. Plus I blame the patent system for that.

You easily are a stronger evangelist for Lutron than I am for Insteon. See first quote above. I don't really even see why you felt the need to defend them in this thread. My post addressed many different companies and products. Lets stay on the broader topic of the thread.
Edited by az1324 - 1/13/13 at 1:47am

You wouldn't know what to do with yourself if you only needed to write one driver for each device class, lol.

A lot of companies don't even want to have to interoperate with other stuff. It sounds great in theory, but ultimately it can be come a huge pissing match when things don't work and there's no one person for the customer to point to as the problem. If you look at the problems of systems like Z-Wave, which is a smaller scale version of what you are talking about, it can be real PITA to get a working system, because the various parts are made by many different vendors and their level of support of features and documentation is highly variable.

It literally takes heroic programing effort to write a good Z-Wave driver. Our customers have never really been totally happy with either of two we've done so far, at huge time expense to us. OTOH, I recently did a Radio RA2 driver, popped it out there, and it's working perfectly right out of the box with no complaints. The difference is that Lutron's system is highly integrated and well designed with everything from a single vendor. If there are problems, I know exactly who to talk to about it. It doesn't try to be everything to everybody. And it's not affected by having to integrate less than stellar implementations of third party hardware within their system.

So, though in theory it's a laudable goal, in reality there are a lot of complications. Such a system would be so generalized and would have to deal with so much variation in quality and feature support, and have to support such a wide variety of capacity requirements, that it would have a pretty reasonable chance of ending up like Z-Wave writ large.

And, let's be real here, any such system would have to target a low price point, and would suffer from the same issues of existing consumer level systems of this sort suffer from. I doubt such a system could span up into the pro realm without using fundamentally better technology. Of course if it actually happened and became ubiquitous the prices would come down. But that would mean it would have to start in the pro world and work its way down. And most companies in the pro world, again, aren't necessarily interested in helping other people make money at their expense, hence how they've all generally implemented Zigbee in a proprietary manner.

So, anyhoo, I'm not saying it's not something to wish for, just it may turn out not to be exactly what you wished for in reality.

Obviously there would be a lot ot be said for that. But, again, that's only in theory. The problem is that you will probably never get all these companies to make devices that fit exactly within those device classes. So you'll end up with lots of inconsistencies. It's one thing for a system like Z-Wave to define device classes for very simple devices, and even then they have issues because some devices just won't fit within the defined device classes, even at that level and even when the manufacturers are making them specifically for the Z-Wave network. Locks being a good example.

Within the much larger world of devices, the ability to create these device classes would get more and more difficult. And it's unlikely that any such standardized device class can be sufficiently flexible without effectively being either far more complex than just doing a protocol specific driver, or so limited that it's not going to be competitive against a system that does do the protocol specific driver and exposes a lot more functionality that the user paid for. UPnP is a good existing example. In theory it can cover a lot of devices, but if you really want to take advantage of as much functionality as possible, much of which may not be implemented by any given device, it's quite complicated because it requires lots of dynamic adjustment to what is available, any of which might render some implicit assumption in the driver (or the client's automation implementation) wrong.

So, anyway, there again, not saying it's not something to wish for (or that double negatives are bad), but it may not be quite as auto-magical as you might think.
Edited by Dean Roddey - 1/13/13 at 2:24pm

I see WiFi as the emerging open standard for home automation. My DirecTv boxes and receivers are all WiFi/network enabled. I can control them with my iPad, phone, or computer just by sending HTTP requests. Roll your own software or use the app. Heck, you can even use your browser. I can imagine a day when every switch, light and appliance has an IP address and we simply send it commands using a single common protocol. Simple. Inexpensive. Non-propriatary.

You have to consider the consequences of an entire home worth of hardware on WiFi, likely with very limited security because you want it to sort of all auto-find each other and auto-configure. The consequences of a network hack would be potentially very significant. I could pretty easily blow your $10,000 speakers probably, or cut the heat while you are away in the winter.

It's easy to just think about the golly-geewhizz aspects of these types of things and miss the possibly serious consequences. None of these things can happen with a secure automation system talking to each device on a private channel, like a serial port, or at least a secure network connection.

And, yet again, not trying to be Mr. Negative, just pointing out that none of these things are no-brainers, despite how it might seem. There ARE existing examples out there, and you have to consider why they never actually achieved what you are looking for. It's not because they weren't capable of it technically. The reasons are much more varied, and much more difficult to deal with.

It's a lot more than that... We are seeing a number of standards (there will never be one - too many variables) for at least the wiring, physical layers and networking. That's WiFi, Ethernet, Cat5e cables, TCP/IP, HTTP, Zigbee, etc. And there's lots of good reasons to use standards here.

And there's the other half - it's the data model and the command / control formats underneath, running on those network protocols that are difficult to standardize. The reason it's difficult is that the speed at which new technology and features gets created is much, much faster than any sort of consortium will ever operate ( Congress!). If you think HDMI has worked well for command/control - look at any number of threads here regarding CEC and EDID issues. And those ARE standards!

The CE industry does need to do a better job of interoperability - believe it or not the PC ecosystem does a much better job of this (for "usability", though, the opposite is true! )... But there were still device drivers to abstract the software from the unique hardware interfaces, and expose common functionality.

The issue is there has to be motivation for interoperability to force that amount of work to occur. If there's no money to be made for the company producing the product, and no market forces demanding it, slowing down your product development or making it more expensive (either actual costs or R&D) to comply with some standards body isn't going to happen. Since the TV maker doesn't get any money when you buy a universal remote, making that work better is just not their priority (that is a bad example, but you get the point). Now, I believe the market forces are starting to come, as the industry adopts (for their own reasons) more Ethernet / TCP-IP / Internet / "Web Standards".

And as the companies learn that providing programmatic access to their products is a good thing, hopefully this will get better. Unlike in years past, they now have a motivation to provide this access, because the mobile device "app" they want to offer will require it anyway. So instead of having to develop and test interfaces that were used for, um, stuff that had no material impact on sales, now it's just a bit of incremental work on top of the stuff they had to do already.

But that won't generate a "standard", not even for basic things like "volume up/down", unless there's some other motivation to do so. While probably 80% of the functions we'd like access to could be easily described in some standard way, the other 20% will always be ahead of the standard and will be unique to certain products. So the best we can hope for, certainly in the next few years, is good documentation showing how to access the gear, hopefully using some common, well-implemented protocols and interfaces (think HTTP and JSON for example).

Getting some traction on an actual data model *and* network protocol standard will take some large market-share folks getting together and agreeing on something, such that there's critical mass to attract developers to utilize it, and then that will apply pressure on others to follow along...

For now, there will remain the need for some smarts in the system, that will have to have some amount of knowledge or programming for each of the devices involved. So yes, the controller will have to know an API specific to your thermostat - but if at least those APIs are documented, and use one of a handful of common web standards, adding the support, even in a device-driver model, isn't so bad. To use a good example - look at PC keyboards and mice via USB - there are universal drivers that work with any of them. And you can type on the keyboard and click the mouse buttons. But if you want to use the special, extra buttons outside the standard, you have to add a specific driver to enable that extra bit...

/rant...

Jeff

Problem is, that hasn't held true, from what I've seen. Look at things like Sonos, AppleTV, etc. They all have apps, but with no real external control. There are other examples where things don't provide suitable IP control, like a few TV's.

The other thing I will say - I would not trust most residential wi-fi networks to run something like my lights. They generally aren't reliable enough, and don't have the coverage to handle a home full of light bulbs and other devices. It is a fairly easy problem to solve, but I'm talking about the average user here that you're trying to target.

Agreed - I wouldn't use either of those as good examples... Neither release their protocol specs to the world to properly interface to them. I would use DirecTV as a good example (but that will leave a bad taste for a lot of folks after they had to pull the guide data support from the public API).

Yep, not one single standard for everything as general purpose networks are not necessarily suitable for more "mission critical" tasks. But there certainly should be a lighting-network-to-WiFi gateway device and an API for that!

Jeff

Don't get your Hopes way Up there....LOL...I've been Collecting and Automating my home, Jeep and Friends, Family's Homes since way back in Late 80's to the First of the 90's and It kills me to see this Technology stay Stuck in Hiding, away from the Average Joe....This could be Big Money Business but it seems to Stay in the Installer/Custom Home Market Like they're keeping a Secret...lol....My First Full Intergrated Voice Recognition System was the Butler in a Box.....around 1993....X-10, Hal 2000, Hal Basic, Hal Deluxe......All that was used in that 1968 movie Space Odyssey 2001....

The crappy part of the ones that are holding this back kinda, like I have the voice PCM modem for a computer that allows all phones to connect, talk to Hal thru phone or open air etc, Well been waiting a few years for a Driver for 64 bit computers and looks like they could care less.... a software disc cost $300 to $500 but don't care to keep you up to date, just want your money is how they are...lol

I've been sending my Lights HVAC etc etc simple commands for over 20 years now...it was at a good price til some saw a need to put a brand name on it and charge $50 for a wall switch when it cost me $5....WiFi is getting ready to change again, for the better...... next generation of Wi-Fi standard, 802.11ac.....and most systems that used that Zigbee have shut down manufacture, rummors of the standard isn't just right or something...lol...

I hope there are further improvements to WiFi:

I spent quite a bit of time getting my WiFi to a point I think it is stable and reliable: and to do it properly is not cheap...much of the consumer WiFi WAP's can be problematic

my opinion only...

To be fair to Sonos, they do provide a fairly extensive control protocol. We have two pretty full featured drivers for the Sonos system, and didn't have any inside information to do that. Though it would be nice if they actually provided documentation for it instead of forcing us to figure it out. Some of it doesn't require much figuring, since it's standard UPnP media stuff. But they have proprietary bits that are not documented and some of that it's hard to use since it's not clear what itis and how it works.

This is true. It's unlikely that anyone in a house sized environment is going to throw some inexpensive consumer grade WAPs in there, with no tweaking, and get a solid solution. It may be ok for simplistic apps, but not for a sophisiticated automation system client like ours, which has to do quite a bit of talking to various back end components. And of course to be able to run multiples of them at once, plus if you had all the other gear wireless and probably were trying to stream at least some media wireless. That's going to typically require pro grade gear to keep it solid.

BTW, we'd probably need a wholesale conversion over to IPv6 before the whole home is going be able to be conveniently IP'd. At least with IPv6 there's no need for devices to get addresses from a DHCP server, because they can generate a unique local address on their own from their MAC address and it won't even change, so reliably connections can be maintained without having to manually set up MAC to IP address assignments in the router. And it also means you aren't limited to 254'ish possible addresses on the local subnet. Once you go beyond that on IPv4 you'd probably have to get into multiple subnets and most folks just aren't going to go there on their own.

Dean

any chance of a Nest thermostat driver that Nest supports?

I guess it could be done. I'm always sort of iffy about supporting devices where the manufacturer doesn't release a spec. If they consider it private, they will likely change it any time they want without consideration for third party clients. So any firmeware upgrade could break the driver. But I guess some folks have spelunked the protocol at this point?

Control 4 released a driver but Nest asked them to remove it: and they did

I am hoping Nest will support a licensed driver someday: I have 8 of them and love them

That's not exactly how to make yourself popular in the automation world. I'm not sure why companies that sort of attitude. It's like Z-Wave, hey, pay us $5000 and we'll give you the right to work your butt off to help us sell a lot more gear and make a lot more profit than you will. Compare that to companies like HAI or Lutron or Global Cache or Elk who send us stuff, sometimes even when we don't even ask for it, to make sure we are supporting their stuff (though to be fair, GC is charging me $35 to send in my GC-100 for a firmware upgrade despite the fact that we've moved a lot boxes for them.) Those are the companies that will be taken seriously in the automation world. Presuambly the Nest folks are more interested in the mass market than in the automation world?

I think the Nest issue stems from the fact the CEO worked for Apple

That certainly makes sense if true.