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.
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.
Quick question… for the 1min/60sec offset, I noticed there are different scripts posted on these forums. Which one is better? What are pros or cons of one over the other especially while using it as a trigger? Suggestions would be highly appreciated.
platform: template
value_template: >-
{% set f = as_timestamp(states('sensor.fajr_prayer')) - 60 %}
{% 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 [f, d, a, i, m] }}
The second one lets you independently adjust the offset of each prayer time whereas the first one doesn’t. Both use now() in their templates which means Home Assistant will evaluate each template every minute, plus whenever a prayer time changes.
Compare that to the example I posted above. It employs a Time Trigger so there’s no template to evaluate every minute and the trigger occurs exclusively at the scheduled time (down to the second). Each one of the five Template Sensors is evaluated only when its associated prayer time changes and can have its own offset value.
Makes perfect sense. Much appreciate the detailed explanation.
Based on your explanation I have consolidated my automation even further than before. Now it all triggers based on the template sensors which have a specific time and not with 60 secs template which gets evaluated every min. Definitely your template sensor saves computing resources and complexity which are not unnecessary for this automation.
Another related question on this. As I am simplifying the automation I noticed that the fajr prayer routine is exactly the same as the other four. The only difference is the length for which I give it an extra 30 secs delays once the prayer automation starts. I think I can consolidate all in one however I need the below on my sub if-then statement. How can I achieve this?
if trigger.entity_id == ‘sensor.fajr_prayer_offset’ then add delay of 3 min 4 secs else delay 2 min 34 secs.
Since my media play template is exactly the same for all 5 prayers, if I can add a sub if-then statement which sees if the trigger.entity_id is fajr prayer then delay it longer.
I tried the above to use in a template but it didn’t work.
I am using your template offset so it triggers 60 secs before, turns on the media player and chromecast and then holds on for 57 secs as the chromecast takes about 45 secs to start and stabalize. Then the media plays after 57secs and since it takes 3 secs to start playing it plays at the precise time the clock turns .00. The delay is just just after the media starts playing and is for the length of the prayer so that it waits till the call for prayer is over. Fajr is 3.4 and rest are 2.34. Once the wait is over, the call for prayer is complete, the automation then turns off the media player by powering off the smart plug it’s connected to. Right now I am using two if statements and two corresponding action statements referencing by trigger ids. The prayers run based on entity trigger ids.
The actions for both if statements are all the same. The only difference between the two is the delay after the media starts playing, since the fajr prayer is 30 secs longer. So the sub if-then statement after the media starts playing will check if the entity trigger id is sensor.fajr_prayer_offset. If yes, it will delay for 3.4 or else will delay 2.34.
Instead of using a delay (3:05 and 2:35) use a wait_template that waits for the media_player’s state to return to idle or use a wait_for_trigger with a State Trigger that detects when the media_player’s state changes from playing to idle.
Aah… that’s perfect. I see the media player going idle precisely at 2.34 and 3.04. I will change the automation per your suggestion. Thank you once again!
Earlier when I added the wait template HA added “\” in the front and end of the code. I noticed it when I selected “edit in yaml”. So I manually removed the “\” and that cleared up the earlier issue of the automation being stuck at the wait template.