Improving reliability: Can’t we just run locally?

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.