Closed Chrischi- closed 2 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.
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.
@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”.
@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...
@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
)
It's not working for me either! @Caprico85 was this tested, and working before merging and publishing?
@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.
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.
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.
@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...
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 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
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
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:
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...
@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.
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 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...
@Zarklord
This is what i get:
Maybe you could add some debug messages?
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.
@Zarklord i don't get any request at all in node-red
but I see the following 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!?
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`;
?
@Zarklord
Do you use ssl offload? no
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
Thanks for your effort and help
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
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.
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.
@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.
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.
same here
and no debug messages in node-red log
@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.
looking at line 62, which if up to date should be command.port = nodeRedData.httpPort;
@Chrischi- Yes, that is correct.
@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
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?
Sorry, you can skip that first step, this is what you need to follow
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.
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.
May I ask what google smart devices your running in your home?
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)
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
Oh sorry, yes. 1 x Google Home 2 x Google Minis
@Paul-Reed try waiting on the inspect page for a minute, sometimes the devices take a minute to show up in the list.
I've made a cable connection instead of wifi, and now they show up, but clicking the blue inspect link, I see;
@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
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)
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....
Is port 8443 the port you use for connecting to the node red instance?
Is port 8443 the port you use for connecting to the node red instance?
Yes
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
.
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?
@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;
@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.
Like @Chrischi- I edited the app.js
to add `"Ready Paul!" and sure enough, at the top of the log, I have;
The IDENTIFY intent: > Object
section...
and Sending >kc
...
@Paul-Reed
Can you run the following commands on your Raspberry Pi and share them with us?
nmap -p 8443 localhost
sudo netstat -tulpn | grep LISTEN | grep node-red
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
.
local execution in other node-red implementations is super fast and definitely belongs in this project.
is someone working already on local execution?