Comparison of scripting data sources

[AldoRamos]

Is there a comparison of the various scripting data sources (Meta, Virtual, Scripting) etc. explaining their intended uses/advantages etc.?

For example, I need to create a manual input; I think a Virtual point is what I should be using, but I'd like to know it's indeed what is most effective for that purpose, and why (or why I shouldn't use a Meta, for example).

Also, on a related note, is it possible to use a scripting data source on a schedule (e.g. reset a value every hour) or as an event handler (e.g. when a MODBUS slave disappears, run a script to attempt recovery)?

Thanks in advance,

Aldo

[JoelHaggar]

Hi Aldo,

Here is the quick run down:

For manual inputs a Virtual data piont is your best choice for sure.

Meta Data Points create new Data Points based on scripts using values of other data points in the system.

Scripting Data Sources are generally used to change the value of other data points in the system based on scripts. They do have the ability to also create their own data points so there is some crossover.

The other difference is that Meta Data Point have the option to update based on Context update where Scripting Data Sources can only run on a CRON. Meta Data Points also have a tool to generate their own history based on the script.

You can use a CRON pattern on the Scripting data source so yes you could use it to reset a value every hour. You could do this on a Meta Data Point as long as the value to reset was it's own value.

Hope that helps

[phildunlap]

My thoughts on the matter is that it's primarily about intellectual separation/containment.

Different Overhead:

1. Virtual Points set to "no change" amount to an extra function call to a no-op every virtual poll period
2. Meta Points must have a context point that updates them or run on a cron, so there is [an] extra script run[s] / compile[s] and context building.
3. Scripting points need to be built into the script's context.

So, I would think Meta points are a clearly different category than the other two. So when would I use virtual points?

1. The thing the virtual point is connected to is a definite thing. Then I can index on that data source if there are other attributes of interest. If everything is no change,the polling period can be very large.
2. The data is a definite thing someone would be interested in somewhere.

When would I elect to use a Scripting point?

1. When the value is ephemeral to the script, such that it can be set to not log and easily awaken in an unknown state in the event of power failure or some such..
2. When the value is a serialization of script state. JSON.parse() and JSON.stringify() are available!

The main reason is to keep things orderly. If you are playing with the behavior of a script, do you want lots of output data variables hanging around your parameters (after all, other scripts or point links or what have you can modify your script's points!)? Similarly, if you messed up the calculations systematically for Field Device 7, and Field Device 7 is compartmentalized as a virtual data source, then you can just hit the "Purge All" button for the data source.

[AldoRamos]

Thanks, guys; that's very helpful information.

2 follow-up questions:

My example of setting a value was poorly chosen; I already know several other methods to accomplish that. What's more challenging is to execute a script that impacts the working environment. For example, I have an issue where I need to reset some serial data sources (see: "scripting-to-reset-serial-modbus-data-source"), and would like to execute those scripts on command, on a schedule (cron) and/or as an event handler. So forget my lame example; what would you recommend for executing (action) scripts in those situations? (Note that a return value may not be meaningful in some situations.)

Also, I meant to ask if there are other scripting options to be considered, and factored into the selections. I left out "Global Scripts" for example (and I've learned to make use of it to some extent). Is there another place where scripting can be done? And, again, what are their (dis)advantages when compared to other scripting?

[phildunlap]

If you need responses as fast as possible, using a Meta Point enables you to execute both on a cron and by context update. To tie a 'command' in your may want a virtual point they can set in the context, to trigger the script. All scripting environments have the RuntimeManager in their scope, so restarting the data source is possible using the meta point, point links, or a scripting data source. The former two both offer context listening, and meta points offer a cron.

If your system is pretty complicated and you need hundreds or thousands of things behaving like this, you can also just accelerate the cron from the scripting data source to execute every second. The advantages are that manipulating the runtime would only be occurring in one place and bizarre situations like two meta points issuing a restart at the same instant are avoided. The potential disadvantage is that the minimum resolution is one second (but this would be true of Meta Point's cron, though they have context update options). You'd then have some input you could set commands to that the script will read and consume..

[psysak]

Hey, hate to revive a long dead thread but I had a question. I am using Virtual points for this purpose of having some user settable factor, and I notice that the "initial value" of a virtual point doesn't work as I expect. I created a couple points and just set them to 1 initial value. Disabled polling on the virtual data source and enabled everything. The point values stay at "active source point has no value" instead of the "initial value" I expected.

Is this expected?

[phildunlap]

It is expected. Ideal or not, who can say. But, originally there was 'no change' to facilitate this kind of point, and it would do what you described. But, it also generated a 'point updated' event every poll period. So, in comes the non-polling virtual data source, which never schedules itself to do any work, it just sits there.

I could understand using the start value even still in this situation: it does seem implied. But, it's just as easy to initialize them elsewhere.