In the previous parts of this series I described my objectives for and anticipated benefits of my home automation system (part 1), and described the implementation (part 2). Now let’s have a look at which of the anticipated benefits I am really seeing today, after several years of use. I will also share some technical “lessons learned”.
Actual benefits
After >2 years of using the system, I find the following features really useful:
- Lighting control: I find it convenient that the lights turn on automatically when I enter the dark hallway or the dark living room — and it is even more convenient that the lights turn off automatically after a while, saving energy.
- Energy consumption insights:
- In summer, energy cost for “big ticket items” in our home is as follows:
Computers > Heating & hot water > fridge & freezer > washer & dryer
Therefore, if I wanted to reduce our overall energy consumption, I should think about the home server (€10/month) before the washer (€2/month). - In winter, of course, heating is by far the biggest item.
- Electrical energy consumption tracked by home automation power meters attached to “big ticket items” accounts for 46% of total electrical energy consumption.
- In summer, energy cost for “big ticket items” in our home is as follows:
- Peace of mind:
- there has been a couple times where I wondered if I had turned off the iron, after leaving the house. I always relaxed after checking the openHAB dashboard via my smartphone …
- when we go on vacation, we ask friends to water the plants in our home every few days. Checking the motion sensors history remotely, I knew when they had been in the apartment, so I could send them a thank-you email every time — assuming it was them triggering the motion sensors, and not a burglar …
- Calls to action:
- being notified when the washer or dryer has finished a cycle is useful, helps to minimize the time it takes to run a couple of loads of laundry.
- being notified if someone calls the landline phone while I am out is useful, so I can call them from my mobile phone if needed. Not sure this qualifies as “home automation”, but it is convenient, and I get this “for free” using the architecture I set up for home automation purposes.
Lessons learned
Beware of tacit assumptions !
Assumptions about usage patterns that sound plausible may still be wrong in 1% of situations, reducing user satisfaction (read: wife acceptance factor).
The purpose of the hallway light is to light up your path while you walk from room A to room B: sounds plausible. So let’s program the system to turn on the hallway light based on a motion detector, and turn it off again 1 minute later. Works … but only 99% of the time. Then we have guests for dinner, and as they are leaving, and putting on their coats in the hallway, we stand there for a few more minutes chatting – and then we stand in the dark, because the hallway light goes off automatically.
Diagnostics !
In the beginning, some of the wireless sensor nodes would fail unexpectedly or drain the battery too fast.
I developed a logging app that listens to all the MQTT messages sent by the MySensors gateways, stores them in a database, and allows me to browse via a web interface. The database also stores a few pieces of information that I had to enter manually: the location of the node, the date the battery was replaced. This way, I could ask questions like: when did a node send the last message? How many months has it run on this battery? What value types has a node reported?
I also created a convention for what MySensors-based nodes report. Some of it is defined by the MySensors network, such as value types for temperature, window contact, etc. Some of it are my additions:
- Every node reports its battery voltage in millivolts, every 6 hours. This serves as an “I am still alive” indicator, and allows me to track battery voltage over time, and compare multiple sensor nodes of the same type.
- Every node reports a label like “MyWindowSensor”, and the Subversion revision number of the source code, on startup. This information is captured by the logging app mentioned above. In motion sensor #135 the battery voltage drops faster than in sensor #136, why? Oh, sensor #135 is running the old r870 firmware, while sensor #136 is running the newer r1120 firmware.
- The code is liberally sprinkled with printf-style serial output for debugging.
Low power !
Most of the MySensors nodes run from one CR2032 coin cell battery, which typically last for >24 months. I achieved that with some low-power strategies:
- Only power sensor elements while they are being polled — that even applies to the pull-up resistor for a simple window contact
- All printf-style debug output to the serial port is sent only if the node detects that something is actually connected to the serial port. The goal here is not so much to save the CPU cycles (power) for executing these printf instructions, but rather to avoid having to wait for the complete message to be sent before going back to sleep. This is wrapped in a small library, available on Github.
Persistence !
By “persistence”, I don’t mean the will to see a design project through and not despair when you can’t find a bug … although that is required, too. I’m talking about data persistence here. In addition to designing for the good weather use case of “sensor node hums along nicely and reports temperature every hour”, also pay attention to edge cases.
What if a node has to have a new battery, and then restart? Will the home automation controller be confused? This is not an issue for the window contact, which just reports open/closed, but it is an issue for the gas meter sensor – who keeps track of absolute consumption since the beginning of the project, the sensor or the controller or me? What if the home automation controller has to be restarted? Will it re-initialize all data?
Conclusion
Was it worth it? Would I do it again? Yes, and yes. For me, benefits-to-effort ratio of my solution is good. I learned quite a bit about how to build low-power sensors. The hard data on power consumption of appliances corrected some wrong assumptions I had before.
I found it helpful to be clear about my objectives and requirements before building something. I don’t like the approach of “here’s the answer, now let’s find a matching question”. I found it useful to be explicit about requirements for specific features as well as fuzzier “capabilities” for future expansion.
Your thoughts?
Tell me in the comments section what you think about this approach. Do you agree? What would you do differently? What did you do differently in your home automation setup? Let’s start a discussion!