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…
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!
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.
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.
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.
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.
I have the trace available when the sensor.bewegungsmelder_aussen_haustur_illuminance_lux went above 70, the other traces I have to wait for tomorrow, as they are not available any more:
Here are the step details:
Executed: 4. November 2023 um 08:08:50
Result:
result: false
conditions/0
Executed: 4. November 2023 um 08:08:50
Result:
result: true
entities: []
conditions/1
Executed: 4. November 2023 um 08:08:50
Result:
result: true
conditions/1/conditions/0
Executed: 4. November 2023 um 08:08:50
Result:
result: false
conditions/1/conditions/1
Executed: 4. November 2023 um 08:08:50
Result:
result: false
conditions/1/conditions/2
Executed: 4. November 2023 um 08:08:50
Result:
result: false
conditions/1/conditions/3
Executed: 4. November 2023 um 08:08:50
Result:
result: false
conditions/1/conditions/4
Executed: 4. November 2023 um 08:08:50
Result:
result: false
conditions/1/conditions/5
Executed: 4. November 2023 um 08:08:50
Result:
result: true
conditions/2
Executed: 4. November 2023 um 08:08:50
Result:
result: false
conditions/2/conditions/0
Executed: 4. November 2023 um 08:08:50
Result:
result: false
entities:
- cover.eltern_rolladen
conditions/2/conditions/1
Executed: 4. November 2023 um 08:08:50
Result:
result: false
entities:
- cover.eltern_rolladen
Ok, perfect
So let’s go on.
As you can see contitions/2 is false because of conditions/2/conditions/0 and conditions/2/conditions/1. What does this mean?
If you scroll the trace further to the bottom, you find a part “Step Config” and there you can find the reasons. In this case we have to find conditions/2
The code/Step config starts:
alias: Checking for opening
conditions:
after this we find 5 major conditions. The first one is just checking if auto_up is enabled, the second one is checking if one of the opening triggers has triggered, …
Where do we find conditions/2? Well, coders are starting to count with 0. So conditions/2 means the 3rd major conditions. Which is:
- or:
- condition: template
value_template: >-
{{ state_attr(blind, 'current_position') | int(default=101) ==
ventilate_position }}
- condition: template
value_template: '{{ state_attr(blind, ''current_position'') | int(default=101) == 0 }}'
So it’s an or-condition with two possiblities.
As you can see in the trace conditions/2/conditions/0 is false and conditions/2/conditions/1 is also false. That’s why conditions/2 is false and the automation is not executing this path.
What is the automation doing at this step?
Well, the attribute “current_position” of the blind is checked. The 1st check has a look if the current_position is the same as the ventilate_position (30 per default). The 2nd check has a look if the current_position is 0 (aka closed).
If the blind is in any other position the automation will stop. This check prevents any hazzle with any manual drive - cause I don’t have any idea what someone wants to achive if driving the blind to another position and therefor I decided to don’t to anything automatic in this case.
Maybe this is already the solution? Your blind is not fully closed and not in ventilate position?
Another reason could be that your blind is not sharing the right position. If this is the case just paste this to developer-tools/template (before opening it manually):
{{ state_attr('cover.eltern_rolladen', 'current_position') | int(default=101) == 30 }}
{{ state_attr('cover.eltern_rolladen', 'current_position') | int(default=101) == 0 }}
{{ state_attr('cover.eltern_rolladen', 'current_position') }}
and have a look at the results on the right part of the screen.
Thank you very much for your detailed explanation. That is probably the reason, because I open up the blind a little bit at 23:00 to prevent full darkness
I can solve this with KNX. I set a virtual endpoint and close the blind not 100%, but the KNX actor will report, that it is closed 
Just a quick feedback: it is working now, I configured my blinds to close to 5%, but they are reporting to HA that they are fully closed.
Now the blinds are opening at the morning
Thanks again for your Support and the blueprint!
Good to know
Maybe I will change from closing the blind completely to a position which everything can define.
But currently I’m not sure if this will or will not create trouble with shading.
Hello @Eimeel,
I have set up a shutter group helper for a couple of roller shutters and included this into the blueprint as the entity.
However, this appears not to trigger the group.
Is this a bug or by design?
There is no reason why shutter groups should not work. So I guess it’s an issue with your configuration. Can you share it?
And what did not work? Opening? Closing? Shading?
Thank you for your respoinse.
If I use this setting and have a workday sensor defined but neither a brightness nor a occupancy sensor should the blinds go up at 6 o’clock or at 7:25 on a Monday morning?
This is the respective YAML config:
alias: EG Rolladen
description: ""
use_blueprint:
path: jmerifjKriwe/automatic_blinds_shading.yaml
input:
auto_shading: false
auto_ventilate: false
time_up_early_non_workday: "07:25:00"
time_down_late: "22:25:00"
blind: cover.rolladengruppe_wohnzimmer
workday_sensor: binary_sensor.workday_sensor
time_down_early: "22:25:00"
time_up_late: "07:25:00"
On a Monday morning the blind should go up at 06:00:00.
Seems we need to do a little debugging 
Can you have a look at Extensive roller shutter control including shading (brightness, sun position, temperature, forecast) - #40 by Eimeel and try to find what is going on at 06 o’clock?
This is what the Log says:
At half past six the blinds were still down…?
It’s not possible to see the issue via logbook. I need to see the corresponding trace.
If you never used traces before, I guess https://www.youtube.com/watch?v=a0w5zkjpeuU&t=469s it’s a good explanation how to get there
Just take one (or more) screenshot like I did at Extensive roller shutter control including shading (brightness, sun position, temperature, forecast) - #40 by Eimeel
That’s easier to see and I can help you to understand automation debugging better