Impact 2024: The Industrial Data and AI Conference for and by Users | Nominate Speakers Now for a Ch...
For the Retrieve data points API and a few other API’s that allow date range input, we are able to specify a string where, “The format is N[timeunit]-ago where timeunit is w,d,h,m,s.” This is able to specify a time in the past. I am now trying to specify end as “-365d-ago” to set a date 365 days in the future, but this is giving an error.Is there another syntax available for specifying future dates?N[timeunit]-afterNow?365d-afterNow?
We are currently exploring workflow development on top of CDF python SDK. The client secret is used in the workflow code in order to connect with CDF project instance. This client secret is bound to expire after predefined interval. It will incur production downtime and manual intervention in order to update the secret.Can we have or do we have some concept similar to refresh tokens in CDF Python SDK.
Currently when fetching datapoints from multiple timeseries, the Python Cognite-SDK splits up the requests into one request per timeseries, while the underlying CDF API supports up to 100 timeseries per requests. This slows down fetching multiple timeseries, which is a problem when you display multiple timeseries (or aggregated of timeseries) in a frontend application.
In CDF, does “Domain Data model” provided out of the box by the product or it needs to be configured? My understanding is, source data is firstly staged on staging/raw layer, then mapped to “domain data model” and then each customer can derive “Solution data model” out of “Domain data model”. Most probably “Domain data model” should be 3NF. Can someone validate my understanding please.
I created a test data model in a test space. I finished testing and deleted the data model, but can not find a way to delete the space (which no longer contains any data models)?
Once we have created the Timeseries, is it possible to change the isString value to be True?
I’m experimenting with filter nodes https://pr-ark-codegen-1646.specs.preview.cogniteapp.com/v1.json.html#tag/Instances-(New)/operation/advancedListInstance using a payload like:{ "includeTyping": false, "sources": [ { "source": { "type": "view", "space": "jca-domain", "externalId": "Facility", "version": "0_3" } } ], "instanceType": "view"}It seems to return entities not of the type of the given source (Facility/0_3). For example it returns Equipment/0_3 entities. Is this the expected behavior and do I have to separately filter for view type? If so how do I do that? Thanks.
I might need to create 100,000s - 1,000,000 of individual timeseries. I would like to understand if the number of timeseries impacts the API performance. e.g. retrieving data points for 1 of the timeseries. Would the API response be similar if I had 100 or 1 million timeseries?Also is there a maximum number of timeseries that can be created per CDF project?
Hi. I’m currently working on an application where we need to check if a node (PLC/PC) have updated any timeseries within x amounts of hours. The way we do it now is to get all timeseries recorded values in a time range, and check if any timeseries have any values. If there is an value on one timeserie, then we consider the node alive. This can be time consuming, since each node can several hundreds/thousands of timeseries. So my question is if there is a way to get the latest recorded value in a collection of timeseries within a timerange? Or just a recorded value in a timerange for a collection of timeseries. In Cognite, we have an asset hierarchy, which preferably would look like this:RigNode 1 TimeSerie1 TimeSerie2 ... Node 2 TimeSerie1 TimeSerie2 ... Node ... TimeSerie1 TimeSerie2 … But the hierarchy could also be completely flat, where all the timeseries are connected to the Rig. Our externalIds for the timeseries are:rigNumber.NodeNumber.SignalNumber So all timeseries wit
I find it useful to be able to filter CDF resources by their source system.How come Assets, Files and Events have a “source” attribute, while time series and events do not? I assume then, that in order to properly filter by source for any resource type, it might be best to rather add “source” as a metadata key for any resource type, rather than use the attribute field which is not available for all resource types?Btw., for the Relationships resource type, “source” has a different meaning than it has for Assets - I suppose this could cause some confusion?
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
Check the
documentation
Ask the
Community
Take a look
at
Academy
Cognite
Status
Page
Contact
Cognite Support
