Wow, I’m sure it could be done but it definitely won’t be easy.
The issue is as of now the automation doesn’t run on a time basis so you can’t change it to run “earlier” or “later”. it’s running continuously based on the change in the sun entity.
And the matrix is only calculated on the azimuth.
If you put in an offset to the matrix based on the elevation then the inflection points would need changed to keep the slope-intercept math working. Otherwise you’ll get into a situation where you could get a position >100 or <0. Which is what was happening above before I realized I had those inflection points wrong.
the only way I see it working is to come up with an “early” matrix and a “later” matrix based on the seasons and use the season as a condition in a “choose” action to determine which set of templates to use.
pseudo code would look like:
action:
choose:
- condition:
- season == early
sequence:
- early matrix templates
- condition:
- seaon == later
sequence:
- later matrix templates
but again you’ll have to come up with another matrix and work out the line formulas and the inflection points for it.
ok, got ya, makes sense. Maybe a slightly different approach from the conditions: couldn’t it be included inside the action’s math part? What if I make notes of elevation values in different times of the year next to each azimuth value? For instance I poll the elevation values from suncalc.org for almost all month of the year, always the 1st day (May, June, July, August, September, October), and then I could group these values into elevation ranges, to which I could attach different cover position values, which you could include in your IF ELIF, to choose the cover position from a different matrix point, what do you think?
I created a new worksheet in my google sheets table to “visualize” my idea how to use elevation as an additional condition, please take a look at it@finity if it makes any sense to you…
thanks a lot Taras for your input, I wish I had the knowledge to decypher it and use it for my own purposes but I guess I’m stuck with relying on other’s goodwill to help me
Of course it could be done using your different matrices but (using your cover 8 as an example) you realize that you would need to calculate 7 different azimuth templates along with their appropriate inflection points? By my calculation that is going to be around 30 different if/elif/else values and about 15 different line calculations.
And that’s for ONLY ONE COVER.
Then you have to do that for every cover you have (so x4 if you keep each cover grouped as you have them in your original matrix).
It really depends on how precise you need to be but to my thinking using different values per season would be WAY easier and likely “close enough”
that way you would only need to calculate matrices for summer, winter and (since spring & fall should be about the same - I think) spring/fall - so three total per set of covers.
but you would have to recalculate the slopes and inflection points over from scratch because I’m not sure they would translate to the three seasons correctly.
I’m glad to help to a degree but that’s A LOT of work. And TBH, for something that I will never get any use out of (aside from the satisfaction of being able to figure something like this out - which is fine but there is a limit. )
Please help me, I’m missing the action for cover 1 and 2 from your solution post, I just realized it… and the original setting ou provided had some problem, remember? Could you perhaps give me the correct action part for cover 1 and 2?
hm, it didn’t, but I give it another try, maybe I messed up something.
Besides this problem, can I still exploit your brain power @finity ? I’m still trying to figure out how to consider the human factor in conditions, specifically: I don’t want the automation to start pulling the covers if someone is still sleeping in the room. I couldn’t come up with a better idea but to watch if the cover was opened (partially or full, doesn’t matter) by the button on the wall. If you remember, the button now controls a Shelly 2.5 relay.
What I thought of first: if cover is above 1%, so presumably someone opened to whatever position, and is not closed, then run the automation. if it’s fully closed, stop. But this blocks the automation obviously when it closes the cover fully, and later when the sun moved away, it will never open it back to let the light come in. So the automation will only work downward, and never upward.
So somehow I would need to catch the event when the cover was controlled by a human being by the physical button in the morning…or, even better, it was controlled by a human being by ANY means, that could be Home Assistant button, or HomeKit button, anything apart from the AUTOMATION ITSELF, should be treated as human intervention.
So the automation should NOT run, UNTIL someone human opened it fully, or partially. Would this be possible somehow? Or any better idea, how to consider the human being in this equation?
Does the button interact with HA in some way or does it directly control the shelly?
IOW, is it:
button->HA->shelly
or:
button->shelly
if it goes to HA then you can use the operation of the button the first time in the morning to set a boolean to ‘on’. then you can use the boolean being ‘on’ as a condition in the automation to allow it to control the blinds.
then it’s easy enough to turn the boolean ‘off’ at some point (midnight, bed presence sensor, etc) to set it up to block the automation until the next morning when someone triggers the blinds manually again.
OK, so it sounds like the button controlling the boolean idea is out…
for another idea you could turn the automation ‘off’ at midnight, etc. then have another automation to turn the blind position control automation back ‘on’ when the blinds first move in the morning based on a change of position.
hm, that’s actually a very clever idea @finity , thanks!!
I realised one thing which could also work, I just don’t know how to set it up…
Shelly is capable of calling a URL at the event of the physical button press, I think this could be the perfect solution… what I would need to be able to solve now:
create a webshook in HA to be called by the Shelly device
let this webhook to turn on a boolean state, let’s say BUTTON_PRESSED_ON
automatically reset this boolean state back to OFF like in every 3 hours
and finally use the BUTTON_PRESSED_ON boolean state as a blocking condition for the roller shutter automation…
Am I somewhat right? Wish I could solve this on my own
@finity , look what I’ve found out after a lot of googling!! Turned out there was some development in the Shelly integration, and now I have built in sensors for the button states!!!
These sensors are disabled by default, that’s why I was not aware of them before (dunno why though), but look, I have two physical button state sensors per shelly, one up and one down :):):):) (gomb = button in my language)
Hi there, the ground you guys @Guesswho620 and @finity have covered is mind boggling awesome.
Any chance of one of you posting the full config? From using your code I cant get it to work, its still way over my knowledge level in HA, Im still stuck with lots of individual automations, and no shading.
Like @Guesswho620 I got plenty of roller shutters and have em grouped to 4 automations to open and close them depending on sun.sun elevation and lux. That kind of leads to funny situations for the terrace doors etc like beeing outdoor and the rollers come down, with no key. .
But no shading is done right now. Still got time to fix this. And yes the WAF is my biggest concern too, as we come from FHEM where there was a template, a bit awkward to setup, but working perfectly for the roller shutters, how ever in 5 years I never got to a usable front end, and we dont have switches for the sonoff tasmota controlled shutters.
absolutely, I will do that, and make @finity 's masterpiece public, later today when I’ll have some time to collect, do some privacy cleanup on the code, and post it here.
I want to enhance it a bit later on - where I most probably will ask Finity’s help again, becasue he was suggesting this enhancement before, but I didn’t have a reliable method to use - to introduce the human or wife factor into the automation: disable the automation for a predefined amount of time (1-2-3 hours) when a shutter control button on the wall is pressed. Previously I didn’t have a reliable method to intercept these button events, but with the recent changes in Shelly integration they are consistently pushed to HA real time, which is great and brings new abilities to me.
)
.
as was used in your code… embarrassing