UDP Local fulfillment failed

[MuadDibVV]

Hello,

Thank you for your great job. I have a docker installation and I just try the UDP Local fulfillment. Unfortunately it doesn't work: In chrome://inspect/#devices I found many reachable devices But I never see a ring icon instead of the usual filled circle. Any idea ?

[Caprico85]

Hi,

I'm having the same problem. The setup at my parents flat worked for a while with UDP. My own setup (mostly identical to that of my parents) never worked with UDP. But in the last weeks it didn't work with MDNS either. Now that I tested it, my parents setup also stopped working. Now they all show the same behaviour as yours. REACHABLE_DEVICES, but no local fulfillment.

Neither switching to MDNS nor downgrading to 0.3.x helped. Though I may not have waited long enough. Sometimes it seems Google bans local fulfillment for a few hours or days after it encounters a problem. Then it magically starts working again.

The people over at NabuCasa (Home Assistant's implementation of Google Assistant) are having the same problems. Therefore I'm not sure if it is a problem at Google's side this time.

[FireWizard52]

Hello @Caprico85

You wrote:

Neither switching to MDNS nor downgrading to 0.3.x helped.

I assume you tried to test with the latest version 0.4.0. After updating to this version, I discovered the same . I never tested with UDP, as for me, after some start-up problems, mDNS has always worked. After the update to 0.4.0. it has been discovered that the app.js file did not work for me. This has been solved by Claudio (@ckhmer1) in a patch for app.js. As I see the version has not been updated yet, I assume that this patch has not been propagated to npm, while it is available on github. See: #345 This means that anybody, who updates to version 0.4.0 through the palette, will receive a faulty app.js file and so local fulfillment will not work, in case mDNS is used.

However I do not think this will solve the UDP issue, but could be something similar. I suggest that you update to a newer version soon. Has this patch been applied by your parents and by yourself and uploaded to the Google Actions Console?

For me, since this issue has been solved, local fulfillment is working fine.

Regards

[mgugu10]

Hi @FireWizard52, Trying also to make local fulfillment working with mDNS. I confirm that that app.js is not in version 2.6 when using patette or npm install. So I made correction manually. But I still get errors: -Service browser shows correct IP address/port -Chrome://inspect shows detected devices but a lot of errors:

And local fulfillment still not working Any idea ? (And thanks to developpers for this great piece of software)

[FireWizard52]

Hello @mgugu10,

Up to yesterday evening 'Local fulfillment' has been working for me. However at the moment it is not working. I assume some Google issue. Nothing has been changed at my side.

If I compare the log screens from 'chrome://inspect' I see that you don't get the error message that I received (Unable to find Node Red Google Smarthome connection info) Currently I do not see any error message in chrome://inpect

Also the logging in the Google Cloud Console does not show any error, except of 1 locale in the execution log. I never saw that before. You said:

So I made correction manually.

What did you correct manually? Did you correct version 2.5 manually and edited also the version number and changed 2.5 to 2.6? See: #345 I changed line 134. and tested it. So my version 2.5 has changed a little. @ckhmer1 released a fix as version 2.6. These 2 are a little bit different. See below:

My patched version from line 133:

} else { clientId = deviceToIdentify.mdnsScanData.txt.clientId; if (!deviceToIdentify.mdnsScanData) { console.error(request.requestId, "No usable mdns scan data"); return createResponse(request, {}); } if (deviceToIdentify.mdnsScanData.type !== "nodered-google") { console.error(request.requestId, "Not Node Red Google Smarthome type. expected: 'nodered-google' got: '" + deviceToIdentify.mdnsScanData.type + "'"); return createResponse(request, {}); } }

Version 2.6 from line 133:

} else { if (!deviceToIdentify.mdnsScanData) { console.error(request.requestId, "No usable mdns scan data"); return createResponse(request, {}); } if (deviceToIdentify.mdnsScanData.type !== "nodered-google") { console.error(request.requestId, "Not Node Red Google Smarthome type. expected: 'nodered-google' got: '" + deviceToIdentify.mdnsScanData.type + "'"); return createResponse(request, {}); } clientId = deviceToIdentify.mdnsScanData.txt.clientId; } try { const nodeRedData = findNodeRedDeviceDataByClientId(request.requestId, request.devices, clientId); return await forwardRequest(nodeRedData, "", request); }

As you can see the two files are a little bit different. I assume that Claudio has tested his version.

I think that the result of the two files should be the same, but I did not test the official 2.6. I recommended to push a new version to npm, so that nobody will install a version with a non functioning app.js.

You might want to try my version, but it would surprise me if that would solve your issue.

But as said, currently my local fulfillment is not working either and I saw in the chrome://inspect of one of my Google devices a similar error as you. Let's wait a while.

Regards

[mgugu10]

@FireWizard52 I use nodered in docker, so to update, I simply pushed the official app.js v2.6 in the node modules volume. I checked your patched version with same results. But now, apps files at actions console and nodered side are different. Is that a problem ?

[FireWizard52]

@mgugu10

I think that is a problem. You should upload the app.js file to Google Actions Console. The app.js file should be identical as the one in the installed version of Google Smarthome, in my opinion

[ckhmer1]

Could You please show the same data shown by @FireWizard52 ?

and

[mgugu10]

Hi @ckhmer1 , Here the screenshots

[ckhmer1]

The first message shows the identify response, the txt part contains the client ID.

Could you please show the content of one customData from the second image?

[mgugu10]

@ckhmer1

[ckhmer1]

All data seems correct, I agree with Google problems

[ckhmer1]

It seems that the port 1880 is not reachable. Did you pass the checks?

[mgugu10]

1880 is also the port for nodered UI, so it is reachable. Service browser detects _nodered-googl._tcp with the right address and port

[ckhmer1]

Il

1880 is also the port for nodered UI, so it is reachable. Service browser detects _nodered-googl._tcp with the right address and port

You have configured the local fulfillment with msdns if service browser detects it. Could you please share your configuration?

[mgugu10]

Here are my confs local and remote.

[ckhmer1]

You have configured node-red for using MDNS not UDP as wrote in the title.

This configuration is not tested with docker, but the MDNS scan packet seems correctly delivered inside docker.

Please, configure the scan type as UDP, fill the other parameters correctly and try again

[mgugu10]

The topic is mixed! I have set the nodered container in host mode to have MDNS working. OK I will test scan with UDP

[mgugu10]

Hi @ckhmer1, here after my configurations for udp scan: I have some doubts with discovery packet, I set it in action console (google example) but maybe it should be set somewhere else ? Result is not working, chrome://inspect shows nothing. @FireWizard52 "force local" and "force default" work fine when you use the phone keyboard instead of voice.

[mgugu10]

OK, discovery packet was wrong, I discovered it has to be "node-red-contrib-google-smarthome", 6e6f64652d7265642d636f6e747269622d676f6f676c652d736d617274686f6d65 in hexa. chrome://inspect shows now that devices are detected and reachable (but different messages for my different speakers, strange). But... local fullfillement is still not working.

[FireWizard52]

I invested some more time in this issue and I'm more and more convinced that it has nothing to do with either UDP or mDNS but that is a general issue.

I investigated carefully, how long "local fulfillment" has been working for me, after Claudio (@ckhmer1) has provided a patch for app.js. In my post 2 weeks ago (more exactly December 13, 2022) I wrote:

Up to yesterday evening 'Local fulfillment' has been working for me. However at the moment it is not working. I assume some Google issue. Nothing has been changed at my side.

That means that it stopped working somewhere on December 12 or 13. The topic at NabuCasa at https://github.com/NabuCasa/home-assistant-google-assistant-local-sdk/issues/28 has posts that mention that local fulfillment has stopped after Google has upgraded their devices.

If I check the software of my 3 devices I see the following at https://support.google.com/googlenest/answer/7365257?hl=en

Last updated: December 13, 2022

It might be coincidence, but that is exactly the same data as I noticed for the 1st time, that "local fulfillment" stopped.

Could be that they mean that the webpage has been updated, but there has been updates rolled out in the same period. Unfortunately I cannot find the date of the last update of my devices.

Has anybody indications that the last Google updates breaks "local fulfillment"? I think Nabu Casa is also waiting for an answer.

Regards

[Caprico85]

I made some more tests. Newer versions, older versions. With UDP and MDNS. With Docker in host networking mode and normal networking. With and without ProxySelected (see this), which fixed local fulfillment earlier. And always waiting a few days to give Google enough time. But I couldn't get it to work. And still no error messages or hints on why it doesn't work.

It still doesn't seem to work for Nabu Casa. On the other hand, there are no similar reports for Smartnora or for Googles official example. So local fulfillment doesn't seem to be broken for every service. Maybe it's related to something we do (or don't do) in our app.js. Maybe Nabu Casa and ourselves have this specific piece of code wrong, other services have it right.

If I can spare some time, I might try getting Google's official sample to work. If it works, I can compare to see what they are doing differently.

[ckhmer1]

The apps.js used by home assistant is quite different by the one we use. I'm wondering if we have to use something similar

[FireWizard52]

Hello @Caprico85 and @ckhmer1,

You said:

It still doesn't seem to work for Nabu Casa. On the other hand, there are no similar reports for Smartnora or for Googles official example. So local fulfillment doesn't seem to be broken for every service. Maybe it's related to something we do (or don't do) in our app.js. Maybe Nabu Casa and ourselves have this specific piece of code wrong, other services have it right.

I did use SmartNora until December last year, so I know that local fulfillment should work. So today I created a test device (a switch) in SmartNora. I configured local fulfillment, but it doesn't work. (Still only the green dot, and no blue dot). It has been configured approx. 8 hours ago. So I will keep you updated. The fact that there are no issues reported for SmartNora, doesn't mean that it works.

A second thing I did, was that I uploaded app.js version 2.4 to the Google Actions Console. This was the last version, known to work with local fulfillment. This was part of release 0.3.14

I waited until this version was reported in chrome://inspect, before I tested it. Local fulfillment does not work

So I upgraded to version 0.4.2 and indeed I got the debug message that the app.js was not reporting its version. So that is working.

Tomorrow I will upgrade the app.js from version 2.4 to version 2.7.

So keep in mind, that Google has pushed firmware updates to the devices recently. This might have effect as well. This is also confirmed in several reports at Nabu Casa.

[FireWizard52]

Hi @Caprico85 and @ckhmer1

I promised:

So I will keep you updated.

More than 24 hours has passed, since I installed/configured the SmartNora Test Switch.

But no local fulfillment, in spite of the fact it has been configured by default.

I opened a new issue at Andrei Tatars Github page. See: https://github.com/andrei-tatar/node-red-contrib-smartnora/issues/238

Happy New Year.

Regards

[FireWizard52]

Hi @Caprico85 and @ckhmer1

Andrei Tatar came back with an answer. SmartNora is not working either. See: https://github.com/andrei-tatar/node-red-contrib-smartnora/issues/238

[Caprico85]

There are reports on NabuCasa that local fulfillment started working again.

My Nest Hub (1st gen) is still broken. I'll see tomorrow if my other install with a Google Home Mini works now.

Edit: Nothing new from my Home Mini so far. Still doesn't work.

[FireWizard52]

Hi, all

According to https://github.com/NabuCasa/home-assistant-google-assistant-local-sdk/issues/28 (latest post) a fix is currently rolled out. We have to have a little more patience, before our devices will get it.

Regards

[FireWizard52]

Hi, all,

Yesterday evening I noticed that a number of my devices showed an open (red) circle, which should mean that "local fulfillment" has worked. Obviously it has been for a short time, as it currently still does not work.

However my only SmartNora device shows that "local fulfillment" is working.

I see, that my Google Nest Hub has received a firmware update, but my both Google Mini speakers are on the "old" level. So we have to wait longer.

Regards

[ChutneyMary]

Hi all. Just wondering if there's any update on Local Fulfillment at the moment? I been through all the fault finding steps and haven't found a resolution. I also understand the history of this likely being a Google backend issue.

[Caprico85]

It still doesn't work for me. Neither on my Home Mini nor on my Nest Hub.

SmartNora and NabuCasa are still reporting the same problems.

There's also a bug report at Google for this: https://issuetracker.google.com/issues/261893570?pli=1.

[Paul-Reed]

Are our devices 'Fuschia OS devices , or Cast OS devices' - as described in the Google issue link?

On Tue, 21 Feb 2023, 09:46 Caprico, @.***> wrote:

It still doesn't work for me. Neither on my Home Mini nor on my Nest Hub.

SmartNora and NabuCasa are still reporting the same problems.

There's also a bug report at Google for this: https://issuetracker.google.com/issues/261893570?pli=1.

— Reply to this email directly, view it on GitHub https://github.com/mikejac/node-red-contrib-google-smarthome/issues/348#issuecomment-1438167928, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHNWDEOLPMVE2BVIMDTRS3WYSFG5ANCNFSM6AAAAAASYUSIAQ . You are receiving this because you are subscribed to this thread.Message ID: <mikejac/node-red-contrib-google-smarthome/issues/348/1438167928@ github.com>

[FireWizard52]

Hi all,

5 days ago a post has been posted on the github page of Andrei Tatar (SmartNora). See: https://github.com/andrei-tatar/node-red-contrib-smartnora/issues/238

I think the poster is correct as I noticed that in the beginning of December 2022 my Google Nest Hub had firmware version 8.20220713.2194059, but has received an update to version 9.20221010.3.176. Also the firmware version of Cast has been updated from 1.63.3247.40 to 1.67330920

However, my Google Home Mini speakers did not receive an update and are still on firmware version 324896 and a Cast firmware of 1.56324896.

I did note that Local fulfillment sometimes worked. At least I saw "open" symbols under the device node. After some investigations, why sometimes, I noted that, when I talked to the Google Nest Hub and a Nest Mini speaker could not hear that, local fulfillment worked. I have also a SmartNora test switch configured, in order to keep an eye on and there I also see that it sometimes worked.

However, It is not stable. Perhaps 10% of the time and only if I talk to the Nest Hub it works.

So the conclusion that only Fuchsia OS devices (Nest Hub) are updated is in my opinion correct but that the Cast OS devices (Nest Mini, Google Mini) are not updated yet.

But as most users has multiple devices, and I'm not sure, which device responds, we have to wait that all devices have received a working update.

So to answer Paul @Paul-Reed :+1:

Google Mini and Nest Mini: Cast OS Google Nest Hub: Fuchsia OS.

[ChutneyMary]

Repeating a comment from the github page of Andrei Tatar (SmartNora) -

I suggest you (and everyone affected) to +1/comment on this issue directly on Google's issue tracker: https://issuetracker.google.com/issues/261893570 Maybe more people reporting to be affected could help increasing the priority of the issue...

[Paul-Reed]

@ChutneyMary On the 9th Feb in the tracker, helenlo@google.com asked for those affected to post their project IDs, so the matter could be properly investigated, but only 1 person has done so. Maybe we should all post our project IDs ??

[FireWizard52]

I have planned to do so.

[Paul-Reed]

I've just posted mine (think I've used the correct Project ID !)

1) Go to https://console.actions.google.com/ 2) Select the project 3) Hamburger top right, select 'Project settings'

[FireWizard52]

Just posted mine as well

[MuadDibVV]

Also posted

[Paul-Reed]

Well the issue tracker reports that we all have posted appears to have had some success. Google have just posted;

Hi all,

Thanks for bringing this issue to our attention. The fix has now been rolled out.

If the issue still persists, please let us know your CastOS version. Thank you.

I guess we just need to wait now for the update to propogate from their servers.

[FireWizard52]

Thanks @Paul-Reed for reporting

I also noted that 2 test devices I created for another SmartNora user already showed a blue dot, which means that local fulfillment worked there. It has not been stable for the last days. Let's wait. I still have the old software in my Google Home mini's.

See: https://github.com/andrei-tatar/node-red-contrib-smartnora/issues/238

Thanks to all those people, that took the time to report this issue at the Google issue tracker and lets hope that everybody receives a quick update.

Regards

[Paul-Reed]

Is anyone getting local fulfillment yet? My speakers are showing CastOS version 1.56.324896 but nothing has changed here...

[FireWizard52]

Hello @Paul-Reed,

No, Nothing has changed so far. I have also CastOS version 1.56.324896. The same software on my sons Google Nest Mini, but he does not use Google Smart Home, This is the same version, I had beginning of December 2022, when the issue started.

So no new update, yet. The Google Nest Hub has been updated since beginning December.

One new report has appeared, March 3, on the google issue tracker, with the following text:

Should we expect a firmware update in the next days or the fix is distributed differently? Current CastOS version is 1.56.324896 on both my Nest Mini and Home Mini and the issue still persist.

The question has not been answered yet,

Regards

[FireWizard52]

Hi all,

Google reports:

Please expect the fix to be in the 1.56.5.XXXXX version around mid-May.

I do not repeat the comments of some users in the Google Issue Tracker. You may guess.

Regards

[Caprico85]

There are rumors on Google's bugtracker that local execution may be working again.

I have checked my own Google Home Mini. It has updated its firmware to 1.56.356012 and I'm seeing the EXECUTE requests in chrome://inspect again.

However, local execution does not seem to be working for me. I don't get the ring icon and my devices don't work with force local. But it's quite possible that I messed something up in my experiments over the last few months. I will have to do some more research.

[ChutneyMary]

I've spoken 'Force Local' and I'm seeing very quick response. I have ring icons under most Nodes, but not all.

It appears to be working for most things here.

[FireWizard52]

(Finally) I received an update for my Google Nest Mini. They are now on Firmware version 356012 and the firmware of Cast is 1.56.356012. Local fulfillment is not working spontaneously, but after giving the command "force local", I see the "ring" symbol again. So I assume that local fulfillment is working again.

The firmware indication does not match with the indications at: https://support.google.com/googlenest/answer/7365257?hl=en#zippy=%2Ccurrent-production-firmware-version It indicates 1.56.356012 instead of 1.56.5.356012. (The 5 is missing), but I think, that this is the version, we should expect.

Regards.

[Caprico85]

Closing this now as local fulfillment seems to be working again.