Published New Dataset
I have been working very hard on my Depth Exam lately and have not had a chance to post much. Until today, when I decided that I wanted to publicly make available a 2010 dataset of a monitored home for use in research on load disaggregation, NILM (non-intrusinve load monitoring or NIALM), Smart Homes, and AAL (ambient assisted living).
This dataset contains ION6200 power meter and Digi Wall Router ambient light/temperature sensors readings; including weather and daylight data. Sensor readings were collected over a ZigBee wireless network at 15 minute intervals. The following published papers used this dataset: 2011hoa and hoa2012.
You can get this and future datasets from here: https://github.com/smakonin/HomeData
Happy Researching!
Related articles
- Public Data Sets for NIALM (op106phd.blogspot.ca)
Home Occupancy Agent: Occupancy and Sleep Detection
Earlier this month I learnt that I (and co-author Fred Popowich) will have my first journal paper published in the GSTF Journal on Computing in the April/2012 edition (vol 2, no 1). Here is the paper abstract:
Smart homes of the future will have a number of different types of sensors. What types of sensors and how they will be used depends on the behaviour needed from the smart home. Using the sensors to automatically determine if a home is occupied can lead to a wide range of benefits. For example, it could trigger a change in the thermostat setting to save money, or even a change in security monitoring systems. Our prototype Home Occupancy Agent (HOA), which we present in this paper, uses a rule based system that monitors power consumption from meters and ambient light sensor readings in order to determine occupancy. The agent is also able to determine when the occupants are asleep, and thus provide the potential for further energy saving opportunities.
Keywords: Smart Home, Intelligent Agent, Occupancy Detection, Power Consumption, Ambient Light Sensors, Sleep Detection, Energy Conservation, Sustainability.
Keep your eyes peeled as there are a number of other submissions that I am either waiting on review or in the midst of writing. Write on…
Related articles
- The Affect of Lifestyle Factors on Eco-Visualization Design (eco-sustain.org)
Modelling the smart home, sensor data
Today David Lindberg a fellow graduate student and colleague ask, “I need a better picture of the data you’re receiving from the houses. Can you send me your database schema“? David will be looking at modelling tools and developing a model for the home. I though it might be a good idea to take some time and post what I have experienced and some of my opinions.
In my opinion, there are 2 basic data types that 99% of all sensors and actuators use (the other 1% in have not seen yet):
- a relay, like on/off, 1/0, yes/no, open/closed, or high/low;
- or, a setpoint, like a scale or discrete value (e.g. the temperature, the light level).
With sensors you can read these values and with actuators you can set these values. When it comes to reading sensors, there are 2 ways that sensors can be read, and this depends on the function of the sensor:
- continuous and periodic set interval, meters and environmental sensors (temperature, light) are typical examples of this;
- or, event triggered, PIR motion and door/window contacts are typical examples.
An example of how you can read sensors and set actuators would be to trigger a furnace to heat a room. You might place a temperature sensor in a room that is connected to micro-controller or MCU (e.g. an Arduino). The MCU would continuous read a discrete value from the temperature sensor, say once every second. The MCU could also be connected to the furnace (the actuator), say via a relay interface. We then program into the MCU the simple command, “when the temperature is under 21°C set the furnace relay to on, and when the temperature is over 21.5°C set the furnace relay to off”. Note: setting the furnace relay to on would turn the furnace on, and 21°C would be considered a setpoint.
Now if you wanted to store sensor data in a database the most basic table you could create that would store any kind of reading would be:
- the sensor name or ID, this is a unique value and a way to identify one sensor from another;
- the date and time of the reading, it is best to store this in UTC or GMT to avoid daylight savings time change issues;
- the periodic value, the amount since the last periodic reading;
- the instantaneous value, what the sensor’s reading is now.
So what is this periodic value, instantaneous value thing? When and how do I use them? Good questions, I am glad you asked! If we look at power meters, the periodic value would be the amount of Wh (watt-hours) used since the last reading and the instantaneous value would be in W (watts) for the current power level. With temperature sensors there would be no periodic value and the instantaneous value would be the current temperature (in °C, °F, or °K).
I may have more to add later…
