Here's sort of a general question I have as I rationalize specifications from my clients and multiple integrators in the Solar/BESS SCADA space. Any best practices or creative solutioning?
Let's say an integrator has a standard tag naming convention for their product, where a device type of typeA has members A1, A2, A3, etc. Obviously much more complicated than that since these facilities usually have hundreds of thousands of tags, but the concept is straightforward. Now let's say they have view viewA which indirects everything based on a param tagPath=instanceOfTypeA.
Now let's say some clients are getting much more particular about their namespace and are providing tag naming schemes for their facilities. I would therefore assume there would be a major renaming/remapping of indirected references below tagPath=instanceOfTypeA, a significant amount of rework, testing, and risk to maintain the same Perspective screens for a new client's tag naming specifications.
Any shortcuts to both accommodate the client's tag naming conventions while still preserving the integrator's thousands of instances of indirection in scripts and views?
One idea I had was having the deployment automation write the original standard tagPaths to a custom property, and then using something like globalVarMap or a script to write a lookup table to a custom property in the root of the UDT instance. This would still require reworking every instance of indirection in scripts and views, but at least could provide a framework for easy rework from client to client. This also sounds like it would be a significant performance hit versus native indirection. But I'm hoping for something even simpler.
Not sure if this is helpful, but when tag path/hierarchy outliers start causing headaches, I inevitably end up reverting to system.tag.query() + document tag metadata at the root of each UDT - or maybe root of each “device” subfolder (there’s a difference I can’t recall at the moment) so I can stop caring about the edge cases. Just return the relevant document tag(s) meta, put it in a page.urlParams prop (or pageVarMap), then use tags() with qvAt() to get the live data (and even mutate the static “value” that system.tag.query returns)
I think custom tag properties might be a good path to go.
Utilize the custom tag properties with your view bindings regardless if it is a “standard” project or a “custom” project. Essentially this makes all projects “custom “ projects (as all PV/BESS is anyways).
You will need to develop a script to generate the custom tag properties. If it is a “standard” project then the script should be fairly straightforward. If it is a “custom” project then the script may require some effort.
The custom properties could look something like Feeder:”F01”, Circuit:”C01”, PCS:”PCS01”, INV:”INV01” with some sort of wildcard (NoVal) to indicate if there is no value for the custom property.
Then each top level view could have a script that runs one time to derive the usable tag paths from the custom.props. Maybe this script needs to be adjusted for custom projects, but the goal should be minimal work at this level.
The indirection in the actual bindings would simply point to the custom.props. It would not be a complex indirection. {1}:”full\path\to\tag”
Sounds like a fun challenge.