AUTOMATION
As I have mentioned several places across these pages and which the screenshots clearly show, I have chosen to base our smart home on Apple Home. I don't really feel a need to defend this choice, nor criticize others who have chosen a different platform. However, sometimes I get both some "criticism" and some questions whether Apple Home is too limited as a smart home platform, especially when it comes to automations and programming. My answer to this is "maybe, but probably not"; if you rely solely on Apple Home and native Home app, there are limitations, both in terms of supported devices and programming opportunities. But both can be circumvented, partly by using other "base stations" (physical or virtual, like Homey or Homebridge) and partly by using other apps for programming (which I will discuss here).
I should also mention that I quite frequently hear more or less denigrating remarks from people using other platforms about how simple and little advanced Apple Home is and how little can be done within that platform. The fact is that when I ask for examples of what such people do with their setup, I very rarely fall short and not being able to achieve the same thing. It has happened, especially when it comes to integrating devices types that are not supported in Apple Home, but not often.
The idea with this section of my smart home page is to show examples of the spectrum of opportunities and how one can achieve different types of programming/automations (all examples are also described under the various rooms where they are applied). I will start with simpler routines and gradually move on to more advanced examples:
TRIGGER - ACTION
The most basic forms of automations are that when something occurs, it triggers some kind of action, with the very basic "syntax" of TRIGGER - ACTION. It is possible to make many different versions of such, as shown below.
Time-based
Either when a certain time occurs or linked to the sun, both are very easy to set up in the Home app:
Example: At 6 am every morning, the lights in the our aquarium turn on (with a red color):
You can choose which days of the week to run this automation and also whether it should depend on certain persons being home or not.
Example: Two hours before sunset, the group of lights called "Afternoon Lights" are turned:
You can finetune if this should happen at sunset/sunrise or a period before or after these.
Person-based
Things can be set to happen when someone arrives home or leaves the home.
It is possible to adjust several factors, such as which people this should apply to, which locations should be involved, and whether this should happen only at certain times of the day or all the time:
For example, we have a routine where the lights of the scene "Evening Lights" are turned on when one of us arrive home and it is after sunset:
Sensor-based
That a sensor of some sort registers av value that should trigger an action. There are many options in this category:
Motion is perhaps the most common, where typically lights are turned on when someone enters a room.
We have many of these, e.g., the lights in the downstairs bathroom turns on at motion and here we also use the option of having it turn off again automatically after a defined period, in this case 5 minutes:
Door or window is opened or closed, based on what is usually called a "contact sensor".
This is also a very useful function and we have many such, e.g., the light in the tool shed turns on when the door is opened (and a corresponding routine turns it off again when the door is closed):
Temperature-based
This is arguably most useful for devices that either heat or cool a room, and you can make rules for a space heater, fan, etc. to turn on or off if the temperature reaches a certain level.
For example, we have a ceiling fan in the master bedroom and a rule that turns the fan off if the temperature goes below 20 degrees Celsius:
It is also possible to base routines on other "climate parameters", just as with temperature, it is possible to humidity and air quality as triggers, but we have not set up any such routines.
Based on "emergencies"
“Emergency” might not be the best term, but it is possible to trigger actions if a smoke detector detects smoke or a leak detector detects water.
We have both such types of sensors, but we have settled for getting a notification if any of these detect something wrong. We could for instance also have created a rule that all lights in the house should turn red if smoke is detected (below this applies only to the aquarium lights for illustration purposes):
Based on light level
Which is something that many sensors measure, e.g., many motion sensors also measure temperature and light level.
As an example (we don't have such a routine active, these lights are controlled by the time of day) the lights in the conservatory can turn on if the light level falls below 20 lux (such a rule would normally be set up to only active before bedtime to avoid the lights staying on all night):
There are also other types of sensors, e.g., vibration, and more will surely come, but the principle for using sensors for automation will likely follow the principles shown above.
Switch-controlled
This is arguably the type of "automation" most similar to what we know from a "non-smart home". If you flick a light switch, the light turns on, and the same principle applies in a smart home, only with many more opportunities. In contrast to a traditional switch, which naturally can only turn on/off devices that are physically connected to it, smart switches can control all kinds of devices no matter where in the home they are:
For example, we have a smart switch at the nightstand by our bed in the master bedroom and a double click on this activates the "Good Morning" scene, which turns on a number of lights around the house (and it could also have turned up the temperature, opened blinds, turned on the TV to morning news, etc.):
Using a different smart switch, in the library, a long press gets "Rob", our robot vacuum, going:
Based on device status
This is an extensive category of routines, where in practice any status/change in status of any smart device can trigger an action:
For example, we could have set up a routine to close the sun screen in the living room covering the windows by the TV whenever the TV is turned on:
In this category, it is only your imagination that might limit what you can; triggers could be lights turning on/off, blinds opening/closing, dishwasher program complete, etc.
TRIGGER - CONDITION - ACTION
Such relatively simple routines can, as the examples above show, be very useful, but even more can be achieved by expanding these with conditions. These are criteria that must be satisfied for an action to be trigger, based on the "syntax" TRIGGER - CONDITION - ACTION. It is possible to define one or more conditions, and if several conditions are set up, it is possible to choose that only one of these need to be fulfilled or all of them must be in place. Programming av such conditions can partly be done in the Home app, while for more advanced versions other apps must be used (unless using Shortcuts in the Home app, more about this further down). Examples of routines and how these can be set up:
One condition/two conditions (where the condition(s) relate to time or person)
This can be programmed in the native Home app, since these are standard conditions shown as options when creating an automation:
You are then presented with the same choices as shown above, i.e., based on the specific times or the passage of the sun or whether different persons are home or away. If both time-based and person-based conditions are defined, these are treated as linked by the "AND" operator, i.e., both conditions must be met for the action to be triggered.
For example, we have an automation where TRIGGER is that (the so-called Audi) garage door opens and the ACTION is that the garage lights are turned on. Since the lights are unnecessary during daytime, we have set a CONDITION that the time should be between sunset and sunrise:
One condition (where the condition is related to something other than time or person)
This cannot be programmed in the native Home app, except for using Shortcuts, and you must resort to one of different other apps. I am quite sure there are other alternatives, but in my case, I have used the Eve app, the Fibaro app, and the Controller for HomeKit app.
Man har da de samme valgene som ble vist over, altså knyttet til spesifikke tider på døgnet eller solens gang eller om ulike personer er hjemme eller borte. Lages det både tids- og personbaserte betingelser behandles disse med "OG"-operatør, det vil si at begge betingelsene må være oppfylte for at aksjonen skal iverksettes.
For example, the following routine looks like this in the Eve app, where TRIGGER is motion in the upstairs bathroom and ACTION is that the lights are turned on to night mode (red light at only 3% brightness). CONDITION is that another light is off. The logic is that this other light, a wall lamp in the library, is one we always turn off when going to bed (using the scene "Good Night"), so if this is off, the bathroom errand takes place at night and we don't want to be hit with bright lights:
Another example, using light level as condition, looks like this in the Fibaro app, where TRIGGER is motion in the conservatory, ACTION is to turn on one of the lamps in this room. Here, CONDITION is that the light level is below 10 lux, which can be set by using a screen keyboard:
Several conditions (where all must be met for the action to be run, i.e., using the AND operator)
Also for this, the three apps mentioned can be used.
For example, we have a fairly complex automation, shown in the Eve app, where TRIGGER is that the office window is closed. This leads to the ACTION that the heat pump is turned on, if a number of CONDITIONS are fulfilled, namely that a number of other windows/doors are closed (except for the door to the office, which must be open for this routine to run, otherwise the rest of the house is not influenced by the window in this room) and it is also set as a condition that the heat pump should be off (this latter is strictly not required). Notice the information in the red oval, that all the conditions must be satisfied, and this cannot be changed, neither in the Eve nor in the Fibaro app.
It should also be mentioned that routines created in other apps also are shown in the native Home app, but when conditions are defined that cannot be defined in this app, these are only shown as "Custom condition":
Several conditions (where it is sufficient for one of them to be satisfied for the action to be executed, i.e., using the OR operator)
This is something that can only be programmed in Controller for HomeKit (or possibly other apps that I don't know of).
We don't have many of these, but one example is an automation for controlling the heat pump. For this, we use as triggering event a so-called "virtual switch", this is explained in more detail below. As TRIGGER we use that the virtual switch Heat Pump Delay Switch turns off (this would have been turned on by the opening of a patio door and turns off automatically after one minute, the logic is behind this is explained below). This triggers a ACTION to turn the heat pump if, if one (or more) of the following CONDITIONS ate met; at the kitchen window is open, that a patio door is open, or the conservatory skylight is open. If all of these are closed, there is no need to turn off the heat pump as it won't try to "fight" the cooling effect from an open door/window:
TRIGGER - ACTION WITH MORE THAN ONE TRIGGER EVENT
A more advanced version of TRIGGER - ACTION also worth mentioning is that you can define several triggers. These cannot be programmed in the Home app, but all the other apps mentioned above handle this. The OR operator is applied to all the triggers (I have not found any way to set up a routine where two or more triggers must happen for the action to take place, this must be programmed using conditions), i.e., if one of the triggers happen, the action is run. As for trigger-based routines with one trigger, it is possible to also here use time-based, person-based, sensor-based, etc. events:
For example, we have a routine where registered motion EITHER in the hallway or outer hallway, which are two rooms adjacent to one another, turns the light on:
VIRTUAL DEVICES
Virtual devices deserve their own mention, as these can be used in different routines, both as TRIGGER, CONDITION, and ACTION. A virtual device is, as the name implies, based on software, but which still appears in Apple Home as any physical device.
It is probably most common to create different types of virtual switches (these can take on different characters; simple on/off, automatic on/off, on/off after a certain time, etc.), but it is also possible to create virtual sensors (for motion, weather/climate, etc.).
The issue with such is that they cannot be created directly in Apple Home, but must be set up via one of several possible workarounds:
Homebridge, which is a server you run at a suitable (always-on) machine, and for Homebridge there are several plugins that enable virtual devices. I use Homebridge-Dummy and have set up several virtual switches, which in Apple Home appear like any other switch, e.g., the already mentioned Heat Pump Delay Switch:
Home Assistant, an even more advanced platform that must also be set up on a separate machine, and which offers even more opportunities for virtual devices. For a while, I ran Home Assistant to integrate devices that I could not find other solutions for, but I have now uninstalled this.
Homey, which is (one of many examples of) a smart home hub supporting many different types of devices, including devices that (at least for now) does not have native Apple Home support. By creating a virtual device based on a non-supported type of physical device, this is a solution to partly expose such devices to Apple Home. In our case, this is exploited to integrate wind measurements in the control of a sun screen installed on the outside of some living room windows. An outdoor Netatmo wind gauge is fully supported in Homey and shows all data generated by this:
Via HomeKitty it is strictly speaking possible to expose this to Apple Home, but then only with the message that it is not supported and cannot be used for anything. I have therefore defined a set of routines in Homey (called flows) which turn on and off a virtual Homey switch, called High Wind, depending on with strength (both steady and gusts). This appears in the Home app as any other switch:
So it does not show the actual wind speed, which of course had been the best solution, but this virtual switch turns on if the wind exceeds a limit where the sun screen can be damaged.
Next, this is integrated into several routines involved in the opening/closing of the sun screen, e.g., a very basic one that simply opens the screen if the wind gets too strong:
A more advanced automation uses two virtual switches and a set of CONDITIONS to determine whether the sun screen should be closed. First, a virtual switch called Sun Screen Down Delay Button, which is turned on if the light level measured by a sensor on the garage wall exceeds 25,000 lux:
This virtual switch is of the type of a "delay switch" because in Homebridge it is set up to stay on for 10 minutes before automatically turning off again. This is done to avoid having the sun screen run up and down as sun as some sun appears or a cloud covers the sun for a short period (a similar delay switch controls opening the sun screen when the light level stays below a threshold for 10 minutes).
When the delay switch turns off after 10 minutes, this acts as the TRIGGER, then the routine checks whether ALL of the following CONDITIONS are met; that the light level still is above 25,000 lux, that the outside temperature is above 3 degrees Celsius (since we have had problems with ice inside the tracks during winter), that the wind is not too strong (the virtual switch High Wind is off), and that our Samsung TV is on (this is because we want the sun screen to close at lower light levels when we are watching TV than when we don't, and is covered by a different routine where the light level limit is 35,000 lux). If all these are fulfilled, the sun screen closes:
These are fairly complicated automations, but which are quite easy to achieve in Apple Home via an app like Controller for HomeKit and virtual switches.
SHORTCUTS
This is the last mechanism for programming in Apple Home I will mention. This originally started as a third-party app called Workflow, which was acquired by Apply and integrated the various operating systems. Eventually it also became possible to use Shortcuts in Apple Home, something that makes it possible to program both the examples shown above and other more advanced routines in the Home app.
You can either start such programming in the Shortcuts app or in the Home app, and in both cases choosing to convert to a Shortcut. In the Home app, this option appears at the very bottom of the list of scenes and devices displayed when given the option to define an ACTION in a routine:
When making this selection, you are taking into the "programming window" with endlessly more options than when staying within the limitations of simple Apple Home routines:
Here you can, among other things:
Choose TRIGGER to start the routine, when in addition to everything mentioned above (time, person, sensor, etc.) can use weather conditions, calendar events, etc.
Create advanced routines using IF sentences, repeating loops, waiting for a set time, etc.
Define ACTIONS, as is done when setting up regular Apple Home routines
Shortcuts can also in many cases be an alternative to virtual devices, .e.g., the 10-minute delay before opening/closing the sun screen could have been programmed using a "WAIT" function instead of a virtual delay switch.
We don't have many Shortcuts, perhaps mainly because I had already solved most programming needs before Shortcuts became available in Apple Home, but one Shortcuts makes it possible to use a so-called Hue Wall Switch Module in Apple Home. This is a smart relay switch that in the Hue app allows assigning different actions depending on whether the switch is on or off, but which in Apple Home appears with only one programmable action irrespective of the switch state before it is operated. But we have solved this using Shortcuts by having a button press test whether the light controlled by the switch is on, and if so, turn it off. If not, the light is turned on:
I hope this demonstrates the rich opportunities offered by Apple Home and gives some inspiration about what can be achieved!