Thanks for your interest.
Let me provide some more detail.
In our initial design, we opted not to use Mango for any control. We instead use a specific, purpose-built controller from the battery inverter manufacturer. The operation of the station is obviously quite complex (especially when you get down to the power flow stuff) and the controller has to interface with the inverters and batteries via CAN and issue very fast and complex/proprietary commands. It just wouldn't be appropriate to even try to use Mango for this application.
Instead, Mango is used for monitoring only. This way, if the server crashes or locks up for some reason, the autonomy of the station is not compromised. The MangoES box polls and logs data from all the station devices (PLCs, protection breakers, battery inverters, battery controllers, PV inverters, diesel generators, weather instruments, panel instruments) , and then we use the Persistent TCP module to a few hundred of these data points to our main Mango server via VPN (we have two redundant internet links with auto failover).
Technicians in our office are therefore able to log into the MangoES box and view any of the 1,300 monitored values in real time, which has proved to be incredibly valuable. We also use DGLux to display some really nice graphics of what the station is doing, which we display in our office.
Visitors are, without exception, impressed by this! We also provide our end customer with access to these dashboards, and I cant imagine them having a better source of data about the performance of their system.
So the original scope for the MangoES did not include using it for control. However, since Mango is 'plumbed in' to every controller and system on the station, some interesting possibilities have arisen since we commissioned the station.
For example we had a minor issue (a result of a bug in the firmware from the battery manufacturer, basically - which they later fixed for us) that had the effect of overheating our battery inverters to the point of shutdown.
Because Mango had access to all of these devices, we were able to write a script that detected when this condition was about to occur using one set of sensors, and then issued instructions to another bit of hardware in order to slow the overheating.
So we did not have to fly an engineer 1000km+ to site to fix the problem - instead we implemented the workaround over a morning coffee!
As the station continues to operate, we do occasionally find that we have unexpected needs. For example we found that a piece of hardware needed power cycling every so often - a relay hooked into our PLC, controlled by Mango, gives us an easy way to do this manually. At some point in the future, I will set Mango up to watch for a 'no change' condition on a data point from the troublesome device to power cycle it automatically.
We also found, a month or two after commissioning, that we had a need to monitor the voltage of our 24V DC supply (which is backed up by batteries). We were able to implement this by reading the DC input voltage of a piece of networking equipment, using the SNMP module! Again, huge expense saved.
Once I figured out I could do that, I also used Mango to detect - and create alarms - for the dual internet setup, which warns me if one has failed.
Of course, Mango is also a great way to receive alarms when various conditions are detected, such as breakers tripping or equipment showing faults, using the standard event detector and email action. We send emails using a 3rd party transactional email service (sendgrid) so as to ensure prompt and reliable delivery.
Feel free to ask further questions.