The DataHub program can read InfluxDB data written by other applications, but there are some limitations, particularly on store and forwarding.
This is what a DataHub instance writes when it is populating InfluxDB:
value – If the value is a number, then this will be
written.
text – If the value is not a number, then this will
be the text representation of the value.
Only one of text or value is
provided for any data value
quality – the OPC DA quality as a number, e.g. Good
quality is stored as 0xC0.
index – a monotonically increasing record number.
Every time the DataHub instance writes any value for any point to this
database it increments this index.
fullname – the fully qualified point name,
including the DataHub domain name. e.g.,
DataPid:PID1.Pv
domain – the domain name of the point, without the
colon. e.g., DataPid
pointname– the point name without the domain and
colon. e.g., PID1.Pv
timestamp - required by InfluxDB for each record.
The DataHub instance sets the record timestamp to the source timestamp of
the point value, not the clock time at the time of write.
The DataHub program can read any data from InfluxDB that is written this way. If another application writes to InfluxDB, it can write extra tags and fields, and the DataHub instance will still be able to read the record, as long as it also includes the tags and fields that the DataHub instance uses.
The DataHub program uses InfluxDB for three purposes. How it is being used determines which of the fields and tags are required.
Logging historical data uses all the fields and tags, although the domain and pointname tags are just a convenience for Grafana and Chronograf users.
Acting as the backing store for OPC UA and WebView historical queries requires:
Fields: value and/or
text, and
quality
Tags: fullname
If you can mimic this format in your InfluxDB writer then the DataHub program can act as the converter from InfluxDB to OPC UA HDA.
Acting as the storage for store-and-forward in MQTT and external historians requires:
Fields: value and/or
text, quality, and
index
Tags: fullname
If you want to use InfluxDB as a store-and-forward source for the DataHub program then there is some extra complexity around the index field, which is required for all store-and-forward operations.
The index must be incremented for each record that is written. That is, it must be strictly monotonic. Values can be skipped, but each index must be greater than the index of the previous record. If the index is not strictly monotonic then store-and-forward will fail to transmit all records. To ensure that index entries are monotonic, you must normally limit the system to only one writer.
However, if you never plan to use store-and-forward, the index does not matter. You can write data from multiple sources and still use InfluxDB as a source for charting and OPC UA HDA. These use cases rely only on the timestamp. InfluxDB does not require timestamps to arrive in increasing order, so you can write from as many clients as you like, and just set the index to zero for all records.
If you want to write data from two DataHub instances to InfluxDB, you can use store-and-forward from DataHub instance #1 to DataHub instance #2 over a tunnel. This way, DataHub instance #2 is responsible for the index, and it would ensure that the proper index is maintained. This lets you use the resulting InfluxDB database for store-and-forward, charting and OPC UA. You could also send the live data from DataHub instance #1 over a tunnel and let DataHub instance #2 write it to InfluxDB.
Briefly, multiple data sources can write to InfluxDB, but if you want to store and forward the data using the DataHub instance, you must write the data from a single source. Typically that single source is the DataHub instance itself.