Just a little thought on your product, great work! I set up a third party modbus device in under an hour, a feat unto itself as I have used many software packages that are much more difficult to setup quantities than this one. keep up the good work
Did you think about integration with XMPP protocol (RFC 3920) ? One application of this protocol is Jabber IM. But this protocol core is REALLY well suited for Automation and M2M. Look at XMPP. It's nice.
In fact, we have been considering using an XMPP implementation to facilitate Mango-to-Mango communication. The idea is for Mango to be able to use another Mango instance as a data source. This approach would also allow anything else that uses XMPP to be a data source as well, but as far as we’re aware there is no equipment that implements anything like it.
MSIE support is planned, but there are issues with the browser that are out of our hands. There is functionality that simply does not work properly for which we have not yet found workarounds. The cases of this are fairly trivial mind you – incorrect z-indexing of charting and change icons being the most “serious” – but they nonetheless exist. Note though that the application to our knowledge works on IE, if you can accept a couple of interface nuisances.
On a related topic, users have asked about how many points Mango can scale to. At this time there have been no definitive stress tests, but the answer depends largely upon the hardware on which the application is deployed. If you have a system of hundreds of points, we estimate that a server with at least 1GHz processor and 1GB RAM should be sufficient. Please note, though, that there are many factors influencing this recommendation including the polling rates being used (for polling protocols), the number of data sources, and the number of event detectors and handlers that are defined.
To help assess whether your deployment is suitable, we will be adding self-monitoring code to the application so that Mango can monitor its own processor load.
Also note that the most performance intensive activity for the application is UI rendering. Even a system with few points may stress if many users are in the watch list or graphical views at once. ("Many" depending, or course, upon your hardware, but we can generalize to, say, 20-50 users.) This is primarily due to the rendering of image charts, so choosing not to use them will relieve much of the load on the system.