search

i8beef / HomeAutio.Mqtt.GoogleHome

MIT License
215 stars 29 forks source link

Evaluate the new localhome SDK when available #53

Closed jarrettv closed 4 years ago

jarrettv commented 5 years ago

https://developers.google.com/actions/smarthome/local-home-sdk

i8beef commented 5 years ago

Its on my list to watch. Have to see if Google actually opens this up though, their moves with Nest at I/O and such seem to herald them moving toward a more closed API structure with vetted partners which would shut us out.

jarrettv commented 5 years ago

i watched the I/O videos as I was assuming the same thing. But they actually called out hobbyist and said we could just skip the very last step "publish". i wish they would get involved https://www.w3.org/WoT/ that mozilla is heading up but I'm guessing IoT will remain fragmented for years to come.

i8beef commented 5 years ago

Keep your fingers crossed. Their API for this is very fragmented already with seemingly zero standardization or oversight, so its already becoming hard to support everything they are exposing. This app might be in for a bit of a rewrite around how it handles their API in the future, and the localhome SDK might require enough changes on its own to undertake that refactoring.

i8beef commented 5 years ago

So curious to others thoughts here as this is in developer preview now: https://developers.google.com/actions/smarthome/concepts/local

If I understand this, I'm actually unsure this will really add anything useful to THIS implementation. Local Home SDK doesn't remove the Google Cloud service part, so it doesn't actually solve the "offline" issue. The only thing it really does is eliminate the third party cloud hosted handler.

But if you are running this app in your local network already, its not IN the cloud. Essentially, you'd replace a call to this app in your local network, with a call to the Home in your local network which THEN calls this app: you're actually ADDING a step in the call chain instead of eliminating one. That would make sense for a third party cloud service that might add its own latency / uptimes, etc... but for this app, the latency of the call to the app from Google Assistant is the SAME as the latency of the call to your local Google Home because they are both the same network, and downtimes would be linked as well: if your home network goes down, you aren't talking to your Google Home OR HomeAutio.Mqtt.GoogleHome since they are both the same network.

The only reason to implement this, it seems, would be as a way to mitigate some of the downsides of a third party cloud host... and this just doesn't have those problems (unless you are hosting this in your own cloud host somewhere and linking MQTT brokers or something, etc.).

So I'm not seeing a good reason to actually implement this. Thoughts?

Vayatoalla commented 5 years ago

I understand that this functionality tries, on the one hand, to add extra functionality to the Google Home speaker and Nest interfaces (and a new sales value, of course).. On the other hand, device manufacturers can use it to cut interactions between the users of the devices and their cloud (these interactions may cost them a lot). I think that for use with HomeAutio, you should have the Raspberry on the same network as the speaker or the Nest. It is not my case now nor do I expect it to be ever. And even if it was, it's also hard for me to see the advantage of this solution. At least for the way I use HomeAutio.

i8beef commented 4 years ago

Closing as out of scope for now. If Google expands this functionality so it presents some advantage, I'll reconsider, but right now the local api doesn't actually add anything.