At seemingly random time points, a large majority of our tags get the "Uncertain_InitialValue" quality.
This can be resolved by restarting the affected tag provider. However, it is unclear to us why this issue happens.
The affected tag provider has about 400 000 tags.
The gateway has 8 cores and 32GB RAM.
The gateway cpu usage is about 3%. So I figure the resources are not the issue (?)
Is this too many tags for one provider?
If so, are there any recommendations for tag provider size?
Any idea why this is happening?
Do we need to spread our tags over multiple gateways?
Uncertain_InitialValue is the starting quality for a tag when it initializes but has not received a value. There isn't really a path I can see for tags to go from having a value/quality back to Uncertain_InitialValue, except maybe by restarting the tag or provider.
Are you sure you're not just discovering a tag that never received a value and remained in its initial state? Or that it's not some other Uncertain quality?
We had another event.
However, I made a mistake: it was not "Uncertain_InitialValue" but "Uncertain_LastKnownValue".
And this time the issue resolved itself after a few minutes without restarting the affected tag provider.
The issue happened after we did a deploy from test to production (might be coincidence ?).
In this deploy, we did the following:
copy projects from the test gateways to the production gateways
send tags from develop gateways to the production gateways with EAM
copy theme files from test gateways to the production gateways
sync tags from the plant production gateways to the group production gateway
Uncertain_LastKnownValue, when connected to a 3rd party server, happens in 3 scenarios:
you've lost connection to the server. The Ignition client will automatically reconnect, resume or establish a new session, and transfer or create new subscriptions.
the server has indicated to us that some subscription is no longer valid for some reason. The Ignition client will delete and then re-create it.
the subscription watchdog timer has elapsed, which means we should have received either data change notifications or a keep alive notification for some subscription, but 2x the expected arrival has elapsed, and now we assume this subscription is no longer reliable. The Ignition client will delete and then re-create it.
The logs may have some indication which of these is occurring. All of them should recover automatically, assuming the server is not broken or overloaded in some way and that the subscriptions can be successfully re-created.