Smart Home Temperature Measurement
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.
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 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.
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.
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 need to be calibrated to get any where near this level of accuracy.
Because of the applications we are using temperature data for, we require a very fast response time (i.e. low latency). A fast response time 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.
We model all of the temperature sensors in our smart home using a
Sensor Java class. This class checks every update against upper and lower limits, which are defined for each sensor in the XML configuration 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
Sensor 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.
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:
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.
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.
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.