In some cases, when you are creating a smart home solution it might not look like it is straightforward to choose your variables, logicblock triggers and actions. Don’t worry, sometimes we need to do a bit of analysis upfront to best decide how to set everything up and make our solutions come true.
In this article, we are going to look into a few examples that progressively increase in “smart” complexity, and see how we would identify the different pieces in our solution so it can be fully automated with smart devices and services.
This should give you some strategies to help you when you are analysing a particular problem to translate that Real World situation into a nice and smart IoT solution
Here’s the TL;DR summary:
- The action is the end result, the solution to your problem.
- The variable is some additional data that Apilio will store and check (with the condition) to determine whether it’s ok to run our action
- The condition is a question that we can answer with the data from the variable.
- The trigger for our logicblock is an event that sets our automation into motion.
These are the examples we are going to consider:
- I want my heating to turn on every day at 6PM.
- I want my heating to turn on every day at 6PM if I’m home.
- I want my heating to turn on every day at 6PM if either I or my partner are home.
- I want my heating to turn on only if the temperature inside is less than 18 degrees C, and only if I or my partner are home.
Defining the action
The resulting action in all these scenarios is the same: turn on the heating.
The action of an automation is usually the first one we can identify: this is the end result, the solution to your problem. Ask yourself: If this automation was already implemented, what should be happening right now?
The action is setup in IFTTT by creating an applet that awaits for a specific event from Apilio, then turns on the heating (maybe by switching on a smart plug, or sending a specific command to your smart thermostat).
Defining the variable
The variable is some additional data that Apilio will store and that will check to determine whether it’s ok to run our action.
Imagine you are queuing to go on a bungee rope trampoline ride at a fun fair. You get to the end of the queue and you are measured to see if you meet the minimum required height. If you are, you get to go on a crazy ride! The height (variable) is the data that is checked with a condition (is the height over the minimum?) before the action (bungee jumping) happens.
Let’s see how we identify the variables in the previous examples:
Example 1: I want my heating to turn on every day at 6PM.
This is the most simple scenario we can have: every day, no matter what happens, turn on the heating at 6PM.
In this case, we don’t need any additional variables and conditions, as there aren’t any: when something happens (it’s 6PM), then something else happens (the heating is turned on).
This is the standard IFTTT scenario and this does not require Apilio at all.
Example 2: I want my heating to turn on every day at 6PM if I’m home.
This is definitely an improvement over the previous scenario. I don’t need to turn on my heating if I’m not home, so I can save some energy. In this case we have our first example of a condition: I must be home.
To check if I’m home, I will monitor whether I’m home or not with a variable. This variable is true when I’m home and false when I’m not.
Then at 6PM, before turning on the heating, I check whether I’m home: only if the condition is true (when I am home), then I run the action to turn on the heating.
Example 3: I want my heating to turn on every day at 6PM if either I or my partner are home.
It would be a bit rude if the heating didn’t turn on because I wasn’t home, but my partner was already home patiently freezing and waiting for me to come back.
In this case, there are two things I want to check before I turn on the heating: if I’m home and if my partner is home.
It is possible to have multiple IFTTT accounts connected to one Apilio account. Following the previous example, we can see that we have two variables: one to check if I’m home and one to check if my partner is home.
When it gets to the moment when I need to turn on the heating (6 PM)
Defining the condition
Once we have our variable, defining our condition is straight forward. You have seen in the previous examples what was the question we were trying to answer:
The condition is a question we ask, and that we answer with the data from the variable.
Before I turn on the heating:
- Am I home?
- Is my partner home?
Only if these specific situations are met, then I will turn the heating on.
Defining the trigger
To finish the loop, we need to determine what is the event that our logicblock reacts to to begin the evaluation.
A trigger is an event that sets our automation into motion.
Examples 1 to 3: I want to turn on my heating everyday at 6PM…
In these earlier examples, we have a common starting point: every day at 6PM we want something to happen. In these three cases, our trigger that launches the evaluation of the logicblock to check whether we need to turn on the heating is a moment of the day.
Example 4: I want my heating to turn on only if the temperature inside is less than 18ºC (64.4ºF), and only if i or my partner are home.
This is now starting to become a very smart solution: we are being more efficient by turning on the thermostat only when we are not at a minimum comfort temperature, and only if humans are at home. We are even completely dropping the 6PM timing from the solution: we want to guarantee our comfort at any time of the day, but still making the most efficient use of our heating at home.
Before I turn on the heating I must know if: the temperature is lower than 18º and if my partner or myself are home. Is the temperature a variable now? Which one is the trigger?
Lets analyse the different possibilities:
- If the humans are the trigger and the temperature is the variable: I will have a condition that checks whether the temperature is lower than 18ºC. If it is, then the condition will be true. When I get home, or my partner gets home, this triggers the evaluation of the logicblock: if the temperature is lower than 18º (the condition is true) then the heating will turn on when one of us gets home.
The issue is that if I get home when the house is warmer and then the temperature drops, my logicblock will not be evaluated again, because my trigger is me or my partner getting home. The event that is important here is the temperature dropping below 18º.
- If the temperature is the trigger and the humans the variable: I will have a condition that checks whether either myself or my partner is home (or both, of course). When the temperature drops below 18ºC, this triggers the evaluation of the logicblock: only if I’m home or my partner is home, then the heating will be turned on.
If the temperature drops when nobody is home, the heating will not be turned on. The issue in this case is that when either myself or my partner get home, the logicblock will not be evaluated again (it was already evaluated when the temperature dropped) and the heating will not be turned on.
Looks like we need to combine both solutions to achieve a truly smart solution!
- We need to have 3 variables and we don’t need an explicit trigger. The variables are: temperature, me being home and my partner being home. Each one of these is checked with one condition. We will make use of Apilio’s complex condition linking that allows you to check if the temperature is low and whether me or my partner are home before proceeding with the actions:
Because we want to be able to turn the heating on if the temperature is low and either one of us is home, or if we were already home and the temperature drops, Apilio allows us to do an automatic evaluation of this logicblock whenever any of the 3 connected variable changes:
As you can see, Apilio allows great flexibility for you to configure your smart home automations. Let us know if these examples helped you with your solution below, thanks a lot!