Vendors come and go, but if I've bought a product, I expect it to work until the product dies. And I don't consider the vendor going out of business to be a valid product death. Not to mention if I'm paying a one-time-fee, and this thing requires communication with vendor servers, that's a service. Who's paying for the servers?
I agree, current user interfaces suck, but I think at least for some vendors that may miss the point. If they publish a full-featured API you could write your own interface, and or integrate it with your home automation control system. I agree, standards need to exist, but I try to reward the vendors who provide an API over the ones who don't cause at least I can work with an API.
And honestly, looking at the result of vendors trying to produce "smart" TVs, I don't want them writing the software that runs my home automation system. I'd prefer a FOSS home automation solution over a vendor one any day, and wouldn't buy one that didn't at a minimum include the source code.
The first the that recurring revenue is strictly better than one-off sales. That means VCs aren't interested in business models that don't end in "aaS".
The second is the emphasis on iteration - making users connect back regularly allows for automatic updates that allow you to ship buggy software and fix it later.
One example is a lack of any kind of manual focus on any phone cameras. If I'm taking a picture of a person or a cat or something the autofocus does the job right almost every time, but try taking a picture of a small shiny button or something - it's a nightmare. If I could press up-down-up-down-A-B-A-B-start-select and get a manual focus slider, I'd be happy all the time, but instead my few salient memories of fighting with the autofocus have soured me on the whole experience.
Another problem is APIs and connectivity. Tuning a light on or off should be doable with a simple POST call to a RESTful service somewhere. Instead, we are sold dubious phone apps for everything.
There's no "open standard for wireless control of a light", because there's not one standard way to do it. For a dollar in parts, I can build a wireless light switch that uses 433 MHz, just like your wireless doorbell.
Oh, you wanted a network of addressable lights? Well now it's a dollar fifty. We'll move to 900 MHz and switch to a ZigBee radio.
Oh, you wanted to address them through WiFi? Well, here's the problem. Light bulb's don't have keyboards to enter your AP+Key. You could try and use WPS with a fixed pin code, but there's another issue. Putting an embedded Linux device that handles POST requests in a lightbulb is rather silly. We'll keep the ZigBee radios, and build a crossover "base station" that has a RESTful XML based JSON buzzword complaint interface.
Did I mention my ZigBee radio only talks with my brand of ZigBee radios?
The problem in making a standard comes down to the radios in the lightbulb. That interface will likely always be proprietary. Even if you get a standardized web interface, no one will be able to make a universal base station for all "smart" electronics. Wink is trying to do that, best of luck to them. I don't see it happening.
http://thegadgetflow.com/blog/wink-wants-new-standard-smart-...
I haven't found an all-in-one solution to do all this. Then again, I haven't looked for anything else once I got my curtains going through Tasker. An open standard would've made the process much simpler though.
Overall I've found that z-wave is quite reliable. It never loses commands and latency is good enough. The protocol supports just about any kind of device or signaling you might want, in theory, though it can't really do high-bandwidth things. The problem is that devices are relatively expensive (compared to the cost of the components) because the protocol is quasi-proprietary. Zigbee is "open" and extremely flexible, but as a result, zigbee devices from different vendors often can't talk to each other. I'll take the more limited but working thing, thanks.
(The Trigger app's geofencing is pretty unreliable, though. Has anyone found an android app that can reliably do http requests when crossing a geofence?)
Unfortunately, the setup stopped working and I don't have useful tools to debug it; no way to know why an INSTEON controller can't see another component, only that it can't. Plus, I'd like to move away from systems that want to use the house wiring at all (INSTEON is hybrid x10 / radio) because I don't want an errant power surge blowing my $100+ of equipment.
This. I keep seeing devices that make me do more manual work to control things around me. These devices make my world more complex, while I need it to be simpler.
It's why I started working on my own system to control lighting at home.
Things that just work for 10 or more years, omg! ;)
But you are absolutely right!. I did not automate anything at home with separate hard/software, because currently it solves no problem for me.
We need not a smart home, we need an intelligent home without controlling or programming everything.
A house/appartment has to recognize if nobody is at home and turn off the light or heating. I dont wanna do that with my smartphone and i dont want controll everything.
The companies that generate and are influenced by this excitement tend to make two main errors.
1. They don't understand that without an open standard for controls and sensors they are just fooling themselves. No one is going to permanently install something in their house that is sure to be useless in 10 years.
2. They don't understand that people don't want to control everything ... they instead want to not have to control everything. Being able to control a light from your phone is not really any better than being able to do it from the light switch. People instead want the light to just do the right thing without having to think about it. They don't want a thermostat controllable from a phone. They want a thermostat that makes it so they are comfortable and not paying any extra money they don't have to. As a result, the home automation people actually want is a much harder problem than what everyone always seems to assume.