mikejac / node-red-contrib-google-smarthome

A collection of Node-RED nodes to control your smart home devices via Google Assistant.
GNU General Public License v3.0
118 stars 37 forks source link

is someone working on local execution? #128

Closed Chrischi- closed 2 years ago

Chrischi- commented 3 years ago

local execution in other node-red implementations is super fast and definitely belongs in this project.

is someone working already on local execution?

Caprico85 commented 3 years ago

Not that I know of.

I have never worked with local execution or have seen how other smarthome projects implement it. I only read about it a while ago. So please correct me if I am wrong.

I am not sure if this will really speed things up. From my understanding local executions changes the path from Smart Speaker -> Google -> Developer Cloud -> Device to Smart Speaker -> Google -> Smart Speaker -> Device. This avoids latencies by eleminating the Developer Cloud. But in our case the Developer Cloud already runs on the local network. So you have almost no latency from Dev Cloud to device.

With local execution you also load some piece of JavaScript to your Smart Speaker. Would that JavaScript talk directly to your device? Then you can't use any Node-Red nodes for device communication (i.e. you have to implement the MQTT stuff yourself instead of using Node-Red's MQTT nodes). Or would that JavaScript talk to Node-Red, which handles the device communication. This would bring your "devloper cloud" back into the execution path.

Zarklord commented 2 years ago

So please correct me if I am wrong.

Yes, that is incorrect.

The current flow is: Smart Speaker -> Google Servers -> Node Red -> Device With local execution that becomes: Smart Speaker -> Node Red -> Device

Would that JavaScript talk directly to your device?

No, it would talk to node red. The local execution simply allows the smart speaker to determine where the message goes(it still doesn't take any action itself) without going to the cloud, no actual processing is going on with local execution.

Chrischi- commented 2 years ago

@Zarklord WOW!

Big thanks for adding it.

Is there any way to find out that the user did everything correctly?

I only know “chrome://inspect” to see that local-execution was initiated. Are there log entries in node-red that indicate that the device was accessed locally? It is surely interesting after local-execution was “activated”.

Zarklord commented 2 years ago

@Chrischi- if you view the node red logs, you'll see log entries using the path /local_smarthome instead of /smarthome. you can also say "Hey google force local" to force local execution(you can say "Hey google force default" to revert that).

I have found that the behavior is sometimes very weird unless all devices are restarted after uploading the app, and even then sometimes it still takes the 30 minutes...

Generally if I set the app and go do something else when I come back its sorted itself out.

Also, as far as I can tell you can't have more than one test app running with local execution, so if you have local execution via home assistant(or some other app that has the [Test] prefix, this was just my second app) also neither will work...

Chrischi- commented 2 years ago

@Zarklord Thanks for the clarification. Unfortunately, “Hey google force local” does not seem to be usable in languages other than English.

I also see the following messages when checking via Chrome with (chrome://inspect)

local
Paul-Reed commented 2 years ago

It's not working for me either! @Caprico85 was this tested, and working before merging and publishing?

Caprico85 commented 2 years ago

@Caprico85 was this tested, and working before merging and publishing?

Actually, no 😮. I only tested that normal excecution still works and then merged it. I planned to try local execution this weekend.

Paul-Reed commented 2 years ago

Well, followed the readme setup, including waiting an hour & restarting node-RED, and now no voice commands work at all, I just get "Sorry the ### is not available right now". There is nothing in the node-RED log & no errors reported in the Google Logs Explorer. I can still control smarthome devices by using the 'Home' phone app, but not by voice. I am now trying to roll back from using Local Execution, to get back working as I need voice control, but before doing so, here's a screenshot of my setup.

not smart

NOTE: if rolling back and you have used the command “Hey google force local”, you may need to use “Hey google force default” to restore smarthome functionality.

Zarklord commented 2 years ago

@Paul-Reed are you saying this update broke regular execution? Even after telling google "force default"?

@Chrischi- that's actually fairly normal, if you expand down the payload sent, you'll see that the mdns data is actually for some other device(my most common service was googlecast), that is in fact what the error message is saying "Not Node Red Google Smarthome type" it means that the mdns data wasn't the node red device running this node.

when node red sends its broadcast, you'll see a successful IDENTIFY request, followed by a successful REACHABLE_DEVICES request, followed by a successful PROXY_SELECTED request.

Edit: can you also verify that your on 0.2.4? When I tried to update it went to 0.2.3 and I had yo manually install 0.2.4 via an npm command...

Zarklord commented 2 years ago

And I see that I failed to copy my latest changes to local-execution/app.js so it was running out of date(and buggy) code, once #240 is merged this should work properly...

Paul-Reed commented 2 years ago

@Paul-Reed are you saying this update broke regular execution?

When I added Local execution I asked “Hey google force local” and got the answer "ok". But then, none of my smarthome verbal commands worked (as I've said above). So I removed the LE settings & rebooted node-RED, and they still did not work ( because I had forced local), so after googling, the command, I said “Hey google force default”, and my SH devices again accepted verbal commands. So I'm now back where I started! The update doesn't break regular execution, but forcing local execution does. Yes I'm on v0.2.4

Zarklord commented 2 years ago

Also because the #240 changes are just for the google home app.js, you can use that app.js without waiting for #240 to be merged. You can find that app here: https://raw.githubusercontent.com/Zarklord/node-red-contrib-google-smarthome/master/local-execution/app.js

Chrischi- commented 2 years ago

Also because the #240 changes are just for the google home app.js, you can use that app.js without waiting for #240 to be merged. You can find that app here: https://raw.githubusercontent.com/Zarklord/node-red-contrib-google-smarthome/master/local-execution/app.js

Looks much better now:

Zarklord commented 2 years ago

Looks much better now:

Whoops, I accidentally copied the link to mikejac's version of the app, I have updated the link to properly point to my repo...

Chrischi- commented 2 years ago

@Zarklord I had used yours because I had taken the file from the PR.

But after a "force local" I get the message "'my device name' is not reachable". If i set back to default my devices are available again. Same behavior which also @Paul-Reed had described.

Paul-Reed commented 2 years ago

I've just applied your last PR, again setup Local Execution, and it's still the same, as soon as I 'force local' none of my SH devices are available. (same as @Chrischi- )

Zarklord commented 2 years ago

@Zarklord I had used yours because I had taken the file from the PR.

But after a "force local" I get the message "'my device name' is not reachable". If i set back to default my devices are available again. Same behavior which also @Paul-Reed had described.

can you verify that your getting successful IDENTIFY and REACHABLE_DEVICES intents? if you aren't try restarting both node red and the google smart home device that your using chrome://inspect on? sometimes they don't show up right away for some reason...

Chrischi- commented 2 years ago

@Zarklord

This is what i get:

app

Maybe you could add some debug messages?

Zarklord commented 2 years ago

Maybe you could add some debug messages?

There are debug messages for every single intent... I'm wondering if something is going wrong on node red's side, can you upload a filtered version(IE. without any private data) of the node red log I'll look and see if I can find anything odd with that.

Chrischi- commented 2 years ago

@Zarklord i don't get any request at all in node-red

but I see the following error:

error

Shouldn't the requests come via HTTPS?

Requests via HTTP do not work locally in the browser either. e.g.: http://hostname:3001/local_smarthome does not work, but https works. Maybe this is the problem!?

Zarklord commented 2 years ago

Couple questions Do you use ssl offload? Can you confirm your on 0.2.4? Can you confirm the app running on the google smart device's line 64 is: command.path = `${nodeRedData.httpPathPrefix}local_smarthome`;?

Chrischi- commented 2 years ago

@Zarklord

Do you use ssl offload? no

ssl

Can you confirm your on 0.2.4?

version

Can you confirm the app running on the google smart device's line 64 is:? command.path = ${nodeRedData.httpPathPrefix}local_smarthome

line64

Thanks for your effort and help

Zarklord commented 2 years ago

Okay, so if you use don't use ssl offload, there is an issue where it can't connect, since its trying to connect at https://hostname.local:port/ which you likely lack an ssl certificate for, I'm gonna work on a patch that will use http for local execution regardless of ssl's state

Chrischi- commented 2 years ago

weird

Actually I use ssl but only have a certificate for my external hostname.

Could it be that you mean the opposite?

With SSL offload enabled, http is used instead of https.

Use external SSL offload: If enabled, the smarthome service will use HTTP instead of HTTPS. Check if you want to do SSL termination on a reverse proxy.

Zarklord commented 2 years ago

weird

Actually I use ssl but only have a certificate for my external hostname.

Yeah, that's what I expected.

Could it be that you mean the opposite?

With SSL offload enabled, http is used instead of https.

Use external SSL offload: If enabled, the smarthome service will use HTTP instead of HTTPS. Check if you want to do SSL termination on a reverse proxy.

No, with ssl offload as false(or off) it will attempt to connect over https, but because its uses mdns its trying to connect over https://hostname.local:port/ which as you said you only have an ssl certificate for your external hostname, so ssl verification fails, and it gets no response from this node. With ssl offload as true(which is what I have it set to, I have a reverse proxy so I don't have this node handle ssl), it tries to connect over http://hostname.local:port/ which obviously doesn't need an ssl certificate, and succeeds.

Zarklord commented 2 years ago

@Chrischi- I have updated my branch with I believe the fix for ssl offload. you can test my branch by running npm install git://github.com/Zarklord/node-red-contrib-google-smarthome.git in the .node-red directory and restarting node red. you will also need to update the app.js. and restart all your google home devices/wait 30 minutes.

please let me know if this resolves your issue.

Paul-Reed commented 2 years ago

please let me know if this resolves your issue.

Still not working here using your fix for ssl offload, (I've also updated app.js). I can force local, but then all of my SH devices are not available. No debug messages in node-RED.

Chrischi- commented 2 years ago

same here

ssl_fix

and no debug messages in node-red log

Zarklord commented 2 years ago

@Chrischi- its appears that either: you didn't update app.js or that the google smart device didn't properly update yet, I can see its still trying over https, which would only happen on an out of date app.js @Paul-Reed can you verify that line 62 of the app.js is command.port = nodeRedData.httpPort; if its not that would mean the app.js is out of date.

Paul-Reed commented 2 years ago

looking at line 62, which if up to date should be command.port = nodeRedData.httpPort;

@Chrischi- Yes, that is correct.

commandport

Zarklord commented 2 years ago

@Paul-Reed can you use chrome://inspect to open the debug window and paste any errors similar to how Chrischi- did? these are the docs if your confused how to do this: https://developers.google.com/assistant/smarthome/develop/local#3_test_and_debug_your_app

Paul-Reed commented 2 years ago

I'm afraid the docs are not helping!! I fell at the first step...

serve the HTML page that runs your local fulfillment app

@Chrischi- seems more system knowledgeable, and maybe able to assist?

Zarklord commented 2 years ago

Sorry, you can skip that first step, this is what you need to follow image

Paul-Reed commented 2 years ago

All I see when I enter chrome://inspect/#devices is as the screenshot below. Smarthome is running on a Raspberry Pi, on the same local network as my laptop where I'm trying to inspect.

inspect

Zarklord commented 2 years ago

All I see when I enter chrome://inspect/#devices is as the screenshot below. Smarthome is running on a Raspberry Pi, on the same local network as my laptop where I'm trying to inspect.

inspect

May I ask what google smart devices your running in your home?

Paul-Reed commented 2 years ago

2 x Sonoffs via MQTT 1 x Shelly dimmer via MQTT 1 x Shelly switch via MQTT 2 self made devices (security alerts) via MQTT

All of the above connect to SH Device nodes configured as lights, dimmers, switches & announcements. All have been working great for a number of months (and still work OK)

Zarklord commented 2 years ago

Wait, you don't have any google(as in nest or google) smart devices? if that's the case you are not and cannot be eligible for local execution

Paul-Reed commented 2 years ago

Oh sorry, yes. 1 x Google Home 2 x Google Minis

Zarklord commented 2 years ago

@Paul-Reed try waiting on the inspect page for a minute, sometimes the devices take a minute to show up in the list.

Paul-Reed commented 2 years ago

I've made a cable connection instead of wifi, and now they show up, but clicking the blue inspect link, I see;

inspect

Zarklord commented 2 years ago

@Paul-Reed I can see from the debug log print of "Ready!" at aogh.js:195(this is the app.js at line 195), that your on an out of date app.js, please reupload this app.js on the actions console, make sure to click the X image for the two app.js's before uploading the new version. That "Ready!" should be on line 194 on the latest app. (Future versions will properly increment the version string)

Paul-Reed commented 2 years ago

OK, I deleted both app.js files, saved, left it 10 minutes, then reloaded the files again. I see this in the log, and it refers to port 8443?? I use port 2053 for Smarthome....

log

Zarklord commented 2 years ago

Is port 8443 the port you use for connecting to the node red instance?

Paul-Reed commented 2 years ago

Is port 8443 the port you use for connecting to the node red instance?

Yes

Chrischi- commented 2 years ago

My Setup is now working.

Using this: app.js

I also modified the "Ready!" String with the Version Number 1.0.0 to see at Chrome Console if I use the right app.js after uploading it again via Actions Console.

And finally restarted all my Google-Devices (Nest Mini, Nest Wifi, etc...)

Now I see log messages at node-red side and via chrome://inspect.

Zarklord commented 2 years ago

Is port 8443 the port you use for connecting to the node red instance?

Yes

Then the app should be working, do you see stuff in the node red log? or in the chrome://inspect log?

Paul-Reed commented 2 years ago

@Zarklord - I've removed all traces of Local Execution, left it 30 minutes, then set it back up again using the 'app' link above from @Chrischi- (which is the file I used previously!). I then switched off all GH devices, waited another 30 minutes, powered them up and issued 'force local'. But still did not work.... The only think appeared in my node-RED log was; POST /smarthome 200 7.851 ms - 149 But when checking chrome://inspect I found;

log

Zarklord commented 2 years ago

@Paul-Reed could you expand out the IDENTIFY intent: > Object and Sending >kc variable and post that debug logging I would need to see that to determine what's going wrong.

Paul-Reed commented 2 years ago

Like @Chrischi- I edited the app.js to add `"Ready Paul!" and sure enough, at the top of the log, I have;

hello

The IDENTIFY intent: > Object section...

object

and Sending >kc...

kc

Chrischi- commented 2 years ago

@Paul-Reed

Can you run the following commands on your Raspberry Pi and share them with us?

  1. nmap -p 8443 localhost
  2. sudo netstat -tulpn | grep LISTEN | grep node-red
  3. wget --post-data "{}" localhost:8443/local_smarthome

8443, because this is shown as the port for the requests above. After 3. You should see a log entry in the Node-Red log. For this, your log level for Node-Red must be at least error.

  1. which Port do you use here for Token and / or Authorization URL? actionsconsole_tab_accountlinking_form.png