|
Just a tought, but could the 1-wire module be created as a plug-in? Or any other "reader" module for that matter?
It would require to change Cumulus, and forces Steve to create some kind of API between his work and others, but that way, one could create an interface for any kind of sensor of any brand, as long as it would be supported.
The "support" would be as simple as values and type of unit to display the data. The source itself would be of no importance because it would be handled by the reader.
want to add 1-wire?
Create a "reader" that sends :
bedroom, 1,value, unit
where
"bedroom" is the id of the sensor
1 is the type of reading (say 1 is a temperature)
value is the read value by the plug-in
unit of the reading (metric / english, others)
Type of reading could be 1=temperature, 2=humidity, 3=corrected pressure, 4=uncorrected pressure, etc
The unit item is also interesting, because some sensors only output in one unit (say output is only F) while the user can want celcius. A unit converter can be build in easily.
Those data should of course wrapped in a XML form, but it is still easy to create on the sending end, and easy to parse on the receiving end
Steve could decide on the standards he wants to use concerning the type of reading, the units, and publish them. If someone wants to send some new kind of data (say, water level in the rain collector cistern), he asks Steve to accept some new type of reading and how to handle that data. A new version can be compiled and released quickly, because only small changes were needed to add the data from that new reader.
for example,this cistern reader could send ["cistern",5,134,"mm"] and be handled as mm of rain (data type 5)
The API used could be as simple as a web service interface, which receive "put" HTTP calls, very easy to do. It would also allow to extend the source of the readings, such as computers across half the planet, that can do HTTP calls via the internet. If you go the .NET way, it's fairly well explain how to do it as web service comes as a library for visual studio (System.Web.Services).
Web services are also easyer on the programmers, because they can use a language they want as long as it supports web services, which is all "modern" language on almost all platforms.
The software doing the PUTs could be running in the same computer as the cumulus software, across the house, or even across the planet. Distributed weather readings... talk about "cloud computing" for a weather software!
On a more vague future, web services included into Cumulus could also be used to send data to specialized software (in fact, the special software would GET the data from Cumulus) that would do special tasks, such as special displays, database inserts, and such.
I understand that this post is quite long and technical (sorry, this is my day job!) But is it very far from me to decide which way Cumulus should go. But going this way would allow for more people to create "readers" for Cumulus while Steve only have to manage the incomming data, not the way to obtain it. For a guy with not enough time, that could be a way to distribute the work without letting the source out of his computer.
Spou
|
Login 
Register
Enhancement requests
Search
. In fact I think I might have known that already, from being asked some time ago.
