SENSEation

The wireless sensor kit presented on this project site is preceded by two iterations. The first iteration was completed before I joined the team. It used Arduino Unos and XBee shields. The sensors were directly soldered to the XBee shields. There were a few different sensor node configurations:

• Air temperature and relative humidity (SHT15)
• Air temperature, relative humidity, and luminosity (SHT15, TSL2561)
• Supply temperature and return temperature (of radiators) (DS18B20)
• Oil flow (pulses), supply temperature, return temperatures and (heating system) (DS18B20)
• Electricity consumption (pulses) (never worked properly)
• Weather station (never worked properly)

The gateway consisted of an Arduino Mega with an XBee shield and an Ethernet Shield for internet access. As a failover measure, the gateway was also equipped with an SD-card and real-time clock for offline logging. The measured data was sent from the sensor nodes to the gateway and from there to an online MySQL database. Although the communication was wireless, all components still relied on cables for power.

Router nodes, which bridged larger distances between sensor nodes and gateway, consisted of an Xbee, which was powered by a mains adapter.

This sensor network was prototyped in a few weeks, deployed in a mixed-use building in Switzerland, and delivered live measurement data. The results can be found here: https://www.sciencedirect.com/science/article/pii/S0306261914006060

Because all sensor nodes and router nodes relied on mains adapter, there was a lot of cable management that needed to be done during installation. Another downside was that for every sensor combination a new Arduino shield needed to be designed.

In summary:

• The sensor network was developed very fast.
• Live measurement data could be collected.
• Limitations: Cables, selection of sensors, relies on on-site internet access

Source: https://www.sciencedirect.com/science/article/pii/S0306261914006060

There are two options for gathering measured data from remote locations: data loggers and sensor networks. Below, I listed my impressions on some of the solutions and their pros and cons. Some of the impressions outlined lead to the decision to start a new wireless sensor framework, and some of the impressions were gathered during the development.

• Academic WSN (e.g., Mica, Telos, Wispes)
  • + Mesh networking
  • + Battery powered
  • + Tested
  • – Seem to be outdated / not active
  • – Not really open source
  • – Small community
  • – Seem to be complicated
    • Meant for electrical engineers
    • Meant for research on wireless networks and not on the measured data
  • – Rather expensive
• Commercial WSN (e.g., Libelium, Advanticsys)
  • + Battery powered
  • + Mesh networking
  • + Flexibility regarding internet access (Libelium)
  • + Flexibility regarding sensor choice (Libelium)
  • + Lots of documentation (Libelium)
  • + Tested
  • – Expensive
  • – Not really open source
• Commercial data loggers (e.g., Testo, Hobo)
  • + Battery operation
  • + Tested
  • – They are data loggers: You only know after the measurement, whether it was successful or not.
  • – Limited selection of sensors from one supplier. You may need products from multiple suppliers
  • – Expensive despite limited functionality
  • Not open source
• Academic data loggers (e.g. OSBSS, Cave Pearl)
  • + Arduino based
  • + Tutorials available
  • + Battery powered
  • – Still in prototyping stage
  • – Not modular
  • – They are data logger (see above)
• Arduino + Shields / Proto-boards (e.g., Arduino, Moteino)
  • + Huge community
  • + Open source
  • + Modular sensor arrangement is possible
  • – Not clear if battery operation is possible
  • – Time for Manufacturing
  • – Still rather expensive
  • – Larger form factor
  • – Not tested
• Custom Arduino based solution
  • + Potentially cheaper
  • + Huge community, since it is based on the Arduino ecosystem
  • + Potentially fast(er) to manufacture (if SMD parts are used)
  • + Potentially small (enough) form factor
  • + Virtually infinite flexibility (if modular)
  • – Risks: reliability, manufacturing

Despite the plethora of papers on WSNs, I could not find a framework that is truly open source and simple enough that I would dare to tinker with it. This led me to think that there is a niche for a simple and modular framework for remote measurements. Although our research field is buildings, I could imagine that it could be used in other fields.

I would like to mention two academic data logger projects, which inspired me to publish our work on GitHub and on hackaday.io:

• The Cave Pearl Project (https://hackaday.io/project/6961-the-cave-pearl-project)
• OSBSS: Open Source Building Science Sensors (http://www.osbss.com/)

Both provide source files, build instructions and tutorials. Check them out!

If there is a modular open-source framework for remote measurements that I am not aware of, let me know in the comments.

Buildings account for about 40% of the primary energy use in the EU and US. The life span of buildings lies between 50 and 100 years. This is why approximately 60% of the current building stock will still be in use by 2050. This means that any endeavor to reduce the energy consumption needs to include buildings, in particular retrofitting of existing buildings.

However with buildings, there is the issue of the performance gap, which occurs when the calculated energy demand differs from the measured energy demand of a building. For building retrofits, the performance gap can be separated into two effects: the prebound effect and the rebound effect. The prebound effect occurs with old buildings that are in need of a refurbishment. There, the energy consumption is usually overestimated, i.e., the actual buildings consume less energy than what the calculation would suggest. The rebound effect appears in new buildings or newly retrofitted buildings. In these cases, the measured energy consumption is usually higher than what the calculation suggests. The reasons for these differences are erroneous assumptions of the building properties, occupants and building systems (e.g., set points, occupancy, material properties, aging of materials, etc.).

These effects lead to imprecise building assessments, which necessitate a large safety factor for retrofit measures.

We argue that visual inspections of the building could be complemented with on-site measurements. With measurements, we can replace estimations needed for the calculations by measuring building parameters and occupant behavior. For this, we developed a wireless sensor kit that can be deployed in occupied buildings to gather information about the actual state of the building.

For more information on the performance gap can be found here.