Best way to structure for multiple instances of device

pyeager

Thanks, Phil! That should get things moving.

One more thing for your attention....

Here is some example code from [https://help.infiniteautomation.com/about-mango-java-script]

var points = DataPointQuery.query('like(name, *boiler*)&limit(10)');
var average = 0.0;

LOG.info('Found ' + points.size() + ' points to compute average.');

for(var i=0; i<points.size(); i++){
    if(points.get(i).runtime !== null){
      LOG.info('Adding ' + points.get(i).runtime.value + ' to the average.');
      average = average + points.get(i).runtime.value;
    }
}

return average/points.size();

It might be considered a "nitpick", but if any of the data points are disabled, the computation will be incorrect.

Why? Because the last line divides by the number of points, not the number of enabled points.

pyeager

@mattfox thanks for the suggestion regarding iteration. It looks much cleaner your way. I just followed the method used in the Mango documentation. Haven't done much javascript for quite a while!

phildunlap

Great!

Yeah, that may be nitpicky ;). You could so easily count the number of enabled points when you're checking the runtime not being null...

MattFox

Happy to help, my javascript ain't too bad IMO. I've got nothing on Jared or Phil mind you but always here if needed.

pyeager

@mattfox said in Best way to structure for multiple instances of device:

My advice here that I can give you would be to look at tagging all of the datapoints instead and then using an RQL query to pull them in. Not only will it enable you to better index your point information but will also give you plenty of control over what points you want to pull.

Thanks for the suggestion, Matt!

However, I have a question.

If querying the data source gets me all the points I need, where is the advantage?

MattFox

@pyeager

@pyeager said in Best way to structure for multiple instances of device:

If querying the data source gets me all the points I need, where is the advantage?

In this case you may have additional info regarding location or logger brand etc etc.
Which if in the case of all being in the data sources then that's fine.

My other reasoning is prior to tags being introduced, I used to do the same thing and link by name or data sources etc Which is fine for single site installs. But what if you find you suddenly need only some particular devices, or a sensor or something is installed which feeds back in different units or magnitude? Or even you're using a mango unit on multiple locations and need different level access? User permissions can get you so far but you cannot always rely the name of the device being consistently named.

My other point is being able to also create generic dashboards that pull data by query rather than individually mapping them. You may be able to individually name them differently, but what if you have the same issues as above? This is where tags are handy.

This is my 10 cents. (2 cents plus inflation and tax etc etc..) And in my case I have dozens of sites and users to take into account with their own locations (some shared) and not necessarily using the same hardware we have.

pyeager

@mattfox @phildunlap

Where is DataSourceQuery documented? I haven't yet found full documentation for that or much else. I've been figuring things out from the examples.

MattFox

Get yourself into the mangoUI and go to Administration -> Watchlist builder then select query as the watchlist type. It will allow you to put together a query and teach you what parameters are available. That was my go to for the first month or so when I started learning RQL.

EDIT: As for the datasource query info, I've not got much. It honestly looks like you use it just to pull datasource property information in order to pull points by it's XID / id.

pyeager

@phildunlap

function reflectPointsList(dataSourceWrapper)

works perfectly.

Do I understand correctly that it is a workaround until the next release?

phildunlap

Correct, although it should continue to work even in subsequent releases. But, once 3.6.2 is released the concerns raised in this thread will have been fixed,

points list not available via .points
JavaScript help says type not typeName while .typeName is correct

pyeager

This post is deleted!