For the past couple of months, I've been developing a data acquisition product for a client. It's turning out very well. I can't share the code, alas, but I can share the design approach and speak, in particular, to the way Web2py has turned out to be a huge asset.
This is a 100% pure python system (ok, 99.9% because I use a shell script to launch it). It supports multiple instances of two different remote sensor modules. One is a wireless product from Synapse Wireless<http://synapse-wireless.com>. The other is from LabJack <http://labjack.com> and is tethered to a USB cable. The interesting thing about these products is that they both support a pure python programming interface. Admittedly, the python running on the Synapse radio chips is somewhat crippled -- no lists or dictionaries -- but it's still python and perfectly suited to the tasks that need to be performed including directly reading and writing chip registers. What's very cool about these products is the way they've implemented a self-organizing wireless mesh with rpc calls and callbacks for communication on very low cost hardware. On the host computer end of things, python2.5, 2.6, and 2.7 are supported by single library that enables the host to act like a node in the wireless network. The LabJack system is more conventional. Their python library is free of charge, well-documented, and just works. The entire system, then, consists of an inexpensive netbox (intel Atom based) running Linux, plus one or more of the Synapse and/or LabJack modules as needed for the monitoring requirement of a particular deployment site. So where does web2py fit in? First, it provides a configuration interface so that installers don't have to tote a monitor and keyboard around. Any laptop, tablet, or smartphone that has a browser can communicate with the netbox. Second, and this where, IMO, Web2py really shines, I'm using web2py -S to run the processes that collect the data, stuff it into a db table, perform analyses, and send the results out over the internet. Third, the same instance of web2py that provides configuration also provides a locally accessible interface with information about system performance, etc. The overall system architecture is (cloud) < -- HOST | < -- RF -- > Wireless Synapse network | < -- USB -- > LabJack sensor module Within the host, all the work is done by 5 python processes: 1. web2py.py ==> The application including the configuration and user interfaces. 2. web2py.py -S data_handler.py ==> Loops, reading sensor data from a named pipe, converts it, stores in db. 3. (fork of) web2py -S data_handler.py ==> data analysis, reports and chores. 4. python synapse_interface.py ==> Gathers incoming wireless data reports, pickles them, and writes to the named pipe. 5. python labjack_interface.py ==> Same as 4, only for labjack reports coming in over USB. So far we have about 40 of these systems deployed at customer sites and expect to deploy thousands in the next couple of years. Did I mention it's all python :-). The gain in productivity is quite significant. This is, so far, a one developer project and it's a huge advantage not to have to code to different interfaces in different languages. There will, obviously, come a time in the product life cycle when hardware costs need to be minimized. I'm hoping that the ever-falling cost of compute power will allow us to stay with the web2py & python architecture, but even if not, the early flexibility will have allowed us to get the product features right for the market before having to re-code it all in C on a cheaper host board. Cheers, Mike P.S. For those who care about such things, there are strong rumors<http://www.eetimes.com/electronics-blogs/other/4217521/Google-s-Android-Home---The-plot-thickens-> that Synapse's technology will be a key component of Android@Home.
