Indigo Domotics

roussell wrote:

I don’t use Nest products, but for those that do, there may be a path forward with the upcoming Google Assistant local control API:
https://developers.google.com/actions/smarthome/local-home-sdk

Edit: Here’s a TechCrunch article that mentions the API - https://techcrunch.com/2019/05/07/google-launches-new-developer-tools-for-the-google-assistant/

Notice that it requires a Google Home device to work - one that is also (BTW, completely coincidental, no relation WHAT SO EVER) always listening. Just say'n...

I don’t use Nest products, but for those that do, there may be a path forward with the upcoming Google Assistant local control API:
https://developers.google.com/actions/s ... l-home-sdk

I started peeking into this -- Google actually announced a couple of BIG enhancements related to HA:

• The Local Home SDK that you mention which should reduce latency (note I still think it has to authenticate, so OAuth changes that Matt/Jay have talked about will likely be required still... not positive yet)
• BIG change here - for compatible devices (definitely phones/tablets, not sure on smart speakers) all voice recognition will be done on device
• A ton of new smart home device types for Google Assistant. Not sure how I would control a pergola, but hey...
• Integration of NEST to Google Assistant

As to the latter, and subject of this thread, one important point is that the Google Assistant is not a fully closed off garden, just... difficult. I don't know that the same level of integration will be available so easily to a plugin, unfortunately. It might be possible running a RPi middle man, which you can use to send announcements to the Home devices via URL/Indigo. But that isn't as good. Unfortunately, my biggest beef with Google is just this - shutting down services with little warning or alternatives.

I will be further investigating this local integration soon, though... though need to release the latest DomoPad soon too.

Adam

These two FAQs make things very clear:

https://nest.com/whats-happening/#im-a-works-with-nest-developer-will-i-be-able-to-access-and-control-nest-devices-moving-forward

I’m a Works with Nest developer. Will I be able to access and control Nest devices moving forward?

No. The Actions on Google Smart Home platform does not provide open API access to Nest devices, so it cannot be used to access and control Nest devices. Instead, managing and controlling Google Home, Nest, and thousands of third-party smart home devices is done through the Google Home app and the Google Assistant.

https://nest.com/whats-happening/#how-is-works-with-google-assistant-different-from-works-with-nest

How is Works with Google Assistant different from Works with Nest?

Works with Nest allows many third-party partners direct access and control of your Nest devices (with your permission). Works with Google Assistant enables all your connected devices to be controlled by the Google Assistant through voice, the Google Home or Assistant apps, or through Home View on smart displays (again, with your permission).

From the Home or Assistant apps, you can set up multi-device automated actions, such as morning or bedtime routines, through Assistant Routines. Third parties will no longer be able to ask for permission to directly access or control your Nest devices, thus keeping your data more private.

Thanks, Gt3mike for boiling it down nicely.

To me, the implication could hardly be clearer: there will be no way for Google (formerly Nest) products to work in a world where Google Home does not occupy the central controlling position, and specifically no "way forward" for an Indigo plugin to control or monitor Nest thermostats or Nest Protects.

Reading a bit deeper, it seems that if you bought Nest products and found ways to plug them into other control architectures (as all of us using Indigo and Nest Home did), then Google is taking this opportunity notify us that:
a) Google has no interest whatsoever in providing any kind of "legacy" support to keep your Nest products working in ways that they worked previously. This includes completely shutting down functionality that was previously advertised as a core part of the value proposition like the entire Works with Nest ecosystem.
b) Nest devices will stop working (even with the existing Nest control infrastructure that Google owns) in roughly 4 months - they're shutting it down completely. (*)
c) In order to continue using existing Nest products you own, you will have to re-subscribe to a different Google cloud service, with new terms of service -- unequivocally under the control of Google and with a Google product in the exclusive controlling position.

"Works with Nest" used to mean that Nest would let you buy their products and hook them up to your architecture in a variety of ways. "Works with Google Assistant" now means you offer some kind of service that can plug into Google's central controller - that is, you are a smart appliance like a dishwasher that a user can turn on or query the status or that you are a company that sells something people can order through Google like Dominos pizza or Starbucks.

(*) Perhaps Nest devices will continue to coast beyond the 8/31 date as basic "dumb" devices (i.e., purely locally controlled thermostats, and smoke detectors)? ... or perhaps not - I can't say.

This is exactly why I keep my ugly Insteon thermostats and First Alert w/smokebridge smoke & CO2 detectors. I don’t need a brain for them that lives in the cloud, Indigo is the brain.

Alexa is my only cloud reliance, and if Amazon kills that, I’ll just go back to tapping buttons on control pages.

Terry


Sent from my iPhone using Tapatalk

roussell wrote:

Alexa is my only cloud reliance, and if Amazon kills that, I’ll just go back to tapping buttons on control pages.

While anything is possible, I'm skeptical that Amazon has interest in creating it's own walled garden around HA. Their consumer business is to sell stuff (from anyone, not just select partners): stuff that can integrate into other stuff openly just increases the possibility for more sales. So instead of Alexa (echo) becoming the center of an Amazon-controlled environment, it's just one more way to get customers to buy more stuff. That's why they were so quick to come out with the ASK for developers to use to integrate (as ill-conceived as parts of it may be).

I came across the news this morning and was just reading this thread.

Do we think that, as result of shutting down the program, NEST is going to push a firmware update to all thermostats to update to a new, closed API?

Isnt our Indigo plugin running by emulating the NEST, rather than a "works with NEST" officially recognized partner?

How long do we think the Indigo plugin will continue to function? I would imagine that they have to keep the old endpoints up for at least a bit longer while the update gets to the devices.

This completely sucks. I hated Ecobee and went back to NEST after trying them.

lanbrown wrote:

I cannot see them getting rid of the App and as such, that is always a passibility to control and get alerts from the device(s).

I'm not sure I see your point that Google preserving some version of App-based access to Nest devices (which I agree they will do) somehow creates a window of possibility for anything like Nest Home to continue to work. Nest Home used the old Nest cloud service let users sign up and request an auth key, then use this to gain control/monitoring access to all devices registered under their account. Google's making it pretty clear that their new replacement cloud service will have no such functionality (except perhaps for their "Special partners"). I think that not even special partners will have the kind of full monitoring access that the Nest API previously provided.

Will there be ways that the new system can be hacked? Perhaps. Will these result in any robust/reliable workarounds on which you could base a plugin? I strongly suspect not.

lanbrown wrote:

If something is web accessible, there is a way to emulate what someone does from the App/Web GUI into a plugin. It is not like Google is going to invent a new form of communication that is not HTTP/HTTPS nor uses JSON, XML, etc. to accomplish what the App/Web GUI are actually doing.

Actually, no. If the payload is encrypted between the device and the server, then it's unlikely that it can be emulated or reverse engineered. This is why nothing other than the iOS APIs can control HomeKit devices - because the encryption makes it impossible for things outside the HomeKit ecosystem to control them. This is clearly something Google can do too.

Your examples have no such encryption or security, so reverse engineering those is possible.

The "Big Boys" showing me ONCE AGAIN, that I was correct! NEVER buy any device to integrates with Indigo that relies on the "Cloud"

Like @roussell , I still have 3 x T1800 Thermostats, I was tempted by the sexy nests, but didn't like the "cloud" aspect. and when it came to irrigation.. Rain Machine.

The internet can completely vanish in one big EMP and my home will keep on working as it has for years and years. (assuming the EMP doesn't get me too)

3 cheers for Matt and Jay!

Oh, and FTC!

You're assuming that the security is done at the network/OS level. My theory is that the encryption will be done at the application level. So TLS and the rest of the transport stack is irrelevant because the message carried over whatever is encrypted. At least, that's what I'd do given that Android can't be controlled as tightly as iOS/macOS.

That is a vast over simplification as most Android apps that are attempting to prevent reverse engineering (i.e. Google apps) would be obsfucated -- Android Studio, in fact, has support built in, though I can't remember if it is enabled by default or not. If the application encrypts the payload as Jay was referencing (nothing to do with TLS versions) then you would need to determine the encryption functions and method they are using to access the key & IV from an obsfucated decompilation. THAT can be very difficult.

You could, though, get around the need for a direct API -- Google has some officially supported APIs/builds for rPi's that enable the assistant on them. A little coding and Indigo could talk to the Pi which accesses the Assistant and acts as the interface. Now, having said that I don't think it would be the fastest interface layer... but it would suffice compared to, well, no control.

Adam

You are talking about transport encryption. They can embed whatever payload encryption they want in their app itself.

Incidentally, Google has TLS 1.2 available back to 4.1 Jelly Bean... with one caveat, only for those devices running the Google Play Services. The security provider can be updated via Google Play Services independently of the OS.

Of which is visible to what they are doing within the app itself. A few changes of code in the app and you can have the app print what is going on. How they encrypt traffic is also clearly available in the app.

It isn't that simple... possible, yes, but not as simple as you make it out to be when developers don't want their code viewed. As with virtually any program, you CAN end up seeing what is going on, no different than going back to the old days of dumping the assembly in old DOS games to find/patch cheats. But it can take some time and dedication. Of course, if they don't care and leave everything "in plain sight" then this IS fairly easy. I just doubt Google is doing that...

https://developer.android.com/reference/javax/net/ssl/SSLSocket

You are showing links to dispute things that are not what I said... this references the built-in Java libraries provided; as I said, "The security provider can be updated via Google Play Services independently of the OS." You have to update the security provider and then enable TLS 1.2. This is made available through the Google Play Services library. If you are really interested, this is how it is done:

https://developer.android.com/training/articles/security-gms-provider

Then in Android 4.2 and below, you just have to override the SSLSocketFactory to provide the 1.2 enabled. 4.3 and above SHOULD have it enabled by default after the provider is updated.