Integrating a Weather Station with BTicino shutters
January 14, 2023In this post I’ll describe my latest home automation project: installing an Ecowitt weather sensor array and using our new openHAB home automation server to integrate it with our BTicino system to bring up the window shutters when the wind gets too strong.
Our window shutters are quite fragile and so far we had to bring them manually up when the wind is getting stronger. Automating this was high on our wish list and would allow us to leave the house with our shutters down and peace of mind that they will be safe when the weather changes. Since also our aging weather station’s outdoor temperature sensor has been broken for some time now, we decided on a full replacement with a sensor array, an indoor display and a gateway for integration with openHAB for automation.
And since the new weather station gives also indoor humidity readings, as a side project I threw in some Shelly components to control our indoor humidifiers.
The post covers:
- Our choice of Ecowitt for the weather station and its integration into openHAB.
- Controlling our BTicino shutters with openHAB and the one major pitfall that I encountered.
- Adding additional humidity and temperature sensors as well as actuators from Shelly to control our indoor humidifiers.
So, without further ado, let’s get right to it.
Choosing the Weather Station
The requirements for our new weather station were:
- Outdoor sensor(s) for temperature and wind speed.
- Support of multiple indoor displays.
- Direct and local integration with openHAB for automation, without having to use any cloud service.
When looking for weather stations that work with openHAB, I quickly stumbled upon the Fine Offset Weather Station Binding. The Fine Offset weather stations are white-labeled products that are sold by different brands under their own name, see the linked binding pages for a list of some of them.
I researched some of those brands and settled on Ecowitt: they have a reasonable web presence, the widest choice of the different Fine Offset sensors, displays and gateways, and their support quickly and competently answered the questions I had before the purchase.
For the sensor array I choose the WS90, their most advanced model, which was recommended by users in the Fine Offset thread in the openHAB community. It’s ultrasonic wind sensor makes it more compact than other sensors working with wind speed cups and a wind vane, and also the piezoelectric rain gauge is said to be more sensitive and reliable.
For connecting the sensor array to our network I choose the GW2000 as dedicated gateway into our LAN. Most of their displays could also act as gateway, but they only support WLAN and I wanted a reliable, wired connection and have the automation independent of the displays, which might get moved around or disconnected by users.
For the display we wanted to start out with only one for testing and then add more later. Our initial choice was the LCD-based WN1980_C, however since that one was out of stock we decided to go all-in and order their largest TFT-model, the HP2560_C. When looking for displays compatible with the WS90 you can check out the compatibility table from the WS90 page. However it does not seem to be fully up-to-date and did not include the WN1980_C, but the WN1980_C’s manual confirmed the two can work together.
While the Ecowitt website seems a bit sketchy on the first glance, it offers useful information, links to documentation and for each product a Q&A section, in which their support was quick to answer my questions.
After settling on those three components, let’s have a look how the overall solution was now planned to look like.
An Overview of the Planned Solution
The following figure shows how the new components will integrate into our home automation system. The WS90 sensor array sends its data via a proprietary radio connection to both the display(s) and the gateway. The gateway is connected to openHAB via the Fine Offset Weather Station Binding (1), where rules are in place to control our shutters via the BTicino bus (2). For our side project of managing our indoor humidifiers, we rely on information of the Ecowitt gateway’s temperature and humidity sensor (3), as well as additional H&T sensors from Shelly (3), the brand already have been using for adding wireless components to our system. For controlling the humidifiers we use their wireless Plug S actuators (4).
The first step for implementing this solution was the installation of the weather station.
Installing the Weather Station and Integrating it with openHAB
The initial setup of the WS90 and GW2000 was straight forward. For the WS90, you just need to add two AA rechargeable batteries and you are good to go. For the GW2000 I followed Method B of this guide, starting with assigning a static IP address to the gateway in our home router and then calling up the embedded web page to set an admin password and update the firmware. The gateway automatically discovered the sensor and nothing needed to be done in that regard. Setting up the HP2560_C was equally easy, I just connected it to the power, and it automatically detected the sensor and started displaying its information:
After the gateway was connected to our LAN, I installed the Fine Offset Weather Station Binding, and it automatically detected both the gateway and the sensor. Adding them to your Things you’ll see that the channels providing actual measurements come with the gateway Thing, while the sensor Thing only gives you information on the sensor’s technical status:
Before we continue with the data model, a brief note on an issue I found. Our gateway Thing in openHAB regularly stopped receiving updates, with the measurements flatlining as shown in the screenshot below. The log files contain a warning with an exception when that happened, and I filed a Github issue for this error. In an amazing display of the efficiency of Open Source development, the issue was fixed in a few days and the developers provided snapshot builds with the fix (here for 3.4.2 and here for 4.0.0). I am now running the 3.4.2 snapshot build with my openHAB 3.4.0 and it works fine. The fix will be included in versions 3.4.2 and 4.0.0 once those are released, which might well have happened already at the time you read this. If you are not able to use the fix, the issue can also be solved by disabling and enabling the gateway Thing each time the warning occurs in the log files. This can be automated with a rule triggered by the warning in the log file, using the Log Reader binding.
And now back to the data model. For the Items in the functional layer I arranged it a bit differently, with one Equipment placed in the Garden and representing the weather station and its measurements and a sub-Equipment for the sensor. The gateway also provides indoor measurements of humidity and temperature in its Thing, for those channels I created a separate Equipment and placed the corresponding Points in it:
Now with the data model in place we can continue with adding control of the shutters.
Controlling BTicino Shutters with openHAB
My previous post on the integration of our BTicino MyHome automation system with openHAB focused mostly on lights and switches, so before we get into the connection between the weather station and the shutters, let’s have a look how they integrate into openHAB and the one major pitfall I encountered in the process.
We’ll begin with a look at the data model for the BTicino shutters in openHAB.
The Data Model
Let’s start again with the physical layer, where you can use the auto scan of the binding or manually add Things representing the shutters, using the Thing type Automation:
On the functional layer, you can use the “Create Equipment from Thing” function and it will create you proper Equipments that you can place in your semantic model:
To be able to control groups of shutters, I have used the same approach outlined for lights in my previous post. A non-semantic structure, still representing our house, its floors and rooms, but only containing the Points representing the shutter action. This is necessary, since the semantic model cannot be used for issuing commands, for the reasons explained in my previous post.
With the data model for the shutters in place, we can continue to the rule connecting it with the weather station.
The Rule
To bring down the shutters when the winds get too strong, I have written a relatively simple rule that brings the shutters up if a configured wind speed threshold is passed, logs the action into the openHAB log files and sends an email to inform users.
To be able to configure the wind speed threshold from the user interface, I created a Point under the weather station equipment, with Type=Number:Speed, Semantic Class=Setpoint and Semantic Property=Wind. For setting it on the user interface, I set the metadata for Default Standalone Widget to a slider card, configured to allow values between 0 and 60 km/h in steps of 5.
Now we can create a rule and enter the script for it. The rule triggers on any change to the wind speed measurement of the weather station. The action script then checks if the wind speed has passed the threshold and brings the shutters up. To be on the safe side, it issues the up command regardless of the shutter state, so even if they are up already or in an undefined state. However, the email notification is only sent if the shutters have been down or in an undefined state, to avoid unnecessary email notifications. This also eliminates multiple emails being sent if the wind speed goes back and forth from up and below the threshold but the shutters are up already.
For sending emails from the rule it is necessary to install the Mail Binding in openHAB, configure it and replace the Thing UID in the script with the Thing UID assigned in your system.
The following screenshots show the rule and the action script. You can also download the action script here.
When testing this rule, I ran into the one major pitfall I mentioned earlier in the post.
The Issue with Auto-Stop and the Shutter Run Parameter
I tested this rule under different circumstances, among them how it behaves when it is executed directly after startup of openHAB, with the shutter states being UNDEF because openHAB does not know their actual status. In this situation the up command sent by the action script set the status of all shutters to 0 (fully opened), as expected. However, I noticed that after about 60 seconds, the state of the shutters went back to UNDEF.
After some investigation with support of the kind folks in the OpenWebNet/BTicino thread in the openHAB community, this issue turned out to be caused by the automatic stop command issued by the actuators before the Shutter Run time set by the bindings auto calibration feature passed.
So to avoid this issue I’d recommend not using the auto calibration but instead manually measuring the runtime of each of your shutters and setting the Shutter Run in openHAB accordingly. And further, you need to ensure that the actuator’s automatic stop is configured to a time longer than that Shutter Run.
To explain this, let’s first have a look at the BTicino actuators, which automatically issue that auto-stop command at a pre-set time after an up or down command has been sent. For our older F411/2 actuators using physical or virtual configuration in the My Home Suite this time can be set via the M parameter to only a few predefined values with M=0 for 1 minute, M=1 for 2 minutes, M=2 for 5 minutes, M=3 for 10 minutes and M=4 for disabling auto-stop. For newer actuators that support the advanced configuration in My Home Suite you can set the value more precisely in seconds:
The second involved parameter is the Shutter Run parameter in openHAB, which should be set on the Thing level for each shutter to the time it takes the shutter to go from fully open to fully closed:
If the shutter is stopped during its run, the binding uses this value to calculate to which percentage the shutter is closed. You can see this in the state of the shutter, which is not an open/closed but always a percentage between 0 (fully open) and 100 (fully closed):
You can read more about the shutter position and the Shutter Run parameter in the corresponding section of the binding documentation.
What is important and not clearly documented is that the Shutter Run parameter needs to be set to a value lower than the auto-stop of the actuators so that the binding only receives the stop command after the Shutter Run time has passed. Otherwise situations like the UNDEF states described above can occur.
And now we come to the auto calibration, which - and that’s a real catch 22 - actually is not able to measure the real time it takes the shutter to fully close but instead relies on that very auto-stop command. While according to the developer it sets the Shutter Run to 0,5 seconds less then the time measured to the auto-stop, this does not seem to be sufficient in some cases. In our case we have the older actuators with a default stop time of M=0 for 60 seconds, and all the shutter Things had a Shutter Run of about 61 seconds after the auto calibration. During operations the auto-stop was then received a short moment before that 61 seconds has passed, leading to the observed issues. This is a typical racing condition and is reflected by reports in the community that the auto calibration works for some users and doesn’t for others.
So, therefore the recommendation to not use auto calibration and manually set the Shutter Run parameter to the actual runtime to ensure proper calculation of the opening percentage. The auto-stop should be set a bit higher, I’d say at least 3 seconds. For our system I manually measured the Shutter Run times and configured all Things accordingly to the resulting values of 30 to 50 seconds and thereby lower than the auto-stop of 60 seconds. After that the issue did not occur anymore. Even if the shutters were in an UNDEF state after reboot of openHAB, a simple up command put them in the known state of 0 (fully opened) and the following auto-stops did not interfere and leave the state at 0.
Getting the Shutters Into a Known State After Startup
If you want to have the shutters in a known state after openHAB restart, you can now issue a simple up command as part of a rule triggered by startup. If the shutters are up anyway, this will just put them in a known state of 0 (fully opened), but if they are down they will physically be brought up. So you have to decide which behavior you prefer in case of an openHAB restart. I decided that having a known state is more important to me then leaving the shutters where they are, so I added a simple rule that’s executed after openHAB has started up and sends an up command to all shutters in the house:
This concludes the integration of the BTicino shutters into openHAB and their control based on wind speed measurements from our new weather station. But before we close this post, let’s have a look at my little side project, the management of our indoor humidifiers.
Controlling Humidifiers with openHAB and Shelly Components
Since the Ecowitt GW2000 also has a sensor delivering indoor humidity and temperature readings, I decided to use that to control our indoor humidifiers.
We have two of those, one on the ground floor and another on the first floor. They are older models from Venta that do not have any smart/remote control capability. Those humidifiers are very useful to keep the indoor humidity up during winter when the heating is on, but even at their lowest setting bring up the humidity to higher levels than we like. One of the issues with that is it leads to condensed moisture collecting at the windows and damaging our wooden window frames. So clearly, control based on actual humidity would be useful and ended up on our wish list for home automation.
For the implementation I wanted to have separate measurements for ground and first floor. For ground floor, I am using the readings from the GW2000, while for the first floor I added a Shelly H&T sensor. Both humidifiers are controlled by Shelly Plug S actuators.
In terms of data modelling, we have already seen the Equipment I created for the indoor sensor of the GW2000, and I created another for the Shelly H&T sensor:
For the configuration, each of the sensors got two additional points for the lower and upper threshold, setup in a similar fashion as the wind threshold we setup previously. Additionally, there is a configuration parameter for setting an amount of minutes for which the value has to be below or above the threshold before an action is taken. This is to avoid the humidifiers going on and off when the humidity changes briefly, for example when we open the windows.
For controlling the humidifiers we use a rule and script again. In this case, the script is not triggered by changes to the humidity but executed every five minutes. Since the logic is the same for both ground floor and first floor, there is only one rule for both sensors, and one script. The script has a function that implements the logic applied to both floors, and below that a block that calls the function twice with different parameters for ground floor or first floor. Again, the rule also logs actions in the log file and informs the user via email.
You can download the script here. If you’d like to use it, you need to insert the names of the Items you created in the bottom, where the function is called, and insert your SMTP Thing’s UID and your email address where the email is sent at the end of the function.
With the rule in place, we now have automated control of our humidifiers and can conclude this projects!
Final Words
Installing the weather station is a very useful extension of our home automation system, the ability to automatically bring up our shutters when winds gets too strong now gives us peace-of-mind to leave the house in summer with the shutters down and the knowledge they’ll be safe.
Adding the Shelly components to our old indoor humidifiers was an inexpensive and easy way to smarten them up, without having to replace them, and now contributes to a healthy climate in our house.
The integration with openHAB was easy in both cases, only the BTicino-controlled shutters and their issue with the auto-calibration and auto-stop caused some headache, but could be resolved with some time and as before with the support of the helpful folks in the OpenWebNet/BTicino thread in the openHAB community.
I hope you found this article helpful, and as always, feel free to contact me in case you have any suggestions or questions.
To conclude this post, here a screenshot of the simple dashboard I created in the Basic UI of openHAB, showing us the most important outdoor and indoor readings, and the configuration parameters for the automation. I am sure this could be done more nicely with the many UI options openHAB offers, but for now it will do its job.
