When placing a call to one of the test numbers (e.g. 460000000001), I receive a callback (event "ice") with the following data:
"to": {
"endpoint": "461",
"type": "number"
}
Responding to the callback with this number (response below) gives me a failure.
{
"action": {
"cli": "",
"locale": "en-US",
"maxDuration": 1000,
"name": "ConnectPSTN",
"number": "461",
"suppressCallbacks": false
},
"instruction": []
}
The error I get is the following:
"reason":"GENERALERROR (NullReferenceException)"
Changing my response to include the original test number (460000000001) successfully connects the call. Why is this conversion happening, and am I supposed to automatically change numbers like "461" into their corresponding test number?
Cheers,
Morten
It seems like we have a bug on the test number, make sure you connect to 460000000001 for now and the team will look in to that. I assume you dont have the same problems when dialing real numbers.
Related
I have a power app that using the flow from power automate.
My flow is doing an HTTP get and respond a JSON to power apps like below.
Here is the JSON as text:
{"value": "[{\"dataAreaId\":\"mv\",\"AccountNum\":\"100000\",\"Name\":\"*****L FOOD AB\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"100001\",\"Name\":\"**** AB\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"100014\",\"Name\":\"****(SEB)\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"100021\",\"Name\":\"**** AB\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"100029\",\"Name\":\"**** AB\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"500100\",\"Name\":\"**** AB\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"500210\",\"Name\":\"****\"}]"}
But when I try to convert this JSON to the collection, It doesn't behave like a list.
It just seems like a text. Here is how I try to bind the list.
How can I create a collection from JSON to bind to the gallery view?
I found the solution. I finally create a collection from the response of flow.
The flow's name is GetVendor.
The response of flow is like this :
{"value": "[{\"dataAreaId\":\"mv\",\"AccountNum\":\"100000\",\"Name\":\"*****L FOOD AB\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"100001\",\"Name\":\"**** AB\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"100014\",\"Name\":\"****(SEB)\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"100021\",\"Name\":\"**** AB\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"100029\",\"Name\":\"**** AB\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"500100\",\"Name\":\"**** AB\"},{\"dataAreaId\":\"mv\",\"AccountNum\":\"500210\",\"Name\":\"****\"}]"}
Below code creates a list from this response :
ClearCollect(_vendorData, MatchAll(GetVendors.Run(_token.value).value, "\{""dataAreaId"":""(?<dataAreaId>[^""]*)"",""AccountNum"":""(?<AccountNum>[^""]*)"",""Name"":""(?<Name>[^""]*)""\}"));
And I could bind the accountnum and name from _vendorDatra collection to the gallery view
In my case I had the same issue as you, but couldn't manage to get data into _vendorData collection, because MatchAll regex part was not working correctly, even if I had exactly the same scenario and I could not make it work.
My solution was to modify the flow itself, where I returned Response instead of Respond to a Power app or Flow, so basically I could return full request from Http.
This caused me some issues also, because when I generated schema from sample I could not register the flow to the powerapp with the error Failed during http send request.
The solution was to manually review the response schema and change all column types to one of the following three, because other are not supported: string, integer or boolean. Object and array can be set only on top level items, but never on children, so if you have anything else than my mentioned three, replace it to string. And no property can be left with undefined type.
Basically I like this solution even more, because in powerapps itself you do not need to do any conversion or anything - simply use the data as is, because it is already recognized as collection in case of array and you have all the properties already named for you.
Response step schema example is below.
{
"type": "object",
"properties": {
"PropertyOne": {
"type": "string"
},
"PropertyTwo": {
"type": "integer"
},
"PropertyThree": {
"type": "boolean"
},
"PropertyFour": {
"type": "array",
"items": {
"type": "object",
"properties": {
"PropertyArray1": {
"type": "string"
},
"PropertyArray1": {
"type": "integer"
},
"PropertyArray1": {
"type": "boolean"
}
}
}
It is easy now.
Power Apps introduced ParseJSON function which helps converting string to collection easily.
Table(ParseJSON(JSONString));
In gallery, map columns like - ThisItem.Value.ColumnName
When we send messages using the below code using the Directline channel, the messages are sometimes received with their order swapped.
await context.PostAsync(msg1);
await context.PostAsync(msg2);
Expected:
mgs1
msg2
But in some cases, they're coming through as
msg2
msg1
Is there any way to handle and prevent this?
I'm going to write this answer assuming you're using the Directline or REST API for receiving messages. I can update if that's not the case.
This entire answer is based off of the Receive activities from the bot docs as well as doing some testing of the Directline API to confirm.
If you're connected via WebSocket, you should always be receiving the messages in order, provided there isn't some kind of size difference in the messages (like one has an attachment) that requires additional processing.
If you're not, messages are retrieved via a polling interval, meaning that your client likely sends a GET request every 5 or 10 seconds (varies by client) to retrieve all messages that have not already been retrieved.
Upon doing so, the client will receive something like this:
{
"activities": [
{
"type": "message",
"channelId": "directline",
"conversation": {
"id": "abc123"
},
"id": "abc123|0000",
"from": {
"id": "user1"
},
"text": "hello"
},
{
"type": "message",
"channelId": "directline",
"conversation": {
"id": "abc123"
},
"id": "abc123|0001",
"from": {
"id": "bot1"
},
"text": "Nice to see you, user1!"
}
],
"watermark": "0001a-95"
}
My guess is that your client is just running a foreach on the array of activities, which could be displaying them out of order. If you have the client order them by either timestamp or id, it should work.
I want to start by saying that this question is not for telegram bot API. I am trying to fetch images from a channel using telegram core API. The image is in the media property of the message object
"_": "message",
"pFlags": {
"post": true
},
"flags": 17920,
"post": true,
"id": 11210,
"to_id": {
"_": "peerChannel",
"channel_id": 1171605754
},
"date": 1550556770,
"message": "",
"media": {
"_": "messageMediaPhoto",
"pFlags": {},
"flags": 1,
"photo": {
"_": "photo",
"pFlags": {},
"flags": 0,
"id": "6294134956242348146",
"access_hash": "11226369941418527484",
"date": 1550556770,
I am using the upload.getFile API to fetch the file. Example is
upload.getFile({
location: {
_: 'inputFileLocation',
id: '6294134956242348146',
access_hash: '11226369941418527484'
},
limit: 1000,
offset: 0
})
But the problem is it throws the error RpcError: CODE#400 LIMIT_INVALID. From looking at the https://core.telegram.org/api/files it looks like limit value is invalid. I tried giving limit as
1024000 (1Kb)
20480000 (20Kb)
204800000 (200kb)
But it always return the same error.
For anyone who is also frustrated with the docs. Using, reading and trying out different stuff will ultimately work for you. If possible someone can take up the task of documenting the wonderful open source software.
Coming to the answer, the location object shouldn't contain id or access hash like other APIs rather it has its own parameters as defined in telegram schema.
There is a media property to a message which has a sizes object. This will contains 3 or more size options (thumbnail, preview, websize and so on). Choose the one that you will need and use the volume_id, local_id and secret properties. The working code will look something like this.
upload.getFile({
location: {
_: 'inputFileLocation', (This parameter will change for other files)
volume_id: volumeId,
local_id: localId,
secret: secret
},
limit: 1024 * 1024,
offset: 0
}, {
isFileTransfer: true,
createClient: true
})
The following points should be noted.
Limit should be in bytes (not bits)
Offset will be 0. But if its big file use this and limit to download parts of the file and join them.
Additional parameters such as isFileTransfer and createClient also exists. I haven't fully understood why its needed. If I have time I'll update it later.
Try using a library that's built on top the original telegram library. I'm using Airgram, a JS/TS library which is a well maintained Repo.
I am trying out the long running recognize method of the Speech-to-Text API (https://cloud.google.com/speech-to-text/docs/reference/rest/v1p1beta1/speech/longrunningrecognize) and specified all needed parameters such as:
{
"audio":
{
"uri": "gs://xyz/blabla.mp3"
},
"config":
{
"languageCode": "en-US",
"encoding": "AMR_WB",
"sampleRateHertz": 16000
}
}
This returned a name I can use with the get operation (https://cloud.google.com/speech-to-text/docs/reference/rest/v1/operations/get).
The documentation says the "operation" JSON object returned by get would include parameters that I do not see in the response.
For example, there is no "done" node. Instead this is all I get:
{
"name": "xxxxx",
"metadata": {
"#type": "type.googleapis.com/google.cloud.speech.v1.LongRunningRecognizeMetadata",
"progressPercent": 100,
"startTime": "2018-06-08T14:40:54.663240Z",
"lastUpdateTime": "2018-06-08T15:05:01.161911Z"
}
}
Any idea why that is? Should at least return a status and maybe an error (https://cloud.google.com/speech-to-text/docs/reference/rest/v1p1beta1/operations#Operation)?
UPDATE: Now I am getting results. Server issues, however? Is it only a temporary glitch?
{
"name": "xxxxx",
"metadata": {
"#type": "http://type.googleapis.com/google.cloud.speech.v1.LongRunningRecognizeMetadata …",
"progressPercent": 100,
"startTime": "2018-06-08T14:40:54.663240Z",
"lastUpdateTime": "2018-06-08T15:05:01.161911Z"
},
"done": true,
"error": {
"code": 13,
"message": "Server unavailable, please try again later."
}
}
At first sight your request is mixing an unsupported mp3 format versus a supported audio encoding (AMR_WB).
Let's suppose that this mixture is ok. If you receive an empty response (a transcript is not returned and no errors have occurred), it's probably that the encoding in your file is wrong. Check some validation steps in the preceding link to determine if your sound file have troubles, for example Cloud Speech-to-Text service currently supports only one audio channel.
To narrow down your issue, you can convert your sound file following the best practices. It will be enough to transcode your file to lossless FLAC or LINEAR16 encodings with a sampling rate of 16,000 Hz or higher, however for whole recommendations please read the prior link.
The error in your last update it seems to be temporary, do you still face the issue?
If your issue persists with the new file, it could be a good idea to report this situation in their public issue tracker.
Regards!
I have setup an Alexa Smart Home Skill, all settings done, oauth2 processed done and skill is enabled on my Amazon Echo device. Lambda function is setup and linked to the skill. When I "Discover Devices" I can see the payload hit my Lambda function in the log. I am literally returning via the context.succeed() method the following JSON with a test appliance. However Echo tells me that it fails to find any devices.
{
"header": {
"messageId": "42e0bf9c-18e2-424f-bb11-f8a12df1a79e",
"name": "DiscoverAppliancesResponse",
"namespace": "Alexa.ConnectedHome.Discovery",
"payloadVersion": "2"
},
"payload": {
"discoveredAppliances": [
{
"actions": [
"incrementPercentage",
"decrementPercentage",
"setPercentage",
"turnOn",
"turnOff"
],
"applianceId": "0d6884ab-030e-8ff4-ffffaa15c06e0453",
"friendlyDescription": "Study Light connected to Loxone Kit",
"friendlyName": "Study Light",
"isReachable": true,
"manufacturerName": "Loxone",
"modelName": "Spot"
}
]
}
}
Does the above payload look correct?
According to https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/smart-home-skill-api-reference#discovery-messages the version attribute is required. Your response seems to be missing that attribute.
In my (very short) experience with this, even the smallest mistake in the response would generate a silent error like the one you are experiencing.
I had the same problem. If you are creating discovery for "Entertainment Device", make sure you have wrapped the output in 'event' key for context.succeed
var payload = {
endpoints:
[
{
"endpointId": "My-id",
"manufacturerName": "Manufacturer",
"friendlyName": "Living room TV",
"description": "65in LED TV from Demo AV Company",
"displayCategories": [ ],
"cookie": {
"data": "e.g. ip address",
},
"capabilities":
[
{
"interface": "Alexa.Speaker",
"version": "1.0",
"type": "AlexaInterface"
},
]
}
]
};
var header = request.directive.header;
header.name = "Discover.Response";
context.succeed({ event: {
header: header, payload: payload
} });
Although, in the sample code, this is never mentioned and an incorrect example is given (https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/steps-to-create-a-smart-home-skill). However, the response body provided includes the "event" key.
Recreating lambda function helped me fix the issue. I also set "Enable trigger" check button while creating, though I'm not sure if that matters. After that my device provided by skill was found successfully.
Edit: Answer was wrong. Only useful information was this
This context.fail syntax is actually deprecated. Look up the Lambda context object properties, it should look more like "callback(null, resultObj)" now.
Did you include the return statement in your function?
return {
"header": header,
"payload": payload
}
It was missing in the example and after adding it, I was able to 'discover' my device.