@cmusselm
can you share a few screenshots?

thanks.

My only thought is maybe some additional high priority threads may be required to help smack out the calcs.
Alternatively have two scripted datasources updating a single virtual datapoint. That way they can fire independently of each other.
These are just ideas, I'm not sure what else to suggest.

I have discovered that the system-timesyncd service is installed and runs out of the box (on the mangoGT). It's not able to sync for us with the default debian servers due to firewall restrictions. I just needed to put our local ntp servers in /etc/system/timesyncd.conf and it works fine.

Thanks

Are you please able to provide any details about the security concerns?

At this point it will be part of Mango 4.0 which will come out in the next few months. We are currently working towards that release.

I'm thinking now that the problem was with the data point 'MangoES_Disk_Percent_Used'. This fails to import, then all the watch lists, event handlers, etc that are linked to it also fail. It appears this also causes the entire DP hierarchy to fail to load. I believe I'll need to remove all references to this DP from the json file before importing. I understand tha a DP starting 'mangoES' doesn't belong on a GT mango, but there are other points like this (eg MangoES_Disk_Space_Remaining) that seem to be imported OK. Is there something in the import processing that's preventing 'MangoES_Disk_Percent_Used' from being created?

Hi Andrew

I have run into the same issue before, unfortunately, there is no easy way to trigger the generated history. The generate history can be triggered by via the rest API, so you could create a script that monitors the mango PTCP data source, stores the timestamp when it disconnects, then when reconnected, do an API request to start the generate history with the saved time stamp and the reconnected time stamp.
I did not have to go this far when I ran into this issue so I have not attempted the script yet.

We have been asked to interface the mango to a system where another computer buffers the data so unfortunately we can’t poll the device directly.

You cannot do this on the query but you could do it on the update statement for the point. The setting of the SQL data point's value could be done via a Meta or Scripting data source. The help docs on the data source should get you going.

Thanks Philip

Welcome back Andrew! All instances I can recall of instances losing their set times have been battery issues, and could possibly have been that the hwclock -w command was never run, which could be the case if ntp servers were not available at the time of manufacture and when you checked it first. Unless these are particularly old, there should be a primitive script to avoid this issue at /opt/control/saveRTC.sh

It does seem unlikely to be the battery losing contact for some period during shipping, but it is possible.

This is working now. I think the main issue was simply that 'DHCP' needs to be upper case. Other things I noticed were that the script takes about 1 minute to complete, the LED's do NOT go off (even after about an hour) and the mango needs to be rebooted (it does not need a reboot when changing to a fixed IP address).

Hi @andrewh we made the timeouts user configurable. They are on the UI setting page - 0_1575325028770_9ae4069d-b1e9-4bbf-83ba-1c81d44e4af0-image.png