Disable an automation when daylight saving time comes or goes

[KrisG (Kris Geusens)]

Hi,
I have an automation that works for the light in our bedroom.
The light is Tuya based and is turned on and off via a Shelly 2.5.in an automation
The problem we have is that the light turns on when daylight saving is changed, so twice a year in the middle of the night.

So I’m wondering if I can turn off the automation on the days that DST toggles, so the last sunday of March and the last sunday of October.

Kris

[123 (Taras)]

Add this Template Condition to your automation and it will prevent it from executing its actions on the last sunday of March and the last sunday of October.

condition:
  - condition: template
    value_template: >
      {% set dst_changeover = now().month in [3,10] 
        and now().isoweekday() == 7
        and (now() + timedelta(days=7)).month != now().month %}
      {{ not dst_changeover }}

---

EDIT

Correction. October is 10.

[CO_4X4 (Colorado Four Wheeler)]

Pretty much if @123 posts it then it’s likely the right answer, so I’m not disputing it. That being said, you might want to create a template sensor so you can use DST in other parts of your automations. For me, I use a DST sensor pretty frequently:

binary_sensor:
  - name: "Is Currently DST"
    unique_id: ef33434a-e2d9-449f-84e9-3b5fed3cf814
    icon: mdi:calendar-today
    state: "{{ now().timetuple().tm_isdst > 0 }}"

Then perhaps another for the suggested one:

binary_sensor:
  - name: "Is Not DST"
    unique_id: 699c9c8f-2123-4016-b3c5-8f63ae532f0a
    icon: mdi:calendar-today
    state: >-
      {% set dst_changeover = now().month in [3,10] 
        and now().isoweekday() == 7
        and (now() + timedelta(days=7)).month != now().month %}
      {{ not dst_changeover }}      

And your condition:

condition: state
entity_id: binary_sensor.is_not_dst
state: "on"

I offer the two variations (even though they seem redundant) in case there is a nuance to what Taras’ formula that differs from my own ;).

[123 (Taras)]

I believe the difference is that my template determines if today is (not) one of the two DST changeover days whereas yours indicates if DST is in effect or not.

If my template is used in a Template Binary Sensor, it will be on for all days of the year except two.

If your template is used for a Template Binary Sensor, it will be on for all the days when DST is in effect.

[CO_4X4 (Colorado Four Wheeler)]

You are the YAML/Jinja/Python Zen Master (not being snarky, I mean that), I like having a template sensor just because I never have to remember how I calculated it on my other automations

[KrisG (Kris Geusens)]

If my template is used in a Template Binary Sensor, it will be on for all days of the year except two

This looks like what I need.
With such a Template sensor I can turn off the automation when the sensor is OFF and it’s 1.55AM and turn it back on at 3.05AM.

Next step is to find out where to put the code

Kris

[KrisG (Kris Geusens)]

@123

value_template: >
      {% set dst_changeover = now().month in [3,10] 
        and now().isoweekday() == 7
        and (now() + timedelta(days=7)).month != now().month %}
      {{ not dst_changeover }}

I did put this in a binary template helper, it’s OFF now, which sounds logical.
I think I can work with this.

[123 (Taras)]

@KrisG

With such a Template sensor I can turn off the automation when the sensor is OFF and it’s 1.55AM and turn it back on at 3.05AM.

Turning off automations as a normal part of their operation is not a recommended practice. An automation should contain all necessary logic to control its operation. What I suggested should be used as a condition in the automation so it can controls its own operation.

If you have just one automation, that shouldn’t run on DST changeover days, then you don’t need to create a Template Binary Sensor. Simply do what I had suggested; add the Template Condition I posted above to that automation. The automation will not execute its actions on the two DST changeover days.

If you have multiple automations then, yes, you can create a Template Binary Sensor with the suggested template and use it in a State Condition in each automation.

@KrisG

I did put this in a binary template helper, it’s OFF now

It should report on now, not off.

The template reports false on the two DST changeover days, otherwise it reports true. Today is not a DST changeover day so it should be reporting on. A Template Binary Sensor reports false as off and true as on.

[KrisG (Kris Geusens)]

@123

value_template: >
      {% set dst_changeover = now().month in [3,10] 
        and now().isoweekday() == 7
        and (now() + timedelta(days=7)).month != now().month %}
      {{ not dst_changeover }}

That is strange, I copied it from here, and it shows OFF now.
I’m not sure if I understand the code good enough but to me it looks like:
SET (so state is ON) if month is 3 or 10 and day=sunday and it’s the last day of the month
else NOT (so state is OFF)

Kris
trying to learn here

[123 (Taras)]

The template is reporting True today because today is not a DST changeover day. That’s exactly what is needed for the Template Condition I posted above and suggested you add to your existing automation. It will prevent the automation from executing its actions on the two DST changeover days (those are the only two days when the Template Condition will report False).

[KrisG (Kris Geusens)]

@123

value_template: >

Found my mistake; I copied the line above too to the helper. Now it behaves as you describe.
(And I will have to look into understanding it properly I guess)

I prefer having it in the helper as I don’t know if I will have other automations using it.

Kris

[123 (Taras)]

@KrisG

Now it behaves as you describe.

Glad to hear my suggestion works for you.

Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. This helps users find answers to similar questions.

For more information about the Solution tag, refer to guideline 21 in the FAQ.

@KrisG

prefer having it in the helper

That’s your choice. If used in a Template Condition or in a Template Binary Sensor, the principle of suppressing actions with the suggested template remains the same (and superior to original goal of turning off the automation).

[KrisG (Kris Geusens)]

I think that last part is a question of semantics, turning it off as in making it not do any action.
But it’s not 100% clear why the ligth turns on on that moment, this is the first try to solve it.

[123 (Taras)]

@KrisG

question of semantics, turning it off as in making it not do any action.

There are advantages to using a condition as opposed to using a separate automation to turn off another automation.

Stop one automation triggering another

FWIW, the technique of one software component disabling another is not a ‘best practice’. By “disabling” I don’t mean simply influencing the other’s behavior but outright shutting it down. It’s an expedient technique, that I have seen suggested more than a few times, but it isn’t optimal. Aside from the questionable design philosophy, one loses the ability to definitively and reliably disable an automation. For example, if you had a good reason to turn off an automation (due to a malfunction …

Trigger automation when current time is bigger than X

The common practice is to add a condition to the automation that checks the state of an input_boolean (or other entity). For example, if you have an input_boolean representing vacation mode, the condition checks if the input_boolean is off. If it’s on then the condition prevents the automation from executing its actions. This technique permits the automation to autonomously determine when it should or shouldn’t perform its actions. This allows the act of disabling the automation to be reserved …

[KrisG (Kris Geusens)]

Like I said, it’s semantics, I called it turning off, but did put it in as condition.

[KrisG (Kris Geusens)]

In the meantime time has changed and it has worked.
Thanks
Kris