Im following the Number Genie article here:
https://developers.google.com/actions/develop/apiai/tutorials/number-genie
Ive taken the files and put them in a github repository here:
http://github.com/quique123/mygennie
I got this in the Heroku log:
body:
{"originalRequest":{"source":"google","data":{"surface":{"capabilities":[{"name":"actions.capability.AUDIO_OUTPUT"}]},"inputs":[{"arguments":[{"raw_text":"36","text_value":"36","name":"text"}],"intent":"assistant.intent.action.TEXT","raw_inputs":[{"query":"36","input_type":2,"annotation_sets":[]}]}],"user":{"user_id":"sometring/mIqGRE=","permissions":[]},"device":{"locale":"en-US"},"is_in_sandbox":true,"conversation":{"conversation_token":"[]","conversation_id":"1493419815932","type":2}}},"id":"e5ca3d68-3efa-4285-923f-3e1ff7fz87cf","timestamp":"2017-04-28T22:33:51.422Z","lang":"en","result":{"source":"agent","resolvedQuery":"36","speech":"","action":"check_guess","actionIncomplete":false,"parameters":{"check_guess":"36"},"contexts":[{"name":"actions_capability_audio_output","parameters":{"check_guess.original":"36","check_guess":"36"},"lifespan":0}],"metadata":{"intentId":"c863e1e2-c950-45d8-9b96-b57e0b1de77e","webhookUsed":"true","webhookForSlotFillingUsed":"false","intentName":"provide_guess"},"fulfillment":{"speech":"","messages":[{"type":0,"speech":""}]},"score":1},"status":{"code":200,"errorType":"success"},"sessionId":"1493418215932"}
But the web simulator returned a sorry, that is not available right now when I tried to guess a number. Why does the json payload hace a code 200:success then?
How quickly are you getting the message that it isn't available? The Google Assistant on your home will timeout requests after about 5 seconds. If your server doesn't reply within that time, Home assumes there is a problem with the connection and terminates the session. It is possible that your application took longer than that to run, so it generates the message about being unable to handle it at the moment and, some time later, your function finally returns results.
Related
i have a custom google home action implemented as described in the documentation (Oauth2 setup, sync, execute, etc... setup) and all works as expected on my Google home app and my google home physical devices.
Now, every now and then i need to reconnect the app in the Google Home App because it seems the app cannot reach my devices after some time. I checked my Oauth server if the refresh tokens are working ok and they do. Also my access token expires after 20 minutes and me reconnecting to the app should be done after some hours so the refreshing works in my opinion.
Now, are there any restrictions in using the TEST of the google home action?
The case i wrote is specific for personal use (intergration with personal server and domotica system) so i am actually not planning on releasing it, I just want to use it for myself. Is this allowed? Can i just leave my action in 'test' forever for such purposes?
EDIT: 18/05/2022: custom actions still working flawlessly after 6 months in test :-)
EDIT: 02/02/2023: custom actions still working flawlessly in test :-)
Additional question:
If i have to submit the app for release, i cannot meet the expectation in implementing state report as i have no control over the usage of buttons pressed at my home domotica. Is State Reporting also accepted when i report the state of my devices over time (let's say, every hour?)
tnx
EDIT:
So it seems there is something wrong with my refreshing of the tokens but i don't know what. When i try through postman, all works as expected, in stackdriver logs i see this :
jsonPayload: {
#type: "type.googleapis.com/google.identity.accountlinking.type.AccountLinkingError"
errorReason: "Failed to get response from 3P. 3P returned malformed response like invalid response code or un-inflatble body."
request: {
body: "grant_type=refresh_token&refresh_token=REDACTED_VALUE&client_id=qbusauth&client_secret=REDACTED_VALUE"
method: "POST"
uri: "https://******.azurewebsites.net/token"
}
sessionId: -1039956344
step: "REFRESH_ACCESS_TOKEN"
If you don't plan to submit your Action for release, you'll just need to occasionally re-enable device testing through the console.
To minimize the number of query intents to your fulfillment, you should implement Report State and proactively send device states to update HomeGraph. You would have to implement this if you decide to release your Action.
Something strange occurs that I cannot find the cause or reason for.
I have a loop which polls Inbox for an authorized user every minute. This goes fine for some time, but then I get 404 and error code is ErrorInvalidMailboxItemId (Item Id doesn't belong to the current mailbox.). I for example get this two times and then the polls starts working again.
GET /v1.0/me/mailFolders/xxx/messages?$filter=isRead%20ne%20true&$count=true&$top=10
Nothing that I can see is different between the polls, so I'm baffled why server suddenly returns 404.
Searching for this error mentions shared mailbox, archive and delegated, however this inbox is neither of these, and besides the error should then be consistent which it is not.
Same bearer token used for all the polls, both when it works, then does not and then when it starts working again.
Any ideas why this goes wrong? Or do I have to look for this error and then just retry or ignore the error for some time?
Thanks
I would try the following:
Do a re-try and see if it works
Implement the detailed response logging at the custom application end, isolate the item, make the same API call in MS Graph Explorer and see if it exists, gets the data or not.
Make sure you have necessary permissions to access the shared mailbox, archive mailboxes or the targeted mailboxes etc
My internally used web solution to retrieve YouTube video statistics that is based on this example (https://developers.google.com/youtube/v3/quickstart/js) now fails to work. Not sure when exactly it happened, but it used to work couple of months ago.
I now tried to run unedited example code (apart from adjusting the CLIENT_ID, of course), and I am getting exactly the same error:
{
"domain": "usageLimits",
"reason": "accessNotConfigured",
"message": "Access Not Configured. YouTube Data API has not been used in project 123 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project=123 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
"extendedHelp": "https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project=123" } ], "code": 403, "message": "Access Not Configured. YouTube Data API has not been used in project 123 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project=123 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry."
}
When I check the YouTube API in developer console, it shows enabled status, and the Credentials compatible with this API include the ID used to authenticate the client. I can see the statistics for credential use increment when I retry the API call attempts, and the metrics reflect the number of requests and also show that the error rate is 100%. But there is no extra info on those failed attempts in the console to help on debugging the problem.
I have deleted and recreated API key and OAuth key, but that did not change anything.
Had there been any extra info on those errors on the developer console side, for example client quote exceeded, I could see how to fix this. Now I am completely stuck.
Create a new project
Weirdly, creating a new project just gets the API to work properly!
The error message is unfortunately a red herring: your project's access to YouTube Data API Services is automatically disabled after a 90 day inactivity period.
You should have received a notice via email regarding this action, which also contains the steps that need to be taken to regain access: please fill out and submit the exceptions form.
Try to start a new Project with new oAuthCliedID & oAuthClientSecret
What seems to have done it for me after a lot of fiddling was to:
Go to the OAuth consent screen of the project.
Enter an Application name.
Press Save.
Lo and behold, after 5 minutes it started working.
I have recently converted a trial account into a paid starter package and, since I've been assigned a long number, my attempts to send messages via the HTTP API have failed with the following messages in the Message Reports console:
An error occurred while attempting to route the message
Routing error (status 9)
I have confirmed that my username, password, and api id are entered correctly and that the long number has been matched to the active API. I've tried the "Valid Sample Code" provided on the API management console, all with the same result. Below are a few failed message ids if that's helpful for anyone on the Clickatell team.
6d7868662782cfd7d1708996bca066b1
4f837467ed535521ef39d9d885f121f9
2be08f4663a3d9d7cf2e5b9e9cad2d5f
For what it's worth, my trial account worked fine and as expected, so I'm fairly certain that this is not (obvious) user error on my part. I also upgraded a few hours ago; I'm not sure if there is a wait period between account activation and functional service. Thanks for any help on this.
Have you tried setting mo=1 and using your long number as your sender id from=123456789?
make sure you dont add any programming symbols in the text message. i had an exclamation mark and it gave me a status 9 error.
http://api.clickatell.com/http/sendmsg?api_id=xxxx&user=xxxx&from=13055140341&mo=1&password=xxxx&to=xxxx&text=xxxx
For what it's worth, I encountered a very similar problem with the REST API. It also requires the undocumented "mo=1" and "from=[your long number]" fields to be included.
Also, in the FAQ, they have "MO=1" but in actuality, it has to be a lower-case.
From OP:
Clickatell support responded with the following advice that resolved my problem. I also changed the password on my API key during the process which seemed to be part of the issue.
http://api.clickatell.com/http/sendmsg?api_id=xxxx&user=xxxx&from=13055140341&mo=1&password=xxxx&to=xxxx&text=xxxx
"from" is your long number, and because I'm using 2 way messaging , mo=1 needed to be set also. It would have been helpful if this were in the exemplary code provided on the api info and help section, but alas, I had to go through support to get my answer. It took about 2 business days for the response, but they were helpful
Early on in developing an iOS app with Xamarin, another developer and I got push notifications working for it using the Azure Messaging Component. It's a few months later now, and sometime between then and now, the push notifications stopped working. The code is still basically the same as before (which is nearly identical to the example code for the component), it was just moved to its own class for maintainability.
On Hub.UnregisterAllAsync(DeviceToken, error =>, error is:
The operation couldn’t be completed. (NSURLErrorDomain error -1012.)
On Hub.RegisterNativeAsync(DeviceToken, tags, error =>, error is:
URLRequest failed for <NSMutableURLRequest: 0x167dbd80>
{ URL: https://[our namespace].servicebus.windows.net/[our hub name]/Registrations/?$filter=deviceToken+eq+'[long token]'&api-version=2013-04 }
with status code: unauthorized
We tried a new hub, and a new namespace with a new hub, but without luck. I've rolled back the changes we've made since it was working, but with no luck there either. The same error happens on multiple devices, on multiple networks. It never shows any errors in the portal for APNS, so I'm assuming this is something with authenticating to the Hub itself. What is really weird is that a Windows Store app that we wrote to test this registers and receives notifications using the same credentials without any issue. Can anyone point me in the right direction on this? The error messages above aren't very helpful.
It turns out that the test devices all had the automatic date and time synchronization turned off. The iPad I was primarily testing with was only off by about 20 or 30 seconds, so I didn't notice it was off. Another question involving the same thing with a Windows or Windows Phone registration clued me into it, but I can't find the link to it now. Apologies for that, thanks to whoever that was!
Looking at the API, it makes sense why it's so sensitive to this. It uses the date and time to generate the SAS Token, thus the unauthorized response when the time is just a few seconds off.