GithubHelp home page GithubHelp logo

ha-blueprints's Introduction

ha-blueprints's People

Contributors

cybe avatar hvorragend avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

cybe rainerstaude cupracer ekozan mithomas

ha-blueprints's Issues

Add checkboxes for different features

Individual Configuration

Various different options for fine adjustment.

  • Prevent the cover from closing immediately after deactivating the lockout protection

  • Prevent the cover from moving to a higher position when it is closed

  • Prevent the automation from moving to a higher closing position at the end of shading

  • Preventing the use of the get_forecasts service. (Possible problems with get_forecasts service in DWD integration)

  • Prevent the end of shading when the cover is already closed

  • Allow a delay in ventilation mode :

    My use case is that I have a cover which I don’t close completely, so I can see our cat if she sits outside, and I don’t want the ventilation mode to kick in immediately when I let her in or out.

  • Ignore shading, ventilation, opening, closing after manual position changes

  • Hotdaycheck: Forecast and not just current temperature: The blinds should not be opened at all when it gets very hot.

  • It is permitted to move to a lower position than the shading position when closing

  • Can fully closed roller blinds be moved to the closed position when closing?

  • Checkbox while closing? "{{ cover_status_helper_enabled and cover_status_shading and (close_position < shading_position) }}"

Do not compare the current day with the day of the timestamp

This is not really the best solution, because if you adjust your cover (position_tolerance=10) after 0:00 than you have a newer close-day.

"{{ is_status_helper_enabled and (now().day != is_cover_closed_ts|timestamp_custom('%-d')|int) and not is_cover_closed }}"

I have to find a better solution for that :-)

Lockout protection and ventilation mode should have different sensors (And maybe 2 of them)

Hi.

_

🚪💨 Contact Sensor Entity
The contact sensor is required for lock-out protection and for ventilation mode. It must be a binary two-way contact sensor.
Lock-out protection:
The roller blind is not closed if the door contact is on or true.
Ventilation mode:
If the door contact changes to on/true, the roller blind is moved to the ventilation position. After the status changes to off/false, the close position is activated. The same applies in the shading-out situation.

_

  1. I have a room with 2 windows with 1 common roller blind. so i need 2 sensors for monitoring, am i right?

  2. i have another room with a balkony door. for lockout protection i take the sensor for the door handle. but when i use this, it will close the blind to my ventilation high (20%).

is it possible to separate these two cases, one sensor for lockout and one for ventilation? and 2 input options for sensors for ventilation? but i could create a group, so it is not so important..

Feature Request: Close windows again after ventilation.

The roller blind was closed. I opened the window. The ventilation function opened the roller blind by 30%.
Now I have closed the window again, but the roller blind does not lower again.
I have not seen a function to activate this.

Expected behavior:
Move to the position as it should be after ventilation.

Closing the door contact should always lower the roller

Closing the door contact should always lower the roller blind in the evening. It should not be checked whether a closing operation has already been made during the day.

  • During the day: Reopen
  • At night: Close again.
  • If previously shaded: Return to shading position

Open after shading when blind should not be closed yet

Currently, one of my blinds moves to ventilation position after shading, when the contact sensor has been opened while shading. I think the blind should move to open position after shading if none of the conditions to close it are met (i.e. time, sun altitude etc.).
The configured shading position is 42% and the ventilation position is 18%.

The blind next to this is configured the same but has no automatic ventilation. While the first blind moves to ventilation position, the one next to it moves to open position.

I think the problem is in one of the following lines of code:

ha-blueprints/blueprints/automation/cover_control_automation.yaml

Lines 2344 to 2371 in 8007002

- if: # Ventilation after shading end
- "{{ is_ventilation_enabled }}"
- "{{ contact_sensor != [] and is_state(contact_sensor, ['true', 'on']) }}"
then:
- if:
- "{{ not prevent_default_cover_actions}}"
then:
- repeat:
for_each: "{{ blind_entities|list }}"
sequence:
- alias: "Moving the cover to ventilate position"
service: cover.set_cover_position
data:
position: !input ventilate_position
target:
entity_id: "{{ repeat.item }}"
- if:
- "{{ state_attr(repeat.item, 'current_tilt_position') != none }}"
then:
- alias: "Moving the cover to tilt position"
service: cover.set_cover_tilt_position
data:
tilt_position: !input ventilate_tilt_position
target:
entity_id: "{{ repeat.item }}"
- alias: "Wait 1-5 random seconds to prevent sending to many commands to covers at same time"
delay:
seconds: "{{ (range(1, 3)|random|int) }}"

Individual opening and closing times

Posted in the community thread:

If you allow I would like to ask if it is possible to add a more sophisticated calendar for individual opening and closing times. More like individual programmes per day.

Hi Herr.Vorragend, well, the work shift schedule might change or be different per weekday. Or pupils have later school on certain days.
So it would be great if it would be possible to open the rollers e.g. on Monday, Wednesday and Friday at 6:30am, on Tuesday at 7:30 and on Thursday at 8:15. On Saturday and Sunday at 9:00 (or dependent on the sun elevation). Same for closing during the weekdays at 22:30 but on weekends on 23:15.

flexibe weekday opening and closing time schedules

Hi @hvorragend , please refer to issue no 6...
thank you for continuouing the work on the roller
I'd like to propose to add weekday opening and closing time schedules.

Use Case: The work shift schedule might change or be different per weekday. Or pupils have later school on certain days.

Suggestion: So it would be great if it would be possible to open the rollers e.g. on Monday, Wednesday, Thursday and Friday at 6:45am, on Tuesday at 7:35am. On Saturday and Sunday at 9:05am (or dependent on the sun elevation?).

image

And the same for closing during the weekdays at 22:30 but on weekends on 23:15.

It'll be great if this could be added into the blueprint.
Thanks in advance
Kind regards

Why do I need is_status_helper_enabled AND is_status_helper_disabled?

One should actually be sufficient and should only be answered with TRUE/FALSE.

  # Own code helper
  is_status_helper_enabled: >-
    {{
      'cover_helper_enabled' in cover_status_options and
      cover_status_helper != [] and
      states(cover_status_helper) | regex_match("((\[[^\}]+)?\{s*[^\}\{]{3,}?:.*\}([^\{]+\])?)")
    }}

  # Fallback for disabled helper. Absolutely necessary for the first run if the helper is not yet set.
  is_status_helper_disabled: >-
    {{
      'cover_helper_disabled' in cover_status_options or
      cover_status_helper == [] or
      states(cover_status_helper) == [] or
      not states(cover_status_helper) | regex_match("((\[[^\}]+)?\{s*[^\}\{]{3,}?:.*\}([^\{]+\])?)") or
      states(cover_status_helper) in ["unavailable", "none", "unknown"]
    }}

Suggestion: Improve Structure on GUI

Currently it is not easy to orientate on all different settings. Would it be possible to re-order by category and add header-titles for the diff. Segments ?

E. G. Combine sub-protection (azimuth, elevation, temperatures) in one segment and add a header to it.

Thanks for the great work !!!

Shading overrides lockout

Hello :)
When lockout-protection is active, cover drives for shading. That is very bad, because my wife was getting locked out, when she was in the garden for sunbathing.

Thank you

When is shadding triggered?

thanks for the blueprint - I am trying to get it to work and had moderate success so far. The auto-up/down is working lieka treat but shadding is still giving me trouble.

I am trying to figure out what is going on but in the traces from this morning I can see it triggered around 11:40 and stopped when checking the weather forecast. I had given it openweathermap as the source, but it only provides forecast for for 3hour intervals - not daily which is what the blueprint is expecting.

I have now changed the weather source, but the shadding has not triggered again (despite "Allow shading to activate multiple times a day" being selected). Seemingly all conditions to Shade-in have been met:

Current state
image

required conditions:

id: '1713370561013'
alias: office blinds automation
description: ''
trace:
  stored_traces: 50
use_blueprint:
  path: hvorragend/cover_control_automation.yaml
  input:
    blind: cover.blinds_office
    auto_options:
      - auto_up_enabled
      - auto_down_enabled
      - auto_sun_enabled
      - auto_shading_enabled
    cover_status_options: cover_helper_enabled
    cover_status_helper: input_text.office_blinds_helper
    drive_time: 90
    time_up_early: '06:30:00'
    time_up_early_non_workday: '07:30:00'
    time_up_late: '07:30:00'
    time_up_late_non_workday: '09:30:00'
    time_down_early: '21:00:00'
    time_down_early_non_workday: '21:00:00'
    time_down_late: '23:00:00'
    time_down_late_non_workday: '00:00:00'
    brightness_time_duration: 120
    brightness_down: 600
    position_tolerance: 5
    workday_sensor: binary_sensor.workday_sensor
    shading_position: 40
    shading_brightness_sensor: sensor.average_illuminance
    sun_time_duration: 60
    sun_elevation_up: 3
    sun_elevation_down: -5
    drive_delay_fix: 2
    shading_sun_brightness_start: 250
    shading_sun_brightness_end: 80
    shading_azimuth_start: 140
    shading_azimuth_end: 270
    shading_elevation_min: 10
    shading_min_temperatur1: 14
    shading_forecast_temp: 14
    shading_weather_conditions:
      - clear
      - partlycloudy
      - sunny
      - exceptional
      - cloudy
      - windy
    ignore_after_manual_config: []
    individual_config:
      - allow_shading_multiple_times
    check_config: true
    check_config_debuglevel: info
    shading_min_temperatur2: 18
    shading_waitingtime_start: 120
    auto_shading_start_condition:
      - condition: numeric_state
        entity_id: sensor.openweathermap_cloud_coverage
        below: 80
    shading_waitingtime_end: 1200
    shading_forecast_sensor: weather.forecast_home_2
    shading_temperatur_sensor1: sensor.soil_tester_temperature
    shading_temperatur_sensor2: sensor.humidity_living_temperature

Include Wind-Sensor

Hey,

at my mothers house I have some wind sensitive covers which need to be opened when the wind is to strong.
I was trying to achieve this by setting the "Force Open" option with a boolean sensor, but it seems that the automation is not going back to normal operation after the sensor is set to "false" again.

For example if it was closed (at night) beforehand it stays now open until the rest of the night.

Is there a way to achieve this with this somehow? If not would be great to have this option in an future version.

Kind regards

[Feature Request] Frost protection (or: auto_ventilate_force)

Currently looking into this blueprint to migrate my shutter automation away from NodeRed to HA internal I found only one thing missing: Frost protection

I have some aluminum shutter on some glass roof and noticed that even with the slightest temperatures below zero it tends to freeze and gets stuck when opening. So in order to protect the motor from having to stop by itself I thought it would be nice to have some sort of option to set temperatures when the shutter should not be opened. This could also be more generic allowing to also define a higher temperature when it should remain down (eg. if a night was already >21°C it's expected to be more hot during the day so the shutter should not open at all; however protecting the motor when the shutter froze seems to me the more important case).

It would be great to have something like that build in as an selectable option to select a sensor and temperature when to prevent from opening.

Thanks in advance and thanks for the awesome blueprint!

Add trigger for Windy Days

I believe a feature which is missing from this fantastic blueprint is a trigger for windy days.

An example is that I use this for external blinds on my patio, however, they are rated up to a particular wind speed and I'd prefer the blueprint to either 1) Not close the blinds if the wind speed is above a set value, 2) Trigger the blinds to open if the wind speed is above a set value.

This would go a long way in preventing the blueprint from running in weather conditions that could damage the blinds. :)

Keep up the great work.

Extend the sun-protection with a second level

Another feature idea from a use-case I have frequently for the sun-protection:

As of now you included current and max temperature. If both are fulfilled, the shutter will go to the desired position. E. g. Current temp > 20 C, max temperature > 24 C to position of 30%. I totally like this setup to identify the need of protection!

But would it be even possible to have a heat protection, where you set for current a different temperature (eg 26 C) and a different position (eg 10%)? In short: just extend the sun-protection with a second level to differentiate closing position between warm days and hot days.

Just an idea and you are the only one to decide if this makes sense.

Source: User Bostil (https://community.home-assistant.io/t/cover-control-automation-cca-a-comprehensive-and-highly-configurable-roller-blind-blueprint/680539/223)

Ventilate when cover position smaller than ventilation position

Could you please check, if it's possible changing ventilation behaviour/condition to
"ventilate if contact sensor is on and actual position ist smaller than ventilation position"
instead of
"ventilate if cover is closed".

I'm using 🦮 Cover Status Helper.

Tilt on covers via a script

This is a great blueprint!

I am pretty green into HA, but I have several shellyies that I am using for controlling external shades that I would like to tilt, but Shelly 2PM, which I am using, does not have support for tilt at the moment.

I found an article about tackling tilt-faking https://medium.com/@lukasvice/a-utility-script-for-controlling-venetian-blinds-with-shelly-in-home-assistant-2e5cbf2d8d5f

If I understand it well, the article suggests creating a script script.cover_position_tilt, which is equivalent to cover.set_position_tilt. Would it be possible to externalize how tilt is called in your blueprint? If I am right, it would let me tilt my shades via your blueprint!

Thanks

Allow controlling a input_boolean helper as entity

I'd like to use the blueprint to control a input_boolean helper. Unfortunately this isn't possible at the moment, it isn't available in the list of entities in the blueprint.

The reason for this wish is that I'm controlling multiple Velux shades via the Velux Gateway (Homekit), connected to Apple Home since 2022. When I attempted to remove them from Apple Home and readd them in HA last year, I ran into major issues.

I therefore decided to keep the shades with Apple Home and instead expose input_boolean.blinds_target_state from HA to Apple Home via Homekit Bridge. In Apple Home I have a simple automation that will open/close all shades based on the state of this exposed helper.

Is there any way to adapt the blueprint to allow controlling input_booleanas entity? Thanks!

Shading activates when door is open - goes to wrong position after manual re-open

Version: 2024.04.08-01

Today I was sitting on my terrace, the door opened (contact in correct state) but the shutter tried to go to shading position anyways.

I noticed it and stopped the motor, sending it to open position again using the local controls on the actor (HMIP-BROLL-2 if relevant).
The actor sent the new position to HA so it was aware, that the shutter is fully opened again.

The shutter did not close again this day.

When shading ended, the said one wrongly went to ventilate position instead of open.
I will open a second issue for that as I beliave this is not related. Just noting this here in case it matters.

brightness_down wouldn't be saved

The value for brightness_down wouldn't be saved.

here the trace of my configuration

id: '1713551064226'
alias: Rollladen-Bar
description: ''
use_blueprint:
path: hvorragend/cover_control_automation.yaml
input:
blind: cover.bar_rollladen
auto_options:
- auto_up_enabled
- auto_down_enabled
- auto_brightness_enabled
open_position: 100
time_up_early: '07:00:00'
time_up_early_non_workday: '07:15:00'
time_up_late: '07:30:00'
time_up_late_non_workday: '07:45:00'
close_position: 0
default_brightness_sensor: sensor.hmip_swo_pl_00181be9a427de_beleuchtungsstarke
brightness_up: 10
check_config: true
workday_sensor: binary_sensor.workday_sensor
cover_status_options: cover_helper_enabled
cover_status_helper: input_text.rl_bar
brightness_down: 1

Lockout protection possible?

Hi,
how can I set up a lockout protection for my patio door?
I would like to integrate this is an essential feature of such a door and I don't want to set up any faked vacation boolean helper.
Regards,
Lars

Description for "Additional Condition For Opening The Cover" doesn't make sense

The description says:

"With this condition you can prevent the automation from opening the cover. You can use this, for example, if the covers normally don't open, but you really want to do it on vacation."

So what does the condition do, if it is met? Will it make the cover go up or does it stay down?

e.g. what will happen with the following condition?
image

Allow shading to activate multiple times a day

Based on this post in the HA forums.

I’d like shading to activate and deactivate depending on the current brightness level. Not only once, but multiple times a day. Currently, this transition is only allowed once per day if the "Cover Status Helper" is being used.

Allowing multiple transitions might interfere with manual corrections, so this mechanic should be optional.

Return to shading after ventilation

Hi!

I setup CCA to only use shading and ventilation. I trigger ventilation with a presence sensor. The thought is to open the cover temporarily during active shading to have some light in the room. The ventilation got activated as expected. But when the "Contact Sensor Entity" returned to off, the state of the cover remained in the ventilation position. Shouldn't the cover return to the shading position, like it was before?

Blueprint version: 2024.03.21-01
Blueprint configuration:

blind: cover.bad_terrasse_doppelwippschalter_rolladen
auto_options:
  - auto_shading_enabled
  - auto_ventilate_enabled
shading_position: 20
shading_brightness_sensor: sensor.gzcgq11lm_a_illuminance_lux
shading_sun_brightness_start: 30000
shading_sun_brightness_end: 25000
shading_azimuth_start: 40
shading_azimuth_end: 195
shading_elevation_min: 10
cover_status_helper: input_text.cca_bad
cover_status_options: cover_helper_enabled
contact_sensor: binary_sensor.bthome_sensor_91de_motion
ventilate_position: 75
auto_ventilate_options:
  - ventilation_if_lower_enabled
position_tolerance: 5

Attached are three traces:

  1. Activate ventilation on motion detection (Contact Sensor Entity = On)
  2. Some trigger for the current position
  3. Trigger for Contact Sensor Entity = Off)

The third trace however did not result the cover to be switched back to shading.

The state of the status helper before trace 1 was:

{
  "open":{
    "a":false,
    "t":0
  },
  "close":{
    "a":false,
    "t":0
  },
  "ventilate":{
    "a":false,
    "t":0
  },
  "shading":{
    "a":true,
    "t":1711097531
  },
  "locked":{
    "a":false,
    "t":0
  },
  "manual":{
    "a":false,
    "t":1711055450
  },
  "p":100,
  "v":4,
  "t":1711097531
}

Trigger on status change of (Additional condition for the entire automation)

Hi hvorragend

I use the additional conditions true/false to completely deactivate the automatic shutter function in certain situations.

It would be great if the automation would trigger after a status change of the additional conditions (e.g. off to on) to move to the correct shutter position.

Thank you for your time and great work.
flyboy1

Implement lukasvice/cover_position_tilt.yaml?

Implement lukasvice/cover_position_tilt.yaml?

https://gist.github.com/lukasvice/b364724d84c3ac4e160f7a7d8fa37066

Hi Herr.Vorragend,

did you considered maybe already a situation where there is need for tilting for venetian blinds and we have no such functionality by the module itself (for example, Shelly 2.5 or Shelly 2PM).
I am using following script for tilting and it work like a charm: Home Assistant script to control venetian blinds with Shelly · GitHub 1

I tried to merge it with your code but I had some difficulties and it is not working for me :slight_smile:

Could you maybe include this in the CCA as selection? For example people could tick a checkbox if they use script for tilting (script.cover_position_tilt with parameters will be called) and if not the default (cover.set_cover_tilt_position) will be used.

I think it would be useful for a lot of people.

Source: https://community.home-assistant.io/t/cover-control-automation-cca-a-comprehensive-and-highly-configurable-roller-blind-blueprint/680539/86

  • Checkbox for disabling the default actions
  • Additional actions for for open, close, ventilation and shading

Tilt for open and ventilate position

Hi hvorragend
first of all thank you for your great work!

All of my Covers have slats. Is it possible to integrate the tilt position not only for shading?
It would be nice if you could do the same for open Position and ventilate Position.

Take a look at adaptive_cover.yaml Line 115 - 134

Thank you and kind regards
flyboy1

Shutter goes to ventialte instead of open after shading

Version: 2024.04.08-01

Today, I was sitting on my terrace so I had the door open, shutter opened completely while all other shutters were in shading mode.
Worth to note, as described in #58 , I manually sent it to open after it closed to shading position (it never reached the shading level).

When shading ended this day, the said one wrongly went to ventilate position instead of fully open (the door was open).

Why does "Forecast Temperature Value" also use the "shading_temperature_sensor1" sensor?

Forecast Temperatur Value
Minimum temperature for forecast sensor above which shading should occur. NOTE: If temperature sensor1 is also defined and its temperature rises above the value defined here, this condition is considered to be TRUE.

    - or:
        - "{{ ( shading_forecast_sensor == [] ) and (shading_temperatur_sensor1 == [] ) }}"
        - "{{ ( shading_forecast_sensor != [] ) and (not prevent_forecast_service) and ( weather_forecast[shading_forecast_sensor].forecast[0].temperature | float(default=shading_forecast_temp) >= shading_forecast_temp ) }}"
        - "{{ ( shading_temperatur_sensor1 != [] ) and (states(shading_temperatur_sensor1) | float(default=shading_forecast_temp) >= shading_forecast_temp) }}"

Centralize config

Hi! I really like your blueprint, it is a great piece of code!

I will be using it on several windows and I wonder if it would e possible to pull out some common configuration to a central helper.
I am thinking about hings like light levels, temperature tresholds elevation tresholds...

Imagine a house with 6 windows into one direction, you'd have to set up 6 individual configurations and change 6 configs for any change.

Or maybe it would be possible to contorl multiple windows with one CCA instance while keeping the control on a per shutter basis (I mean that CCA doesn't get confused as it would with a group today)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.