They're will be (and are) lot's of this sort of thing coming together and it's about time ( looks wistfully at DTI proposal way back in 1995 doing this way way back then
)
The real issue is an easily exchangeable data packet with some form of generalized definition of what the data is all about.
If I would comment on one aspect that I believe is important it is the complete decoupling of the measurement side of the system and the reactive element.
If you collect data you should only publish that without any facility to modify settings of the system. This is good to do in a webby sort of way but any publishing mechanism will suffice. Very good from a security model because you can enforce any rules you wish for who can see what, safe in the knowledge the system can't do any direct damage if it is compromised. There are some excellent Frameworks that make this sort of application pretty secure and mean that database access is handled by something reasonably solid.For what it's worth, I use django and it seems to be interfacing to all kinds of interesting things in this regard. It also maintains the tables for you in a reasonably friendly way which save many hours of sweating over a hot SQL editor.
That set of data is 'watched' by your very secure management element which reacts to it's own local configurations and any particular lump of published data it may have access to, be it your own or other sources ( the air temperature and pressure upwind of you for instance), and it controls your pumps etc via any appropriate mechanism that seems fit for purpose, (One wire, X-10, ZigBee, C-Bus, home built hairy box of wires, proprietary protocol, or whatever).
Now getting an acceptable standard to work in that way is the real problem cos everyone will suggest their system is the one all the others should standardize on and that's a row that can run and run to no great benefit except within islands of standards zealots, which ain't beneficial.
To that end just keeping a list of possible systems is going to be nightmare and that's before you even begin to get into generalized system description stuff.
But as long as we actively welcome competitors then this could be avoided. There will be a strong desire to control this sort of thing but really that is impossible and as long as people write code that they will interface to something better when they recognize it as such when it appears then that should address it.
Reliability is of great importance and also the modes of failure. The UPS is as much an active component of your system as the central heating pump, it would be galling to have both the above components in place, if when the power failed, one couldn't power the other without moving wires in the dark, your reactive controller must recognize that sort of event and respond sensibly, and of course the testing of such a system is going to be long and laborious.
Little microcontrollers do this stuff well and as long as you don't get power crazed into thinking everything needs a GUI it should be pretty simple.
Quite how it's accessed is moot It's tempting to give it a web interface but the how much might you trust a TCP/IP stack without decent security?
Perhaps it can get over http but only be modified over RS232, Many people will have different views, and some will be fairly vociferous about it.
As has been said discussion, here, has been ongoing and as such is as good a place as any to chat about this, people will be understandably cagey about some aspects, and that really is up to them, we can't make anybody do anything, it's they're system but if we can get to a stage where we could make comparative measurements of one or two basic components the issue of chocolate teapots, for example, can become an interesting discussion between a journalist and a computer, rather than having to involve layers of opinion with varying degrees of bias down the tree.
Quite how useful we find such a system might be could really take our breath away when we look back at it in about ten years time.
