Solved

Does CDF support timeseries ingestion with non numeric values

  • 17 November 2023
  • 7 replies
  • 102 views

Badge

Does CDF support the direct ingestion of timeseries with non-numeric values ( enums).  If the workaround is to convert enums to integers to ingest, this is unnecessary overhead and a limitation. Also have to remember to convert the values back for visualization. 

icon

Best answer by Johannes Hovda 17 November 2023, 06:34

View original

7 replies

Userlevel 2
Badge +3

Hi,

CDF supports direct ingestion of non-numerical timeseries data. You can provide datapoints in either numerical and string form. 
https://developer.cognite.com/dev/concepts/resource_types/timeseries/

So yes, you don't need to convert enums or strings to numbers - you can ingest them as strings. 
 

However, we have many helper functions if you want to map the enum values to numbers. This is often used if you want to normalize or standardize enum values across multiple machine types and equipment suppliers. 

https://developer.cognite.com/dev/concepts/resource_types/synthetic_timeseries/#convert-string-time-series-to-doubles
 

Hope this helps  

 

kind regards

Johannes

Userlevel 3

Hi,

We currently do not natively support enums in Time Series (for example for representation of machine states), however this is in our roadmap for 2024 (though possibly second half of the year due to other priority items in the queue)

Kind Regards, Glen
 

Badge

Hi there, I see there has been an update on this. Can we say string, numeric, enums will be supported for time series data from Jan 2024?

Badge +2

@Glen Sykes will this also be built into the extractors like PI and OPCUA to enable catching the machine status, error messages etc?

Userlevel 3

Hi there, I see there has been an update on this. Can we say string, numeric, enums will be supported for time series data from Jan 2024?

Hi, Time Series has supported the string type for a long time.  There hasn’t been any change there.  Enum support should be coming during 2024, but it is more likely to be the second half of 2024.

Userlevel 3

@Glen Sykes will this also be built into the extractors like PI and OPCUA to enable catching the machine status, error messages etc?

The extractors support string types today.  When we declare support for machine states, we will have ‘end to end’ support, which means we will develop the feature on the extractors at roughly the same time as the storage API. 

The current design hypothesis is that the states will be stored as an integer, and an enum mapped to that.  Basically a ‘productised’ version of the recommendation that @Johannes Hovda makes earlier, where we will offer some common enum mappings out of the box, and allow for new mappings to be created.

Badge +2

Great, looking forward to getting more detail on these features when you can disclose them @Glen Sykes and @Johannes Hovda 

Reply