Improving reliability: Can’t we just run locally?

I really don’t see why this would be the case when there are, currently, apps that run locally like Smart Lighting. Just because you trigger and process things locally doesn’t mean that those events can’t then be synchronized back up to the cloud for data mining purposes (not that I’m sure that they’re doing that to that level of fine grained detail, but maybe).

You can continue to keep the mobile app running through the cloud vs. local to make sure that the end user has incentive to keep the hub online if that would also be a strategic concern. In fact, running the mobile apps through the cloud makes sense because, otherwise, you’d have to rely on the end users to muck around with their LANs to ensure direct connectivity to the hub LAN or WAN.

Crap, I just read bravenel’s response to you. Oh well, since I typed it all out, here’s the td;lr - read bravenel’s response.

That’s not true. Vera, Philips Hue and many others solve this problem without requiring the user to always connect “through the cloud” or “muck around with their LANs”. Which again points to the fact that this is a business decision, not a technical limitation.

1 Like

Philips Hue absolutely needs you to be connected to the cloud for remote control. I believe Vera does as well… My Hue bridge will NOT do a damned thing if I’m not connected to the cloud (third blue light blinking). My lights won’t even show up.

It’s not their fault. Something’s wrong with your setup. I have both Vera and Hue and can assure you that I can control them over LAN without internet connection.

P.S. Refer to Philips Hue FAQ.

Do I need an active Internet connection to control the Hue system?

All in-home Hue features will remain working without an active internet connection being active, except out of home control, IFTT, geofencing, Siri voice control and software updates and HomeKit

If you are using scenes created in your hue cloud account, then you have to have an active Internet connection. Or if you want to use Siri for voice control (that’s always true of Siri).

But otherwise as long as your phone/tablet is connected by Wi-Fi to the same network that your hue bridge is on, you should be able to do everything.

https://www.reddit.com/r/Hue/comments/40599l/what_can_the_hue_bridge_do_without_an_internet/

So it all comes down to what we mean by remote control. If you mean control the lights at home while you are at your office across town, then yes you have to have an Internet connection. But I believe the original question was could you use your phone app locally, and the answer to that is certainly phone apps can be written that don’t require Internet access. But the phone/tablet does have to be on the same network as the device being controlled.

1 Like

Yes, I was referring to the ability to control things remotely, not while sitting on the LAN. It’s possible that the app team hasn’t yet gotten around to adding the local execution portion of the mobile apps yet. If that road map even exists, I would think that it would of low priority since the model has always been cloud based. I find that more plausible than there being a higher level directive to keep it going through the cloud for data collection purposes since, like the existing local apps, any of those events could subsequently be sync’d up to the cloud.

My (short) list of priorities would be:

  1. Local synchronization of device handlers and smartapps for local execution

um… that’s it. Of course as I continue this journey, I’m sure I’ll think of more things. As of right now though, I can’t think of anything more important.

PS. I just wanted to say that I enjoy reading the forums and especially posts from veteran members. So I don’t want to come across as combative or anything so please don’t take it personally if I disagree with you. We all have our opinions :smile:

1 Like

This is accomplished via a local web API to the hub and upnp discovery. Not rocket science, but yet another api that the (already fragile) ST app has to support. And honestly, Hue is a single device with a handful of attributes (plus groups of same) - not the panoply of device types with device independent UI descriptions that ST supports.

The best bet to pull that off is indeed a local compute capability which directly mirrors a single instance version of whatever grails framework + goo they’re running on aws (or wherever) with both the hub and the mobile app doing “local discovery” of the local server and if found, using it’s compatible API over the cloud… with the local compute then pushing state changes to the cloud graph.

Or at least that seems likely the path of least resistance to me. Maybe we should start a kickstarter project :slight_smile:

2 Likes

I agree with the main points of your note, I did just want to mention that Staples connect, which does have multiple device types, and harmony, as well as connect4 and various environmental control systems all offer the same thing as Hue. That is, local operation as well as tablet/phone app control over LAN.

As SmartThings is implementing “local control,” you can get smartapp which runs locally, but you can’t turn on lights individually or arm or disarm your Smart Home Monitor or lock your door. Or turn off the siren. Only a predefined automation can run. It’s true you might have set up a minimote in advance, but as someone who can’t physically use a minimote I’m very aware of these limitations.

Most of the home automation systems that I’m aware of that do have local operation also have a control UI that will work locally at that time. It might be on a desktop rather than a phone, but it exists.

1 Like

Do any of those support non-vendor supplied device types or behaviors (ie, apps?)

Some of the ECS do, and certainly there are ones with desktop UIs that do. They may not have any option for access when you’re not on the LAN, but when you’re on the LAN there’s a UI. Indigo, OpenHAB, Vera, even insteon all have local UIs and allow for custom code.

I wonder if ST is listening and I would hope that true local reliability is in the work. Otherwise, this is a bit like Apple saying that they can decide if your app runs on the iPhone as a PHP-based web site or as a Cocoa-based native app.

Yes, Vera supports third-party custom plug-ins and multi-protocol abstraction model. It can communicate with any Z-Wave, UPnP or generic IP device over TCP or UDP sockets, as well as any serial interface via USB-to-serial adapter, for example Insteon PLM, Zigbee USB dongle, Bluetooth USB dongle, etc.

P.S. There’s also a number of pretty cool DIY open-source projects using Vera as a controller. See, for example http://www.mysensors.org

Is the Vera your primary HA device? If not, why not?

Yes, I run two independent Z-Wave networks - one on Vera and another on ST.

I’m definitely looking at Vera Plus when it comes out. I think the gap may be in the cloud-to-cloud services part of my design (e.g. Harmony, Alexa).

I use cloud services for some things, particularly voice. You can always mix systems if you want to. (You can also do Echo to Harmony just through IFTTT.)

Just as an example, Insteon runs mostly locally, but uses cloud to Echo. Harmony itself will run locally, but again uses cloud to IFTTT.

2 Likes

Any input on insteon systems JD?

Every system has pluses and minuses. There’s already a topic for Detailed discussion of Insteon as well as other options, so follow ups on that topic probably better go there:

Oh sorry. I don’t remember insteon being in that post.

1 Like

This is an awesome idea! I wish it could happen. My always on Mac mini server is basically the most valuable computer in the home, its doing about 30 tasks that require a server to be always on, adding a SmartThings server to it would be yet another great use.