Loss of Disabled Tag Provider Data After Update to 8.3.1

Ignition
1

I updated from 8.3.1 RC1 to 8.3.1 LTS with one of my tag providers disabled. Upon GW startup after upgrading (which went smoothly), the tag provider that was disabled only showed 1 tag in it, and re-enabling still kept the tag count at 1. Tag groups, UDT’s and Tag data was all missing on upgrade for this one disabled tag provider. Luckily, I managed to restore via an older gateway backup. This could be a potential bug with disabling a tag provider in 8.3.

2

While I would encourage you to contact support about this, your description isn't lining up with what I would expect when a provider is enabled. When disabled the Tag Provider should be noted as Not Available for the tag count like the following:

DisabledProvider

Could you provide a bit more information about this? Specifically:

  1. Is this a Standard or Edge version of Ignition?
  2. What type of Tag Provider is this (Specified in the Type column of the Services.Tags page)?
  3. Were there any changes to the tags in the provider prior to the provider being disabled?
  4. Are there any errors in the logs prior to a restart?

Thanks,
Garth

3

When re-enabling, the tag count stayed at 1 and it seemed all data associated with that provider was missing - can I find this in the system files and import some how?

to answer your questions:

  1. Standard
  2. Standard
  3. minor changes made to the tag provider before disabling, then disabled the tag provider (troubleshooting something), then a few days later updated to 8.3.1 LTS.
  4. I did not find any obvious errors regarding my tag provider.
4

In 8.3, the tag definitions are held in the following locations relative to the Ignition installation directory:

  • Tag Provider Definitions: ./data/config/resources/core/ignition/tag-provider
  • Tag Group Definitions: ./data/config/resources/core/ignition/tag-group
  • Tag Type Definitions (UDT Definitions): ./data/config/resources/core/ignition/tag-type-definition
  • Tag Definitions: ./data/config/resources/core/ignition/tag-definition

Within the above folders, there are sub-folders per Tag Provider. Within the provider folders there will be configuration files. The files that would have Tag Definitions in them would be:

  • tags.json: Contain definitions for all atomic tags in a given folder (non-UDT, non-Folder types).
  • udts.json: Contain defintions for all udt types in a given folder. In tag-definition, these would be UDT Instance definitions. In tag-type-definition, these would be UDT Definitions.

You would be able to take to contents of these files and paste them into the tag browser and the tags would show, if they exist.

The 1 tag that you are seeing present is actually the _types_ folder which is added to any tag provider automatically and is the folder UDT Definitions get placed in when they get created. It isn't really meaningful other than you have what looks to be a empty tag provider.

With tags being in the resource system, the (simplified) way things should work when tags are created and modified is:

  1. Tag gets created/modified in Ignition
  2. The tag is loaded into memory and is immediately active for use
  3. A process in the background occurs that will write the configurations to the file system

This means that when the tag is first created, it isn't from a configuration stored on disk. The first time the configuration on disk would be loaded would be:

  1. If an API call was made to sync from the resource system
  2. The Tag Provider is disabled and subsequently enabled
  3. A Restart of the Gateway

Note that restarting a tag does not read from the file system. It uses the cached definition from the resource system memory.

All this is to say, while I hope the definitions would be on disk, I don't have high confidence you will find anything when you look based on your description of what is going on. It also means that the logs that might have information about what happened might be a few days/weeks old.

I do encourage you to reach out and work with support so we can try and better understand what might have happened as these types of issues are typically tough to track down and we haven't had any success in replicating the behavior you have seen.

Thanks,
Garth

1 Like