Auto Lock function understanding or behavior options

[oesip]

Checklist

• I have filled out the template to the best of my ability.
• This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
• This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.

I started using the shadow control for the shutters in the house some days ago. So far very helpful but I have some struggles with the auto lock function. First general question. Is that right: currently any not from shadow control triggered movement of the shutter activates the lock and it stays until I manually unlock it? There is no automatic unlock, something like moving the shutter fully up or after the conditions for the day (like out of the sun) continuously false. The idea is that such reset must be always triggered from outside, right? If that understanding is wrong, maybe you can forget about the comments below and just get me a hint how to configure it. I have some use cases where „auto lock“ is helpful but later requires manual intervention or additional automation. I use controllers for each shutter that has a a daily timer Funktion to close and open for the night. That’s configured for each window independently while shadow control combines all windows per floor and side of the house. This causes each morning „auto lock“ is activated and shadow control does not work automatically. Other than this sometimes we must manually close the blinds in the kitchen in the morning, but then leaving the house for work. The „WAF“ is not very high if my wife needs to do extra actions to keep the automatic function running.

Describe the solution you'd like

So any chance to get some options for the „auto lock“ function like: 1. dont use it, 2. reset by time, 3. reset by condition ( out of sun, fully up after manual movement, or something else), 4. a timer, no idea what also would make sense and makes the reset simple.

Describe alternatives you've considered

create some reset function via external automation.

Additional context

Other than that, very helpful integration for my needs. Thank you best regards Peter

[starwarsfan]

Hi
Thx for opening the issue.

The main goal of the integration is to handle the whole shutter movement, so in any case the shutters are moved from something or someone else than the integration itself, the instance is going into auto lock. That is intentional and so expected behaviour in your case, where the shutters are moved by the actor during the night.

At the moment there is no internal functionality implemented, which covers the four suggestion you made. So for your case with the movement by the actor you should setup an additional automation to unlock the integration, which is triggered by the actor in the morning, right as it opens the covers. But in the sense of the Shadow Control features, you might disable that functionality within the actor and let the integration close/open the shutters at dawn. That's why shadow and dawn handling are two separate things.

If you need to close some shutters manually in the morning, then usually the threshold is too high. To handle this better, you might check out the settings around adaptive-brightness-control.

Additionally and if I understand you right, you're using one instance to handle multiple shutters. Is that right? As stated on the documentation, this only works right, if the shutters respectively the facade where they are located have the same azimut, offsets a.s.o. So it might be better to have separate instances for each window because then you could handle such things like the open/close/tilt state of each window independently.

[oesip]

Hello,
Thanks for your reply and explanation. I want to start to answer the easy items first.

1. multiple instances - sure I combined only shutters that I want to have same behavior (like left end right side of a big glass facade at the kitchen, so mainly each side of the house and floor separated. That’s works and I could setup independent ones but they would have same configuration values.
2. Adaptive brightness control works very well since the bug with the Value (5000) is fixed. That’s a big advantage especially in the morning.

But back to my issue with the auto lock. I agree, it would be goos if the shadow control handles everything and (if I would live alone) I would let the automation do all automatically fine. However that’s not the case. My mother lives in the ground floor in her own apartment but she is in the wheel chair. So if whe want to take a rest after lunch or want to watch TV, she wants to close she shutter in the room with Alexa. That works, but then she opens it and leaves the room. When she goes to bed the shutter will not close, because its auto locked. If she closes manually it will not open in the morning and also not close half because of the sun shining in. I can’t teach her to unlock it again. That’s just one example where auto locked gives me a hard time. Also there are other cases. That’s why in general I think auto lock is a goos idea, however, it would be better if the Funktion Hase some configuration option ( disable, a timer, wait next trigger or something else to not lock the functions forever.

I hope I could explain a bit. The shadow function is exactly what I was looking for and the many setup parameters make e very good adjustment to all needs. Only headache for my wider rollout is the auto lock ;-) best regards Peter

[starwarsfan]

Hi Peter

Thx for the feedback, that confirmed my assumptions.

To just disable the autolock in some way would re-introduce a lot off issues, which are solved with the autolock at all. So just implementing an option to disable autolock would not be a solution.

Simply think about repositioning if there are updated values like the sun position or brightness. If the shutter would be moved manually without autolock and some seconds after that the sun integration (or your weather station or whatever...) delivers new values, the manual positioning would be reverted. That was a huge show stopper before the autolock was implemented and you would also run into this issue.

I'm not sure if it's a good idea to introduce a timer option to unlock the autolock because that's not flexible enough. Tbh, why not simply setup a automation a/o timer, which is triggered as soon as autolock is activated and unlock after the given amount of time?

[oesip]

Hello Yves,
Thanks again for the reply, thoughts and explanation. I agree. The auto lock makes sense. I just wanted to know that’s the correct function and behavior and what’s planned to be implemented in future. It’s fine to know that the intention is to always keep it locked until unlocking from outside is triggered. So I can do something like timer function or think of some presence detection, what ever. Another question, I just don't want to open another issue. You have any plans to do an adaptive height setting depending on some conditions? Like: temperature is still low or season is spring, only close 50% of the set value and when it is summer, close 100% of the set value? Sorry just a quick explanation, i hope you can catch what I want to say. There is an entity option, So I was thinking about such function to implement as an external automation. Just to know if I should spent time figuring out something like that or if you have any plans already in mind? br Peter

[mzurhorst]

Hi. I have not yet configured this particular integration, but I am also failing with exactly those requirements in my own automations. On the one hand, I like to have an unattended automation taking care, at the same time, the algorithm shall stay in the background when a human is taking action. But, for how long?

When my automation would close the window covers when windows is exposed to sun, and anybody would open them again afterwards, I do believe that this event (e.g. in the afternoon) would be totally independent from a regular scheduled closing in the evening. --- I was playing around with helper variables and hysteresis to temporarily deactivate my automations for time X in the ballbpark of 2-3 hours or so, but there will always be another corner case where it does not match anymore. ;-)

[starwarsfan]

Hi @ALL

but there will always be another corner case where it does not match anymore. ;-)

That's exactly the problem. There are always corner cases which needs extra treatment and that has nothing to do with the integration at all.

Example: If the shutter should be slightly opened as soon as the window is tilted, that operation must be done by the integration, not by automation beside the integration because that would lead to auto lock! I'm using automations to modify the desired position values in such cases. So i. e. the max angle is set to 0 (fully closed). As soon as the windows is tilted, the max angle is set to something like 10% (slightly open). So the window events modify the configuration of the instance and the instance modify the shutter afterwards. That worked this way for more than ten years now (as the integration initially was implemented and used the same way for a different smarthome server. See readme for details about that.)

[plebann]

As soon as the windows is tilted, the max angle is set to something like 10%
For that you are using Enforced position height or other? If it's other - how you select what entity should be adjusted (D04-05, D09-10, S06-07, S11-12 or Natural hight/angle)? Also, if you change it, how do you reset back to original state?
I'm courius how you solved it.

Also I was thinking of "auto-unlock" feature of my own (as separate integration), and this would work the way, that when I manually changed position/angle of shadow and then (later, no matter when) your autiomation's desired state of that shadow matches (to some approximation) this state - it would automatically unlock.

Had you considered that behaviour?

[starwarsfan]

I'm using this kind of automation to handle the open/close/ajar state:

- id: 'tur_essbereich_behang_nach_offnungsstatus'
  alias: 'Tür Essbereich Behang nach Öffnungsstatus'
  triggers:
    - trigger: state
      entity_id:
        - sensor.status_tur_essbereich
      # Verhindert Trigger bei Neustart (von unknown/unavailable)
      not_from:
        - unknown
        - unavailable
  actions:
    - variables:
        input_value_shadow_height: "{{ states('input_number.shadow_max_height') | float(0) }}"
        input_value_shadow_angle: "{{ states('input_number.shadow_max_angle') | float(0) }}"
        input_value_dawn_height: "{{ states('input_number.dawn_max_height') | float(0) }}"
        input_value_dawn_angle: "{{ states('input_number.dawn_max_angle') | float(0) }}"
        fenster_status: "{{ states('sensor.status_tur_essbereich') }}"
    - choose:
        - conditions: "{{ fenster_status == 'Geschlossen' }}"
          sequence:
            # Shadow position
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_shadow_max_height_tur_essbereich
              data:
                value: "{{ input_value_shadow_height | round(0) }}"
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_shadow_max_angle_tur_essbereich
              data:
                value: "{{ input_value_shadow_angle | round(0) }}"
            # Dawn position
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_dawn_max_height_tur_essbereich
              data:
                value: "{{ input_value_dawn_height | round(0) }}"
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_dawn_max_angle_tur_essbereich
              data:
                value: "{{ input_value_dawn_angle | round(0) }}"
        - conditions: "{{ fenster_status == 'Geöffnet' }}"
          sequence:
            # Shadow position
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_shadow_max_height_tur_essbereich
              data:
                value: "0"
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_shadow_max_angle_tur_essbereich
              data:
                value: "0"
            # Dawn position
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_dawn_max_height_tur_essbereich
              data:
                value: "0"
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_dawn_max_angle_tur_essbereich
              data:
                value: "0"
        - conditions: "{{ fenster_status == 'Gekippt' }}"
          sequence:
            # Shadow position
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_shadow_max_height_tur_essbereich
              data:
                value: "{{ input_value_shadow_height | round(0) }}"
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_shadow_max_angle_tur_essbereich
              data:
                value: "{{ input_value_shadow_angle | round(0) }}"
            # Dawn position
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_dawn_max_height_tur_essbereich
              data:
                value: "{{ input_value_dawn_height | round(0) }}"
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_dawn_max_angle_tur_essbereich
              data:
                value: "{{ (input_value_dawn_angle * 0.8) | round(0) }}"
        - conditions: []
          sequence:
            # Shadow position
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_shadow_max_height_tur_essbereich
              data:
                value: "{{ input_value_shadow_height | round(0) }}"
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_shadow_max_angle_tur_essbereich
              data:
                value: "{{ input_value_shadow_angle | round(0) }}"
            # Dawn position
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_dawn_max_height_tur_essbereich
              data:
                value: "{{ input_value_dawn_height | round(0) }}"
            - action: input_number.set_value
              target:
                entity_id: input_number.automation_dawn_max_angle_tur_essbereich
              data:
                value: "{{ input_value_dawn_angle | round(0) }}"

So the inputs come from my configuration entities and the outputs are the entities of the corresponding Shadow Control instance.

Had you considered that behaviour?

Yes and it was not realized. If the shutter was modified manually, it must stay locked until a defined event happens and that's not the event, the calculation "passes" the current shutter position.

[plebann]

OK, so you are setting only D04-05 or S06-07.
Actually this only confuses me more, what about neutral state and state after shadow/dawn?

Yes and it was not realized.

I was asking mainly because my integration very often reaches "locked" state on it's own, and it's hard for me to understand why this is happening, and I was thinkering around just unlocking it.