Smart Home Temperature Measurement

In the smart home, temperature sensors can be used for many things:

  • Simply temperature measurement and display, typically to satisfy user curiosity.
  • Heating, ventilation, and air conditioning (HVAC).
  • Safety and early fire detection.
  • Telecare and other health applications.
  • etc.

With this in mind, it makes sense to choose and install temperature sensors that are suitable for use in all these many applications and are not limited to one single purpose or application.

Temperature sensors can only be used for many of these applications if they are reliable, accurate, provide a good resolution, provide timely updates (report all significant temperature changes) and have low latency (fast response time to changes). In many applications this rules out traditional wireless and battery powered sensors as typically implemented as being part of the Internet of Things (IoT).

This feature covers the measurement, capture and analysis of temperature data in our smart home. Our smart home works on the premise that we have at least one temperature sensor in every zone (equivalent to a room in most cases). We take a very similar approach with humidity sensors.

Our Home Control System (HCS) is a single logical entity built using a distributed architecture. It is also a hybrid technology technology solution using technology abstraction to enable it to work independently of the implementation technologies. We currently use many different sensors and three main technologies to capture temperature in our smart home. The use of technology abstraction makes it very easy to add new technologies and remove old ones.

DS1820 1-wire
We use Dallas 1-Wire DS1820. These sensors are cheap (~£1.20 each) but, they require a 1-Wire interface adaptor for each 1-Wire network instance. There can be many sensors on each network though. Typically we use this where it is easy to run cables covering multiple zones. They can be used over a wide temperature range (-55°C to +125°C).

Because of the way these sensors work, they can be mounted in series along a long (many tens of meters) length of cable. Another disadvantage is that they need to be polled and this takes around 750mS per sensor. This level of latency is not really an issue for most applications though.

LM35DZ temperature sensor
LM35DZ sensors are cheap (~£1 each) and provide reasonably good accuracy. They can be used over a wide temperature range (-55°C to +150°C).

Typically we connect these to a slave HCS processor (a Raspberry Pi) using an I2C 8-channel analogue interface board. The length of wire that can be used to connect these sensors is a limiting factor. 3m is about the longest lead length recommended and we tend to use much shorter lengths than this.

Everspring ST814 Z-Wave Temperature and Humidity Sensor
We have various temperature measuring devices connected using our Z-Wave (wireless) mesh network. These are much less configurable in terms of reporting frequency and a design flaw with the MiCasaVerde VeraLite means that only integer values are currently reported. One advantage of this approach is the ability to use Z-Wave association to directly link the sensor and actuator (whilst still collecting the associated events).

These wireless Z-Wave sensors are typically around £35 each.

We are continually looking at other methods to capture temperature and these will be added here soon.

Design Factors

Accuracy & Resolution

We only capture and process temperatures to a resolution of 0.1°C. We can see little point in working with temperatures at a higher resolution in the smart home. At this resolution it is even possible to see the effects of people entering a room after a relatively short period of time but, there is currently no way that our Home Control System (HCS) can infer things like this automatically. There are very few temperature sensors that are accurate to 0.1°C despite many reporting temperatures to two or more decimal places. Temperature sensors also need to be calibrated to get any where near this level of accuracy.

Timeliness & Latency

For pretty much all smart home applications you will need temperature data from sensors in a timely manner. Many require a very fast response time (i.e. low latency). A fast response time can often results in temperature values that oscillate between two values but we have employed an algorithm to implement hysteresis, whilst still maintaining good accuracy and low latency.

Most battery powered sensors have such long latency times that they are effectively useless in detecting fires or for things like heating control. For this reason we have employed a low-cost solution that uses wired sensors with IP network interfaces (typically an Arduino UNO or Raspberry Pi). The key requirements we place on our temperature sensors are typically:

  • Report temperatures with a minimum of 3 seconds between readings. This is effectively in-built rate limiting but our Home Control System (HCS) could handle updates at much higher rates.
  • Report temperatures to 0.1°C resolution.
  • Report temperatures changes >=0.3°C; in real time (assuming 3s since previous update).
  • Report temperature every 15 minutes even if the value hasn't changed.

These simple rules mean that we never need to poll temperature sensors and that they provide a highly accurate and timely view of temperature in any given zone. It also means that updates arrive only when needed and we actually only see quite a small number of updates from a typical sensor each day, because it is only reporting changes.

Modelling & Technology Abstraction

Our technology abstraction means we don't care what phyical technologies are used to implement temperature sensors in our smart home, so long as they deliver the required messages to our Home Control System (HCS) at the right intervals.

We model all of the temperature sensors in our smart home using a Java class. This class checks every update against upper and lower limits, which are defined for each sensor in JSON configuration files for our smart home. This enables advanced features to be implemented (once) and applied to every single temperature sensor, effectively making them all 'smart' sensors. Our Java class monitors actual temperature and the rate of temperature change, both of which are used to improve safety in our smart home, by enabling rapid detection of excessive heat sources or fire.

An integral feature of our Home Control System (HCS) is the capability to monitor performance and usage. This data is exposed along with all temperature data discussed here for individual sensors and zones. This includes last update times, maximum and minimum values, zone averages, etc. These are all exposed via a multi-purpose query interface.

Example Implementations

Airing Cupboard

Fibaro Universal Sensor
We were are using a Fibaro Universal Sensor with three DS1820 sensors in our airing cupboard to measure water temperatures in our hot water tank at various heights to assess the hot water capacity.

This is one of the scenarios that proved Z-Wave latency is too high to be useful for this type of application, so we now have the same DS1820 sensors connected to an Arduino UNO.


This is the raw log data from our Home Control System (HCS) over a 24-hour period on 24th November 2013. It has been filtered to show only the events captured for the temperature sensor in our study. It was captured using a LM35DZ connected via I2C to a Raspberry Pi.

- 00:00:00 Study Temperature = 17.4
- 00:17:57 Study Temperature = 17.0 : 26m34s
- 00:59:19 Study Temperature = 16.7 : 41m21s
- 01:41:46 Study Temperature = 16.4 : 42m27s
- 02:45:27 Study Temperature = 16.0 : 1h3m40s
- 03:33:49 Study Temperature = 15.7 : 48m22s
- 04:46:34 Study Temperature = 15.3 : 1h12m44s
- 05:45:12 Study Temperature = 15.0 : 58m38s
- 06:25:17 Study Temperature = 14.6 : 40m5s
- 06:25:28 Study Temperature = 14.9 : 11s
- 06:25:59 Study Temperature = 14.6 : 30s
- 06:26:04 Study Temperature = 14.9 : 5s
- 07:16:50 Study Temperature = 15.3 : 50m45s
- 07:17:23 Study Temperature = 15.0 : 32s
- 07:17:25 Study Temperature = 15.3 : 2s
- 08:29:51 Study Temperature = 15.7 : 1h12m25s
- 09:10:18 Study Temperature = 16.0 : 40m26s
- 09:38:17 Study Temperature = 16.3 : 27m59s
- 10:07:28 Study Temperature = 16.6 : 29m10s
- 10:33:54 Study Temperature = 17.0 : 26m25s
- 10:53:19 Study Temperature = 17.3 : 19m25s
- 11:05:47 Study Temperature = 17.6 : 12m27s
- 11:49:01 Study Temperature = 18.0 : 43m14s
- 11:57:41 Study Temperature = 18.3 : 8m39s
- 11:59:22 Study Temperature = 18.6 : 1m41s
- 12:21:08 Study Temperature = 19.0 : 21m45s
- 12:29:11 Study Temperature = 19.3 : 8m3s
- 12:34:33 Study Temperature = 19.6 : 5m21s
- 13:35:53 Study Temperature = 19.3 : 1h1m20s
- 13:37:49 Study Temperature = 19.6 : 1m55s
- 13:37:52 Study Temperature = 19.3 : 2s
- 13:38:08 Study Temperature = 19.6 : 16s
- 13:38:28 Study Temperature = 19.3 : 19s
- 13:38:41 Study Temperature = 19.6 : 13s
- 13:38:47 Study Temperature = 19.3 : 5s
- 13:38:50 Study Temperature = 19.6 : 2s
- 15:18:29 Study Temperature = 19.3 : 1h39m39s
- 15:21:47 Study Temperature = 19.6 : 3m17s
- 15:30:04 Study Temperature = 19.3 : 8m17s
- 15:53:48 Study Temperature = 19.6 : 23m43s
- 16:06:54 Study Temperature = 19.3 : 13m6s
- 16:25:02 Study Temperature = 19.0 : 18m8s
- 16:45:28 Study Temperature = 19.3 : 20m25s
- 17:08:58 Study Temperature = 19.0 : 23m29s
- 17:37:05 Study Temperature = 18.7 : 28m7s
- 17:40:15 Study Temperature = 19.0 : 3m9s
- 18:20:31 Study Temperature = 19.3 : 40m15s
- 18:44:50 Study Temperature = 19.0 : 24m19s
- 18:45:07 Study Temperature = 19.3 : 16s
- 18:57:09 Study Temperature = 19.6 : 12m2s
- 18:59:43 Study Temperature = 19.3 : 2m33s
- 19:02:39 Study Temperature = 19.6 : 2m55s
- 19:08:28 Study Temperature = 19.3 : 5m49s
- 19:10:26 Study Temperature = 19.6 : 1m58s
- 19:30:33 Study Temperature = 20.0 : 20m6s
- 19:55:09 Study Temperature = 20.3 : 24m35s
- 20:47:19 Study Temperature = 20.0 : 52m10s
- 20:57:46 Study Temperature = 19.7 : 10m26s
- 21:24:47 Study Temperature = 19.4 : 27m1s
- 21:58:11 Study Temperature = 19.0 : 33m23s
- 22:37:18 Study Temperature = 18.7 : 39m7s
- 22:55:04 Study Temperature = 19.0 : 17m46s
- 23:04:39 Study Temperature = 19.3 : 9m34s
- 23:34:17 Study Temperature = 19.0 : 29m38s
- 23:44:24 Study Temperature = 18.7 : 10m7s
- 23:50:44 Study Temperature = 18.4 : 6m19s
- 23:59:52 Study Temperature = 18.4

This following graph shows this data plotted as a scatter graph with temperature against time:

24hr graph

We force all temperature data to be logged at 00:00:00 and 23:59:59, to ensure graphs like this cover the full 24-hour period. This enables a consistent graph to be created covering periods that cross days and longer time periods, such as month.

Our approach enables a whole days data to recorded accurately with just 67 data points in this example 24-hour period. This is achieved by the slave HCS processor collecting and analysing the data locally and then only sending an event if the temperature has changed by more than 0.3°C. This has proved an very efficient way to maintain low latency and high accuracy, whilst effectively compressing the data set down to a low number of events. Despite this, there is still some natural temperature oscillation visible from about noon to around 3pm.

Smallest time period in the above data is just 2 seconds, which shows how quick the response time can be. In reality our system can detect changes even faster than this. We now enforce updates to be at least 3 seconds apart.

There is more insight to be gained from this graph and data, than we have space to go into in detail here! The bottom line is that such data enables us to understand how our smart home is working and thus improve it.


We have three temperature sensors in our smart conservatory and one that is connected to the conservatory slave HCS processor to the outside (garden). We also have a humidity sensor in the conservatory.

These three sensors allow a local slave HCS processor to determine the temperature gradient from floor to ceiling and to then operate the ceiling fan accordingly. We have a 3-speed ceiling fan at the moment but, we are investigating variable speed control.

We are also looking at a much more advanced set of climate control features in this room. This includes occupancy and presence to ensure the fan only spins at a slow speed when the room is occupied (it can blow a gale!).



We model all sensors in our smart home using a Sensor Java class. This class validates updates and checks them against individual upper and lower limits defined in the XML configuration file for each zone. If either limit is breached, an alerts is generated by the sensor. This basically turns every temperature sensor in our home into a fire alarm. Each sensor can result in a voice announcement, SMS message, alarm sounding, etc.

You can see from the above log data that our Sensor class also records a duration since last update for temperature update. This enables it to calculate the rate at which the temperature is rising or falling. As part of our monitoring we have captured the maximum temperature rises that occur naturally in each zone and used this to set a valid threshold value, above which we can assume action needs to be taken.

This value is set on a per zone basis, to handle the variable rate at which the temperature rises in different types of zone. For example, when our Fisher Fury R1 kitcar is parked in the garage after a drive, the residual heat from the engine causes the temperature in the garage to rise significantly and at faster rate than we would ever see inside our home.

Climate Control

The primary application for these temperature sensors is intelligent climate control, which is also linked to the humidity sensors in our smart home.

Future Stuff

As part of our query interface capability, we will implement the ability to track the mean (average), maximum and minimum temperature for each zone. This is based on the principle that we have more than one temperature sensor in most zones.

Share ...
We are on ...
Facebook Twitter
YouTube Flickr Follow us on Pinterest