I just saw that Nest is having a press conference on the 17th (as seen on http://www.theverge.com/2015/6/4/8730145/nest-event-june-17-announced)…
Anybody here with insider info (as if that were legal… lol!) that might know what’s cooking? 
1 Like
They’re taking SmartThings off of Samsung’s hands for $100M.
Just kidding…
2 Likes
I’d downvote this, so much.
4 Likes
@April Me too!!! That would be the saddest day ever!
Really? You don’t think there is some possibility of a positive result from a strategy rearrangement such that SmartThings becomes a member of the Nest family instead of Samsung?
This is just a thought exercise; there are likely quite a few Community members who may not think that that Samsung arrangement is optimal, and that the success of Nest in the marketplace is an indication that perhaps they and/or Google could be a net positive catalyst.
(I think this doesn’t stray from the OP Topic, since Nest + Google is most certainly positioning themselves to be a major player in the Smart Thoughtful Home market.). As such, SmartThings’s business and technical strategy will be impacted by Nest’s influence.
3 Likes
Can only say “touché!”
1 Like
The article suggests some audio solution. Maybe they are considering an Amazon Echo and/or Sonos type platform.
2 Likes
Well they purchased Revolve, so I’m sure that’s going to get chewed up and spat out as “Nest Home” or something like that. Although google thinks your can run a smart home from a phone… that leaves throughout the day…
Where did you get this impression??
Google = Nest
Nest = every Nest device with WiFi also has Thread, therefore, every Nest device can be an IP to/from Cloud router (i.e., a SmartThings Hub V1 with Thread instead of Z-Wave & ZigBee).
I was pretty sure the latest google I/O had project Brillo controlling your home directly from android phones.
And I guess the nest could become a hub, but that would be different from its current implementation.
That’s not what I understood.
Brillo is just an OS (Android Lite)… Like the little Linux distribs for Raspberry Pi, but smaller. It says nothing about the communication layer (though preferred stack is Weave (when available) on top of Thread).
And as for Nest: I do believe they work as I describe (i.e., they can route Thread to/from Cloud, but currently restrict Thread use to between Nest devices only, and do not open Thread connections to 3rd party devices but only allow Cloud-Cloud for such).
Interesting. I’m getting less and less excited about anything that says cloud though. I’m getting more jealous of Insteon’s local control as I learn and experience more scenarios.
I agree with your concern, as do many consumer-focused designers.
The trend is towards the SmartThings Hub V2 model though (hybrid local / cloud) due to:
-
The desire to use the Cloud for data collection and mining (Google especially, obviously, is primarily an advertising platform based on data mining).
-
Optimizing processing power and minimizing software distribution (a la Chromebooks).
-
Making it unnecessary for the Consumer to pick a “Hub” first, since any Thread device is potentially a Hub if it also has TCP/IP. And/or, Thread routing may become commonplace in home broadband modems / WiFi routers.
Right now pretty much any voice solution, including Amazon’s Echo,
Ivee, Ubi, Cortana, and even just plain Siri or Google Now on a smartphone is a hybrid solution, because everyone’s doing voice recognition in the cloud. Voice has massive processing requirements.
But I do think there’s a difference between a cloud service like weather or voice that returns a value and having your rules engine in the cloud.
- Making it unnecessary for the Consumer to pick a “Hub” first, since any Thread device is potentially a Hub if it also has TCP/IP. And/or, Thread routing may become commonplace in home broadband modems / WiFi routers.
Weave, maybe. Not Thread.
Remember, Thread is hardware-dependent and includes an antenna standard. WiFi is not and cannot be “Thread.” (Thread is low energy. wiFi definitely not. thread is mesh. wifi again definitely not.)
Thread devices can identify WiFi devices because both use IP addresses, but that doesn’t make a WiFi router a Thread device.
http://threadgroup.org/About.aspx
Thread addresses the need for a new and better way to connect products in the home. Built on open standards and IPv6 technology with 6LoWPAN as its foundation, Thread offers numerous technological advantages over other wireless standards including secure and reliable networks with no single point of failure, simple connectivity and low power. With Thread, product developers and consumers can easily and securely connect more than 250 devices into a low-power, wireless mesh network that also includes direct Internet and cloud access for every device.
IEEE 802.15.4 is the “open standard” which defines the physical layer used by Thread.
WiFi is based on IEEE 802.11ac. Different physical layer.
Ummm… I didn’t say “bridge”… I said “router”.
Thread will use IPv6 addresses for all your Things. Thus, just like NAT routing, internal IP addresses and ports should be exposable to the WAN (or at least tunneling of Thread through TCP/IP is feasible)… No? In other words, Thread is one way to enable the dream of unique IP addresses for everything and that facilitates easy routing between locations, with protocol conversion on the way as necessary.
Weave is an extra layer if devices need to describe each other to interact.
Per your Thread quote:
wireless mesh network that also includes direct Internet and cloud access for every device.
The whole point is that every WiFi router already has everything it needs to be addressable by a Thread device and vice versa–they both use IP addresses. Done.
It’s meaningless to say “Thread routing may become commonplace in home broadband modems/WiFi routers” because the routing piece is the IP address they already use.
So if you’re predicting something will change in the future (“become commonplace”) that would be the software communication protocol. Weave, not Thread.
You may be right about Weave, but that’s not what I’m saying.
I’m saying WiFi routers may include Thread hardware (i.e., be a part of your Thread mesh). Weave doesn’t exist, but Thread does. Thread can exist without Weave.
It’s not possible.
It’s possible for there to be a plastic box that includes a WiFi router and a Thread device, just like it’s possible to have a plastic box that includes a television and a blender.
But a WiFi router cannot include a Thread device. They have different energy draw standards.
If you’re suggesting we might eventually get a communication center box in our homes that includes multiple antennas, including one for WiFi, one for Thread/Zigbee, one for bluetooth, etc, then, sure, a lot of people (including Samsung with Artik) are betting that there will be widespread home use of multiple protocols in the future.
But you’re not adding anything to the WiFi router. You’re just housing it and some cousins in the same plastic case.
SmartThings didn’t add zigbee devices to the Zwave mesh. It housed two antennas in the same plastic box, with two controller devices, and added a software scheduler that could talk to both from the cloud.
I know…this is hardware, and most people don’t care. But these are very hard problems to solve from the engineering side, and it really does make a big difference if you say the router joins the mesh. Just sayin’. 
Yes. This is an accurate way to describe what I am suggesting. And to the best of my knowledge, the Nest Protect (and probably Nest Thermostat) also fit this description more or less.
I didn’t mean to imply that specifically; rather, we can compartmentalize and do protocol routing. The Thread interface is on the Thread Mesh. The WiFi is on the WiFi LAN, the WAN is a third interface, Z-Wave a fourth, and so on. Traffic can be exchanged across interfaces using intelligent protocol conversion / routing (like NAT and more). Weave is an option to help, but not the only way to do this.
1 Like