Don’t know if anyone remembers, but during their Kickstarter campaign, SmartThings promised plethora of connectivity methods, including Bluetooth and Ethernet:
SmartThings Packs will support a variety of connectivity methods, including Ethernet, cellular, Zigbee, Z-wave, and Bluetooth. The initial launch units will be U.S. only, and may or may not include cellular connectivity.
Well, as we all know, Bluetooth hardware didn’t make a final cut. That was very disappointing because Bluetooth, particularly BLE has much greater potential than Zigbee, considering that every iPhone, iPad and MacBook supports BLE natively.
Ok, but local control over Ethernet was still on the road map. Then finally, during October 2nd “Office Hour” it was announced that local network control is coming real “soon”. Now, three month later, we’re still waiting. Curiously enough, the recording of that Office Hour is no longer available on YouTube. So as the title says, what’s up with that?
One of the things I saw somewhere as a rationale for doing things “cloud first” was to provide us all access to “supercomputing” (not kidding, that was the wording) power. You know, for face recognition, or other really complex calculations that my apps might try to do.
Right now, all I want is for 15s on a “runIn” call to mean 15s instead of 75. Or for my deadbolt to open reliably when I get home, not 5 minutes later.
It’s possible that the Quartz scheduling system SmartThings uses under the covers is just really, really bad, and local control won’t fix that, but I’m betting that at least some of the delay I see in my apps is because I live out in the boonies and my internet is slow, and SmartThings’ servers are running at high load.
It would be really awesome if the smartapps could run locally on my hub.
Agreed, but there are two separate issues here - one is communicating with the hub over LAN rather than over Internet. This is what other (presumably less smart) controllers do (e.g. MCV Vera, RTCOA WiFi Thermostat, etc.) This eliminates dependency on being connected to Internet and drastically cuts down latency (which is by the way pretty awful sometimes and makes ST borderline unusable.) Unfortunately, as you pointed out, ST pretty much drew the line on this issue and I suspect it will never happen. And if you ask me, I’d say that the reason is not technical (others have done it), but rather rooted in ST’s business model. They want to be the “man-in-the-middle” and have unimpeded access to all physical graph traffic the same way Facebook have access to all your social graph traffic.
The other issue I was referring to is an ability to control IP-based devices (in addition to ZWave/Zigbee). As embedded Wi-Fi modules become more and more affordable, many OEMs choose Wi-Fi over ZWave, Zigbee and other proprietary RF technologies primarily because they can connect directly to the Wi-Fi routers and do not require intermediary gateways which are huge pain in the butt for both OEMs and consumers. Examples are WeMo, Nest, RTCOA WiFi Thermostat. They cost practically the same as their Z-Wave brethren, but don’t need separate hub/controller.
Currently, ST hub cannot communicate with these devices directly. A kludge that’s being tossed around in ST forums is to deploy a SmartApp with custom REST endpoints and implement some sort of a bridge software running on a separate PC to connect third-party IP-enabled device with ST backend. This is kinda ugly.
With the announcement of controlling SONOS they have to be able to control IP-based devices through LAN now. So hopefully this becomes more clear soon.
I also agree with Col. Hack that all these hubs are making a mistake by having everything go through the cloud. In actual use it’s a horrible idea and creates huge delays. For many people it won’t even be an option.
I can’t really understand how the Smartthings folks can think that having all the logic running on the Cloud in all cases is a reasonable architecture. I can understand the value of keeping the hub hardware simple and cheap; I can understand the value of developing and debugging the applications through a web interface; but I should be able to eventually deploy my set of applications completely local; delays and reliability are obvious issues; but also think about other scenarios: how can I invest in home automation based on Smartthings in my current condo when I know than in 2-3 years I’ll leave it and rent it out or sell it; plenty of lighting and heating mechanisms are based on zwave switches that interact one with the other; clearly the new owner or the renter can’t go through my account to manage things; home automation is a feature of the home not of the owner - and Smartthings is tying it to the person. I should be given the option, at least, to buy a more expensive hub which is able to run all the applications locally.
The only explanation that comes to mind is “monthly access fees,” like some other providers. If those are implemented Smartthings would not want you to be able to do anything without the cloud.
@borism: I can only speculate, of course, but I bet ST have a better idea than just charging monthly fees. At any rate, if I were their investor, I wouldn’t buy into a fee-based business model. This is not what would make me millions. These days, investors only raise their ears when they hear “big data” and “social networks”. So, it’s not too far fetched to assume that ST sold themselves to VC’s as the “Facebook of Internet-of-Things”. Now, that would explain why all the data have to travel through their servers. With all the home appliances eventually becoming “smart”, this will be a goldmine.