Quote:
Originally Posted by linuxworks /img/forum/go_quote.gif
that reminds me, one possible thing to do with 'gathered information' is to send it to a pc, somewhere. suppose you wanted to get a graph of simultaneous (ie, time matched) sensor readings of rail voltage, bias voltage, heatsink temperature, powerOn-time and maybe even volume level. those are a bunch of collected 'data points'. the ard can't keep all that locally (for long) and so if you are into data collection or need to watch things for debugging, you want that up on some host or pc.
a wireless link is kind of neat there are these xbee modules that have arduino drivers. you can create a pt-pt tunnel between arduinos and other arduinos or even pc's. if one endpoint is the pc, then it can store the logged data. import into a spreadsheet and go nuts
|
On the "enterprise class monitoring" side of things, I hope there is the ability to have some meta data, so that these things, the sensors/actuators can become self describing.
e.g. query for attributes that give, say, name, type, range?, and operations/methods - something like the java bean api, for example.
That way you could have a generic web/java/c# app for *any* device that implemented the API/Protocol, and as you add new capabilities to the device, the client app could recognize them, *with no additional work required*
You can still write custom apps using the API to some up with a "pretty" remote UI for the device (from an iPhone, nokia770 or other browser, say),
Sample attributes to display on historical trend graphs. Alert on out of band/range values. etc etc
All this can be done external to the device, as long as there is some generic way of getting the data out of the device, on request ( getValue(AttributeName) , say) , or setting an attribute value, or performing an operation remotely.
What say you?
This is the sort of thing I'd be interested in, and would be willing to help with.
*edit* - *Aha!*
Define the API/Protocol, then you can write adapters to the component model of you choice ...
e.g. write an adapter (only needs to be done once) to make the device appear as a JMX/java bean, then you can monitor/control it by jconsole out of the box, or plug it into any bean aware framework ...
Same approach works for any other component based framework ..., JMX, SNMP, etc
REST based web interface, etc etc