Replication of Non frequent data change

Dear community,

I am actively using OPC UA input listener plugin (suscription) for ingesting data into influxdb. Suscription means that I only ingest data when data changes. The problem I encountered is that some points are changing at ms rate like speed or current, nevertheless, some other points are almost static like PLC firmware. What would be the best way to replicate all measurements at 12:00am for example so I could reduce the timeframe of my queries and also avoid loosing data if the retention policy of the bucket is reached? I was thinking in a couple of options: telegraf restart every midnight (which is not the most best way because possible lack of data) or a kind of task running into the db every midnight at 00:00, looking for the last value of each measurement and create a new one with the same value at 00:00. What do you think?

Thanks in advance

I’m facing a similar issue and decided to stick with the basic interval read plug in for now. I don’t know how feasible it is from a configuration standpoint, but you could split the nodes into static and dynamic categories? Put all fast changing nodes (sensors, etc.) in the subscription plugin and the mostly static nodes in the basic read plugin with a long interval like 1h?

Hello. Thanks for your reply.
The solution you propose could be an option but due to the fact that maybe some signals remain inactive for days and during certain operation start to change frequently it is very difficult to define static and dynamic variables to be managed with different input plugins.
I would have preference for the auto-generated measurements every midnight but to be honest I don’t know exactly how could be implemented when speaking about thousands of measurements…

In any case thanks for your comment.

I hope someone could give us some brightness.

So I still think this should be possible only using Telegraf. You are allowed to add the same node to both the inputs.opcua and inputs.opcua_listener plugin. A metric with a fixed interval would come from inputs.opcua while fast changes are captured by inputs.opcua_listener. I should mention that everyday at midnight is not trivial to configure, but 24h itself is a valid interval. Would this work for you?