Yeah, you’ve got the basics down. The Z-wave and Zigbee protocols what I see as the most widely used to enable local control. Basically, if the internet connectivity is lost, but the hub is still connected to a powered Wifi router, local control based systems retain most wireless control functionality and automation capabilities.
Google Home and Amazon Echo are absolutely 100% cloud based, which becomes annoyingly obvious every time my internet drops And Google rudely interrupts me to let me know she’s worthless. SmartThings claimed at one point to be partially based on local control, but I was never able to see it demonstrate that. So why the obsession with local vs. cloud based control? I’m glad you asked!
Some folks insist on a local system because otherwise “They” will see what your doing and watch you and stuff… I won’t criticize that perception, but it certainly is NOT mine. There is a very minor distaste I have for the inherent operational inefficiencies which are cloud based control systems.
I’ll illustrate this using my own set up because I regularly use both. I am a heavy Google Home user which I have as integrated with my Hubitat Elevation Hub as possible. When I use Google to turn on my kitchen lights, I do the requisite “Hey Google, turn on the kitchen lights”. She’s rocking about an 85% success rate to all, and that’s on with me. So, the verbal command is recieved by my Google Home Mini, which digitizes it instantly in order to transmit it to my wifi router. Through the router determines where the packet is going and pushes it through my modem, over to the closest Comcast hub, and off to the cloud. After the packet redirects 3 or 4 times, it arrives at the Google Home AI interpretation algorithm processing system somewhere in cyberspace. The data packet is then processed in ways which are a mystery to me. Does it analyze the command whilst still in digitized wrappers, or does the system reconvert the command data back to analog? Whatever happens, let’s call it magic, magic happens and the Google AI recognizes my command by validating the data integrity to confirm it’s actually coming from my Google Home device, and then scrutinized the command against what my particular set up has integrated. As luck would have it, it matches the designation of “kitchen light” with a known device which is residing on another system, Hubitat.
At this point, had I asked for a joke or something, the response is sent back down the pipes the same way (sorta) that it came. But in this case, Google determines it needs to pass this command off to the appropriate partner app. So now Google sends an OAuth intent to the Hubitat servers which is 3,000 miles away physically, but mere nanoseconds in Google speed. Once Google is able to confirm that it’s authorization is still valid, they execute a handshake, and like a drug deal in plain site, Google slips the command to Hubitat, in Google language still. Once Hubitat bows and kisses the ring, Google goes into stand by mode while Hubitat translates the Google command into a Hubitat command it just recieved. Hubitat servers already know its associated with my hub, based on the OAuth handshake, so it determines if the command matches with what I have on my hub. It finds that my kitchen light is actually listed, probably does a few more magic data validations, before it is satisfied enough to take the command, now translated into Hubitat speak, packages or up nice and neat into a data packet, and pushes it out across the expanse with my modems IP address in the To line. Once the Hubitat confirms the data packets are successfully on their way, Hubitat servers glance over at the Google server which has been patiently waiting, and informs Google that the command was successfully sent. Your OAuth is now disabled until next time.
Now is a race, almost always won by Google in my house. The Hubitat data packet racing to my IP, but what of Google? Well once Google recieves the confirmation message from Hubitat, it immediately fires off a digital command back to my Google Home Mini, by way of Comcast servers, my modem’s IP address, though to my router which, get ready for this, routes the data packet to the appropriate local IP address assigned to the specific Mini. Unless there is some weird built in delay with Hubitat, the command packet from the Hubitat server appears to follow closely behind the Google Home data. As you suspect the routet this time pushes the command to the Hubitat Hub local IP address, where the Hub now decrypts and validates the command, and sends the appropriate signal via the appropriate protocol radio. In this case, it sends an “On” signal via Zigbee radio addressed with the unique device designation in order to direct it along other Zigbee services until it gets to the Peanut Smart Outlet which I have a lamp designated “Kitchen Light” plugged into. Once the command is recieved, the smart outlet validates it as legitimate, and activates line power to the outlet, and tada, light! The outlet then sends a message back to the Hub to record the event and update the status to “On”.
Now, the Google data that came into my network ahead of the Hubitat command data, what happened to it? A fraction of a second prior to the actual light illuminating, my Google Home Mini will announce “Ok turning on one light” as it’s follow up. It’s supposed to stop doing that and only play a tone as confirmation now, but all my Minis aren’t there yet.
So yes, that entire trip through cyberspace took probably 1.1 seconds total. But Jesus that’s a lot to just turn a light on. Let’s contrast that with what happens during local control. Same hub, same light, same command. The difference this time is instead of a voice command, I’m using a godawful looking dashboard UI on my cell phone.
When I launch the dashboard on my phone, what is really happening is I’m launching a reconfiguring Google Chrome browser which always points to my Hubitat Hub Wifi Router designated local IP address. So up comes the dashboard, I cringe, but work through it. I find the square that has “Kitchen Light” in bold letters. I tap the square and that fires off an HTML formatted message through my phone Wifi radio to my router, the router directs it to the Hubitat Hub. The Hub then translates the HTML into Java, validates it a few magical ways, and determines which radio to use to send an “On” command through and what designated device. As with before, the Zigbee radio is used and the means is sent, long of the short, we’ve seen this part before, BOOM light.
SOOOOOO much less… EVERYTHING. So much cleaner, so much quicker (it actually is), and you know what, when the internet goes down for the 12th time in a day, I can still turn my kitchen lamp on without getting off my ass!! But the primary reason I wanted local control was because of the stupid internet. I wanted to automate the power recycle for my modem in the event of internet connectivity loss. So I got myself a Zooz Z-wave part strip, badda bing!
Lastly, if you’re not familiar with Z-wave or Zigbee, they are competing systems, both great, but both limited to simple near binary data transmitting and receiving. These are protocols for turning things in and off, not streaming video, audio, or to send complex code.