Hey!
Was just wondering about the planned functionality/purpose of “reference tags” – are they any different than pointing an expression tag at the tag to be referenced? I was sort of expecting these to work like “Tag Aliases” e.g. would not have to specify datatype, other metadata – all would be pulled from the reference… but it does not seem like this is the case thus far.
Was also wondering if the reference tag would automatically link to the reference tag’s history (if configured).
Thanks in advance!
-Paul
I’m not the authority on Reference tags, but I’ve used them as “aliases” pretty extensively. You do have to specify the data type manually (it isn’t gleaned from the referenced tag), but other than that they work as I’d expect. You can even use the data type to sort of override the referenced tag, ie: specify an int value instead of the original tag’s String value, and you can get the numeric value of an address instead of preparing your own transforms.
Hey! Thanks for the quick reply. Is there any difference between doing a datatype cast this way vs. with expression tags?
Expression tags seem more flexible for this sort of purpose…
I was hoping to be able to share/mirror tags between providers using reference tags (e.g. such that metadata/types etc. would only need to be defined once at the base tag) – but it doesn’t sound like this is an option for me.
Is there any planned functionality for linking the base tag’s history to the reference tags?
Thanks again!
-Paul
There seem to be two differences between using a reference tag and an expression tag, with the main difference being logic; Expression tags allow you to construct your path with logic, whereas a Reference tag is literally just a provided path.
Example: suppose you have motor1-motor99, and you have a Numeric Entry Field - you cold use an Expression Tag to get the value of motor45 by supplying a value of 45 into the NEF and constructing an expression of "[default]MyTags/UglyPath/TooFar/MakeItStop/MyMotors/motor"+{NumericEntryField.props.value}
The second difference between the two is that Expression Tags obviously have an execution mode to drive their dynamic values.
As for the tag’s history… That’s really more of a @Colby.Clegg question…
Right – so basically the difference is:
- Expression tags have more functionality (i.e. they can do what reference tags do, + more)
- Reference tags do not have an execution mode – they are basically “cast” functions (?)
If the reference tags are able to access the base tag’s history automatically… then I definitely see the value of them in that case
Hi,
Yes, currently they aren’t much different than what you mentioned- expression tags, or more directly, derived tags. They are lighter weight than both of those in that they don’t create expressions in memory (though derived tags don’t need to actually create expressions if you don’t define read/write expressions outside of the default), though that’s not why they were created.
The main reason why they were created is because we want to make it really easy to drag tags from MQTT or other “managed” providers into your normal tag providers, and we thought it would be best to create a very simple/direct reference instead of a potentially more confusing expression/derived tag. ALSO- they were originally supposed to be what you first thought- complete tag symlinks that pulled in all sub properties. I think this would probably be ideal, but it became very complicated when thinking about how alarms and history would work.
So where we’re at now is something that isn’t terribly useful, but not really a problem to have, so… we probably have about 2 weeks to figure out whether we should remove it or make it better.
2 Likes
Would be nice if we could use this “reference tag” feature to share UDT definitions between providers (e.g. something like what is asked for in this post: [Feature] share or sync UDT data type between 2 realtime tag provider).
Are there any plans to create a “global” tag provider – e.g. where UDT defs can be defined/automatically inherited by other tag providers on the gateway?
Sorry to revive a dead topic, but this was the only discussion I could find as to why certain features are or aren’t on reference tags.
I only barely comprehend the scope of complexity of mirroring properties and alarms and history off the source tag, but I have a use case where it would be nice if the reference tag could just use the history of the source tag.
Meaning, the reference tag would never put anything in the history database itself, and any queries of it’s history will do the query against the source tag. This came up since we were referencing a MQTT/SparkPlug tag, and the edge device was using historical store-and-forward which the MQTT engine is just injecting into the history database directly. So, those moments in history are never seen by the reference tag.
I feel like this might not be too hard? I dunno, I’m probably way off base, but it would be useful for us if it’s easy.
As I was about to create a new topic, I ran into this thread and Justin’s specific question.
For my application, I have a centralized group of OPC tags for which I enabled history and alarms. Then I was hoping that I could create multiple structures of reference tags pointing at them that would allow me to alias back to the “central tags” from diffferent “angles”. For instance, I want to group tags by machine section but also want to group them by variable type (temp, pressure…) . I could just have two folders with different ref tags organized for different functions (two or more ref tags pointing to same source tag).
However, I realized that once I create the ref tag, it does not pull history or alarm config from source tags. So If I only needed to alias ONCE, then I would just disable history on source tag and enable in ref tag, but then how would I use the other structure without having multiple tags instances storing history from exact same source?
I assume there is a recommended way for what I am trying to achieve? Is there maybe another way of adding meta data to tags so I can group them symbollycaly for my views/components?
What is the recommended practice for having history/alarms? source tag or ref tag?
Thanks a lot.
Daniel.
curious on what your solution was to this as I am trying to do something similar in order to use the adhoc trends with reference tags.