I've referred to our system a bit loosely and also mentioned in the comments of a better way of doing things that we've developed so I'll just clarify this now. Our original system (we're now calling this system 1) was fully wired - and it worked great on the bench! However, installation proved a real challenge as we had to route the cables over the ceiling, adding another unexpected 5m to the length of them. Some of the sensors didn't mind this - the 1-wire protocol used by the DS18B20 temperature sensors coped fine for example. But the I2C communication to the TSL2561 light sensors was intermittent and some of the other sensors seemed a bit less reliable as well.
After a lot of research and trying out some circuits I settled on using a wireless solution from JeeLabs called the JeeNode. I wanted to use an open source solution partly on principle but mainly on very practical grounds. The JeeNodes have a vibrant community of hackers, many experts among them, who are invaluable in getting stuff working quickly. With a closed-source platform you are dependant on the vendors to help you, and they might be busy or just not that bothered. We are also thinking of making our own boards one day and of course, open source hardware makes it explicitly easy to do these things.
Also JeeNodes are a derivative of Arduino, so we could carry on using the libraries and code we'd developed without having to port anything over. The radio side is handled by a well coded library developed by JCW at JeeLabs, and we had good confidence in it. The radio chip used can also be added to a Raspberry Pi with little difficulty or expense, as it uses SPI to communicate. The add-on board we use is tiny and costs only slightly more than the radio module itself, you can see it here plugged directly into the Pi's GPIO pins:
Once we'd got a couple of wireless sensors built the advantages started to really stack up. Most importantly for us was the decoupling of sensors and base station - we could use multiple sensors and not worry about I2C address conflicts, running out of analog pins etc. We can even foresee having multiple redundant sensors and redundant base stations - a Redundant Array of Inexpensive Hardware. If one sensor fails then it can be replaced without affecting the rest of the system - no need for downtime while the new one is wired in.
We're calling this wireless approach system 2 - and we're recommending it for all new projects and systems. The system running in Todmorden that is monitored by the dashboard has a mixture of wired and wireless sensors - you might call it a system 1.5! Hope that helps clarify where we're up to - now on with the hacking!