hi everybody!
I need to access remote tag history.
My idea was using a "Remote Tag Provider (Gateway Network)" but I didn't want use the "Gateway Network" because only I need access to the history but not at the tag realtime values.
Therefore I use "History Access Mode" at Database and I configured the rest of parameters.
That only work if I enabled the "Datasource History Provider" option for this connection. The "problem" is that connection is only for access the tag history but not to do local historisation.
It don't have sense to need enable the "Datasource History Provider" for a connection that never It store data, specialy when all the configuration parameter to access the data was declare in the "Remote Tag Provider/History Settings".
For now, I'll use the "Gateway Network", but maybe that situation it a bug
Do you have a database connection to the DB holding that remote gateway's history? If so, you don't need an RTP at all, just construct history tag paths using the local DB connection, and the remote gateway's name and tag provider name as the parts of the "driver" term. See this topic and linked topics:
Yes, I have a connection to database of the tag remote history called "DB_fast_node_1" in my Ignition Gateway "GW-Node_0".
And you are right, with this method It isn't need to use a RTP for access the historizartion of the others Ignition gateways "GW-Node_x".
Ex. from my main GW (GW-Node_0) only use:
That work fine, but still It need to enable the "Datasource History Provider" for this connection "DB_fast_node_1" in my gateway even if it is only used to read values.
That's truth, but the idea was for many nodes. Each nodes It save your values and a "master node" or "Node_0" read the values. So for a lot number (or not a lot, a few) of nodes the config of "Node_0" stay dirty whith many "Datasource History Provider" enabled without use as never the node 0 store data, only read. My idea/objetive was avoid it.
Thanks anyway.
Consider using database replication (outside Ignition) to move your data from the multiple remote nodes to the single central node's database. Then a single database connection will work for all of the other node's history access.