• Skip to main content
  • Skip to header right navigation
  • Skip to site footer
CDP Studio logo

CDP Studio

The no-code and full-code software development tool for distributed control systems and HMI

  • Why CDP
    • Software developers
    • Automation engineers
    • Managers
  • Product
    • Design UI
    • Develop
    • Analyze and test
    • Deploy
    • Framework and toolbox
    • Compatibility
  • Services
  • Use cases
  • Pricing
  • Try CDP

CDP Studio Documentation

CDPCompactDatastore Framework - Data Logging

InfluxDatastore

Introduction

InfluxDB (https://www.influxdata.com/) is an open source time series database. It is designed to handle high write and query loads and provides a SQL-like query language called InfluxQL for interacting with data.

The CDP Logger InfluxDB integration stores data in an InfluxDB server. The server can be some InfluxDB instance running on some cloud provider or a private InfluxDB server.

Note: The CDP Logger integration was made for version 1.7.7. Newer InfluxDB 2 will work through the v1 compatibility API. The v1 API Database will automatically be mapped to a v2 API Bucket.

Configuring the Datastore

To use this integration, add InfluxDatastore.InfluxDB from the Resource tree to your CDP Logger component. The following are the most important properties to fill:

PropertyDescription
URLAddress and port of the InfluxDB server (e.g. http://127.0.0.1:8086).
DatabaseName of the database to use. Created if one does not already exist and configured user is allowed to create databases.
MeasurementInfluxDB measurement used for reading/writing data. An InfluxDB measurement is similar to a SQL database table.
UserPwd<string>Login details for password protected databases. String in format [user name]:[password].
APIToken<string>Alternative to UserPwd. The API token is an access key that can be generated in an InfluxDB 2 server.

In addition, following properties are available:

PropertyDescription
LastRequestTimeTime stamp of the last request sent
LastStatusCodeProtocol specific status code the request received by the last response. For example, for HTTPRequest status code 200 means successful request.
Interface<string>Specific interface name (like ETH0, from Application configuration) to be used for request. Useful in multi-interface setup to determine the network device to use for request. Can be left unspecified - then system default network interface will be used.
Proxy<string>Proxy server to be used for request e.g. http://proxyserver:8080/. Useful in some network setups that require a proxy to be used in order to reach the Internet or special network segment the URL is located in.
ProxyUserPwd<string>Login details for password protected proxy servers. String in format [user name]:[password].
ProxyAuthMethodForce use of specific proxy authentication method. Authentication method is negotiated with proxy server and used to send user name and password (specified via ProxyUserPwd property) to proxy server. Can be one of the following:
  • Any - use any method server supports
  • AnyExceptBasic - use any method server supports except "Basic". This setting is default because "Basic" is generally considered too insecure (especially over unencrypted transmission).
  • Digest - use digested methods only
  • SPNEGO - use SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) method only
  • Basic - use "Basic" authentication only
FollowLocation<bool>If set to true follow (re-request) to any new URL that is pointed in request response with HTTP 3xx status code and Location header. Default is not to follow.
EncryptionRequest connection TLS encryption. Choose between options:
  • TryTLS - Use TLS certificate based encryption and optionally authentication if supported by remote server
  • TLSv1.x - use specific version of TLS encryption
  • Unencrypted - no encryption
TLSCACertFile<string>Server certificate issuer (CA) file name (used for TLS certificate based verification).
TLSAllowVerificationErrorsDisable some remote host TLS certificate verifications. Choose between options:
  • NoErrorsAllowed - request is interrupted an any TLS certificate validation error. This is default and strongly recommended secure setting.
  • AllowHostNameMismatch - allow only cases where remote host name does not to match with the one specified in TLS certificate
  • AllowCertificateFailure - allow only cases where server TLS certificate authentication (via CA certificate) check fails
  • AllowAnyCertificate - neither server TLS certificate authentication nor host name matching will be done

Database Format

The CDP Logger creates one measurement (named by the Measurement property) for storing value changes. Each point in the measurement contains a timestamp and every field which has had a value change.

The field names are used in the logger and will be visible in external tools to view data. It is recommended to use friendly and meaningful field names. Fields are the defined in the LoggedValues table of the CDP Logger. To rename a field, just change the Name property of the LoggedValue.

Note: By default field name is the name of the logged signal, parameter or property and if there are several fields with the same name, a number is appended to make the field unique. E.g. if there are 3 signals all called Temp, the logger fields names will be Temp, Temp1 and Temp2. It is recommended to rename these to meaningful names e.g. outsideTemp, insideTemp…

A second measurement is created for storing metadata of logged values. It is named by appending "_nodemap" to the Measurement property. Each point contains a "name" tag and a "routing" field which match the Name and Routing properties in the LoggedValues table of the CDP Logger. This can be used to map the friendly name of a logged value to its full path in CDP system.

Installing InfluxDB

As mentioned, the CDP Logger connects to a running InfluxDB instance specified by the URL property. This means InfluxDB must be set up first. One option is to use a cloud provider (for example https://aiven.io/). Other option is to install InfluxDB on your own PC. Download it from https://www.influxdata.com/.

After installing and starting InfluxDB, you may now connect to it by filling the datastore URL (default is 127.0.0.1:8086), Database and Measurement properties in CDP Studio. By default authentication is disabled but if enabled from InfluxDB settings, you must also fill the UserPwd property of the datastore (format is [user name]:[password]). Make sure the user has a right to create databases, otherwise you must configure the datastore to use an already existing database. When logging to cloud, it is often necessary to also set the TLSCACertFile property (or for simple testing purposes certificate validation can be disabled by setting TLSAllowVerificationErrors to AllowAnyCertificate).

Note: The CDP Logger integration was made for version 1.7.7. Newer InfluxDB 2 will work through the v1 compatibility API. The v1 API Database will automatically be mapped to a v2 API Bucket.

Viewing Logged Data

There is basic integration to access logged data through CDP Logger built-in server (see Viewing Data) but performance may suffer when database gets large. For huge data sets it is recommended to set up continues queries aggregating data and plot data using third-party tools (like Grafana).

CDPCompactDatastore Framework - Data Logging

The content of this document is confidential information not to be published without the consent of CDP Technologies AS.

CDP Technologies AS, www.cdpstudio.com

Get started with CDP Studio today

Let us help you take your great ideas and turn them into the products your customer will love.

Try CDP Studio for free
Why CDP Studio?

CDP Technologies AS
Hundsværgata 8,
P.O. Box 144
6001 Ålesund, Norway

Tel: +47 990 80 900
E-mail: info@cdptech.com

Company

About CDP

Contact us

Services

Partners

Blog

Developers

Get started

User manuals

Support

Document download

Release notes

Follow CDP

  • LinkedIn
  • YouTube
  • GitHub

    © Copyright 2022 CDP Technologies. Privacy and cookie policy.

    Return to top