You have 1 second bug or new limitation?

Configuration
1

So for the longest time I had

alias: Light off day
description: “”
triggers:

  • type: turned_on
    device_id:
    entity_id:
    domain: switch
    trigger: device
  • trigger: time
    at: “08:00:00”
    conditions:
  • condition: time
    after: “08:00:00”
    before: “08:00:01”
    weekday:
    • mon
    • tue
    • wed
    • thu
    • fri
    • sat
    • sun
      actions:
  • type: turn_off
    device_id:
    entity_id:
    domain: switch
    mode: single

and it worked but now I have to change to this for it to work
conditions:

  • condition: time
    after: “08:00:00”
    before: “08:01:00”
2

Check out this for posting code. It helps us help you!

:one::one: Format it properly

3

You don’t need that condition at all unless you want to limit what day(s) of the week you want the automation to run on (and by the look of it, you have it set to every day).

4

Ok but the thing I wanted to know is why it worked before then a update stopped it from working all due to condition only having 1 second to do it in?

5

Which update?
Are you running the System Monitor? If so, did the processor use changed following the update?
What hardware are you running on?

7

likely the last update because whats happening after 8am the light is still on when it used to be off due to the automation.

the hardware is just a smart plug that is Tuya

8

Hmm yes here is another story what might be happening is during the 1 second window the internet cuts out precisely at that time to which HA did try to turn off but failed then the 1 second window past meaning HA just leave the smart plug on.

9

A 1 minute window works and 1 second doesn’t. How about 30 seconds? 2 seconds? At what time T does it not work and T+1 it does work?

I would try 2 and if still not working try 3. If still not working, my curiosity would have me determine T with a binary search.

10

Look at the automation traces if you still have entries from before you changed from 1s to 1m. It’ll tell you exactly why it didn’t work.

PS- your first turned_on trigger is redundant. It’ll only perform the action if you turn on the switch manually exactly between 08:00:00 & 08:00:01. I think you intended to use that as a condition but put it in the wrong place.

11

yes but it worked for many years fine thats what I don’t get?

12

Which is why I told you to check the traces. They’ll tell you exactly what’s going on

14

So after doing a test automation now it worked so I’m not sure why the last couple of days it didn’t?
I set it back to
after: “08:00:00”
before: “08:00:01”
and see if it works tomorrow

15

so the light stayed on and this is what I see for the trace
Triggered by the time at 4 August 2026 at 08:00:00

Test If the time is after 8:00 and before 08:00:01

Turn off Living Room light Socket 1

Stopped because an error was encountered at 4 August 2026 at 08:00:00 (runtime: 0.21 seconds)

network error:(-9999999) Remote api run unknown failed

16

Ok, so now you know that the time condition has nothing to do with the issue (at least not directly). It failed because there was an error with the api for the bulb.

Let me guess - wifi bulb?

18

No guessing involved. If it’s Tuya Wifi, it’s almost expected. At the very least switch from using the cloud Tuya integration to the custom Tuyalocal or localTuya or whatever it is the kids are using these days.

19

smart plug for a light

I put a Wireshark for HA to see if traffic really is being sent at the time

but I guess the problem could do with Tuya servers? or maybe HA does not do retry on fail as much?

20

But it only just started happening so could there of been a change to HA to not retry on fail?

I think all of Tuya stuff is wifi and over the internet no local, unless your suggesting get smart plugs that can be control local by HA?

21

or what If I do this
alias: Light off day
description: “”
triggers:

  • type: turned_on
    device_id:
    entity_id:
    domain: switch
    trigger: device
  • trigger: time
    at: “08:00:00”
    conditions:
  • condition: time
    after: “08:00:00”
    before: “08:00:01”
    weekday:
    • mon
    • tue
    • wed
    • thu
    • fri
    • sat
    • sun
      actions:
  • repeat:
    until:
    - condition: switch.is_off
    target:
    device_id:
    options:
    behavior: any
    sequence:
    - action: switch.turn_off
    metadata: {}
    target:
    device_id:
    data: {}
    mode: single
22

Tuya products are notoriously bad devices. There have been no changes in HA regarding retrying on failure. HA simply has never retried sending commands, retries have to be built into the automation by the user. You did not do that.