Clarify use of variable name on meta data points

[iperry]

Heya,

Can you clarify the use of the "variable name" on a meta data point please? Is the use of it limited to the context of the point?

https://forum.infiniteautomation.com/topic/3033/using-json-store-for-data-point-tagging-can-it-be-done

I reread Jared's posting (as I planned to use metadata of the meta point itself) and it dawned on me that I may have been setting it with a "bad" name. I had thought the variable name should be unique and had been using the same as the point name, i.e. name/variable name = "Temp 1 High Alarm".

Is there any reason to change the default value of "my" for the variable name? Is there a naming convention I should use, i.e. camel case?

Thanks
Ian

[MattFox]

@iperry
Hi Ian, been a while!

@iperry said in Clarify use of variable name on meta data points:

Heya,

Can you clarify the use of the "variable name" on a meta data point please? Is the use of it limited to the context of the point?

Yes it's limited to the context of that datapoint.
The variable name is literally a varName = value;
I'd recommend not using the variable name with spaces as you won't be able to address it in your script without errors. Camelcase is fine, as long as the variable name is a single word.

@iperry said in Clarify use of variable name on meta data points:

Is there any reason to change the default value of "my" for the variable name? Is there a naming convention I should use, i.e. camel case?

It's not necessary, sometimes i've never bothered changing it because it is never used as part of the script. I generally end with a return and that sets the value for that meta point.

Any further questions please yell

Fox

[iperry]

Hi @MattFox,

Still here chugging along. Got about 3 different streams of development going for stuff, which seem to merge at times. heh

Thanks for the clarification. After reading Jared's posting and bit of testing, it looks like I had been setting them incorrectly. It wasn't until I tried to use the variable name that I realized the issue. Whopps. At least updating the existing meta points I have isn't that big of a hassle, i.e. export > text replace > import.

In the end the point data wasn't going to help me as I was hoping to get its hierarchical info. Guess I will need to query for that data.

(The intention was if the setpoint associated to the alarm was set to -1, get the setpoint of the group it's in instead)

Thanks again,
Ian

[MattFox]

In the end the point data wasn't going to help me as I was hoping to get its hierarchical info. Guess I will need to query for that data.

Ah that I remember based off of a post phil did a while ago... I'll take a gander at a script I wrote...
var pointConfigs = JSON.parse(JsonEmport.dataPointQuery(query)).dataPoints;

use an RQL query consisting of each of your points, I believe this may give you the nuts and bones data about storage and pointLocator types etc... This may be what you need to leverage that info...

Fox

[phildunlap]

Hi iperry,

In the end the point data wasn't going to help me as I was hoping to get its hierarchical info. Guess I will need to query for that data.

You mean the point hierarchy information? You could get this through the DataPointWrapper easily.

var dpPath = p.getDataPointWrapper().getPath();

You can also get the point folder id or the data type id from the DataPointVO,

var folderId = CONTEXT_POINTS.p.getVO().getPointFolderId();
var dataTypeId = CONTEXT_POINTS.p.getVO().getPointLocator().getDataTypeId();

(The intention was if the setpoint associated to the alarm was set to -1, get the setpoint of the group it's in instead)

As far as grouping, I would use tags instead of the point hierarchy.

use an RQL query consisting of each of your points, I believe this may give you the nuts and bones data about storage and pointLocator types etc... This may be what you need to leverage that info...

This would certainly work if one is more comfortable using the JSON than going through the DataPointQuery object to get a list of DataPointWrapper objects (so if they're enabled, their .getRuntime() method returns what a normal context point is). So,

var queriedPoints = DataPointQuery.query(rql); //also has byXid method
//Let's just assume there's at least one for this example, and it's enabled,
print( queriedPoints[0].getRuntime() ); // should be the same as print(p) if p is a context point