Template binary sensor with time_pattern trigger only works once

I have a set of template binary sensors that change value based on time_pattern triggers. These binary sensors have been working, code untouched, for years. Recently, potentially after a version upgrade (not sure, only noticed the problem recently since these sensors are only used when I am away), they stopped working. If I restart Home Assistant, each of the sensors will work once and then never change value again. The sensors are defined in my template.yaml. Here’s an example of one.

- trigger:
    - platform: time_pattern
      hours: "/1"
  binary_sensor:
    - name: random_break
      state: "on"
      delay_on: "00:{{ range(1,60)|random|int}}:00"
      auto_off: "00:{{ range(1,60)|random|int}}:00"

I did read that my sensor definition was using an outdated format so I updated the definition to this:

- triggers:
    - trigger: time_pattern
      hours: “/1”
  binary_sensor:
    - name: random_break
      state: “on”
      delay_on: “00:{{ range(1,60)|random|int}}:00”
      auto_off: “00:{{ range(1,60)|random|int}}:00”
      attributes:
        updated: “{{ now() }}”

However, that did not improve things. I did see this post that looked like a similar issue but I was not able to resolve my problem with the infiormation there.

Does anyone have any ideas how I might be able to address this problem?

Thanks
DM

There are “fancy” quotes everywhere in your template. They should be straight quotes like this "/1"

I believe those quotes are just an artifact of my copy/paste action. I rechecked and all my quotes are indeed simple/straight.

DM

it’s because your template is wrong.
try using`something like that (sorry slightly modified using seconds but hours&minutes since I’m not too good in waiting for hours :slight_smile:

delay_off: "{{ '00:00:' + (range(10,15)|random|int)|string }}"

problem with yours you wanted to start with a string tried to add an int and finall a string.

I don’t believe that’s the issue. Remember these sensors have been working for literally years with that code. I would have expected to see problems long before this if type mismatches were the issue.

I suspect a recent change in the Home Assistant core is what is causing my grief.

DM

It’s not. Your template is fine.

I am concerned about your trigger though.

The time pattern you are using will trigger every second (the hours always remain divisible by 1 even though the seconds and minutes change). Try this to trigger every hour:

  - trigger: time_pattern
    minutes: 0
    seconds: 0

If that does not work, remove your template sensor from the package and put it in your configuration.yaml file under template:

Thank you for the suggestions. I’ll try them and report back.

DM

Actually, thinking about this, it may never trigger as the pattern is always true.

Except after a restart (unavailable → true), which is what you are seeing.

doubt that, still because

watch for the last minutes since there’s a gap where HA was restarted.
I play with this problem for pure fun, so be patient I honor your thoughts about a fine template, but reality shows differnt.
Nevertheless since keeping braincells alive I’m always interested in a solution which works with the original templates. To be aware of difffernt solutions is always a benefit.

So this is just in case you’re willing to test it on your machine.

All what’s changed to save time is turning hours and minutes to seconds so things do happen without waiting for too long.

template:
  - triggers:
    - trigger: time_pattern
      seconds: "/20"
    binary_sensor:
      - name: random_break_originalcode
        unique_id: random_break_originalcode
        state: "on"
        delay_on: "00:00:{{ range(1,15)|random|int}}"
        auto_off: "00:00:{{ range(1,15)|random|int}}"
        attributes:
          updated: "{{ now() }}"
        

  - triggers:
    - trigger: time_pattern
      seconds: "/20"
    binary_sensor:
      - name: random_break_working
        unique_id: random_break_working
        state: "on"
        delay_off: "{{ '00:00:' + (range(1,15)|random|int)|string }}"
        auto_off:  "{{ '00:00:' + (range(1,15)|random|int)|string }}"
        attributes:
          updated: "{{ now() }}"

I set up a few variations using a 10 minute interval, and the issue seems to be present… after restarting HA or the integration they work one time again then stop.

Sensor configs
template:
  - triggers:
      - trigger: time_pattern
        minutes: "/10"
    actions:
      - variables:
          delay_on: "00:{{ range(1,5)|random|int}}:00"
          auto_off: "00:{{ range(1,5)|random|int}}:00"
          timestamp: "{{ now() }}"
    sensor:
      - name: random_break_timestamp
        state: "{{ timestamp }}"
        attributes:
          delay_on: "{{ delay_on }}"
          auto_off: "{{ auto_off }}"
    binary_sensor:
      - name: random_break_original_var
        state: "on"
        delay_on: "{{ delay_on }}"
        auto_off: "{{ auto_off }}"
        attributes:
          delay_on: "{{ delay_on }}"
          auto_off: "{{ auto_off }}"
          timestamp: "{{ timestamp }}"
      - name: random_break_original
        state: "on"
        delay_on: "00:{{ range(1,5)|random|int}}:00"
        auto_off: "00:{{ range(1,5)|random|int}}:00"
      - name: random_break_static_delay_on_1m
        state: "on"
        delay_on: "00:01:00"
        auto_off: "00:{{ range(1,5)|random|int}}:00"
      - name: random_break_auto_static_off
        state: "on"
        delay_on: "00:{{ range(1,5)|random|int}}:00"
        auto_off: "00:05:00"

The trigger seems to be working fine, since the timestamp sensor is updating…

What is your use case?

I think you probably hit on something fairly esoteric. You’re using delay_on and auto_off correctly in a static sense, seemingly. But I am not sure that the definition of these parameters is consistent with your expectation given the constant on for the state. This could explain why a change to the implementation resulted in a change to the behavior you’re seeing

The more explicit way to do this is probably with a timer.

There is a missing leading 0 for the seven minute time (delay on) but I’m not sure that is an issue.

Interesting. One for petro to look at when he returns from holidays.

Thanks for that. I’ll give that a try and see where that goes. I’m open to all suggestions.

DM

Thanks for taking the time to do this. I’ll put together a few variations myself and see what happens.

DM

I am using a number of sensors configured similarly to the one in my original post to control the lights in my house when I am away. The sensors basically provide randomized on/off intervals for the lights. There are associated automations which use a number of these sensors to mimic a reasonably realistic light pattern versus simple static timer based logic.

Has worked well for quite a while. Some of my neighbours never even realize when I am away :slight_smile:

DM

Have you seen this?

I think I found a work around… instead of using delay_on, use a delay action

template:
  - triggers:
      - trigger: time_pattern
        minutes: "0"
        seconds: "0"
    actions:
      - variables:
          delay_on: "00:{{ range(1,60)|random|int}}:00"
          auto_off: "00:{{ range(1,60)|random|int}}:00"
      - delay: "{{ delay_on }}"
    binary_sensor:
      - name: random_break_delay_action
        state: "on"
        auto_off: "{{ auto_off }}"

* NOTE: I only tested it with a 10 minute interval… I’m not sure how practical it is when working with the full hour.

2 Likes

Yep, noticed that myself and I would have bet a tenner it’ll fail … since if you do things completely wrong the log says it expects HH:MM or HH:MM:SS or even HH:MM:SS.F and HH:M:SS is something different. But it accidently did work.

Tried with another idea but that one failed

delay_off: "{{ '00:00:' + "%2i" | format (range(1,15)|random|int) }}"

but while typing these lines I bet it it must read

delay_off: "{{ '00:00:' + "%2s" | format (range(1,15)|random|int) }}"

to serve the trailing 0 upon need.

EDIT: and I now know why “%i” did fail. It created something such as " 1" means 11: 1:11 is definatly invalid while 11:1:11 is accepted.

The trigger is resetting all the templates. For this to work, the sum of delay on and auto off needs to be less than the time pattern.