We want to work with timezones in the Watson Assistant responses.
Basically we want to implement the "good morning" sample as described here:
https://console.bluemix.net/docs/services/conversation/dialog-methods.html#date-time
When we post to this URL
https://gateway.watsonplatform.net/assistant/api/v1/workspaces/<workspaceid>/message?version=2018-02-16
using this payload (first call in the conversation)
{"context":{"$timezone":"Europe/Amsterdam"}}
We keep getting greetings based on the UTC.
When we add the now() output to the response we also do see the time according to the UTC.
The strange thing is, when we try this out in the try-out panel of the Watson Assistance workbench (browser) the output behaves as expected ?
The value should be, without the dollar sign:
{"context":{"timezone":"Europe/Amsterdam"}}
The $ is used to denote (context) variables for the short syntax, but in the payload you are working with the regular context struture and key/value pairs.
Related
I want to find out the changed files between two given commits/branches/tags using the Bitbucket Rest API.
I tried to use the diff command from here
curl -u USER:PASSWORD https://REPO-URL/rest/api/latest/projects/PROJECT/repos/REPO/compare/diff?from=COMMITHASH1&to=COMMITHASH2
where CAPITAL words are place holders for actual values I cannot post here.
The result of the request is always something like
The command "to" is spelled wrong or cannot be found
(the original result is in German, so that might be the translation).
However, if I switch the query parameters like .../diff?to=...&from=..., it says that the command from is unknown. I also tried other similar diff queries like .../compare/changes?from=...&to=... or .../diff?since=...&until=..., but the result was similar as mentioned above. Also giving branch names instead of commit-hashs showed no result.
Therefore, my assumption was that the second query parameter cannot be handled correctly by the API.
Other basic queries on the API like .../branches work fine, so authentication or whatever is no problem.
What am I doing wrong? Do I need to wrap the commit-hashs into "" or something like that?
Thank you very much!
PS: As the repository is commercially used, I cannot give you the actual url, user or password to try for yourself.
I'm currently training a chatbot to recognize intents and provide fulfillment based on these. It is working fine when the query passed to it resembles what it has been trained on.
However, I'd like to train my chatbot to handle out of scope requests. The idea here is to capture the "confidence" value and use it in an "if/else" statement to provide a standard response if the value is too low.
Is there a way to capture this "confidence" value? Is there a tracker for it similar to slots? See snippet below for confidence value I'm trying to extract.
Received user message 'show me Brazilian steak houses'with intent '{'name': 'restaurant_search', 'confidence': 0.4830598338322177}'
this is currently not returned as part of the payload, but it is printed if you have logging level set to debug, see https://github.com/RasaHQ/rasa_core/blob/4adf5914f25bff9d59dfc1a5492a18e14f7acba7/rasa_core/policies/ensemble.py#L68
we can certainly look into returning that as part of the payload, but possibly your best approach is to create a custom policy which checks this number and overrides it with a fallback action. We should add some documentation on how to do this.
I am attempting to preview a track via the 7digital api. I have utilised the reference app to test the endpoint here:-
http://7digital.github.io/oauth-reference-page/
I have specified what I consider to be the correct format query, as in:-
http://previews.7digital.com/clip/8514023?oauth_consumer_key=MY_KEY&country=gb&oauth_nonce=221946762&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1456932878&oauth_version=1.0&oauth_signature=c5GBrJvxPIf2Kci24pq1qD31U%2Bs%3D
and yet, regardless of what parameters I enter I always get an invalid signature as a response. I have also incorporated this into my javascript code using the same oauth signature library as the reference page and yet still get the same invalid signature returned.
Could someone please shed some light on what I may be doing incorrectly?
Thanks.
I was able to sign it using:
url = http://previews.7digital.com/clip/8514023
valid consumer key & consumer secret
field 'country' = 'GB'
Your query strings parameters look a bit out of order. For OAuth the base string, used to sign, is meant to be in alphabetical order, so country would be first in this case. Once generated it doesn't matter the order in the final request, but the above tool applies them back in the same order (so country is first).
Can you make sure there aren't any spaces around your key/secret? It doesn't appear to strip white space.
If you have more specific problems it may be best to get in touch with 7digital directly - https://groups.google.com/forum/#!forum/7digital-api
We have a list of address, And trying to get coordinates of them using server side script.
Due to limitation of google map api(2500 query per 24 hour), We move to bing map REST api.
But when we are calling API its not giving the coordinates, While google map api returning the correct coordinates.
Please tell me what i am doing wrong?
Here is the sample call
http://dev.virtualearth.net/REST/v1/Locations?query=A+Beka+Acadamdy,2303+Maravilla,Lompoc,CA,93436,&incl=queryParse&key=MY_API_KEY
if I replace everything with %20 in address then still its not returning data
http://dev.virtualearth.net/REST/v1/Locations?query=A%20Beka%20Acadamdy%202303%20Maravilla%20Lompoc%20CA%2093436&incl=queryParse&key=MY_API_KEY
Another URL is
http://dev.virtualearth.net/REST/v1/Locations?query=103+Black+Men+of+the+Bay+Area+Community,3403+Malcolm+Avenue,Oakland,CA,94607-1407,&incl=queryParse&key=MY_API_KEY
We also tried with this
https://msdn.microsoft.com/en-us/library/ff817004.aspx#sectionToggle6
But sometimes we don't know the country, That's why its not working correctly.
A couple of things to change. First, drop the name of the location, you only need the street address.
So geocoding "2303 Maravilla, Lompoc, CA, 93436" will work.
Secondly, it looks like you are escaping the query value rather than encoding it. Escaping isn't as good as encoding and will result in some queries failing all together. For example if a query had "first & Main" in it, escaping it would not escape the ampersand which would make everything after it a new URL parameter which would likely either cause an error or mean your query is just for "first". By encoding it the ampersand would be changed to %26. This is documented in the best practices here: https://msdn.microsoft.com/en-us/library/dn894107.aspx
By encoding your query parameter your address will look like this:
"2303%20Maravilla,%20Lompoc,%20CA,%2093436"
I am using the ruby paypal rest api and everything I do seems to be right but PayPal keeps saying my date format is incorrect.
Here is my call:
Payment.all(:start_time => '2013-03-06T11:00:00Z', :end_time => '2013-03-06T11:00:00Z')
After many attempts I literally took the date example in the documentation: https://developer.paypal.com/webapps/developer/docs/api/
Because no matter what I do I keep getting the same response:
'{"name":"VALIDATION_ERROR","details":[{"field":"start_time","issue":"Must
be a date_time string of form yyyy-mm-ddThh:mm:ss(.sss)?Z"},{"field":"end_time","issue":"Must
be a date_time string of form yyyy-mm-ddThh:mm:ss(.sss)?Z"}],"message":"Invalid
request - see details","information_link":"https://developer.paypal.com/webapps/developer/docs/api/#VALIDATION_ERROR","debug_id":"dcd8a9ce6a5e7"}'
Am I blind or does it not make sense?
Looks like it's a bug in our API where it's expecting raw value rather than url encoded value. The SDK was always url encoding the value of the start_time and end_time (or as a matter of fact all url parameters as per the HTTP spec). We have filed a bug and get this fixed as soon as possible. Meanwhile if this is something you need to work, we can possibly make the SDK not url encode the params or you can just modify the code for now locally.
I think your issue might be that you're setting both the start time and the end time to the same exact value. If you want a single day's worth of transactions the end time would be 2013-03-06T23:59:59Z.