Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local execution fails with multiple Google Home devices #300

Closed
FireWizard52 opened this issue Jul 12, 2022 · 10 comments
Closed

Local execution fails with multiple Google Home devices #300

FireWizard52 opened this issue Jul 12, 2022 · 10 comments

Comments

@FireWizard52
Copy link
Contributor

Hi all,

After updating to the latest version (0.3.7) I noted that local executions fails. It has been working for a longer time.

However I do not think it is the root cause, but I discovered it after the update.
About 2-3 month ago I extended my Google Home with 2 extra Google Home Mini speakers.
Before I have been using only a Google Nest Hub.

If I look to Chrome: Inspect I see the following:

Screenshot_chrome_inspect1

nodered-google is expected and it receives both googlezone and googlecast. Regardless of the device.
This has been noted before (See closed topics) and some research showed that it might be caused by the Google grouping.

Has anybody similar problems? And better, has anybody a solution?

Regards

@Caprico85
Copy link
Collaborator

I just noticed local execution doesn't work for me either, on none of my two installations. I don't even see the IDENTIFY or REACHABLE_DEVICES intents that you have.

I'll see what I can do. So far I have absolutely no idea on what is causing this.

@FireWizard52
Copy link
Contributor Author

FireWizard52 commented Jul 18, 2022

This afternoon I tested once more, after having reboot the Google Device and restarted the Google Home server and also restarted Node RED. To my surprise, I do not see any error in the Google Console for any of my devices. But still I do not see, that local fulfillment is working. Al least, I do not see the "open" circle. So probably I see the same as you do.
In "Info΅, I find IDENTIFY and all my REACHABLE_DEVICE

As I'm not sure, if in "Google Actions" the "Name" is required and I also noticed that it does no harm, I added in Google Actions a "Name" field.

Google_Actions1

However, I'm not sure if .*\._nodered-google\._tcp\.local is correct.

Regards

@Caprico85
Copy link
Collaborator

I'm not even getting as far as you.

On my parent's home, often the smart speaker is not listed in chrome://inspect. If it does, I'm only seeing the first two "Ready" messages and nothing else. No IDENTIFY or REACHABLE_DEVICES intents. On my own home, the smart speaker itself is shown in chrome://inspect. But no running scripts are listed and nothing to inspect. I tried setting up UDP scanning but I don't see any UDP packets on my network. I also did a factory reset on my speakers, but to no avail.

To be honest, I'm fed up with this. Nothing works and no error messages anywhere so you don't even know where to start fixing. Personally, I'm just giving up on local execution. Normal execution works good enough. Maybe one day local execution wil magically start working again.


But now, back to your problem.

I think the error messages by these IDENTIFY requests can be ignored. Those are other devices responding to mDNS requests. I would have expected Google to filter them out using the mDNS service name specified in the console. Seems like Google just forwards all devices into the app.js script and let the script do the filtering. Maybe we should change this error into a info message. If I ever get my local execution working again, I might try to change this.

It's a good sign you are getting REACHABLE_DEVICES intents. REACHABLE_DEVICES means one of the devices was successfully discovered as the Node-RED host and Google tries to find other devices reachable through this device.

Can you please expand the pc and the Objects in the REACHABLE_DEVICES intent?

image

I'm hoping to see what data we are reporting to Google. It should list the IDs of the Node-RED device nodes somewhere in there.

Can you also please check if you see at least one EXECUTE request after you rebooted your speaker or haven't used it for a while? I want to know if Google tries at least once to control your devices via local execution. Maybe it gets an error on the first try and refuses to use local execution afterwards.


As I'm not sure, if in "Google Actions" the "Name" is required and I also noticed that it does no harm, I added in Google Actions a "Name" field.

Seems like Google does not filter devices, neither by the mDNS service name nor the "Name" parameter. If filtering is really up to the app.js script, it should not matter what you enter as "Name". app.js does not use the Name field.

@FireWizard52
Copy link
Contributor Author

FireWizard52 commented Jul 29, 2022

Hello,

I continued with some extra tests, but the issue still exist.

1, I replaced the app.js file in Google Actions console.
This has been done in order to be absolutely sure that the file is not malformed in any way.
2. I restarted all my 3 Google devices in order to be sure that the correct file, if it had been malformed, should be loaded.
3. I restarted Node RED.

Tested, but no indication that local fulfillment functions (no open ring)
I do not see any error in the Chrome browser (chrome://inspect)

You said:

To be honest, I'm fed up with this

I fully understand, and I noticed that it is working perfectly. How to check, whether "Local fulfillment" is working or not or is it only the indication below the node (open ring)?

I think the error messages by these IDENTIFY requests can be ignored.

I do not receive any error messages in Chrome console, so, like you, no starting point.

Can you please expand the pc and the Objects in the REACHABLE_DEVICES intent?

See below my pc

Screenshot_local_fulfillment_chrome1

And here the Objects in the REACHABLE_DEVICES intent

Screenshot_local_fulfillment_chrome2

This contains all my devices in use.

Can you also please check if you see at least one EXECUTE request after you rebooted your speaker or haven't used it for a while? I want to know if Google tries at least once to control your devices via local execution. Maybe it gets an error on the first try and refuses to use local execution afterwards.

No, I do not see any EXECUTE request, after rebooting the speaker, so obviously Google does not try to control the devices using "Local execution" No errors either if I control a device with my speaker. While I am 100% sure that it has worked before and that I also saw EXECUTE requests

I have also ran out of ideas for the moment and perhaps it will start working again.

Anyone else with the same issue?

@Paul-Reed
Copy link
Contributor

I'm also not able to execute requests locally.
I haven't been taking much notice recently, so not sure when it actually stopped working, but...
I've rolled back the node from v0.3.7 to v0.3.0 to see if things improve.
So far, it's the same, but in the past it's taken 24-36hrs for things to propagate through google, so I'll update you in due course.

@Caprico85
Copy link
Collaborator

How to check, whether "Local fulfillment" is working or not or is it only the indication below the node (open ring)?

Say "Hey Google, force local". After that all commands should be executed via local fulfillment only or otherwise they will fail. Revert with "Hey Google, force default".


No real progress from me so far. By upgrading my Google Home Mini to the preview programm, I at least got the chrome://inspect debugger back. But my speaker only sees three "googlezone" devices, but not my Node-RED. So still no local execution for me. But hey, at least I can play with mDNS discovery now.

@Caprico85
Copy link
Collaborator

I noticed there is a ProxySelected intent in your logs.

ProxySelected is undocumented by Google and nobody knows what it is doing. But the folks over at Home Assistant (which our app.js is "inspired" by) disabled ProxySelected because it may break things.

image

I prepared a new app.js without ProxySelected and uploaded it here. Maybe this will help you. For me it doesn't help. But unlike you I'm not even getting the REACHABLE_DEVICES and ProxySelected intents.

It'll report as version 2.1a in chrome://inspect, in case you want to check if it's running.

@FireWizard52
Copy link
Contributor Author

FireWizard52 commented Aug 1, 2022

Hello @Caprico85

Thank you very much for the new app. To make a long story short, as we used to say, local fulfillment is working again.

I did the following:

  1. I deleted the old app.js, version 2.1, in the Google Actions Console and uploaded the new version 2.1a
  2. I rebooted my Google Nest Hub and my 2 Google Nest Mini speakers.

Screenshot_local_fulfillment_chrome3

  1. Waited a few minutes, and without the need for the command "force local", it started to work again, after a long period of not working.

Screenshot_local_fulfillment_chrome4

I suggest, that you make available this new app.js 2.1a to other users as well and then release it as app.js, version 2.2.

@Paul-Reed
Paul, can you test it as well?

Is there anything, you want to see or know from my configuration?
It is pity, that it doesn´t work for you, as I believe you found the cause of, at least, my problem.

Thank you very much.

Regards

@Paul-Reed
Copy link
Contributor

Nice work @Caprico85 & @FireWizard52
Using app.js 2.1a has restored local fulfillment for me too!

@Caprico85
Copy link
Collaborator

I released v0.3.8 including version 2.2 of the app.js script. You don't necessarily need to upgrade. It's the same as 2.1a, only with a more "official" version.

Thank you for reporting and testing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants