(deprecated) Extensive roller shutter control including shading (brightness, sun position, temperature, forecast)

[DirkSt]

Hi @Eimeel, many thanks for that Blueprint! I’m also migrating from FHEM to HA and NodeRed but FHEM is still running because of ASC. I could not find any proper solution to replace it with NodeRed. But your Blueprint is a very good solution and it seems to finally replace ASC! it seems to be even better than ASC!

But one thing i would like to add: As a brightness sensor i would like to use my Unifi Protect cameras, too. But they just have the ent “isDark on/off”

The merit is i have so many cameras around the house looking to any direction. So i can use that information to match the direction of camera and shutter. Would you be able to add this as an additional brigthness sensor value?

And for shading would it not be good to have a set point of the direction of the window/door? Let’s say to define the north side, east side and so on? In that case it would be more easy to set the shading values in a reasonable way. What do you think?

In Addition: for window sensor i just can use binary sensors. But Homematic threestate sensors are not binary. Would it be possible to add them, too?

best regards
Dirk

[Eimeel]

I understand your requirements. As I mentioned in the initial post, I won’t be implementing any additional functionality. The blueprint now has quite a lot options, making it rather complex. This complexity has made testing more time-consuming and resource-intensive.

Some people have also suggested additional features to me privately, some of which align with your ideas and others are completely different. Implementing all of these would further bloat the codebase.

While it can be done, it’s not something I’m inclined to do. If someone is interested, just use this blueprint as a basis and incorporate additional configuration options. However, it might be more useful to transition away from a blueprint and move towards a module or something similar.

For now, my recommendation is to adapt the blueprint to meet your requirements. Just keep in mind that the Brightness Sensor currently focuses on exceeding or falling below a numerical value, so you’ll need to make the necessary adjustments. As for the Door Sensor, it currently only considers on and off states, but with a Three-State Sensor, you’ll need to differentiate further.

[C0mmanda]

Hey,
great Blueprint, thanks for that. (Hopefully it’s more reliable then ASC )
First experiences after a few days are great.

But I’ve one question: is there any chance to see what the next driving times will be?

Thanks.

[Eimeel]

There are no timers, only triggers. And after something triggered, I just check if every condition is ok.
So there is no real “next driving time” calculated.

[C0mmanda]

OK, got it
I just was wondering about a possibility to visualize driving times and check why different covers in the same room with same settings has closed at different times.
Something with different triggers then, because 1 cover has no activated shading (north side) I guess.
Thanks!

[Eimeel]

Can you share the blueprint configuration for those covers?
Shading should have no effect on closing in the evening.

[C0mmanda]

Thanks, its working simultaneously now.
Don’t know what the problem was. Thank you for your effort!

[Geolin]

Hello @Eimeel ,

I have a problem that the covers are not going up at the morning. If I do it manually, they work as expected. At the evening they are going down as expected.
The cover is KNX based and is working normally when I operate them manually.

Here is my config:

alias: "KNX: Rolladen Beschattung Eltern"
description: ""
use_blueprint:
  path: jmerifjKriwe/automatic_blinds_shading.yaml
  input:
    blind: cover.eltern_rolladen
    shading_azimuth_in: 110
    shading_outdoor_temperatur_sensor: sensor.heizung_temperatur_aussen
    forecast_sensor: weather.frankfurt_main
    auto_ventilate: true
    brightness_sensor: sensor.bewegungsmelder_aussen_haustur_illuminance_lux
    workday_sensor: binary_sensor.arbeitstag_sensor
    auto_up: true
    auto_down: true
    shading_blinds_position: 25

Is there anything wrong in the configuration?

Thanks for your help.

[Eimeel]

Can you check what’s the state of the blind if it’s open? The blueprint checks for “open” and maybe the KNX integration use 100 instead, don’t know. That’s currently not handled but would be easy to fix.

Another possibility is the brightness. As brightness_sensor is used in case brightness_sensor2 isn’t defined, maybe the default value (10) for brightness_down is too low. Can you check the value of sensor.bewegungsmelder_aussen_haustur_illuminance_lux at the point of time you’d like the blind to be closed?
I can image that you have a kind light at your main door (Haustür) during the (early) evening which maybe “conflicts” with the setting?

[Geolin]

The blind is reporting 100% when it is open, see attached screenshot.

Maybe I did not explain it precisely: only automatically opening the blind is not working, closing is working as expected.

[farmio (Matthias Alphart)]

@geolin have a look at the KNX group monitor for the telegrams sent when it should open by this blueprint.

[Eimeel]

But the state is open, so this is fine.

I still think the issue is the default value for brightness_down.
Can you have a look at the history of sensor.bewegungsmelder_aussen_haustur_illuminance_lux? Please check at which timestamp it has gone bellow 10 yesterday evening.

[Geolin]

The sensor has dropped under 10 for the first time at 16:59, risen again to 14 at 17:03 and then to 4 at 17:07.

[Eimeel]

Ok, this is strange.
Are you able to access the trace of this automation for 16:59?

[Geolin]

I will try to extract it.
But again: the blinds are going up fine in the evening.
The problem is that they do not go up in the morning.

I am trying to figure out how to access the trace…

[Geolin]

I understand how to trace it. I will let you know by tomorrow morning and see what I can see in the trace and I will report it here.

Thanks for your support!

[Geolin]

Sorry for my typo:

I meant:

But again: the blinds are going down fine in the evening.
The problem is that they do not go up in the morning.

[Eimeel]

Sorry, for some reason I’ve been on the wrong track and thought the problem is going down :-/

In the afternoon I can post a screenshot which shows you exactly which node of the automation trace we need to look at.

[Geolin]

Thank you.
I have downloaded all traces for this morning as json files. What I can see is that all of the executed steps stopped the automation, so no execution for the blind going up.
Please let me know which trace you need.

[Eimeel]

So, let’s start with Home Assistant debugging for beginners

First of all it’s interesting to see what is happening at the default opening times, which are:

• ‘06:00:00’ at work days (earlist opening time)
• ‘07:00:00’ at non-work days (earlist opening time)
• ‘08:00:00’ (latest opening time)

Check if you can find one of this timestamps in the dropdown window

Next the trigger should be one of the opening triggers (I marked them in red). Check if you find the orange color for one of these triggers.

Next if an opening triggers has been triggered, the orange line should go to the most left node.

As far as I understand, this is the case. But instead of opening the blind it’s going the right way (the hand symbol like on my screenshot).

Now you can check why it’s not executing the path it should use, which is the middle one.

Therefor mark this red node. And now look at the right side of the trace window. There should be an option “Step details”.
Can you copy this for the trace when sensor.bewegungsmelder_aussen_haustur_illuminance_lux triggered because it’s above 70? Also the one at 08:00:00 would be interesting.