This also did not work for me, attached you can find my trace i hope this can help identify my problem, thanks so much
I have found a bug.
############################################################
# ANCHOR: CONTACT CLOSED
# Source: Ventilation, Lockout
# Target: Open, Close, Shading
############################################################
- alias: "Contact sensor closed"
conditions:
- "{{ is_down_enabled }}" # Only close if it is allowed
The first condition doesn’t fit to your config.
I will remove it.
I cannot scroll your trace on the jsonblob-website on my mobile phone. I’m sorry, but you’ll have to wait until I have the computer on.
looks like that solved the problem!
thx
New Update
2024.06.29:
- Breaking change: The checkbox introduced in the last update "reset_manual_detection" has been moved to a separate selection. Please reconfigure.
- Added: Time and timeout in minutes to reset the manual override #95
- Added: Additional Actions After Override Reset #94
- Fixed: The cover may also be closed after ventilation if the down mode is not activated
- Many thanks to crandler for the ideas
Please note the breaking change:
The checkbox introduced in the last update “reset_manual_detection” has been moved to a separate selection. Please reconfigure.
By the way
- Link to “Buy me a coffee” added
- Licence added due to the new upcoming feature in Core 2024.7 “Take control over a blueprint-based automation or script”
With the current blueprint, the contact sensors no longer work for me. I have created 2 template helpers for my 3-way sensor (Homematic) for ventilation and lockout protection.
alias: Shuttercontrol - Fenster OG_3_F2
description: ""
trace:
stored_traces: 20
use_blueprint:
path: hvorragend/cover_control_automation.yaml
input:
blind: cover.og_3_f2_rollo
auto_options:
- auto_up_enabled
- auto_down_enabled
- auto_sun_enabled
- auto_ventilate_enabled
- auto_brightness_enabled
- auto_lockout_protection_enabled
cover_status_options: cover_helper_enabled
cover_status_helper: input_text.shutter_og_3_f2_status
time_up_early: "05:30:00"
time_up_early_non_workday: "08:00:00"
time_down_late: "20:00:00"
time_down_late_non_workday: "20:00:00"
default_brightness_sensor: sensor.ms_garagentur_illuminance
brightness_up: 45
brightness_down: 42
position_tolerance: 2
workday_sensor: binary_sensor.workday_sensor
contact_sensor: binary_sensor.shutter_og_3_f2_status_griff_gekippt
ventilate_position: 20
shading_position: 35
shading_waitingtime_start: 60
shading_waitingtime_end: 900
individual_config:
- prevent_shading_end_if_closed
- allow_shading_multiple_times
sun_elevation_up: -1
sun_elevation_down: -1
contact_sensor_lockout: binary_sensor.shutter_og_3_f2_status_griff_offen
auto_shading_start_force: input_boolean.shutter_og_3_f2_switch_shading
auto_up_force: input_boolean.shutter_og_3_f2_switch_opening
auto_down_force: input_boolean.shutter_og_3_f2_switch_closing
drive_time: 45
workday_sensor_tomorrow: binary_sensor.workday_sensor_tomorrow
ignore_after_manual_config:
- ignore_shading_after_manual
auto_up_condition:
- condition: state
entity_id: input_boolean.shutter_og_3_f2_switch_vacation
state: "off"
shading_temperatur_sensor2: sensor.weatherman_sonnen_temperatur_gleitend
shading_min_temperatur2: 35
hvorragend/cover_control_automation.yaml konnte nicht geladen werden
Invalid blueprint: min and max are required in slider mode for dictionary value @ data['blueprint']['input']['override_section']['input']['reset_override_timeout']['selector']. Got {'number': {}}
…beim Erneut importieren der Blaupause
Please re-import.
Strangely enough, I did not have the error with the same code base. But I was able to recreate and fix the error.
Thank you.
Done, it works
This is the traces of the position changes. I need the one before (I think).
What exactly is not working?
According to the trace, opening it worked.
The roller shutter currently moves to the ventilation position when the handle is tilted. However, when the window is opened (handle sensor open), the roller shutter does not move to the lock protection position.
Edit: If the shutter was in the ventilation position, the window is then closed when the handle is in the open position.
Edit: In the course of the status helper, it is always displayed that the automation was triggered by the handle tilted.
Template (open)
{{ not is_state('sensor.og_3_f2_griff', ['closed','tilted']) }}
Template (tilted)
{{ is_state('sensor.og_3_f2_griff', "tilted") }}
I have edited my post.
When I switch on the check in the automation and then start it manually, I get the following errors in the Home Assistant Core protocol
Logger: homeassistant.helpers.template
Quelle: helpers/template.py:2629
Erstmals aufgetreten: 08:22:22 (4 Vorkommnisse)
Zuletzt protokolliert: 09:10:03
Template variable error: 'dict object' has no attribute 'from_state' when rendering '{{ trigger.from_state.state not in ['unavailable', 'unknown', 'none', 'query failed'] }}'
Logger: homeassistant.helpers.script
Quelle: helpers/script.py:851
Erstmals aufgetreten: 08:22:22 (2 Vorkommnisse)
Zuletzt protokolliert: 09:10:03
Error in 'choose[3]' evaluation: In 'template' condition: UndefinedError: 'dict object' has no attribute 'from_state'
I’m sorry. I always try to keep track of things, but I really overlooked your post yesterday.
It sounds to me as if the shading had never been activated. And the opening of the blind was the normal daily opening of the blind.
But it’s difficult to answer if I don’t have a basis in the form of a trace. The configurations here in the forum are simply too different for that.
Maybe there was even a bug. But I can’t remember that. But shading is used by some users here in the thread without other features. That should work.
I don’t think we can currently achieve this via CCA. There are simply too many individual requests. But with the Force functions, you might be able to realise it from outside - i.e. with your own automation.
As I said, this should work. And in the worst case, you can prevent it with an additional condition of your own. CCA is quite flexible here.
That’s not a bad thing. This is simply because the code was executed manually. However, I have come up with a fix that will be included in the next version.
There is no lockout position. There is a lockout protection, but it has no position. Nothing simply happens. The executing roller blind movement is simply blocked.
I am sorry. I don’t understand all this.
Would you like to send me a personal chat message in German?
That’s what it does. After all, it’s always the same handle. You have only interposed the templates. But HA sometimes notices this and resolves it.
I think we can ignore that.
And one more request:
I need traces. Otherwise it’s all really difficult for me.