I was encouraged to see Google announce renewed interest on the home front. This is pretty darned exciting. Even if cloud based, I imagine Google’s servers can keep up with it.
Yes Google knows a lot about me, and because of that it has the smarts to present me with services and information without me even having to ask for them. It knows when I am traveling, in a meeting, on vacation, my upcoming itinerary, and this can make for a truly smart home.
As for community concerns, the Android community has almost 7 million members, with nearly 500,000 active contributors. Real developers that have provided rootkits, optimized kernels, and even fully operational custom firmware, all free of charge. I think I’ll know where to go to get answers if I need them.
So we will soon have a player in HA with the financial resources of a samsung (and then some), the innovation of an Apple (and then some, IMHO), an open source OS, and a huge legacy of services provided based on what we ask for, what we search, what we buy, where we are, where we’ve been, and what we schedule. And now they’re not only in our pockets, but on our wrists and in our cars.
While this can be scary to some, and even I am sometimes astonished at what Google now presents me with (“how the heck did it know that?”), it provides tremendous value and convenience, and I know (unlike most other services) I can wipe all that data at any time with a couple of mouse clicks, and even download to my computer before hand.
Agreed. I realize how big the android dev community is. and you as a dev will know how to interpret those answers… but what about the layman?
How would a new (non-dev) user get a specific use case taken care of? Is someone in the android community going to custom write an entire android app for the one specific use case that only a small number of people (maybe just one person?) will use? I’m not active in the android dev community so I’m not sure how willing people are to do this kind of thing. A lot of people are willing to the that in this community.
Agreed. I love this too! I was playing devils advocate. Do we want them to have more info then they do now? As long as it is anonymous I don’t really give a fridge… AKA. Don’t serve me ads based on whats in my fridge… etc lol.
I think a STs could to cloud integration would be cool! Openess and community of STs with the cloud of google… that’d be cool! Then with the local processing of Hub V2 you could control your Weave stuff with local rules if either cloud has a hiccup or your internet goes down. (someones gotta do local processing of weave stuff eventually)
I didn’t want to hijack the Brillo thread, so I started a new thread on diagnosing network issues. You may have already tried everything there, but just in case it might give you some ideas. Meanwhile, I feel your pain, that sounds horrible!
There are plenty of layman their now. They have no problem getting answers they seek. And there is also the more layman like Android Central (with another 2.5 million members).
But I don’t envision the kind of granular support necessary to SmartThings to be akin to what Google will do. It knows when I get home, and it will know if it is dark. It will most likely ask me once if I want the lights turned on under those circumstances; and if I say yes, it’ll be done going forward. Granted that is a simple scenario, but you get the idea.
The next Android, ‘M’, will actually track your devices’ usage. It will recognize long, regular periods of not using your phone (like when you sleep), and shut down non-priority services to save battery. The new Photos app they pushed out yesterday already knows which of my photos have snow in them, or when I was playing golf. My Google Voice number knows many incoming calls are SPAM and sends them to the bit bucket with no interaction from me, as does InBox/Gmail. Last year I forwarded one of my main email addresses to Gmail that always got a ton of SPAM; I don’t recall it ever having made a mistake with the messages it recognizes as SPAM. It is these kinds of smarts and amazing algorithms I expect Google will bring to the table.
I have no idea what the local/remote processing model will be. I can say that my mail, contacts, calendars, photos, music, magazines, many documents, shopping lists, and more have been on Google’s servers for years, and I can’t recall a single time when I have been unable to access any of it due to a Google issue. That is a far cry from SmartThings. Google cloud services are the gold standard! I will be all in and quite confident it won’t be an issue.
My internet going down is also not much of an issue. Heck, the power goes out far more frequently. But if there was an issue in this area, I wouldn’t think twice about replacing my AEBS with a CradlePoint unit. It may even be possible for one of our mobile devices to be designated a tether for those times your main ISP goes AWOL, and additional hardware may not even be necessary. Our phones already do this for the services they provide, doesn’t seem that much of a stretch to have weave tied into them.
Now it is not inconceivable that Google will screw this pooch… heck, I had avoided Android for a very long time. But what I have seen over the last 18 months has been very exciting. I just put Android Auto in my truck; while it is clearly not finished, it is very cool and I prefer it to CarPlay. It’s the Google way to throw it out there unfinished and get user feedback, which they take to heart far more actively than Apple or Microsoft. Expect this with the home endeavor as well, but I think it will be exciting to be an early adopter.
So my question is what happened to Android@Home? Is Brillo a totally new architecture or a modification of previous work? I normally like to be an early adopter, but I’ve become somewhat wary of Google’s new ventures (e.g. Google TV), especially when it could cost time and real money. I’m somewhat curious but not holding my breath on this one…
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
28
I’m not sure I see the value in being an “early adopter” … nor holding one’s breath. Both just increase stress.
These innovations and developments are exciting to follow and worth “borrowing” ideas from. But, as exemplified by @octoxan’s postings, spending “$1000+” on gadgets that you don’t understand well (or that have various degrees of uncertainty as to their futures) is the path to frustration.
We are in very interesting times for Home Automation / Smart Homes / Thoughtful Homes / IoT – Of all the major new entrants (Apple, Google, Samsung…); I personally find Amazon Echo to be the most interesting and amazing, as that device does one thing extremely well (and potential integrations are materializing very well too…), without Amazon having made their own predecessor (ie, no OK Google, Siri, or Cortana).
Perhaps IoT is a fresh fertile ground for everyone. That means there will be a lotta cowpoop to go around.
What could make Google fail in this space is that it is far too easy for them to fall back upon their core business.
No, just because you wear smarty pants doesn’t mean you are a smarty pants. This will mean, though, that many people will be wearing trousers smarter than they themselves are (though, thinking back over some past encounters, this may not be the first time this has occurred… ).
However, when contemplating “Android Gear”, “Galaxy Gear”, etc., this will bring about a whole new meaning to the phrase “Get your arse into gear!”.
Brillo is the slimmed down (but not tiny) version of android intended to run on HA devices. Some reports say it will require 32 m , others 64 , both are pretty heavy. Android@home included a hardware piece, Nexus, which is absent from this week’s announcement. Brillo is intended to encourage device development by other companies, like android for mobile phones.
Weave is the communication protocol, not quite clear on the details yet except that there’s going to be some interoperability with Works with Nest (through Thread?)
Android@home talked about mesh and bluetooth but never really got far enough to clarify things like hops and range.
The most interesting thing about Weave is that it won’t require Brillo.
Beyond that…not enough to know yet.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
32
At Google I/O in the “Nest Home” area, I had the pleasure of meeting and chatting for a while with the Thread Group President “Chris Boross” (Mr. Thread) and here’s my very rough, off-the-cuff explanation of what I understood.
Full disclaimer:Please be clearly assured that everything I’m writing in this post is being pulled out of my donkey. There are most certainly great resources you can Google for accurate information, and there will be excellent writers that can present way better analogies than my sketchy attempt here.
Brillo
Already described excellently by JD:
Is Brillo more like Linux or more like Android? Does it matter? Will Thing “chips” be tuned to run Brillo? Can ARTIK run Brillo, or are they in competition? Does anyone care? – not yet!
Thread
A communication layer that enables IPv6 addressing of all Things. Using this definition, very roughly → Thread is the “TCP” in “TCP/IP”; i.e., Roughly, the Transport Layer of the OSI Model.
Thread is physical layer independent, and possibly also not restrictive to particular Data Link Layers and Network Layers and might be used in concert with various existing wired and wireless networking technologies (such as ethernet, Z-Wave, ZigBee, Bluetooth, 6LoWPAN, etc.), though IEEE 802.15.4 is the official preferred transport. Thread on non-802.15.4 thus involves some protocol conversion or redundancy (WiFi, for example, already can address IPv6 devices, of course, so perhaps Thread won’t run “over” WiFi). The Thread standard includes security, reliability, mesh networking, power-friendly, etc… Thread will be implemented, like ZigBee, etc., on specialized chips (i.e., hardware – but with configurable firmware).
Weave is software. Weave maps to the “session layer” in the Seven Layer OSI model, I think, and it can theoretically use “any” lower layers (i.e., Weave could run over Thread, TCP/IP/WiFi/Ethernet, Bluetooth, and, yes, possibly over ZigBee and Z-Wave).
But let’s put this in Internet of Things terms…
Weave is an API that overlaps with some of Z-Wave and ZigBee. Weave let’s Things identify their types and abilities, so it’s a bit like ZigBee Cluster Specs and Z-Wave Command Classes. But Weave also provides standard APIs for Things to talk to each other, on the same network or routed to other networks (i.e., Weave communications can travel over Thread on 6LoWPAN and be routed to via TCP/IP to a WiFi, ZigBee, Z-Wave network, or WAN to a Cloud, or Bluetooth to a phone, etc…). This is a bit like the SmartHub V1 which routes ZigBee and Z-Wave to the SmartCloud.
Weave also provides a framework that Things can use to directly interconnect each other functionally: i.e., Weave compatible Things could agree that one is a switch, the other is a light bulb, and the switch can thus control the light bulb. This is a lot like Z-Wave direct association, but more open and flexible. Weave provides an API so that a mobile App can find, understand, and control a Weave compatible light bulb, switch, etc…
So … If I haven’t overestimated its role; Weave enables hub-less Thing to Thing interaction, not just communication.
Weave is likely redundant or in competition with other framework layers, like Apple Home Kit and Alljoyn, and, as mentioned, some parts of ZigBee and Z-Wave. But they can likely co-exist with API abstractions, protocol conversions, bridges, whatever. Weave could also make some major “pieces” of SmartThings unnecessary.
Based solely on this rough and likely inaccurate understanding and brief discussion I had with Mr. Thread, if you were running all Weave compatible Things, and SmartThings made a “Weave compatible API” to the SmartThings Cloud, you would no longer need a SmartThings Hub. You would only need the SmartThings Cloud to take advantage of it’s rules engine, cloud-cloud connectivity, and front-end apps. Your Weave Things might actually talk to the SmartThings Cloud via a Nest Thermostat: which uses Thread for local mesh wireless communication between itself, Nest Protect smoke alarms, and various other Thread connected Things like motion and contact sensors, lights, etc.; and the Nest Thermostat would use WiFi and TCP/IP route the Weave to the SmartThings Cloud and/or your smartphones or other TCP/IP devices (computers, Hue bridges, etc).
This is consistent with various discussions about Apple Home Kit and earlier mentions about Weave where we seem to observe: These frameworks imply we can have a SmartHome without a hub. After learning this bit about Weave, I’m inclined to agree. But keep in mind – just because we can run without a hub, it doesn’t mean that there won’t be equivalents in the home. The Nest Thermostat, for example, acts like a hub, in that it has intelligence, and it routes between Thread and TCP/IP/WiFi. SmartThings has hinted that Samsung may build SmartThings “hubs” into future models of televisions. With Weave, a hub is not necessary for consumers to start to make their home “smart & thoughtful”. This concept is live right now as many homes have Nest Thermostats and/or Protects and/or Dropcams and … no single equivalent device to the SmartThings hub.
The above few paragraphs on Weave are extra BS, because Weave is less defined than Thread at the moment, and I can’t find any good lazy reference links on Weave yet.
The chart shows the Zigbee and Thread stacks, and is a good visual representation of how Zigbee ‘fills in’ the hole for Thread at the application layer with the Zigbee Cluster Library. You can also see how Zigbee can take advantage of Thread’s IPV6 IP at the network layer.
Google I/O was a lot of fun, but the Brillo/Weave/Thread announcement was a tiny, tiny portion of the Keynote.
The 20 minute Nest API / Developers presentation was informative, but focused on REST-API communication with the Nest Cloud only; there was no information given on if, how, or when third-party Thing developers can directly use Thread and/or Weave to communicate to/from Nest devices within a Thoughtful home (i.e., there’s no way for third-party developers to use the Nest as a multi-protocol “hub” … yet).
Hmmm…I wouldn’t have picked TCP, as Thread doesn’t appear to actually support TCP (a session based protocol).
Rather, I would have picked UDP, which Thread does provide along with DTLS (think TLS/SSL, but for datagrams (like UDP) rather than sessions (like TCP)).
Thread also includes the IP layer (IPv6) and, as @tgauchat says, runs over 6LowPAN over the 802.15.4 (low power mesh network) MAC and PHY layers.
The focus on datagram based protocols and the omission of session based protocols makes sense given the focus on an underpinning low power mesh network.
Also incorporated is a commissioning process which ensures only authorised devices can join the network.
Thread also includes an efficient routing protocol (RIPng - RIP for IPv6 - a simple distance vector routing protocol) to allow nodes on the mesh network to function as router nodes but without requiring excessive resources to do so. This also allows the mesh network to support multiple border gateways, so there needn’t be a single master node (single point of failure) in charge of the network.
When a device joins the network it states whether it can function as a router or not. If it can, the network decides whether or not it should. Just because a node can be a router doesn’t mean it should be - the network may already be sufficiently resilient and adding another router just increases the size of routing tables and RIPng traffic.
So, in all, a very functional network running over a low power mesh network with a nice UDP (and DTLS) upper layer which lots of people are already familiar with and can be routed over standard IPv6 networks (and tunneled over IPv4).
Before anyone tries to drill too deep into all that, let’s just note that an API is how people write software that accesses the features of other software. Literally “application programming” interface.
A network communication protocol is how devices communicate with other devices. Including addressing schemes, message routing, repeaters, etc.
They may look somewhat similar from a coder’s point of view but they are really different from a device manufacturer’s perspective.
A 16 bit address has significantly different implications for device design than a 128 bit one. But application programmers won’t care.
I also wanted to mention that there are two forms of hubless networks.
One form tends to have very loose security, and pretty much lets any device talk to any other device that can receive the signal. Sometimes these are unidirectional (devices are either transmitters or receivers). A simple example is plain old FM radio. The station sends out the signal with no idea of who the listening devices are or where they’re located. The radios pick up the signal and listen, but don’t send back.
This isn’t used much in home automation, because you’d be picking up signals from your neighbor’s house.
The other version doesn’t have a dedicated hub, but does have a device that manages who belongs to which network. In most of the current models this is a smartphone. But it could be another multipurpose device like AppleTV. Or it could be something built into the WiFi router.
But when we’re talking home automation, even in a “hubless” network there will be some way for a lightbulb to know whether “all lights off” applies to it, or was meant for the next apartment over.
I’ve emailed them a few times. Usually they say they’ll look at the logs to try to figure out why nothing is working and then just never respond again.
I’ve made sure me and my 2 nearest neighbors are on non-interfering channels as far as WiFi goes. And my house isn’t very large, my Nighthawk gives me a good WiFi signal all over the property outside the house. Also my Nest and non ST controlled devices all work great.
Fingers crossed there’s a hub V1 to V2 trade-in program because I’d be a little nervous throwing more money at this problem if it doesn’t end up functioning as advertised like V1.
Probably not. Brillo and Weave are hardware and cloud platforms, respectively. They are being built for developers. Brillo is a stripped down version of Android for device makers and Weave is IoT platform for letting all of your devices talk to each other. Given the release schedule for these two platforms, you probably won’t see any real world things using them until early 2016. Even then, they are not a replacement for SmartThings. Brillo will power an entirely new batch of devices. Weave might work with your existing stuff and it might not.
Because everything I’ve seen says Thread is completely physical layer dependent: it runs over IEEE 802.15.4 devices. That’s an antenna specification. Low power, 2ghz spectrum.
Again, application programmers won’t care, but device manufacturers will care a lot.
Yes all the bulbs in my entire house are Cree lights.
Oh well I hope V2 actually functions. At the moment we feel like we were just tricked/swindled out of thousands of dollars because nothing works nearly as smoothly as it does in SmartThings advertisements. Not for me, not for my friends, not for my parents and not for most of the people I’ve talked to.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
40
I think you are correct. Thanks!
The confusion is because I am led to understand that ZigBee can run Thread or coexist with Thread or something along those lines.
Is ZigBee 802.15.4??
Weave, however, should be physical layer independent, still, I think.
AKA. Don’t serve me ads based on whats in my fridge… etc lol.
).
