Automate Somfy screens with IFTTT and a Raspberry Pi
Tired of opening and closing your Somfy screens yourself? You can automate this process based upon weather forecast and current weather conditions. Make your screens think for themselves!
Last summer we added sun screens to the ground floor of our house. They are on the front and the side of the house, facing the south and the west. It did not take long to realize all four screens have their own closing and opening time. Since we like light in our house, the screens should only close when the sun is shining on the window. But only in summer. But only in good weather. So although the screens are equipped with a remote control and a control box (Somfy Tahoma) with app, the need to automate rose quick!
The home automation basic script
This is not the first time I feel the need to automate some process (surprise!), so there is already an automation framework running on a Raspberry Pi somewhere hidden in the house. It doesn’t have a screen and only a very limited web interface for debugging purposes because it is about automation and not interfacing. Most functions can probably be developed in existing automation frameworks but I like to develop my own.
The basis is a python script that is executed every minute by crontab. This main script has only a few basic functions:
- Read configuration file — The configuration contains a list of scripts to execute, IFTTT credentials, IP address configuration for home devices, etc.
- Configure logging — Configures logging to a rolling logfile
- Call automation scripts — call all automation scripts as defined in the configuration
Lines 8 till 14 configure the logging functionality, logging to a rotating logfile. This log configuration will be used automatically by all called automation scripts. The utils.get_config() returns the configuration from the specified file as a dictionary (line 18).
The loop calls all specified automation scripts from the configuration (config[‘scripts’] is an array of strings containing script names). For a script with the name automated_script it opens the Python file utomated_script.py and looks for the run() method in the file. If this function is present, the run() function is executed, passing the config as a parameter.
The basis structure of an automation script is:
Line 5 retrieves the predefined logger. Lines 7 till 10 show an example how to use a persistent Boolean variable across multiple runs. This enables the storage of e.g. a Boolean storing whether the screens are closed or not. The example boolean variable is read from the STATUS_FILE, in this case it is inverted and stored again in the same file.
Control Somfy Tahoma over IFTTT
IFTTT integration was a knock-out criterium when we decided on the screens to install. It is possible to send commands to the Tahoma box by IFTTT. In IFTTT a set of Tahoma scripts is created for opening and closing screens. Each screen has a unique name and a screens_open_screenname and screen_close_screenname webhook defined in IFTTT that sends the open or close command for the specific screen to the Tahoma box. For opening and closing all screens there are also screens_open_all and screens_close_all commands.
The IFTTT scripts all have the form IF “receive a web request” THEN “Launch a Tahoma scenario”. In the Tahoma app, for each screen two scenario’s are defined; open_screenname and close_screenname.
So when a screens_close_livingroom webhook of IFTTT is activated, it starts the scenario close_livingroom in the Tahoma box which will close the screen of the living room window. If there are more screens in one room, the Tahoma scenario can close multiple screens.
A tahoma package is created with a Screens class to control the screens from Python. This is an excerpt from the __init__.py file, showing how screens can be controlled by name or all at once.
The ifttt_call() method uses a HTTP Post command to send a command to IFTTT in order to activate the webhook.
First version
The first version of the script was relative simple, only following the specified open/close schedule from the configuration:
This examples specifies e.g. the Livingroom screen closing at 11:45 and opening at sunset. Sunset will be replaced by the sunset time of the current day.
The run method is executed every minute and checks to see if one of the specified event moments occurred. If so, the required action is executed.
The time related helper functions in utils are:
The Astral package is used for sunrise and sunset calculation where the location of Amsterdam is close enough to my actual location. The is_now function checks if it is the specified time, given as a string, like “11:45”.
But it did not take long for some major flaws to appear…. The script is followed every day, even when the weather is bad. On a rainy day, the screens needed to be reopened by hand. This also happens when the weather gets worse during the day. It became clear al little bit of additional logic was required to fulfil the complete set of requirements.
Main logic for opening and closing
The main requirements for opening and closing of the screens are:
- Only close screens today if the weather is warm and sunny
- Close the screens when the sun is shining
- Open the screens when the sun is not shining or it is raining
- Closing and opening due to changes in cloud coverage must be delayed to prevent continuous opening and closing the screens
- When it starts raining or the wind picks up, open the screens immediately
- Only close a screen when the sun is shining on the window. This is dependent or time and sometimes sunrise or sunset, depending on the location of the window
Only the last requirement is fulfilled by the first version described above. This base script will be extended to implement the requirements above. First we calculate the following boolean variables:
- close_today — True, if the weather forecast predicts warm, sunny weather
- open_now — True, if the screens should be opened now (delayed) due to bad weather
- no_delay — True, if the screens should be opened now without delay due to extreme bad weather
- force_opened — True, if the screens are opened due to bad weather
This results in the following first lines for the run function:
The close_today is based on the weather predictions and the open_now and no_delay on the current weather. Weather predictions are obtained from OpenWeatherMap.org. The current weather is retrieved from my personal weather station that logs weather information to this same Raspberry Pi, extended with cloud coverage from OpenWeatherMap.
The open_now is set True if for example the cloud coverage is high. In this case the no_delay is False. The no_delay is True when the screens need to open instantly, for example in the case of stormy weather. The delay() function determines if open_now is used immediately or if a delay is used:
The following function determines, based on the weather predictions wether or not it as a day to close the screens (close_today):
In the period October till May this true if the temperature is above 20 degrees Celsius and the cloud coverage below 80%. So only during exception warm and sunny weather in this period, the screens close. This year this has happened only three times in this period.
During the summer, it depends on the cloud coverage and predicted temperature. If it gets hotter, the cloud coverage becomes less important. This tweaking is implemented during two summers to find the sweet spot.
The next function determines if the screens need to be opened and whether this should happen immediately. This all in case of changing weather:
If it is raining or windspeed is above 50 km/h, the screens must open immediately (line 7). The screens should close normally when cloud coverage increases and the sun radiation value drops, indicating a covered sun (line 10–12). Low air pressure is an indication of bad weather coming so under low pressure less clouds lead to opening the screens (line 16–19).
The function in determine_min_radiation is defined by logging radiation levels for several days at the moment the screens should open. Using a simple lineair regression model, a curve is fitted with x=hour of day and y=lowest radiation level to keep screens closed. The first version of the script did not use this minimum radiation feature an struggled with controlling the screens in case of a clouded day. The cloud overcast percentages where not sufficient for accurate control so the solra radiation was added.
The state machine
The final step is to determine in the run() method if, and if so, which action must be taken.
The code implementing these states is given below. If the required action is to open all screens (line 10–13), the open_all() method of the Screens object is executed, activating the IFTTT webhook and then activating the open all scenario of Tahoma.
If the conditions improve the screens will be reclosed after the delay period is passed, but only those screens that would be closed at that moment with good weather (line 15–25). When the delay period is set to 7 minutes, opening and closing screens will only take place once every 7 minutes.
With the given screen specification when the weather improves at 15:00 the screens in the kitchen and the Livingroom will be closed and the screen in the driveway will stay open.
Finally when open_now and forced_open are False the default schedule is executed. In practice, this is the state the system will most likely be in (line 30–35). This is the main logic of the first version of the script.
Final thoughts
It takes quite some time to optimize the opening and closing conditions for the screens. But the reward at the end is the experience that screens open and close automatically at the moment you think “It is time that they open (or close)”. A lot of this functionality can be created with off-the-shelf automation frameworks but for me a great part of the satisfaction is the idea that your own work is performing the task flawlessly. Well almost, I only miss the override function to temporarily open the screens when the window cleaners are at work. I still need the Somfy remote control with the danger that the script will override the status when the conditions change.
The delay is also implemented in two different variants. This should be aligned to one method.
It all started with a basis script without the opening and reclosing when weather conditions changed. But this only increased the annoyance of ill working screens. On a clouded day the screens stayed closed and when it starts raining I still had to grab the remote control. Starting with a minimal product (only opening and closing according to schedule) showed the functionality worked and where additional logic was required.
I hope you enjoyed this article and feel inspired to automate your own home appliances.
