Since I have a very well insulated house, the heat inside the house dissipates very difficult once heated up. My aim is to keep the heat out of the house by means of automatically working sunscreens at every window facing the sun. I have been struggling for a long time to get it working properly.
First I tried to determine whether the sun is shining be means of LUX sensors. (Fibaro Multisensor). Apart from the fact that they didn’t work as trustworthy as I hoped, they solely measure sunlight intensity, which is something different than sun warmth. Furthermore the multisensor is not meant to be mounted outside, requiring a protection enclosure, which affected the LUX readings. This also rendered the temperature sensor of the Fibaro Multisensor useless, since it is mounted in direct sunlight inside a box. So I concluded a separate temperature sensor would be required.
While trying to combine the LUX sensor with a Temperature sensor, I came to the idea to simply look at the difference between the temperature of direct sunlight and the ‘standard’ outside temperature (shadow). I found out that this is a trustworthy way to determine whether the sun is shining, and at the same time it provides me with proper temperature data. The Fibaro Binairy sensor I use can handle 4 temperature sensors simultaneously. Currently it measures temperatures of sunlight, shadow (outside temperature), inside living room and cellar.
It all resulted in the following flows:
One flow calculating the average shadow temperature, using the last 18 raw data readings
One flow calculating the average sunlight temperature, using the last 18 raw data readings
One flow calculating the temperature difference and set a Boolean at a certain value
One flow measuring the shadow temperature and set a Boolean at a certain value
These flows are closing the sunscreens:
One flow setting above mentioned Boolean TRUE when temperature difference is more than 7ºC
One flow setting above mentioned Boolean TRUE when shadow temperature reaches 20ºC
One flow checking if both booleans become TRUE and if so, lower the sunscreens (also depending on the time).
These flows are opening the sunscreens:
One flow setting above mentioned Boolean FALSE when temperature difference is less than 5ºC
One flow setting above mentioned Boolean FALSE when shadow temperature is less than 20ºC
One flow checking if Boolean for temperature difference becomes FALSE and if so, open the sunscreens.
The result as shown in Insights over the course of two days:
Nice! Interested in how you are doing the average temperature flow for the last 18 raw readings… are you storing 18 variables and averaging this? I’m looking at found something similar but more efficiently than having so many flows.
Thanks for your replies. Below are the flows I use to get it working as it currently does.
The first step is importing the raw data. I have the following flow mainly in order to filter out wrong readings. However they almost never occur anymore since I improved all wire connections to the temperature sensors:
The second step/flow is making an average of the raw temperature readings. This is important for a smooth working of the screens. I don’t want to have the sunscreens jumping up and down with every cloud passing by. So this is particularly important with sunlight temperature. Therefore I am averaging this readings with 18 previous readings. This gives a delay of about 40 minutes. So 40 minutes of consistent sunshine is required to lower the sunscreens:
Hmm, I am eager to understand this formula, but I don’t grasp it yet.
What should be in my case filled in the place of ‘the-average’ between the brackets?
I am trying to figure how this formula would work and I created a test flow… without succeeding
It is not clear for me how the 10 previous readings (which then need to be averaged), become part of the calculation.
If I understand correctly:
New-Average = (10*Old-Average + new value) / 11
Since the old average is taken from 10 data points, just give it a weight of 10. Add the newest datapoint (= weight 1) and divide by 11 for the new average.
For example
10 datapoints: (1+2+1+1+1+2+1+1+1+1) / 10 = 1.2 average
New datapoint = 2
New average = (1.2 * 10 + 2) / 11 = 1,27
As @Sytze already mentioned, the 10 previous readings are already in the variable “old-average” but you don’t need 2 variables (New and Old-average), this can be the same variable called “the-average” or just “average”. Only from the start, the calculated average will rise slowly, from zero to the “middle” value. It is also possible to use only the last 6 points by ((average*6)+new)/7.
Also, @TedTolboom is right, it’s not '100% math right all the time, but for this purpose, I wouldn’t care.
Be aware that if you put this in a mathjs card, there have to be “$” signs before and after the variable name in the left box:
I’ve got the formula working and letting Insights create some graphs. I will revert with a screenshot of the actual results of this type of averaging. Thanks for the input so far!
Here is a Insights screenshot showing the actual behaviour of different calculations of averaging. I conclude that the proper/standard formula for calculating the average reflects the movements of the raw data the best. If I want to achieve the same smoothness of the curve by using the ‘new’ formula the lag becomes pretty much. For the purpose of automatic sunscreens a lag of 30-45 minutes seems to be optimal.
So, I will for now implement the new formula and multiply the average by 12 (green curve). Practise needs to proof if the smoothness of the curve is sufficient. I tend to think that the sunscreens will be a bit too actively jumping up and down. However, much easier implementation of the formula is the advantage we are looking for.
Thanks for showing! My usecase and the approach is very different.
Before there was domotics, in our previous family house, we had a Somfy wind and sun sensor outside and a switch for sun / wind speed / timerdelay inside. For a sun screen of 7 meters long, with 2.5 meters arm length on the south really a good thing to keep it from sailing away!
Now I have two adjacent roller blinds on the east side of an apartment building and I use Suncalc and the lux measurement of a Sensor6. When a certain angle of entrance is passed, the the “down” response comes fairly quickly after we reach a lux value above Lux_Max_Living room. The signal “up” after some time delay when back under Lux_Min_Living room or a “sunset-x” angle. We had some knowledge exchange on this last year @ Slack.
All this shows that there are opportunities here for a sunscreen maker or an app wizard to create a truly versatile solution.
