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.

When you finally have to login you're using a hidden field and that's good. Any way, not having a hidden field when creating the account is a problem: some one can see over your shoulder and remeber your password. Is a security risk.

Do you have a public Issue tracker and version control system? Someghing like trac or suversion? It would be cool to submit bugs.

Please note that Serotonin has limited resources for completely testing various browser and platform combinations. The only browser that we can "officially support" is Firefox, which is what is nearly exclusively used for Mango development.

Let's say that other browsers like Safari are "unofficially supported", meaning that we are happy to hear reports of ways in which they do not work, but cannot guarantee that any such problems will be fixed promptly, if at all.

Browser requirements for the next version have been substantially relaxed.

Sadly, i can't test the 1-wire problem with Chrome at the moment. Can anyone else reproduce this?

Hi Mino,

This is a bug. A fix will be included in 1.8.2.

Thanks, bumpig the update period out to 10 seconds fixed it.

Ta Zap.

Doesn't matter much. Anyone that can get to the page can just view the source and see the password. Otherwise, you're just balancing the threat of someone looking over your shoulder with the nuisance of not being able to see what you're doing.

Thanks. I know I did it once--I just installed Mango a couple of days ago--but forgot how to get there.

I'll get used to the UI navigation.

BTW, nice work.

Data source function and browser viewing are completely different. How are you determining that polling has stopped when you close your browser?

Try running Firebug. Are you getting a script error on the page?

@mlohbihler said:

The application landscape is constantly changing. We may, in fact, forego such development and just build integration with a product such as Lightstreamer instead.

Maybe you should look into the upcoming HTML 5 WebSockets and software that already offers implementations that can emulate it if not yet supported.

Some pointers are:
http://www.kaazing.org/confluence/display/KAAZING/Home
and
http://www.orbited.org/

thefixer said:

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

The same thought for me.

Not sure, but i'm assuming for now that it is a Dojo thing. It's possible that there's an API fix for this, but the documentation is wanting.

Great I'll look forward to it

thanks

keith

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.