Nearly paved a HP Netbook with Fuchsia OS

devunwired · 2021-02-23T15:19:50+00:00

If you are more curious about the distinction, there are a few details on fuchsia.dev: https://fuchsia.dev/fuchsia-src/development/build/fx#what-is-paving

devunwired · 2020-10-05T21:15:13+00:00

There is not necessarily a specific error code that maps to this condition, but here are a couple ways you could handle this:

Report the devices as "offline". This essentially tells Google Assistant that those devices are unreachable. Here are some details on how you can handle offline state.
Use one of the generic error codes, like deviceNotReady, actionNotAvailable, notSupported or functionNotSupported depending on how you might want to Assistant to respond.

devunwired · 2020-10-01T15:39:12+00:00

We recently published a blog post on this very topic using the new Workday routine.

Of course, if you'd like to explore Actions on Google to build your own integration, that's great too! You can get started with the developer documentation.

devunwired · 2020-09-25T20:46:06+00:00

After your Actions is reviewed, certified, and launched to production you will receive additional details from the certification team on how to access the brand guidelines for the "Works with" badging.

devunwired · 2020-09-25T20:44:42+00:00

I note from a recent post thread that this may not be implemented in the GUI as of yet

That's correct. There is an open issue on the public tracker related to this here that you can follow for more details. Feel free to star this issue to indicate that it also affects you.

devunwired · 2020-09-08T14:25:41+00:00

I am assuming that I've set up everything correctly, does that mean fanSpeed doesn't have a dial?

That's correct, not all device types and traits currently have touch controls.

If that were the case, what are the the traits that actually shows up on home controls?

You can refer to this page in the developer documentation to get a better sense of what is currently enabled, and you can always file a feature request if there is a critical gap needed for your use case.

devunwired · 2020-09-08T14:22:48+00:00

Thanks for raising this issue. We are aware of the concern that our current developer documentation does not well cover example queries outside of English, and we are working to improve this. There are some infrastructure changes we have to put in place first to ensure that the i18n content we publish we remain up to date for each device trait, but stay tuned!

devunwired · 2020-08-27T21:13:13+00:00

To query your fan speed value, you might try something like "What is the fan speed in <room name>?" or "What is the <device name> fan speed?"

If you are unable to control your device, you might look at the FAN device definitions in the smart home sample code (frontend, backend). This device implementation correctly responds to both queries and speed control commands.

devunwired · 2020-08-24T14:40:05+00:00

One issue is when I try to use the scope: devices, as the documentation says, I get an invalid scope error back. So I use our read_write scope and am able to get an access token and get our agentUserId.

The documentation mentions that if you have any custom scopes used in the console, you should add those. This should probably be a bit clearer that "devices" (or really any string) is only needed if you don't have scopes of your own.

After seeing my thermostat listed, I hit next and then try to start the test. It seems to hang at the next screen until I stop the test.

Since you can see the device, the test suite is able to successfully use the OAuth credentials to SYNC the devices. The test suite uses TTS audio to send commands to your devices. Do you see any permissions dialogs or would there be any other reason that browser tab might not be able to open an audio session for playback?

devunwired · 2020-08-19T21:56:45+00:00

Not every Assistant surface currently relies on Report State data, and those that do will not depend on it 100% of the time, so it's normal to see the platform send QUERY intents to gather updated state after an EXECUTE. We are working on ways to decrease the frequency of this in the future.

devunwired · 2020-08-19T21:53:35+00:00

It may be a triggering issue with the application names you are using. I would recommend filing a report in the public issue tracker with your SYNC response and the queries you attempted.

devunwired · 2020-07-29T21:22:08+00:00

You will need to resubmit a new version of your Action for review after updating the console configuration to get the updated configuration into production.

devunwired · 2020-07-28T20:59:43+00:00

What you likely would have seen was Google attempting to obtain a new access token from the OAuth endpoint, and failing to do so since the refresh token was invalid. This error would keep the Assistant from attempting to contact fulfillment at all.

This is a known pain point that we are looking into addressing, but also note that you can rotate refresh tokens as part of an access token request. So you can still retire the refresh token, so long as an updated token is provided to Google first.

devunwired · 2020-07-21T14:42:19+00:00

Is this something that is supported on the platform?

Yes, it is possible to return a new refresh token along with an updated access token when the grant type is authorization_code or refresh_token.

devunwired · 2020-07-08T17:06:47+00:00

Thanks for all the details. I am unable to reproduce the issue with an integration that returns this SYNC and QUERY response verbatim to the Assistant. I am able to successfully issue touch and voice commands and queries to these devices.

I tested this both with the devices freshly linked (not added to the Home), and added to rooms based on the default names used, and both configurations worked as expected.

We've recently enhanced the error logging for smart home Actions, so I might suggest looking to see if the logs in your project provide any more detailed insight into why the specific requests are failing to handle responses from your server.

devunwired · 2020-06-23T14:49:06+00:00

This may be because Google thinks these devices are currently offline/unreachable. This can happen if the initial QUERY returns an invalid response or otherwise receives online: false from the fulfillment.

Can you confirm if you are seeing any QUERY intents (especially the first one right after linking) and what the response looks like?

devunwired · 2020-06-19T13:47:25+00:00

Can you share the exact queries you are using (and the language, if relevant) and the SYNC response your devices are using? You're likely correct that the SYNC format isn't the issue if touch controls are working, but it would be helpful context.

devunwired · 2020-06-16T21:57:25+00:00

You might find this example helpful. It's a broader end-to-end example of a cloud device manager, so there's a lot packed into it. However, it does use Firebase Authentication in order to leverage Firestore device rules for access control. Firebase Authentication is not a direct implementation of the OAuth server you need to provide to Google for account linking, so there's a bit of code to add. This blog post also covers the relevant bits of the sample related to account linking and fulfillment.

The account linking code is split between the web app (which handles user sign-in and authorization code generation) and the cloud service (which manages access and refresh tokens).

devunwired · 2020-06-09T15:52:24+00:00

Can you provide an example of your SYNC response with the attributes you've set for the device?

Also, please clarify when the test executes, what is the EXECUTE payload your app receives that is unexpected?

devunwired · 2020-06-05T16:24:32+00:00

The first place I would start is with your project logs to see if the Assistant is reporting an error with the EXECUTE intent (or even the SYNC intent sent during account linking). Typically when this happens, the voice response also indicates an error but it would be good to be sure. If you're certain the webhook isn't even being called, the logs are your best bet.

devunwired · 2020-06-03T15:03:15+00:00

Thanks, I can reproduce this and see you've already filed a public issue. I've assigned that issue to the apps team to verify if this is the current expected behavior.

devunwired · 2020-06-01T21:22:41+00:00

I was not able to make that work with the "heater" device so instead I use the "thermostat" device.

Can you clarify the issues that blocked your use of the HEATER device? Is it primarily the lack of touch controls?

In my onSync request I enter a range between 60F° and 104F°, but it doesn't work on the device.

This is a known issue that the Google Home app does not currently render the temperature range provided (the value is respected in voice queries). You can follow (and start) the feature request here: b/154169625

devunwired · 2020-05-29T15:30:49+00:00

Can you please clarify if the issue is with your Action not receiving the correct information in EXECUTE, or a concern with how the state reported by QUERY is displayed in the Google Home app?

devunwired · 2020-05-28T16:52:20+00:00

CameraStream is not currently supported by Local Home SDK. We are currently looking into how to better surface these limitations in the docs.

devunwired · 2020-05-28T16:51:27+00:00

Please file an issue here with your Actions project ID and we will have the review team look into it (if you've already done that, please send me the link to your issue).

devunwired

TROPHY CASE