SmartThings Hub Version 2.0

@DallasFlier. ASUS routers cannot hold a stable 4G connection over days and weeks. And even if they could, the added latency of mobile connection would slow down my Internet experience compared the primary 100 Mbps cable connection. Using 4G when I don’t need it would be stupid in others words. Not a solution to ASUS’s problems. The Peplink router failover mode actually manages the 4G WAN connection for you. You can have instant failover or cold standby failover that takes a few seconds to turn on and initiate.

1 Like

@Ben Whether it be through an expansion slot of native built in, Insteon would just be wonderful. I’m not trying to debate which is better, just as a current Revolv orphan I would really love to have native support through ST. It was why I went with Revolv in the first place. Insteon at the time had the only light switch I could find that didn’t require a neutral. I couldn’t rewire everything for my old home. I realize this isn’t the case any longer but I have $500+ in Insteon devices and would really love to be able to keep using them. I can limp along my Revolv hub until ST 2 is ready. Please consider! Do what Revolv couldn’t and by the time Nest has it’s stupid Thread protocol done you’ll already have an unstoppable market share.

1 Like

Given that Samsung is part of the thread group is ST going to be using the protocol in hub 2.0 or in the future?

I wondered about that too @jodyalbritton.

I did a bit of reading before on it and iirc Thread uses the same freq. as Zigbee so I wonder if a device with a Zigbee radio would be “software” updated to use Thread? This article seems to imply this would be possible: (A good article, BTW, on the benefits of Thread vs. some of the other formats)

So far I haven’t really heard much about Thread at all, so I don’t know if it’s gaining traction at all. You almost wonder if because Google (and now Nest) seems to be heading it if Samsung would look more at it as competition? For what it’s worth, the article linked above also stats that it’s the chip division of Samsung that is part of the Thread standards, vs. the ‘CE’ (Consumer Electronics?) side.

Good stuff. I stumbled across it while checking out Big Ass Fans. Seems they are already using thread for communication between the fan and the nest. I like the idea of devices announcing to each other what their capabilities are. Having a device pop on to your network and announce, “I have temperature, humidity, and a switch with the following states” would be pretty cool. I don’t think we are headed to a hubless future but certainly one where devices need the hub less.

I’m not sure we’ll ever get to the point of having no Hub. There needs to be something with brains that tells the rest of the stuff what to do based on what conditions.

Now, what the form of that Hub is will be more open for debate. Could the Hub be embedded in a thermostat, for example? Or could the hub just be a program running off your computer? Could the Hub be embedded in your WiFi router? For that matter, could any one of your HA devices be smart enough to act as hub and it’s just randomly chosen by the Mesh network?

The benefit of a larger standard, though, is the reduction of multiple hubs for multiple devices/protocols. Instead of having a Hub for ST, and one for Hue, and one for PlantLink, and one for Lifx, etc. etc. it would all work off one Hub.

1 Like

I think it is important to distinguish the different layers of the architecture, even if they may or may not be running in the same physical box.

There’s a difference between a bridge which has various types of radios (Zigbee, Z-Wave, BLE, IPLo-whatsis) and converts to IP, then a router which forwards these converted packets to a processor which executes apps / rules / event processing.

The latter portion could be 100% cloud based, but we know that is undesirable.

The HUE Bridge is a good example of a ZigBee to IP converter (and it provides an http REST-API server), though it communicates with the Philips cloud.

This deserves a detailed and accurate diagram with all the variations and protocols on it in pretty colors.

I just hope the new hub has a better method of detecting mobile presence, whether it uses Bluetooth to do that (though there you’re limited by range - Wifi would seem to make most sense for this) or whatever it takes.


I hope so too. I allow Smartthings to lock my door based on the presence of my phone. I would like to have the abilty to narrow the radius much further than what is currently allowed. I like the idea of the presence sensor having an option to use wifi or bluetooth.

Another option would be the abilty to set zones based on the presence sensor using GPS for example:

Zone 1: Park
Zone 2: Grocery store
Zone 3: Movies
Zone 4: etc.

Scenario, youu arrive home, Sonos plays:

Welcome home John. Kim is at the (grocery store). I sent her a reminder about (reminder) for you. The boys are: ( Tony, library) and ( Michael, is in his room). Is there anything else I can do for you (awaiting reply).

Sort of like using GPS to “tag locations” and create zones and in addition as other members have stated beacons to sensor locations within the home.


The hub currently doesn’t do anything with mobile presence detection. That is all your phone’s geo-location services. Bluetooth will likely be a part of the solution going forward.


In hub V2.x or V3, Smartthings should address some issues related to the way the service manager is tightly coupled with its child devices.

As I posted in another thread and at the last developers’ discussion, this causes robustness and reliability issues for many device types out there. Many ecobee users prefer to use my custom ecobee device rather than the ST stock for that reason.

The service manager should follow OO patterns like Inversion of Control (IoC) and the Factory patterns. This should be taken into account for the hub v2.x or 3.x architecture, especially for local processing.

In my books, a device handler (device type) should be a self contained object with no tight dependencies to other objects.

For more info on IoC and the object factory patterns, please refer to the following links:



I’m currently using Wifi connectivity to trigger presence events using the Tasker Android app, and I know a lot of other people here are as well. But I’d love to see Wifi connectivity as a core part of the SmartThings app for determining presence. Bluetooth would be great as well.

Fellow Revolv orphan, looking for a new home. Just need Insteon to support my Fanlinc’s. Ben, what are our chances that ST/Samsung wants us more than Google/Nest did?

Switched to Telzio btw… Thanks :wink:

Hi everyone,

I was wondering if anyone thought it would be a good idea that the next hub had an on board battery to allow a remote reset.

I notice lately that resetting my hub tends to resolve most issues. So I’m thinking if the hub could be reset without physically unplugging the hub it would be convenient.

For security applications, I would assume battery backup to be essential. But what if your Internet goes down as well?

Rather than adding a battery to the Hub, it would be better to use an UPS for both the Hub and router.

Another thought to explore. As the Hub basically uses an USB adapter, get a USB adapter with built in battery. One example is the HooToo HT-TM04 Tripmate Elite. As the HooToo supports a 3G/4G dongle, maybe that can be leveraged as well???

That’s a cool device. Thanks for pointing that out!!!

Hi Paul,

I have a U.P.S for my network. What I would like to do is has the abilty to turn the SmartThings hub off and back on without physically unplugging it. My main problem is I will lose control of lights etc and nothing will work until I do a hard reset.

For example when I install my dropcams I always place something into the frame that is constantly moving i.e. a digital clock. Just an added measure that my live feed is in fact live. Many times when I’m at work I’ll check on things and devices are unresponsive. I can verify this by viewing my cameras.

When I get home, usually 14 hours later I need to unplug the hub wait and reconnect it at which time the devices for the most part will function. I would like to reset the hub without having to use a second hub on the outlet SmartThings is plugged into. I was thinking that maybe with a built in battery the hub would be able to power cycle itself remotely??

I am a Revolv orphan as well. I have a fair number of insteon devices which is complicating my next step. I have to agree if there was insteon support you could expect a massive influx of users from Revolv. The antenna wouldn’t need to be native, it would be fine if it was expandable somehow.

@Cheekid Why not reboot the Hub using the Hub Command ‘Reboot Hub’ from the web interface?