unfortunately I think I have another issue… sorry
From yesterday the t_shading_end_1 trigger is never triggering.
I use brightness sensors and t_shading_start works fine as I would expect so I guess the sensor is fine too.
The only difference I see is that the template for shading end is different from shading start but I’m not good enough at “code” to understand if that is the problem or not…
platform: template
value_template: |-
{{
(shading_temperatur_sensor1 != [] and states(shading_temperatur_sensor1) | float(default=shading_min_temperatur1) < shading_min_temperatur1) or
(shading_temperatur_sensor2 != [] and states(shading_temperatur_sensor2) | float(default=shading_min_temperatur2) < shading_min_temperatur2) or
(shading_brightness_sensor != [] and states(shading_brightness_sensor) | float(default=shading_sun_brightness_end) < shading_sun_brightness_end) or
(shading_forecast_sensor != [] and (shading_weather_conditions == [] or states(shading_forecast_sensor) not in shading_weather_conditions)) or
default_sun_sensor != [] and
(
(state_attr(default_sun_sensor, 'azimuth') | float(default=shading_azimuth_end) > shading_azimuth_end) or
(state_attr(default_sun_sensor, 'elevation') | float(default=shading_elevation_max) > shading_elevation_max) or
(state_attr(default_sun_sensor, 'elevation') | float(default=shading_elevation_min) < shading_elevation_min)
)
}}
for:
seconds: 600
enabled: '{{ is_shading_enabled }}'
id: t_shading_end_1
is the part after ‘default_sun_sensor != [] and’ correct?
It looks “formatted” differently compared to t_shading_start_1
platform: template
value_template: |-
{{
default_sun_sensor != [] and
state_attr(default_sun_sensor, 'azimuth') | float(default=shading_azimuth_start) > shading_azimuth_start and
state_attr(default_sun_sensor, 'azimuth') | float(default=shading_azimuth_end) < shading_azimuth_end and
state_attr(default_sun_sensor, 'elevation') | float(default=shading_elevation_min) > shading_elevation_min and
(shading_brightness_sensor == [] or states(shading_brightness_sensor) | float(default=shading_sun_brightness_start) > shading_sun_brightness_start) and
(shading_temperatur_sensor1 == [] or states(shading_temperatur_sensor1) | float(default=shading_min_temperatur1) > shading_min_temperatur1) and
(shading_temperatur_sensor2 == [] or states(shading_temperatur_sensor2) | float(default=shading_min_temperatur2) > shading_min_temperatur2) and
(shading_forecast_sensor == [] or shading_weather_conditions == [] or states(shading_forecast_sensor) in shading_weather_conditions)
}}
for:
seconds: 150
enabled: '{{ is_shading_enabled }}'
id: t_shading_start_1
Unfortunately, I don’t really understand the question.
If you only want shading to be started in cloudy weather, then you must also allow the value there.
Actually, this has nothing to do with the trigger, but rather with a condition.
From a purely technical point of view, I will probably have to remove the change in the weather situation as a trigger anyway. This is because I do not trigger the current status via the prediction, but via the current status. This is not actually logically correct.
I didn’t restart home assistant today and I update the blueprint yesterday so I guess that’s not the problem.
I was just looking at the code as a complete ignorant just to see if I could find anything…
About the override function, did I understand nothing for that too?
I agree that the resident sensor could be a trigger also for shading start… or something similar.
In these days at my home the conditions for shading are met at around 7 but nothing happens in the sleeping room as my wife is still asleep. When she wakes up, ie. 7.10, the triggers for shading are already over and the shading doesn’t happen.
Maybe it could be good to have a trigger like t_open_6 but for shading? Just an idea of course…
It’s not only updating the blueprint.
CCA is using “FOR” to track if all conditions are true for a defined time. And “FOR” can be crashed with every change you are doing within Home Assistant. So e.g. creating or changing any other automation can kill it.
An option is to switch to helper timer. But this would a) add complexity to the blueprint and b) add an additional cause of error if people are not creating one helper timer per automation or (by accident) use one helper timer for two automations … It’s a hell for anybody tries to do support.
all clear, thanks!
I think that was my problem then… I was “playing” with the parameters, probably I messed something up.
I will try to not touch anything today, I’m pretty sure it will be ok then.
all conditions are fine but FOR is not reached yet
you are changing something which touches any automation → something happing within HA which do a kind of reset (without doing a real reset) for triggers
All conditions are already fine. But it will not trigger. So the period of time defined for FOR will never be reached. Thus nothing will happen.
unfortunately I have to confirm that shading_out is not working anymore for me. I made a test:
- changed Waiting Time For Sun Shading End to 30 seconds - changed Sun Shading Azimuth End Value to a value that would trigger the shading_out in some minutes - changed Sun Shading Brightness End Value to a value that would trigger the shading_out in some minutes
- created a test automation that would send a notification to my phone with the same triggers (the ones above) as the shading_out
After the values changed, the notification arrived to my phone but nothing happened in the CCA automation. No triggers at all so I can’t send any trace sorry
Open, close and shading_in all works, just shading_out doesn’t
edit: I was able to make it work by creating a new automation… now I just have to find the differences and what I messed up… sorry for wasting your time
edit 2: I was missing shading_weather_conditions… my fault.
Time For Drive Up - Early On Non-Workday: 09:00
Time For Drive Up - Late On Non-Workdays: 11:00
assume that shading has triggered before drive up and its conditions (sun elevation) it seems that the blinds are opened at last at 11:00 even if shading already closed the blinds, is that correct?
Did I missunderstood the logic somehow? May I make sure that shading always triggers after drive up and its conditions?
Hi,
I replaced a fibaro FGR-224 Z-Wave module with a NODON SIN-4RS-20 Zigbee module and since then the shading doesn’t seem to work.
Under HA, when comparing the modules, I noticed that the NODON has a tilt command in addition to the open/close command.
I have the impression that CCA only controls the tilt for the NODON.
To open/close the shutters at night I use Scheduler Card, which controls the NODON correctly.
2024.08.03:
- Fixed: Helper length analysis template variable warning #120
- Fixed: New trigger "t_shading_reset" causes errors #119
- Fixed: "Manual Override" don't work #122 (Thanks to Eimeel)
- Fixed: Commenting out the check of the position information in the config check #121
- Fixed: Blinds not opening with resident mode when auto close disabled #115
Whether early or late, whether based on brightness or the position of the sun, the system always checks whether shading is already present when the roller blinds are raised each day.
Oh, brilliant. There is already a Fibaro FGR-224, which is nice to hear.
I look after a neighbor’s SmartHome and have installed FGRM-222s everywhere. They are okay, but I myself am glad that I have Homematic.
The FGR-223 had major problems under FHEM back then. I have no idea whether this is also the case under HA. In any case, I have avoided this model.
I like Fibaro.
To your question:
I’m pretty sure it’s not because of CCA.
I don’t know your devices. But the Zwave devices always have many configuration options. Or a calibration run is missing.
Unfortunately, I can’t help you there.
The FGR-224 works without a problem with CCA, it was configured correctly. I replaced it with the NODON SIN-4-RS-20 because under Z-Wave JS it is often in dead link (probably because of the firmware of the aeotec Z-Stick 7 controller).
It’s with the NODON SIN-4-RS-20 Zigbee module that I’m having problems, it seems to be poorly implemented under Zigbee2MQTT.
It has a command for the position and one for the tilt which don’t seem to be independent, if I change the position the tilt changes and vice versa.
I tried setting the tilt in the Position Configuration section of CCA, but without much success. The best I got was a 96% position instead of the 25% set.
I’ll just have to hope that Zigbee2MQTT fixes it.
Shouldn’t ventilation mode open the cover when the door/window is in closed or sun shade mode? I could not find a documenation about that feature and I wonder what it is supposed to do, as my cover do not move if I open the door/window.
Yes, that’s exactly how it should be.
I could take a closer look at the details with a trace.
But you have created a Cover Status Helper, haven’t you? You should have, because otherwise the shading wouldn’t work either.
That would be wonderful of you. The status helper is created, just as you thought. Here’s a trace of a window being opened while in sun protection mode.
