Trigger an automation based on time sensor with offset of few seconds

Thank you! This changes the trigger.entity_id … correct? What will be the new ids for the 5 times? f, d, a, m and i ?

I had tried that code earlier while experimenting different ways to trigger… the problem with this was the action failed everytime… since it was looking for triger.entity_id. There are two different mp3 files. One plays only for the first morning call for prayer … thats sensor.fajr_prayer. Rest 4 play for the second mp3 file.

Should I change the code to trigger.entity_id == ‘f’ else ‘Adhan’}}.mp3

I’d split the trugger into 2 and then use a Chose action to decide which mp3 to play. Something like this:

description: ""
mode: single
trigger:
  - platform: template
    value_template: |-
      {% set d = as_timestamp(states('sensor.dhuhr_prayer')) - 60 %}
      {% set a = as_timestamp(states('sensor.asr_prayer'))   - 60 %}
      {% set i = as_timestamp(states('sensor.isha_prayer'))  - 60 %}
      {% set m = as_timestamp(states('sensor.maghrib_prayer')) - 60 %}
      {{ now().timestamp() | int in [d, a, i, m] }}
    id: Morning
  - platform: template
    value_template: |-
      {% set f = as_timestamp(states('sensor.fajr_prayer'))  - 60 %}
      {{ now().timestamp() | int in [f] }}
    id: Remainder
condition: []
action:
  - choose:
      - conditions:
          - condition: trigger
            id: Morning
        sequence: []
      - conditions:
          - condition: trigger
            id: Remainder
        sequence: []

Please be aware that I haven’t tested this so it may not work as you wish.

Much appreciated. I will update the script and report back. Thank you again!

This worked perfectly. I was even able to consolidate another related automation into this where I turn on the receiver and chrome cast a min before prayer time and power off immediately after the prayer ends.

Thank you so much and GOD BLESS!!!

1 Like

Thanks for letting me know.

Make five Template Sensors, one for each of the five prayer-time sensors. Each reports a time that’s 3 seconds earlier than the actual prayer time.

template:
  - sensor:
      - name: Fajr Prayer Offset 
        device_class: timestamp
        state: "{{ (states('sensor.fajr_prayer') | as_datetime - timedelta(seconds=3)).isoformat() }}"
      - name: Dhuhr Prayer Offset 
        device_class: timestamp
        state: "{{ (states('sensor.dhuhr_prayer') | as_datetime - timedelta(seconds=3)).isoformat() }}"
      - name: Asr Prayer Offset 
        device_class: timestamp
        state: "{{ (states('sensor.asr_prayer') | as_datetime - timedelta(seconds=3)).isoformat() }}"
      - name: Maghrib Prayer Offset 
        device_class: timestamp
        state: "{{ (states('sensor.maghrib_prayer') | as_datetime - timedelta(seconds=3)).isoformat() }}"
      - name: Isha Prayer Offset 
        device_class: timestamp
        state: "{{ (states('sensor.isha_prayer') | as_datetime - timedelta(seconds=3)).isoformat() }}"

Your automation’s Time Trigger simply uses the five Template Sensors (and will trigger at the precise second specified by the Template Sensor).

trigger:
  - platform: time
    at:
      - sensor.fajr_prayer_offset
      - sensor.dhuhr_prayer_offset
      - sensor.asr_prayer_offset
      - sensor.maghrib_prayer_offset
      - sensor.isha_prayer_offset

If you want to play a different sound file based on the prayer time, simply create separate Time Triggers and specify the sound file’s name in a Trigger Variable.

alias: example 
trigger:
  - platform: time
    at: sensor.fajr_prayer_offset
    variables:
      song: Fajr_Adhan
  - platform: time
    at:
      - sensor.dhuhr_prayer_offset
      - sensor.asr_prayer_offset
      - sensor.maghrib_prayer_offset
      - sensor.isha_prayer_offset
    variables:
      song: Adhan
condition: []
action:
  - service: media_player.play_media
    target:
      entity_id: media_player.your_player
    data:
      media_content_id: "/local/adhan/Mishary_Rashid_{{ song }}.mp3"
      media_content_type: audio/mp3

This is so tempting. I will use this method as well and experiment on the automation and report back. Thank you @123

@123 I have added the offset sensors to the config.yaml and wating for the prayer time to test the trigger.

For the new offset sensors, I would like to move them to the sensors.yaml file as I refer that in my config.yaml. Right now my sensors.yaml file looks like below, however I am not able to move the new offset sensors in there and config check is giving me an error.

Here is my sensor.yaml file…

- platform: systemmonitor
  resources:
    - type: disk_use_percent
      arg: /config
    - type: memory_use_percent
    - type: swap_use_percent
    - type: load_1m
    - type: load_5m
    - type: load_15m
    - type: processor_use
    - type: processor_temperature
    - type: last_boot
    - type: network_in
      arg: enp4s0
    - type: network_out
      arg: enp4s0

You can’t do that with the Template Sensor configuration I posted above.

Template Sensors defined in modern format (as opposed to the older “legacy” format) are part of the template domain, not the sensor domain, so you cannot put them in sensors.yaml.

If you have this line in your configuration.yaml file, then you can put them in the templates.yaml file.

template: !include templates.yaml

For more information, refer to the documentation: Template integration

@123 U da best!

I created a template_sensors.yaml file and added the below sensors plus added a unique_id for each so that I can hide the offset sensor from the dashboard.

- sensor:
  - name: Fajr Prayer Offset 
    unique_id: fajr_prayer_offset
    device_class: timestamp
    state: "{{ (states('sensor.fajr_prayer') | as_datetime - timedelta(seconds=3)).isoformat() }}"
  - name: Dhuhr Prayer Offset 
    unique_id: dhuhr_prayer_offset
    device_class: timestamp
    state: "{{ (states('sensor.dhuhr_prayer') | as_datetime - timedelta(seconds=3)).isoformat() }}"
  - name: Asr Prayer Offset 
    unique_id: asr_prayer_offset
    device_class: timestamp
    state: "{{ (states('sensor.asr_prayer') | as_datetime - timedelta(seconds=3)).isoformat() }}"
  - name: Maghrib Prayer Offset 
    unique_id: maghrib_prayer_offset
    device_class: timestamp
    state: "{{ (states('sensor.maghrib_prayer') | as_datetime - timedelta(seconds=3)).isoformat() }}"
  - name: Isha Prayer Offset 
    unique_id: isha_prayer_offset
    device_class: timestamp
    state: "{{ (states('sensor.isha_prayer') | as_datetime - timedelta(seconds=3)).isoformat() }}"

After you have had a chance to test it, let me know if what I proposed works properly and meets your requirements.

Yes, I am working on it. For some reason the mp3 did not play for the Asr prayer however other activities in the automation worked properly till the end. Re-doing the media player action… must be some thing with the breaks in the lines. Will definitely report back.

To easily test the service call, go to Developer Tools > Services, switch to YAML mode and copy-paste the following:

service: media_player.play_media
data:
  media_content_type: audio/mp3
  media_content_id: "/local/adhan/Mishary_Rashid_Adhan.mp3"
target:
  entity_id: media_player.your_player

Don’t forget to change media_player.your_player to the entity_id of your actual Media Player.

Thanks. That worked when I gave the straight path to the mp3 file. To make the automation less complex I am using the following template which has worked perfectly in the earlier automation. It changes the file based on trigger.entity_id. Of the 5 prayer times only the morning Fajr prayer is a bit different and around 30 secs lengthy. Rest 4 use the same mp3 as they are all the same. So trying to use one trigger for all 5 times.


data:  
media_content_id: >-    
/local/adhan/Mishary_Rashid_{{'Fajr_Adhan' if trigger.entity_id ==    'sensor.fajr_prayer_offset' else 'Adhan'}}.mp3  
media_content_type: audio/mp3
service: media_player.play_media
target:  
entity_id:    
- media_player.basement_receiver

It’s interesting that it works because the documentation doesn’t mention that trigger.entity_id is supported for a Time Trigger.

Automation Trigger Variables for a Time Trigger.

That’s why the example I posted specifies the desired song’s name (in a variable) in the Time Trigger itself.


BTW, I assume you already know this but I will mention it in case you don’t, you can’t properly test an automation by executing its Run command if the automation references the trigger variable (like trigger.entity_id) or any other variables set within the automation’s triggers (like the song variable). Why not? Because those variables are defined only when the automation is triggered by one of its triggers. If you use Run, those variables will be undefined.

Yes precisely, that’s the issue I am aware about. Hence waiting for the next prayer time as the trigger will come as undefined since the trigger is based on the time. One advantage with trigger.entity_id is that the logs show which specific prayer time triggered the automation. Where as with directly specifying just shows automation triggered without showing which entity was behind it.

On second thoughts, I may look into subtracting the seconds from the offset script you provided to bring the time stamp closer to my time to make the sensor current. This way I should be able to test out the trigger earlier rather than waiting for it.

You can also (temporarily) add an Input Datetime helper to the Time Trigger. Set the Input Datetime to the time needed for conveniently testing the automation.

It works. Just got isha prayer triggered by trigger.entity_id. The issue I have identified is that I am combining another task which happens 1 min before the prayers which is to turn on the receiver outlet which turns on the receiver and chromecast. This step works however it messes up the trigger.entity_id method.

With the earlier automation where I used a 57 sec delay, I used entity_id for that trigger and gave the fajr and other 4 prayers their unique trigger ids and provided direct path to the mp3. So all triggers work in perfect sequence. I like your 3 secs offset better and will have to sacrifice the trigger.entity_id route and just go with time triggers as you suggested.

So I decided to use the best of both solutions.

From @templeton_nash solution I used his 60 sec offset to trigger the receiver power on with trigger id set as Adhan_Prep

From @123 solution I used the 3 sec offset to trigger separate Fazr and rest 4 prayers with triggers id set as Fazr_Adhan and Adhan

So I have 3 triggers with 3 trigger ids and 3 if/then actions which will trigger certain actions based on the trigger ids.

Thank you @templeton_nash and @123 for your prompt responses and suggestions. GOD BLESS!!

For future reference, the Solution tag is normally assigned to the first, or best, post that answers/resolves the original question/problem mentioned in the topic’s first post. You chose to mark your own post with the Solution tag, despite the fact it contains solutions supplied by others.

Reference: FAQ Guideline 21