You need to look not only at the trigger, but also at the other code for the corresponding trigger
So today I tried to artificially start the shading by configuring the light sensor to 50 lux and also giving the weather sensor the rainy condition.
Test 1 with a temperature of 15 degrees. No shading started.
Test 2: Then I set the temperature to 0 degrees and removed the weather sensor. No shading either.
The third trace I uploaded is the one after I turned the lighting back down, which is when shading shouldn’t normally occur.
I really don’t know what else I can check to see what the problem is.
https://drive.google.com/drive/folders/1PLfuO9yck6jMOLzkZtFFYT3phYXTeuXA?usp=sharing
Hey there,
this may be a stupid question, but how do i create the cover status helper?
I got Shelly 2PM Gen3 devices as controller for my covers. i just want to use the sun protection feature.
The first trace cannot be used because CCA was executed manually.
In trace 2, I can see how a shading was detected and the waiting time begins.
In the third trace, the detected shading was then continued. But finally stopped in the 10th condition because the shading was already executed on the same day at GMT : Thursday, 24. April 2025 09:12:39
That’s weird, though. The cover only moved twice the entire day: morning and evening. So it couldn’t have been shaded at that time of day. When I take a look at the log of the shelly, I also can’t see anything at that time.
Now, unfortunately, I’m even more confused.
Everyday at 6 o’clock in the morning and around 7 pm, I get this status in my automation:
ausgelöst durch Uhrzeit change or manual update via template
So it is executed by a time change, or an manual update. Any idea, what that could be?
Wenn ich es richtig verstehe, testest du mit manipulierten Werten über die Entwicklerwerkzeuge. Deine Wartezeit für Shading beträgt 1 bzw. 5 Minuten.
Vermutlich hat sich der Sensor in dieser Zeit wieder auf den reellen Wert resettet.
Stell die Wartezeit doch mal auf wenige Sekunden oder stelle sicher, dass der Wert nicht vom echten Sensor überschrieben wird. Dann sollte Bewegung reinkommen.
Beachte, dass die Trigger nur anschlagen können, wenn der Ist-Wert den Schwellwert kreuzt. Wenn der Schwellwert bereits unter-/überschritten ist und sich der Wert ändert, wird kein Trigger anschlagen. Also z. B. Shading ab 20 Grad, Ist-Wert 21 Grad, Ist-Wert Änderung auf 22 Grad => kein Trigger!
An deiner Stelle würde ich mich erst mal auf einen Sensor (z. B. shading_azimuth) konzentrieren und den Rest deaktivieren bzw, auf niedrige Werte setzen, damit sie TRUE ergeben. Die prevent_*-Haken erstmal alle deaktivieren.
Poste mal deine YAML mit Minimal-Konfiguration, falls es da auch schon klemmen sollte.
1 Like
Shading was ended though it shouldn’t ?
alias: "Rolladen: Wohnzimmer Terrasse"
description: >-
fährt nach Sonnenauf- /untergangszeiten, aber nur innerhalb des Fensters (7-9
Uhr)
Beschattung ab 18 Grad
use_blueprint:
path: hvorragend/cover_control_automation.yaml
input:
shading_forecast_sensor: weather.openweathermap
blind: cover.rolladen_wohnzimmer_terrasse
time_up_early: "07:15:00"
time_up_early_non_workday: "07:30:00"
time_up_late: "07:45:00"
time_up_late_non_workday: "08:15:00"
sun_elevation_up: -1
time_down_early: "17:00:00"
time_down_early_non_workday: "17:00:00"
time_down_late: "22:00:00"
time_down_late_non_workday: "22:00:00"
sun_elevation_down: -5
drive_delay_fix: 0
drive_delay_random: 5
position_tolerance: 5
shading_azimuth_start: 158
shading_azimuth_end: 258
shading_forecast_temp: 18
workday_sensor: binary_sensor.workday_sensor
check_config_debuglevel: info
check_config: false
auto_options:
- auto_up_enabled
- auto_down_enabled
- auto_sun_enabled
- auto_shading_enabled
- auto_ventilate_enabled
shading_position: 40
time_control: time_control_input
ventilate_position: 85
individual_config:
- prevent_shading_end_if_closed
- allow_shading_multiple_times
ignore_after_manual_config:
- ignore_shading_after_manual
shading_weather_conditions:
- sunny
- partlycloudy
- clear
- cloudy
auto_shading_end_condition: []
auto_shading_start_condition:
- condition: state
entity_id: binary_sensor.fenstersensor_terrassentur_contact
state: "off"
auto_shading_start_action:
- action: notify.persistent_notification
metadata: {}
data:
message: "Terrasse: Beschattung gestartet"
cover_status_helper: input_text.rolladen_status_wohnzimmer_terrasse
cover_status_options: cover_helper_enabled
contact_window_opened: binary_sensor.fenstersensor_terrassentur_contact
trace:
stored_traces: 20
EDIT: exactly 10 min after this (at 15:20) it shaded_in again!?
EDIT > SOLVED: Openweathermap provided shit data (reported “rainy” though sky is clear :)):
1 Like
I don’t know your config. But it can be quite normal that there are several triggers that do not execute anything.
For example, the default value of time_up_early is 06:00. If it was not yet bright enough, nothing else happens. However, triggers are of course triggered in order to be able to check the conditions.
Incidentally, the default value of time_up_early_non_workday is 07:00.
But I can only answer this 100% correctly if you show me a trace of the trigger.
However, I would say that this is quite normal.
Thank you for the answer. I guess that’s it.
Would it be possible to make the sun shading more dynamic? I set every cover, in every room to track the room temperature. Only if the temperature is reached, the cover will start the sunshading. However, in the summer, it is a good idea to open the windows in the morning and to keep the cool air in the room. With the current sun shading, the cover will only close of the room temperature is reached. Instead of applying a new temperature to every room for summer, it would be cool to have a boolean input to switch between two temperatures.
Try it with Additional Conditions for example the temperature which is predicted with the weather forecast or room temperature.
The problem is, that I need to trigger the automation to shade, not to keep the shading. The latter is easy.
It would be so cool if you could reference a variable instead of hardcoding values for certain sensors/values. That way, you’d have maximum flexibility and could, for example, adjust threshold values dynamically. @Herr.Vorragend
try to use met.no as weather integration!
Hello,
is there a possibility to use HACS Sun2 instead of the default Sun integration? I am not able to choose the Sun2 integration as Sun Sensor. Reason behind this is that the update frequency of Sun Elevation is terrible after sunset.
Thank you and enjoy your evening,
Christian
have you seen a better quality from your experience?
In my first days with HA a few years ago, I was also totally enthusiastic about this integration. In the meantime, I no longer see any reason to use it. I am not aware of any worse evening update times for the normal Sun integration. But I have also never observed this.
If necessary, couldn’t you start the “Update Entity” action via an automation if something is really missing?
Unfortunately, the Sun2 integration is completely different and I would have to rebuild a few things. And so far this request has only come from you. Therefore, no customization is currently planned. Sorry.
No problem and thanks your answer. I found this about the timing in Sun: Quiet the chatty sun.sun by Swamp-Ig · Pull Request #23832 · home-assistant/core · GitHub
I also found out about „Update Entity“ but here I have to check where to put it in.
Thanks for your great support and integration.
Christian
yes i tested several weather integrations, DWD, openweather, accuweather and met.no. And for me met.no was the best. Yes sometime the weather condition is still wrong, but much better than from the others, and the forecast temperature is more accurate! I was testing last year about 3 or 4 months! I would say, load all of them into your HA and create a separate dashboard where you put them all in. Than you can compare them directly over a few days/weeks. Than you can decide wich integration should be deleted…