Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.

Brought them out of root level and now everything is great. Have some buttons assigned to specific date ranges on the page itself. Now if there's a way to hide the top blue bar, it will be perfect.

Hi andresmorago,

I don't have a great deal of experience with OPC devices, but some googling and reasoning suggests it's either an error with the server not having sufficient permissions (seems unlikely unless you installed the OPC server software as well, then possible) or it has some sort of authentication you need to get Mango to do or a client whitelist that you need to add it to.

@pierjsap
Please do share your solution as I can see this logic being very useful. I think my method would be to duplicate your event sent points and logic in the meta data point script. Then use the if statement that your proposed to set the meta point. Keep the event detectors so that your event page will still list the events.

Hi Wingnut2.0,

Yes!

Unfortunately, the modules' i18n.properties files in their classes directory is not affected by the overrides directory currently. This means that currently you need to modify that file in place, then back it up for when updates come along. To change the alarm names, you can copy Mango/classes/i18n.properties into Mango/overrides/properties/ and modify it there. After you've renamed the alarm levels as desired, you can restart Mango to see the changes.

It's also not an option to simply put the updated keys into the one i18n.properties file, either. You have to modify the module's i18n.properties file.

https://github.com/infiniteautomation/ma-core-public/issues/1236

thanks @phildunlap ;)

Hi Wingnut2.0,

A quite large enterprise server I've seen, the one described here, has a 45GB ext specified heap, 40 cores at 2.6 GHz. About 550000 total points across 30 or so persistent data sources, 300000 values/second, throttle incoming persistent threshhold set to 37500000. Also a very large NoSQL minimum batch size (so that it always hits the minimum small batch wait time, which is 60000ms on that system). This system has been cruising along for quite a while. The settings left us a fair amount of room to run large, complex reports or zip around the UI.

Yes

That makes sense, thank you!

@phildunlap Thank very much, The problem was resolved

Glad to hear it :D

As I'm sure you saw, you can probably drop all the URL parameters for hiding things now.

@rectifier I agree, good idea.

Thanks for sharing the resolution!

If Haystack is available in that Niagara version, you would create a Haystack data source in Mango which would behave as a client and poll the Niagara server. This solution would probably be easier, go ahead and try! All you need is the URL to your Haystack server and your authentication information to create the data source.

If using a scripting data source, you would have the full flexibility of the REST API that was the subject of the post. If it's serving a REST API and that's what you're querying, then you're the client and its the server again.

There are other options. Both the BACnet and Modbus publishers in Mango accept writes over those protocols. If you find it easier to output a CSV once a day, there is a Data File data source that can import something you copy to it or you can define an arbitrary poll class and have Mango copy the file from the remote server. So, either client-server relationship is possible, but both the scripting and Haystack options would definitely be clients to their respective APIs.

BACnet is working now:

I upgraded the eGauge firmware and set each eGauge broadcast mask back to what I had before the V3 upgrade (192.200.255.255) per eGauge recommendations. I did not change the netmask. eGauge does not think the firmware upgrade would affect the BACnet discovery. Nonetheless, Mango subsequently found the eGauges via BACnet WhoIs, but the old BACnet points were still not updating. Mango allowed me to add new BACnet points from the eGauges, and the new (redundant) BACnet point updated, but none of the old points updated.

Disabling/enabling points, or disabling/enabling the BACnet datasoure, also did not cause the old BACnet points to update. The old BACnet points finally started updating after I saved the BACnet datasource, even though I had not made any changes to it. The only LAN switch/router configuration settings changed for troubleshooting were "IGMP snooping" and "Flood unknown multicast traffic," but they were subsequently re-enabled, and BACnet WhoIs still works. Neither LAN setting had any effect on BACnet.

Thanks for your help.

I have created a new data point, plain subscribe to /motor1/temp1 and I get the value to show. The only difference is that the value that I can't see is a json value.

This is running core 3.3.1 ATM. I see that latest core is 3.3.3 and I will upgrade tomorrow.

Hi Mircsicz

I needed to accomplish a similar UI with flow meter totalizers. These 2 videos should help you with navigating the legacy UI for data points and getting the delta roll up you trying to accomplish.

I Installed the update and can approve that changing the passwd now works for me ;-)

I've moved this issue to it's own topic

And BTW: I've pasted the log output in that new topic...