Smart Cover Automation - new custom integration

Share your Projects! Custom Integrations
, ,
22

Please read the documentation.

The window position is called cover azimuth and needs to be configured as documented here.

The integration has a feature called manual override detection that detects manual adjustments and pauses the automation to avoid conflicts. The pause duration is 30 minutes by default, but can be adjusted.

23

I can read, and I have read extensively. Your overall approach may be interesting (for you), but in my case, I would like to be able to do at least what I currently do in YAML:

  • Be able to completely disable automation for a section (e.g., guest room, where visitors can do what they want, unless the alarm is set, in which case it closes).
  • Manage positions, delays, and schedules individually (by room).

In fact, it should be possible to install multiple instances of the integration.

It’s a shame because it seems clean and well documented.

24

Version 1.2 is available!

You can now set up multiple instances of the integration to create cover groups, each with their own configuration.

The new version comes with additional improvements and bugfixes, e.g. Fahrenheit as temperature unit is now supported correctly.

2 Likes
25

Thanks for the multiple requests :wink:

I’ll continue my tests.

26

Just found this integration looks nice.
I made this protection / lock automation for wind and rain.


alias: Screens
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.buienalarm_neerslag
    above: 0.099
  - trigger: numeric_state
    entity_id:
      - sensor.buienalarm_volgende_neerslag
    below: 6
  - trigger: numeric_state
    entity_id:
      - sensor.average_wind_speed
    above: 28.9
conditions:
  - condition: or
    conditions:
      - condition: and
        conditions:
          - condition: numeric_state
            entity_id: sensor.buienalarm_neerslag
            above: 0.099
          - condition: numeric_state
            entity_id: sensor.buienalarm_volgende_neerslag
            below: 6
      - condition: numeric_state
        entity_id: sensor.average_wind_speed
        above: 28.9
actions:
  - action: smart_cover_automation.set_lock
    metadata: {}
    data:
      lock_mode: force_open
    target:
      device_id: 50a95aac3675af5f71f03967b0674b0b
  - wait_template: >
      {% set wind_safe = states('sensor.average_wind_speed') | float(0) <= 29 %}
      {% set rain_safe = states('sensor.buienalarm_neerslag') | float(0) <= 0.1
      and states('sensor.buienalarm_volgende_neerslag') | float(999) >= 5 %} {{
      wind_safe and rain_safe }}
    timeout: "02:00:00"
  - delay:
      minutes: 30
  - action: smart_cover_automation.set_lock
    data:
      lock_mode: unlocked
    target:
      device_id: 50a95aac3675af5f71f03967b0674b0b
mode: restart

Would be nice if we could use sun sensor in lux or w/m2

1 Like
27

Version 1.3 is available!

Three new features requested by the community are now available:

  • Tilt angle control
  • External control option for sunny weather state
  • Absolute time for evening closure
1 Like
28

Version 1.3.1 is available!

This new version has several improvements that increase the resilience and fix bugs with the following:

  • Evening closure
  • Tilt angle control
  • Manual override detection
29

Version 2.0 is available!

This new version adds additional external control options to further increase the integration’s flexibility, specifically for:

  • Weather hot?
  • Tilt angle

In both cases, external controls are available as global and per-cover entities to allow for individual control per room.

2 Likes
30

Use your PV to determine if it’s currently sunny!

Much more accurate than relying on the weather forecast and doesn’t require any hardware that you don’t already have (assuming a PV, of course).

Full documentation with template sensor definitions:

31

Thank you very much for this integration; it’s well done and well documented.

I’ve got a small problem :slight_smile:
In the configuration wizard, step 6, Time Settings, I can configure “Evening closure”, but I never see the “Morning opening: mode” options, so I can’t set the shutters’ opening times in the morning.
How do I enable this option?
I’ve tried reinstalling Smart Cover Automation 2.0.0 several times, restarted HA, checked every step of the wizard, and tried installing an older version… without success.

Have I missed something?
Thank you for your excellent work

Hervé

1 Like
32

Thanks for your kind words, @coyotte14. And I need to apologize: the morning opening time is going to be available with version 3.0 of the integration. Unfortunately, the website theme I’m using doesn’t support maintaining different versions of the docs, one per product version. As the implementation work on 3.0 is already done, the docs are also already updated. I am painfully aware this is not optimal as the latest published release is still 2.0.

What you can do:

  1. What for 3.0 to be released. Shouldn’t be long now.
  2. Use the current integration code from the main branch, which is most likely what’ll be released as 3.0 unless bugs are found.
33

Thanks for the quick reply. No problem, I’ll wait for version 3.
Thanks again.
Hervé

1 Like
34

Version 3.0 is available!

This new version adds and improves a ton of things:

  • Morning opening time (complementing evening closure time)
  • Minimum daily temperature for heat protection
  • Automatic reopening during the day
  • Evening closure cover position
  • Re-close covers opened manually during the night

Please note that the integration now requires Home Assistant 2026.4.1.

35

Question is it possible to have in the weekend other morning opening times?

36

@TheMystery Yes, of course. You can specify the morning opening time from your own automation according to your preferred schedule (docs).

37

Oké thx overlooked that, than I wil make an automation for it.
And is there a solution for the evening close to do this on summer time at a specific time and in wintertime at sunset?

38

There’s currently no way to automate that.

39

Ok, than only solution is too add it 2 times and enable/disable the automation for summer and winter time?

40

You could, of course, set up an automation to handle this, but as part of an integration, you could add two switches:

  • Alarm : This could, of course, be combined with the “mode” setting, but we could also have the option to configure the alarm_control_panel entity… anyway, just an idea…

  • Guest : The idea here is to bypass the automation without deactivating it, when a guest is present in the room.

I’m trying to test and manage what I’ve set up so far. And thanks for the ability to manage multiple zones.

41

Dear Helge, thank you very much for this excellent work. It is meant to help me keep my conservatory cooler during the summer. Conservatories are very sensitive environments and require sophisticated automation. I see a lot of potential in your solution, but I would like to offer a few suggestions:

  1. Use of dedicated entities for local micro‑weather: If the user has their own weather stations (I have one) and light sensors (every outdoor motion detector has one, and so does every standard weather station), you can capture real‑time conditions and control the slats and the awning more precisely.
  2. Temperature is a truly important metric and often differs significantly from general weather reports. It’s not uncommon for the temperature at my place to deviate by several degrees.
  3. In my previous automation, I also integrated an air‑conditioning unit. When the sun heats up the conservatory strongly, the AC should kick in as well. This isn’t essential for your integration, but I wanted to share it as a practical example.

I hope my input is helpful to you.

Thank you very much and best regards, Dimi