I'm trying to create device groups to eventually create a Job with this particular device group to send a reboot command to all the devices in it. I'm using the IoT Central API REST for this with the URL looking like this (which is how it is on their documentation): PUT https://{subdomain}.{baseDomain}/api/deviceGroups/{uuidCreatedByMe}?api-version=2022-07-31
The body on the request looks something like this:
{
description: `Pulses' group to be rebooted, created at ${DateTime.now().toISO()}`,
displayName: `Reboot group ${deviceGroupId}`,
filter: query,
}
And the query is very similar to this
SELECT * FROM devices WHERE $template = "templateId" AND $id IN ["deviceId1", "deviceId2"]
But for some reason, when I send the request, it responds with an error:
Request failed with status 500 and error: {
"code": "InternalServerError",
"message": "Something went wrong on our end. Please try again. You can contact support at https://aka.ms/iotcentral-support. Please include the following information. Request ID: requestId, Time: Tue, 06 Sep 2015 477:10:01 GMT.",
"requestId": "requestId",
"time": "Tue, 06 Sep 2022 16:10:01 GMT"
}
However, when I try to create a Job and get the list of device groups, this brings me all the device groups I have been attempting to create, but it doesn't let me see the number of devices and doesn't allow me to continue creating the Job. And then, I request through the REST API to delete such device group with one of the ids, and it deletes it just fine.
My question would be...
Is this related to the query or what exactly?...
Because according to their documentation this is a valid query
I can confirm that it is not supported yet, try to use ($id= '' OR $id = '') to work around now.
Related
TLDR:
Can't post to local Cosmos Emulator. Can post to Azure Cosmos, but not with #azure/cosmos-sign, only with #azure/cosmos (which seems utterly bizare as the latter is supposedly built upon the former.) This is not ideal (as the message signing portion alone is very lightweight with REST API directly). Bug, or user error? Why do the instructions for enabling networking/https not seem to work?
Details:
I have a Node.js based app, and am using the Azure/cosmos-sign package to generate the correct headers via the generateHeaders method to save a JSON object in the local Cosmos Emulator.
Upon trying to post from the Node app to the URI provided in the Emulator Quickstart (https://localhost:8081), the error returned is...
Error: connect ECONNREFUSED 127.0.0.1:8081 : https://localhost:8081
As per these instructions...
Enable access to emulator on a local network
If you have multiple machines using a single network, and if you set
up the emulator on one machine and want to access it from other
machine. In such case, you need to enable access to the emulator on a
local network.
You can run the emulator on a local network. To enable network access,
specify the /AllowNetworkAccess option at the command-line, which
also requires that you specify /Key=key_string or
/KeyFile=file_name. You can use /GenKeyFile=file_name to generate
a file with a random key upfront. Then you can pass that to
/KeyFile=file_name or /Key=contents_of_file.
To enable network access for the first time, the user should shut down
the emulator and delete the emulator's data directory
%LOCALAPPDATA%\CosmosDBEmulator.
-https://learn.microsoft.com/en-us/azure/cosmos-db/local-emulator?tabs=cli%2Cssl-netstd21#enable-access-to-emulator-on-a-local-network
...I thought perhaps I needed to enable the networking functionality. It is all on the same (Windows) host (with the Node.js application running in Docker on the same host as the Emulator is installed). But this caused more problems with no benefit. With the generated key, I can load the included UI for managing the local emulator instance, but I then can't create Databases or Containers (without resetting the emulator and starting it again normally, eg: without the AllowNetworkAccess and related settings).
Attempting to use the included Explorer to create a Database returns...
Error while creating database SampleDb:
{
"code": 401,
"body": {
"code": "Unauthorized",
"message": "The input authorization token can't serve the request. Please check that the expected payload is built as per the protocol, and check the key being used. Server used the following payload to sign: 'post\ndbs\n\nmon, 29 mar 2021 23:33:45 gmt\n\n'\r\nActivityId: 29e4e700-d1b7-4d59-bdea-5931e4d6622d, Microsoft.Azure.Documents.Common/2.11.0"
},
"headers": {
"access-control-allow-credentials": "true",
"access-control-allow-origin": "https://localhost:8081",
"access-control-expose-headers": "Access-Control-Allow-Origin,Access-Control-Allow-Credentials,Content-Type,x-ms-activity-id,x-ms-gatewayversion",
"content-type": "application/json",
"date": "Mon, 29 Mar 2021 23:33:45 GMT",
"server": "Microsoft-HTTPAPI/2.0",
"x-firefox-spdy": "h2",
"x-ms-activity-id": "29e4e700-d1b7-4d59-bdea-5931e4d6622d",
"x-ms-gatewayversion": "version=2.11.0",
"x-ms-throttle-retry-count": 0,
"x-ms-throttle-retry-wait-time-ms": 0
},
"activityId": "29e4e700-d1b7-4d59-bdea-5931e4d6622d"
}
I did see this somewhat similar SO question, but it was abandoned.
This one, however seems to imply they simply reverted the KeyFile steps mentioned in the MS Docs. It seems odd that I am getting the same error from the Node.js POST regardless of if I use the AllowNetworkAccess switch or not.
Using the /NoFirewall switch as recommended here didnt resolve POSTs but did allow the Explorer UI to still work properly. The upvoted answer for that question is what I have already tried (/AllowNetworkAccess /KeyFile=...., and is not working, as explained above).
The docs here indicate that TLS (https) is in fact required...
"The Azure Cosmos DB Emulator supports only secure communication via TLS"
However, here they seem to indicate that, in the Node SDK (which relies on the same cosmos-sign library I am using)...
"TLS verification is disabled. By default the Node.js SDK(version 1.10.1 or higher) for the SQL API will not try to use the TLS/SSL certificate when connecting to the local emulator."
I tried adjusting the start script for my Node Docker image as suggested here...
If connecting to the Cosmos DB Emulator, disable TLS verification
for your node process:
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
const client = new CosmosClient({ endpoint, key });
...and changed the start script in my package.json from...
"start": "node $NODE_OPTIONS node_modules...."
...to...
"start": "NODE_TLS_REJECT_UNAUTHORIZED=0 node $NODE_OPTIONS node_modules...."
...and rebuilt my images, but still receive the same ECONNREFUSED error from the Node client/app.
As I was reading the documentation for the REST API I was reminded that, as opposed to using the CosmosClient (which just needs the base URL), to do a post to the API the url needs to be fully formed as indicated here...
Method: POST
Request URI: https://{databaseaccount}.documents.azure.com/dbs/{db-id}/colls/{coll-id}/docs
Description: The {databaseaccount} is the name of the Azure Cosmos DB account created under your subscription. The {db-id} value is the
user generated name/ID of the database, not the system generated ID
(rid). The {coll-id} value is the name of the collection that contains
the document.
After appending /dbs/SampleDB/colls/SampleCollection/docs (yes, my entities are CamelCase) to the base url offered by the Emulator UI's Quickstart URI (https://localhost:8081)... I am still getting the ECONNREFUSED error to http posts.
Hmm... retargeted the Node app to point to a collection in my Azure Cosmos DB, and I am still having no luck.
400: Invalid API version. Ensure a valid x-ms-version header value is
passed. Please update to the latest version of Azure Cosmos DB
SDK.ActivityId: bfdeb339-8fef-4ba9-a03d-444a8664c02b,
Microsoft.Azure.Documents.Common/2.11.0
Added x-ms-version and set it to 2018-12-31 (latest, as per here).
Now I am getting (after trying both my secondary, and primary keys... just in case)...
401: The input authorization token can't serve the request. Please
check that the expected payload is built as per the protocol, and
check the key being used. Server used the following payload to sign:
'postdocsdbs/TopHand/colls/SampleTbltue, 30 mar 2021 02:54:25
gmt'ActivityId: bb258bb4-f5a8-4495-b0b5-b54fa8b7c46f,
Microsoft.Azure.Documents.Common/2.11.0
I verified that the required headers are all present. What can possibly be left?!
Base URI for Azure Cosmos had a trailing /, which ended up duplicated when the rest of the path was appended. Fixing the url string, still getting the 401.
A github issue pointed me to what may have been an error in the URL/REST path I was posting to. Rather than posting to (what I had previously)...
dbs/SampleDb/colls/SampleTbl/docs
...I changed it to...
dbs/SampleDb/colls/SampleTbl
...and am now getting error 405, MethodNotAllowed, RequestHandler.Post. 405 isn't listed as code returned by the Cosmos REST service.
This example in the MS docs definitely uses the /docs string at the end of the url/REST path.
Example
POST https://querydemo.documents.azure.com/dbs/1KtjAA==/colls/1KtjAImkcgw=/docs HTTP/1.1
x-ms-documentdb-partitionkey: ["Andersen"]
x-ms-date: Tue, 29 Mar 2016 02:28:29 GMT
authorization: type%3dmaster%26ver%3d1.0%26sig%3d92WMAkQv0Zu35zpKZD%2bcGSH%2b2SXd8HGxHIvJgxhO6%2fs%3d
Cache-Control: no-cache
User-Agent: Microsoft.Azure.Documents.Client/1.6.0.0
x-ms-version: 2015-12-16
Accept: application/json
Host: querydemo.documents.azure.com
Cookie: x-ms-session-token#0=602; x-ms-session-token=602
Content-Length: 344
Expect: 100-continue
{
"id": "AndersenFamily",
"LastName": "Andersen",
}
I contacted MS support and was giving some info that unblocked me (but doesn't entirely address the issues noted above).
For my own use-case, simply setting a key and allowing network access to the emulator was sufficient.
Note: This doesn't address the issues of the Emulator's Data Explorer becoming nonfunctional.
The feedback I received from the support personnel in regard to using the command line switches disabling the UI was...
By changing the key to something other than default one, you also
protect your emulator data from being seen via the Data Explorer.
Apparently the key alone isn't enough to protect the data, and disabling the UI is a "feature".
Solution: Simply executing...
.\Microsoft.Azure.Cosmos.Emulator.exe /AllowNetworkAccess /Key={insert your base64 encoded 64+ character string}
...allowed network access to systems on the same host as the emulator. This avoided all the certificate/key generation/importing/etc headache.
You must connect to the non-loopback IP of the host the emulator is running on to connect to it (writes/reads/etc).
I have an Azure IoT Device in an IoT Central application.
We don't want it to execute offline commands. Is there any way to switch off this offline commands execution capability.
Based on my test (sync command), the behavior of executing "offline command" is working well. In the case, when the device is disconnected from Azure IoT Central App, the error Not Found is returned back after 30 seconds, see my example:
{
"error": {
"code": "NotFound",
"message": "Could not connect to device in order to send command. You can contact support at https://aka.ms/iotcentral-support. Please include the following information. Request ID: cic9xs38, Time: Sun, 09 Aug 2020 05:08:00 GMT.",
"requestId": "cic9xs38",
"time": "Sun, 09 Aug 2020 05:08:00 GMT"
}
}
and the following screen snippet shows a command history in the IoT Central App:
Note, that in the present version there is no feature such as re-executing (retrying) a sync or async command on the re-connected device. If the device is not connected, the command is completed with a failed status = NotFound, in other words, the command is invoking in the sync manner, see more details here.
From past few days the nest protect devices created using nest simulator tool are not responding properly. All of the nest protect are having same name Entryway and the battery status field is not updating in the Json response of Rest streaming . Is there anything I can do to fix this issue .
NOTE :previously I was able to get all the update properly
Following is the response I'm receiving:
{
"structure_id": "5vPPJJbCkUvNlf6JiLSY6eQaHKjf2iMd5YO4LsWuakUUiiU_M0jqKg",
"where_id": "45oC0YSjNKW13CclRc5F5DMrlsCCmp4VKVPaF1WQMBbd2FAAO-GqMg",
"name": "Entryway",
"name_long": "Entryway Nest Protect",
"is_online": true,
"device_id": "Hqw7qr2DPBzVp6Wrqds6hs8AFPWfjT7T",
"is_manual_test_active": false
}
My permissions are Away read/write ,Thermostat read/write ,Smoke+CO alarm read.
Getting the following response even when I make one request (concurrency set to 200) to a web service.
{ status: 503, headers: '{"content-length":"174","content-type":"application/json; charset=utf-8","etag":"\"8ce068bf420a485c8096065ea3e4f436\"","server":"Microsoft-HTTPAPI/2.0","x-ms-request-id":"d5c56cdd-644f-48ba-ba2b-6eb444975e4c","date":"Mon, 15 Feb 2016 04:54:01 GMT","connection":"close"}', body: '{"error":{"code":"ServiceUnavailable","message":"Service is temporarily unavailable.","details":[{"code":"NoMoreResources","message":"No resources available for request."}]}}' }
The request-response web service is a recommender retraining web service with the training set containing close to 200k records. The training set is already present in my ML studio dataset, only 10-15 extra records are passed in the request. The same experiment was working flawlessly till 13th Feb 2016. I have already tried increasing the concurrency but still the same issue. I even reduced the size of the training set to 20 records, still didn't work.
I have two web service both doing something similar and both aren't working since 13th Feb 2016.
Finally, I created a really small experiment ( skill.csv --> split row ---> web output ) which doesn't take any input. It just has to return some part of the dataset. Did not work, response code 503.
The logs I got are as follows
{
"version": "2014-10-01",
"diagnostics": [{
.....
{
"type": "GetResourceEndEvent",
"timestamp": 13.1362,
"resourceId": "5e2d653c2b214e4dad2927210af4a436.865467b9e7c5410e9ebe829abd0050cd.v1-default-111",
"status": "Failure",
"error": "The Uri for the target storage location is not specified. Please consider changing the request's location mode."
},
{
"type": "InitializationSummary",
"time": "2016-02-15T04:46:18.3651714Z",
"status": "Failure",
"error": "The Uri for the target storage location is not specified. Please consider changing the request's location mode."
}
]
}
What am I missing? Or am I doing it completely wrong?
Thank you in advance.
PS: Data is stored in mongoDB and then imported as CSV
This was an Azure problem. I quote the Microsoft guy,
We believe we have isolated the issue impacting tour service and we are currently working on a fix. We will be able to deploy this in the next couple of days. The problem is impacting only the ASIA AzureML region at this time, so if this is an option for you, might I suggest using a workspace in either the US or EU region until the fix gets rolled out here.
To view the complete discussion, click here
When using Foursquare API, if I pass up to 6 categories id's in categoryId parameter, it works fine. But, if I pass 7 or more, Foursquare returns 500 internal server error, saying that their servers are down (see below). The fact is that the servers are up and the API docs don't say anything about categories limit. The specific query I'm using is this:
https://api.foursquare.com/v2/venues/search?v=20120321&ll=-19.879190%2C-43.927068&limit=50&intent=checkin&radius=500&categoryId=4d4b7105d754a06374d81259%2C4d4b7104d754a06370d81259%2C4d4b7105d754a06377d81259%2C4d4b7105d754a06375d81259%2C4d4b7105d754a06378d81259%2C4d4b7105d754a06379d81259&client_id=[MY_CLIENT_ID]&client_secret=[MY_CLIENT_SECRET]
If I add categories like 4d4b7105d754a06372d81259 and 4d4b7105d754a06376d81259 (all valid categories), the server starts to return 500 Internal Server Error. Is this a bug, or am I missing something?
I don't believe this is a URL size limit, since the entire URL with escaping is exactly 410 characters long when passing the 6 categories id's.
The error response is as follow:
HTTP/1.1 500 Internal Server Error
Date: Tue, 21 Aug 2012 18:19:48 GMT
Content-Length: 183
Content-Type: application/json
Connection: close
Server: nginx/1.2.1
{
"meta": {
"code": 500,
"errorType": "server_error",
"errorDetail": "Foursquare servers are experiencing problems. Please retry and check status.foursquare.com for updates."
},
"response": {}
}
I think this has been fixed — I tried a search with just shy of 30 categories and it seemed to work. No server error and I got a good sampling of venues from most of the categories.