I have a DialogFlow agent I am trying to test on Google Assistant. I've created a relatively simple Intent called "Set name" with the following Training phrases:
My name is Ryan.
Bill
I'm Steve
The name's Bond. James Bond.
It has two parameters:
Required: given-name with the Entity #sys.given-name and the value stored as $given-name
last-name with the Entity #sys.last-name and the value $last-name
I'm able to test in just fine in the DialogFlow test console. But when I try to "See how it works in Google Assistant." I get the following error:
Request contains an invalid argument. The query pattern 'The name's
Bond. $SchemaOrg_Person:given-name $SchemaOrg_Person:last-name.'
contains an undefined parameter 'last-name.'
If I delete the "James Bond" training phrase, it works okay. But I would like to include that. What am I doing wrong?
Here is a screenshot of the intent that is causing the problem:
Here is the link I'm clicking to try in Google Assistant:
And finally, here is the error message that appears in the bottom-right corner of the screen when I click that link:
I suddenly got a few of these error messages when both clicking the "See how it works in Google Assistant" link and submitting the app for production.
It seems like characters like apostrophes and hyphens in the training phrases creates trouble and can give that error message.
In addition it complained about a variant of the training phrases that I could not find anywhere no matter how much I looked at all languages, all pages of the phrases and all intents. I finally found the phrase in question by exporting the project and searching through the JSON files. Then I could delete the phrase locally, delete the intent in Dialogflow and do an import back to Dialogflow. (From my understanding it had messed up a follow-up intent which it also in the JSON (nowhere in the UI) had attached parts of some training phrases.)
Try to remove the dot from the sentence. So it will be:
"The name's Bond. James Bond"
I ran into same error and finally it was found to be an issue with the additional language I have added.
There was default "en" language and "en-IN" added by me. The issue was with training phrases in "en-IN" language. I didn't need it so removed it and it worked fine.
So, do check how many languages are enabled in your agent and whether training phrases are set properly for them or not.
Related
I'm running into an issue with the Actions Builder that I think is a bug at Google's side of the Actions Builder platform, but not I'm not a hundred percent sure.
I'm building some sort of a shopping list app (that integrates with backend services). I have an intent to add one or more "generic names" (= product names) to a list.
When I configure the Intent with an InputType like this (notice the List being false),
The input I send to the intent gets parsed correctly, like this:
You see, "kokosolie" is resolved when my query was "add 'kokosnootolie' to the list". In this case, I get both the resolved and the original value of the InputType.
But in my use case, I want to receive multiple values for a "Generic name", so I turn on the "is list" checkbox.
The same query/voice command now results in this:
Only the resolved input type is returned here. While I need this one later in the app's logic, I also need the original values, but Google doesn't return them to me.
Is this a bug or a missing feature at Google's side of things or rather me, missing some configuration?
I am new to botium and my developer (not me) has created a framework with conversation text files that I should be able to run botium scripts on.
An example is something like this:
#me
What are the stats for my neighborhood?
#bot
There are ten matches in your neighborhood
When I run this test in my IDE, it passes. So, I created a text file called NEIGHBORHOOD_UTT which has sentences similar to the following:
What are the stats for my neighborhood
Show me neighborhood stats
Neighborhood
And then changed my convo.txt file to:
#me
NEIGHBORHOOD_UTT
#bot
There are ten matches in your neighborhood
All these I've tested on the app through the GUI and should return "There are ten matches in your neighborhood"
The error is something like: TranscriptError: BotiumError: neighborhood/Line 6: Expected bot response (on Line 3:
#me - NEIGHBORHOOD_UTT) "Sorry, I couldn't find any listings for" to match one of "There are ten matches in your neighborhood."
The GUI is not responding with "Sorry, I couldn't find any listings", but the expected response. There is no API documentation for me to check there. I can't share too much as this is work/proprietary. Both the utterences and the convo txt are in a folder called botium
I have tried naming the file both NEIGHBORHOOD_UTT.utterances.txt and NEIGHBORHOOD_UTT.txt
I cannot think of anything else so I have searched github for random projects similar to mine and haven't found any that provided any clues
The first line of an utterances file is the utterance reference code. For example:
USER_HELLO_UTT
hi
hello
nice day
USER_HELLO_UTT can be used in convo files then:
Say hello
#me
USER_HELLO_UTT
#bot
Hi!
More examples available in the Botium Wiki
I have a flow in my chatBot application where I switch workspaces and its giving me SpelEvaluationException error.
I have a router workspace that determine initial indent of the client, once I know the initial intend I route the next request to appropriate workspaces
Workspace Router :
Bot :- Hey this is an awesome bot, what do you need help with
1. Apples
2. Bananas
3. Oranges
Client :- I need help with my apples
--- I pass a custom JSON from the workspace with tells my app to route next request to apples workspace ----
Apple Workspace :
BOT: Hey what can I help you in apples .
The flow works fine but when I send request to Apples workspace. I get the following error in log_message .
SpelEvaluationException when evaluating dialog node ID [node_2_1517933972148]. The syntax of condition [intents[0].confidence < 0.50] is valid, but cannot be evaluated. Check that objects in expression are not null or out of bounds.\nSpEL evaluation error: EL1025E: The collection has '0' elements, index '0' is invalid\n
So somehow you are asking Watson to evaluate the intents array before actually passing any input, so no intent data is returned, thus the spell expression fails and throws the error.
So however you are calling that second Apples workspace make sure you have input text being sent as well.
The same thing happened to me, you can try to jump by response so that the condition is not evaluated and check if you are not trying to save the intent in a variable inside the JSON. Possibly you already solved it but I leave my proposal hoping it will serve someone else.
My apologies if the question is duplicated. We are facing an issue with the analysis of a profile using Watson Personality Insights API in Spanish. We have a demo we implemented using PI API version 2 and then we tested the results (exact same text) with the demo published on developer cloud(in spanish) and we found important differences on how the big five were calculated when the facet values were not that different. Is it possible that these differences are caused because of the API version? The issue that with our demo the big five values produced a kind of negative summary profile when the developercloud summary is kinder.
We could send both result jsons. For example here is how the big five rated:
BigFive DeveloperCloud Demo V2
Openness 0.773834349 0.847273232
Conscientiousness 0.916616088 0.914907481
Extraversion 0.796331544 0.612606551
Agreeableness 0.17445636 0.096118648
Emotional range 0.036287447 0.01623536
thanks in advance!!
So the API version would not make a difference, as that just governs the format of the API; the back-end models are the same for both v2 and v3 of the API.
So the jist of your question is that when you run the same text in your app, and in the demo you get different big5 results, while the facet values are about the same.
This might be easiest solved by you opening a support ticket so we can debug the issue together; if you'd rather not do that then can you provide a sample text? Typically it boils down to a difference in the way the text is parsed.
Another question; did you try making the request using curl? That would cut out any custom logic in your app and narrow down the problem.
thanks Neil for you answer!
We tested the text using CURL and we noticed that the results didn't change by the service version used but instead by how the text was sent. If we called the service using curl passing a plain text input(formatted in UTF-8 with line breaks) it returned the same results for version2 and version 3 and also matched the ones from our demo. If we called the service using curl passing json input WITHOUT line breaks it returned the same values as well. But if we called the service passing the json input WITH line breaks then the results changed and almost matched those shown by ibm demo. My question here is which are the correct results? The ones shown when the text is sent as a plain text input(with line breaks) or when the text is sent as json input(with line breaks)? Is there any technical guideline besides the one shown in developercloud on how the text should be parsed to use this service?
Thanks again!
This is my 1st question on this forum... So, please, be indulgent !
I'm using TYPO3 4.7.11 (PHP 5.3.3) with extension direct_mail 3.1.1 for the intranet site of a non-profit firm.
My problem (maybe connected to Bug #51583 : http://forge.typo3.org/issues/51583) is that, after numerous tests and attempts, it seems impossible to have an updated version of a page saved as draft for newsletter in an automatic scheduler driven way : the same newsletter is produced with the same informations that were already there on the day it was first created and saved.
The specific page used for newsletter includes a content element 'Menu/Sitemap' with 'Recently updated pages' as 'Menu type'. It has been saved as 'draft (for recurring sendings)' in Direct Mail.
The scheduler contains these 2 tasks with recurring type :
- Direct Mail: Create Mail from Draft (direct_mail)
- Direct Mail: Mailing Queue (direct_mail)
Note : the manual way is fully functional and the newsletter produced is really updated. Same with option "Testmail - Simple" !
So, my problem seems to be linked to the automatic scheduled mailing ! It looks as if the newsletter draft has turned into a freezed snapshot of a specific moment and that Typo3 is unable to update/recalculate this page when invoked in scheduler mode.
On the web, I saw reported problems that could be related like "When mails get sent via the scheduler the same subject is used for all sendings ( https://review.typo3.org/21313 )" and "Adding hooks when sending direct mails via scheduler ( forge.typo3.org/issues/48994 )", but these issues seem to be fixed with direct_mail 3.1.1 version.
I made these observations and, in my opinion, there is some relevancy :
1.There is no domain proposed in the 'Domain of internal links' drop-down list in 'Set default values for mail content fetching options' in Direct Mailer, and yet I have a single record in sys_domain table with a domain name (with no protocol and no final slash). Is there a reason why this record is not considered good, or isn't it the right table ? (uid=3, pid, tstamp, crdate, cruser_id, hidden, sorting, prepend_params and forced=0, redirectHttpStatusCode=301, domain_name=site.subdomain.domain, redirectTo=)
2.In the Typo 3 Log, I get this systematic error message for user _cli_scheduler#LIVE :
Core: Error handler (BE): PHP Warning: Invalid argument supplied for
foreach() in
...typo3conf/ext/direct_mail/Classes/Scheduler/MailFromDraft.php line
125.
The concerned part of MailFromDraft.php is this function : initializeHookObjects
...
/*
* Initializes hook objects for this class
*
* #return void
*/
function initializeHookObjects() {
foreach ($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] as $hookObj) {
$hookObjectInstance = t3lib_div::getUserObj($hookObj);
if (is_object($hookObjectInstance) && ($hookObjectInstance instanceof x_directmail_Scheduler_MailFromDraftHook)) {
$this->hookObjects[] = $hookObjectInstance;
}
}
}
...
I'm not sure of understanding very clearly the origin and the use of the hook Object... (in spite of this interesting article by Robert Lemke : typo3.org/documentation/article/how-to-use-existing-hooks-in-your-own-extension/ )
3.Nothing like the apparently requested GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] seems to exist in TYPO3_CONF_VARS (Global configuration).
Can anybody give me an advice or a clue about what's going on and why I can't get a weekly updated newsletter with the scheduler ? I feel a bit confused !
Thanks in advance for any suggestion or solution (if a miracle is possible).
Greetings.
P-H SILLIAU
I've read about this issue before, but couldn't remember where.
Googling "direct_mail draft (for recurring sendings)" helped.
Try this bug: http://forge.typo3.org/issues/4421
User Markus says:
Things work fine, when you set a domain-record in your system and
select it in the direct_mail settings!
If you don't have a domain-record and specify it in the direct_mail
setup you're able to send normal newsletters, but if you try the
draft-functionality it won't work because the getUrlBase function in
class.tx_directmail_static.php returns an unsuable URL to the System
so it can't use the fetchHTML($file) and quits - therefore not
replacing the old draft contents created when starting the first time.
I don't really get why this works the first time you set up the draft
though....
So setting up the domain-record is a work-around that works.
I hope it does!
Probably, you will find more related topics.
Else, workarounds would be
re-considering the task. As it's a NPO intranet, maybe requirements are not that required suddenly, if asked again :-)
setting up a custom notification tool that only does that precise job.
To put an end to this problem, after many attempts (and informations gleaned from the internet), here is the solution we finally used in our specific case to make the newsletter work :
1st. We created a record in table sys_domain. This was a recurrent instruction in the manual and the forums, and it was IMHO legitimate.
Important : note that the redirectTo field had to remain empty, due to global malfunction of the site if filled (whatever we put in it like /, /var/www/sitename, ...)
2nd. All images, CSS, JS included in template had to be hardcoded (i.e. http ://site/fileamin/images/xxx.png for instance). If we didn't do that, the result would have been an abort in the production of the newletter : Not Found... Maybe, by digging a bit deeper, should we be able to find a parameter we forgot or neglected in some way to solve this issue...
3rd. In the newsletter template TS setup, we added these 2 parameters :
mod.web_modules.dmail.use_domain=[uid of sys-domain]
config.absRefPrefix = / (in order to get rid of PHP DOCUMENT_ROOT (or TYPO3_DOCUMENT_ROOT ?) otherwise wrongly present in all generated links.)
The result is now a well dynamically-generated newsletter, the date is OK, all links are correct and realUrl-compliant (no ../index.php?id=nnn) .... and you know what ?... We're happy ! :-)
Hope it will help !
Many thanks to everybody who answered (Markus, Urs...) or even thought of a possible solution...
P-H Silliau