Home Automation (HA) using ubiworx™.
Home Automation (HA) is a topic of major interest to many of us. Even Mark Zuckerberg has been getting involved recently with a project to build a simple AI to run his home inspired by Jarvis in Iron Man. He notes “For assistants like Jarvis to be able to control everything in homes for more people, we need more devices to be connected and the industry needs to develop common APIs and standards for the devices to talk to each other”. That’s exactly where ubiworx can help by providing a common API to access a heterogeneous mix of proprietary devices and protocols.
The technology already exists today to automate most of the systems in our homes but our choices are often limited to a few proprietary point solutions that don’t interoperate with each other. What I’d like to build is a single cohesive system where all the systems can contribute to the overall logic. I’ll look at a few examples in this article of systems connected together using ubiworx.
One of the most common systems in our homes that we want to automate is our heating system. Some people are content to buy a proprietary boiler controller or even just to install a few radiator TRVs but some of us would like to have more control than that. What features do we need from a HA heating control system? Scheduling is obviously one. Being able to select when and on what days the system is active is a basic requirement. Zoned temperature control is a must as well, with perhaps input from room occupancy sensors being a nice to have. Being able to read and compare multiple thermostats would be good. Remote monitoring and control would be nice. Historical trend graphs would be interesting to see. Finally, the ability to analyse the data to determine things like temperature climb and fall rates to predict how far in advance to being heating, pro-actively monitoring boiler efficiency, counting run hours to predict when the boiler will need a service, receiving alerts when wireless thermostat batteries need changing and so on would be cool too. Happily, all of these are easily achievable with an IoT system based on our company’s ubiworx™ IoT framework. The sky is the limit with possibilities, including things like AI learning when we get up or go to sleep and when the house is occupied or unoccupied, but I’m limiting the scope to basic control for now.
Another very common goal for HA is lighting control. Again here we are looking for scheduling, but also occupancy and adaptability to external influences like sunrise and sunset times. I’ll cover that use case here as well.
As with my other projects, while it is a bit of fun, I am using it to demonstrate some key advantages of using ubiworx such as not having to write any code (even though for some people that is actually a disadvantage!). ubiworx is very modular and extensible, and you can add on support for any sensor you want, but for most use cases you just can configure it out of the box which is a great way to rapidly develop an IoT solution. In addition, the web UI allows dynamic creation and tuning of logic rules to be executed by the gateway without ever having to physically access the gateway.
Hardware
I built my HA system using an UP Board [http://www.up-board.org]. This is a very powerful and cost effective embedded system (SBC) that has a quad core Atom x5 CPU. You could also use a raspberry-pi, beagle bone, old laptop or desktop or pretty much any system that can run Debian or Ubuntu Linux.
My UP Board also controls lighting schedules and access control so being able to do it all in one system is very useful.
For temperature control I used Oregon Scientific THGR810 thermometer and humidity sensors. These powerful battery operated thermometers are very accurate and have excellent battery life. I’ve had some of them running now for over a year and haven’t changed a battery yet. To read these I used an RFXCOM RFXtrx433E USB controller. This powerful device is a 433MHz transceiver that ubiworx can interact with over USB.
For PIR sensors, I used a couple of Home Easy HE861 Passive Infra-Red (PIR) sensors. Again, these are read by the RFXCOM.
Finally, you need to have Smart Plugs. You could wire up relays like the TOSR04 but Smart Plugs are safer and more flexible. There are many of these on the market, the Belkin WeMo being one common example. The features to look for in a Smart Plug are first, obviously, the ability to remotely switch an appliance on and off. It may also incorporate metering to remotely measure how much power each appliance is using and is cumulatively using over time. Connectivity could be WiFi, which has the advantage of not requiring any additional transceivers, or it could be another wireless protocol like LightwaveRF which uses the 433MHz frequency. PowerLine Communication (PLC) seems to me an obvious choice but I haven’t seen many of these. Finally, it should be as cheap as possible as you will need a number of these. I’m using the Kankun KK-SP3 plug which is a basic WiFi connected smart plug without any metering capability but it is very cheap. It uses a proprietary protocol and Smartphone app, but it runs OpenWrt and it has a default root password! WiFi means you can connect to them over your existing home WiFi without any extra hardware. They can even be in another location entirely. You could have a lamp on your desk that comes on whenever your boiler at home is on. I’ve no idea why you’d want to do that, but you could!
Software
The software is Emutex ubiworx 0.9.2 which was released in November 2016. I didn't have to write any code for this project - just connect existing blocks using the web UI interface. The first devices I set up was the RFXCOM devices. I set this to discover mode to find the THGR810s and the PIR sensors for me. ubiworx's discover mode creates new sensors as it finds them. The THGR810 temperature sensor reports about once a minute so after a short wait each one appeared. I installed the 0.9.1 agent on each of the Kankun plugs and named them plug1 through plug8. After that, it was simply a matter of creating rules for them to interact.
Temperature Sensors
The THGR810 is easily mounted to any vertical service or can be left free-standing. Here is one I mounted in my kitchen, directly over the existing wireless heating control. Having both in the same location allows me to make a direct comparison to check the accuracy of the new one. First impressions are very good. It reports temperature to 0.1 degrees centigrade as opposed to the 0.5 degrees of the Veissman controller.
Once the RFXCOM sensor is set to discover, each THGR810 device that is seen will cause new sensors to be created in the ubiworx dashboard. Each THGR810 actually appears as four sensors: temperature, humidity, signal strength and battery level. Each unit has a unique 16-bit id which will appear as part of its unique id. Since the value reported to ubiworx matches the value displayed on the LCD screen, it’s reasonably straightforward to figure out which one is which.
Once they have been identified you can rename them to have more meaningful names by editing the “Name” field. The unique id remains the same, but the Name is what appears in rules and so on. I went with “Kitchen”, “Bedroom” and “Garage” as well as leaving one unassigned for now. I am not monitoring battery levels or signal strengths at the moment, though in time generating an email alert when batteries need to be changed would be very useful.
Boiler Control
Most central heating boilers have a mains voltage input connector to enable heat. This is in addition the mains power supply and is used to switch on the boiler when heat is needed. It may come from a traditional boiler time clock or from a wired or wireless thermostat. This is the input we need to be able to switch with our HA heating control system.
Many buildings also have different zones (upstairs, downstairs, etc.) controlled by a motorised valve (MV). Each motorised valve can be opened by applying mains voltage to them and then they revert back to closed when the input voltage is switched off. Each MV also has a contactor which closes when the valve is opened. To control a zoned heating system, we actually control the MVs, not the boiler. We can then wire the contactors from each of the MVs in parallel to a mains source on one side and to the boiler switch input on the other side. Then if any MV opens, it will switch live to the boiler input and cause the boiler to start heating. If all MVs are closed, the boiler switches off.
There are a number of ways to handle mains voltage switching. One way is to wire up a relay board such as a TOSR04 and connect to your HA gateway using USB. Another is to use a smart plug and to wire a plug to the MV motor, which is what I did. It also makes it more flexible, since I can easily bypass the smart plug by plugging directly into an unswitched mains socket, or to revert to the old control system in case I mess up anything and I need time to fix it, but preferably not in a cold house while I’m fixing it!
Here is how I set it up. The wiring needs to be tidied up but hopefully you get the idea. The two sockets on top are permanently on. Into each of these I put a Kankun plug - left is upstairs, right is downstairs. Into this I plugged the two MVs. Below that are some terminal blocks where I wired the MV contactors together. Below that again are the legacy zone heating controls. One a Sunvic and the other a Veissman module. Below that again are two more sockets. These sockets are switched by the controllers above them. This lets me unplug a MV from the new system and plug it into the old system at any time (just in case!) without any rewiring.
To control the outside light, I am again using Kankun plugs. These socket are very small and accept any plug but unfortunately the ones I got have Chinese mains pins. The vendor I used kindly included Chinese to UK adapters though. Since these plugs are gateways in their own right, they can be independently managed and monitored. Also, you can use their relay functionality as a remote actuator in our logic which is a good demonstration of how we can create interactions between gateways that are running ubiworx. You can even create interactions at different locations and in different WiFi zones if we want to so long as each location is connected to the internet.
Rules Logic
The screenshots below shows the logic I used. I created a tag called “heat-time” which is driven by three schedule blocks, one for morning, one for evening and one for weekends. These are OR’d together so any one of them enables heat. You can see in the right hand pane the configuration for the morning schedule is from 6:00 to 7:30 every weekday.
The zone controls are simply a comparison between a set temperature and the current temperature AND’d with the heat enable “heat-time” tag. The output of this logic creates a tag called “heat-zone-upstairs”.
The “heat-zone-upstairs” tag drives a remote actuator. For a remote actuator, you need to give it the name of the actuator (which is simply “relay” on the Kankun plug) and the name of the remote device (“plug4” in this case). The remote device can be anywhere on the internet, but for obvious security reasons you can only control devices with the same vendor id.
Once everything has been running for a while, you can start to look at trends to see how the system is doing. In the graph beow, I can see temperature falling during the night from 19.5 degrees to 17.6 degrees and then beginning to rise again from 5:10am as the heating comes on.
If we want to automatically calculate the rate of change of temperature, that’s pretty easy to do. We simply drop a “delta” rule block into our logic and tell it over how many intervals we would like to calculate. The delta block, like most rule blocks, is event driven not time driven. So it will change its output whenever its input changes. Since the THGR810 updates don’t happen exactly at one minute intervals (its about 50 seconds or so) I have added a “resample” block to update the output at precisely one minute intervals. Since I’m going with minutes, I’ve set the delta block to be 60 elements deep to give me an hourly rate of change.
From the tag “rate-temp-bedroom” I can then create a virtual sensor which reports the value of this tag once a minute to the cloud. From the dashboard I can then plot the range of values. Knowing how many quickly my room heats up or cools down in degrees per hour will let me do some clever tricks such as knowing how far in advance to turn on the heating to reach a given temperature by a given time.
Lighting Control
One enhancement that I have also made to my HA system since my last post has been to add sunset and sunrise timers to my outside lights. This is a new feature in ubiworx 0.9.2. There are various system tags that contain values that you can query from your rules logic and two of these are $SUNSET and $SUNRISE. Assuming you have entered your latitude and longitude correctly on your device dashboard, these values will contain the exact time the sun sets and rises each day. Building logic to control outside lights using these is far more useful than using fixed timers which have to be adjusted regularly in spring and autumn. I also combined them with a rule to turn off at night. No point in having everywhere lit up when we’re all asleep. I also use sunset and sunrise timers to control indoor lights as well. The hall light is set to come on 15 minutes before sunset and off at 23:30 for example.
I want to use the PIR sensors for occupancy sensing in the garage. Both to detect when someone is attempting to “borrow” my tools but also to activate the lights to save me fumbling in the dark for the light switch. However, SWMBO decided that an outside light where she parks was more important so that took priority. I used the home easy HE861 wireless battery powered all weather sensor to detect motion. Because this unit has no wires, it offers great flexibility in its location and doesn’t need to be mounted near the actual light it is controlling. So I put it on the opposite wall to the house so it can “see” motion from either the back of the house or the front.
Summary and Future Enhancements
Total setup time was about 2 hours, and most of that was wiring. Setting up the logic in ubiworx took 10 minutes. Many IoT frameworks require significant amounts of Python other scripting language code to be developed. This is ok for a prototype but clearly needs to be redeveloped and carefully validate before production. ubiworx has been carefully validated and is maintained by a team of professional software engineers so no need for that here.
I have a few enhancements in mind when I get time. I could use the measured temperature rise time to calculate when to turn on the heating to have the house at the desired temperature by the desired time. I can use occupancy sensors to detect when the house is empty to lower the temperature. I could even add geo-fencing to lower the temperature if I am more than a certain distance away by having my phone report its location to ubiworx.
For lighting, I could create overlapping pools of lights so that one sensor brings in a number of lights near it. This would allow me to move through zones around the house and ensure I the area I am in is always lit as I move around. This is only possible with inter connected lighting and sensors so is another interesting use case. Using the accumulator block in the graphical logic will allow me to count the total number of hours of use each light has. I could use this to calculate the running cost and see if I can justify swapping the halogens for LEDs. Or I can see if some lights get a lot more usage than others. I could even check how many hours I get from a single bulb to see if the manufacturer’s claims are accurate.
I have also started looking at dashboard solutions to give me a single page to view and control everything. One solution that is very interesting is freeboard.io. This service allows me to drag and drop widgets and connect them to the ubiworx API. It will need some coding to do actuators but I am hopeful I can add thermostats and switches and so on.
Other aspects for HA that I haven’t covered here might include air conditioning control (similar problem to heating), coffee pot control (another use case for smart plugs), load scheduling (another), automatic blinds, garage door openers, pet feeders, and so on. Then just hook it up to Mark Zuckerberg’s Jarvis project to get voice control, facial recognition, AI and we have the ultimate smart house. There is pretty much an endless list of what could be done. Just need to do them one at a time!