• 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.

    posted in User help read more
  • 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.

    posted in User help read more
  • 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.

    posted in User help read more
  • MattFox

    Note: I'm using 3.5.6 until we're ready to upgrade..
    Your query will likely work better if you iterate rather than using get:

    var sources = DataSourceQuery.query('like(name,polecat*VIRT)&limit(10)');
    //I'm not confident with the like(name,polecat*VIRT), but hey if it works then good
    for(var i=0; i<sources.length; i++ ) {
        source = sources[ i ];
        print( source);
    }
    

    You should be able to print(source) and see all the associated datapoints in that datasource, regardless if the datasource is enabled or not. P.s I also found it to be typeName for the type of datasource. Most likely not been updated.

    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.

    posted in User help read more
  • MattFox

    To my knowledge, not at this time. The users are stored in the mango database as there are distinct permissions they need to inherit for it (the dashboard) to work.
    If you were to write an API that handles all of the login part and talks to the mango users api to gain access to the dashboard then maybe you can arrange something. Otherwise, no.

    posted in Mango Automation general Discussion read more
  • MattFox

    Try referring to this, I know it relates to meta points. but due to a similar issue with updating in 'real time' a bigger cache might solve this issue...
    https://forum.infiniteautomation.com/topic/4272/inconsistent-values-between-mqtt-and-meta-points/10

    posted in Mango Automation read more
  • MattFox

    Thanks Phil, so from what you're saying here even my suggestion wouldn't change the outcome due to how the system caches data?
    Will be good to know with an upcoming project I'm doing will have to resolve as much as 16 points at once through the same algorithm.

    posted in User help read more
  • MattFox

    Thanks Phil, haven't quite mastered the art of answering forum posts while catching 40 winks!
    Good to see you're sorted Chio.

    Fox

    posted in User help read more
  • MattFox

    @iperry said in Inconsistent values between MQTT and meta points:

    updated when the MQTT point changes, which in this case is 6 time in < 1 sec.

    Ah so this function is practically being called each time each of the points are updated, not just a single point in particular... There could be some sort of deadlock if each metapoint doesn't fire in it's own thread quick enough or something silly like that. But I doubt that's the issue here.

    return ... just will set the metapoint at the time it is returned, which in your case is during the context update of a given point. My suggestion was merely to see if this improves capturing all changed values rather than trying to smack them all simultaneously in the same meta data source. Only playing with ideas here. Phil will likely have something more to add.
    My idea of using set() just meant that you weren't pressed to have the meta point firing right when every point updates nearly simultaneously. It could fire each of them in their own cron thread every ten minutes, setting the meta point with the correct value and timestamp. Create an additional point and run a historic on it for me then let it run for a few hours to see if it gives you the desired solution.

    Fox

    posted in User help read more
  • MattFox

    @iperry said in Inconsistent values between MQTT and meta points:

    Are there considerations I need to make if changes to a data point occur at millisecond frequency?

    Just looking at what you're saying here just so I don't get my proverbial wires crossed...

    1. Your point values update every ten minutes.
    2. The updates within the MQTT space occur within a span of a few milliseconds.
    3. You suspect that the points aren't updating fast enough prior to the context in your meta point calc firing.

    If 3 is correct, my idea is running the meta script every ten minutes, and setting itself with the value and timestamp. myPoint.set(calcTemperatureWithOffset('L1-CS01-01',p2576.value,0),p2576.timestamp ); That way there is no issue with trying to run your system in a reactive nature. just ensure meta point has the 'Is Settable' checkbox ticked.

    posted in User help read more