To be accessible from outside of HA, it should be in the www directory and accessed through a URL closer to http://192.168.1.132:8123/local/music/20Hz4Sec.mp3.
Well, I was explaining why you were getting errors when trying to access the files via a web browser. I can’t speak as well to Media Source as I’ve never used it, but your service call doesn’t follow the example from the docs you shared. If it did, it would look more like this:
So after several hours burned on this issue. I have found a ‘solution’, as there is a failure of some nature paying an audio files with media_player.play_media from the default ‘media’ folder when your HA instance is without ssl. (I’m using HA’s cloud)
I want to thank everyone who helped me, it was with all your suggestions that enabled me to get to the bottom of this issue (don’t think this basic function should have been a problem, but I digress. )
Hope this help some in the future…
Used the \config\www\ folder to place my audio in. Thanks @r-j-taylor
This thread now serves as an example of how not to report a problem.
Instead of simply stating the tone failed to play but the TTS message did after the delay expired, it reported:
Anyone who has used Home Assistant for awhile knows that’s nonsense; a delay has no affect on actions preceding it.
The first post also gave the misleading impression that the tone did play:
Yet it never did play because Home Assistant was improperly configured to play local media.
Finally, the Solution post allegedly provides instructions for correcting the cause of the tone’s failure to play (for which delay was blameless) yet it overlooks to follow the instructions found in Media Source.
Well as it turns out I did indeed follow much of the ‘How to help us help you’ list.
0-1-2-3-4) I have spent more hours reading and re-reading over and over again, watching help video’s and working on it before ever starting this post.
5-6) I didn’t follow
I personally thought the title of this post was clear.
I stated the goal first and not the problem and I thought I was clear when I said “Appears”…
9-11) I showed my automation, I believe properly formatted. Yes I didn’t understand the root cause, but isn’t that part of learning from the failures in your understanding and logic? “You don’t know what you don’t know” kind of thing.
I failed to do, as at the time I didn’t think it was relevant in this case.
An observation over the 2 months of reading the posts and reply’s on this site is that most people here are extremely helpful, willing and able to help those who are new and simply don’t have the programming background required to accomplish many tasks in HA.
Then there are a few others, mostly HA veterans who fail to understand, either via hubris or repetition (the "get off my lawn type) that many, like my self are not programmers (hobby or professional) and thus when we read the documents some of it doesn’t make sense no matter how much we re-read.
In this specific case I read that section quite a few times (and many others), with no success (albeit due to a lack of knowledge and understanding on my part)
Thankfully @r-j-taylor and @finity could see through the noise of my ignorance and provide useful and meaningful steps to help me solve the problem at hand and more importantly help me gain knowledge and understanding of how HA works.
Just to add -
this would have been MUCH easier to diagnose - had “show trace” been clicked, and the results posted here. At the very minimum, we would know from the timestamps that the automation did indeed run in the expected way.
Additionally to answer this:
That would be unaffected by editing the automations, provided that they were automation triggers, because it’s the core state system that keeps track of how long things have been in a certain state, the only thing that would throw that off, would be an actual restart of core.
But if you had an automation with a trigger of no motion detected for 10 minutes, that would still fire when the automations were reloaded, once there had been no motion for 10 minutes. So if you reloaded the automations 9 minutes after motion was last detected - it would still trigger a minute later.
Indeed, however yet another piece of the HA puzzle I was not aware of until yesterday. It is a VERY nice feature in which I’ve already used to diag. another issue.
Thank you. So if I’m understanding you correctly. If I’m working on (updating) an automation and I hit the save button, the trigger will still be valid?
It is indeed very handy. Especially when you start passing variables to scripts. Eg - I have a LUX sensor outdoors, which I use to set a master slider to a value between 0% and 100% and all the rooms use the value of the master slider to determine the current level that any lights that are on should be set to:
service: input_number.set_value
target:
entity_id: input_number.master_brightness_based_on_lux
data:
value: >-
{% set val = trigger.to_state.state|int %} {% set min_in = 1 %} {% set
max_in = 3000 %} {% set max_out = 100 %} {% set min_out = 1 %} {% set out =
(101 - (max_out + (min_out - max_out) * (1 - ((val - min_in) / (max_in -
min_in))))) %} {% if out < min_out %}{% set out = min_out %}{% endif %} {%
if out > max_out %} {% set out = max_out %}{% endif %} {{ out|int }}
and then say the Livingroom is triggered when the value of the master changes - so it can determine it’s brightness level:
service: input_number.set_value
target:
entity_id: input_number.livingroom_light
data_template:
value: ' {% set min = 15 %} {% set max = 82 %} {% set b = (trigger.to_state.state|int) -(100 - max) %} {% if b <= min %} {% set v = min %} {% elif b >= max %} {% set v = max %} {% else %} {% set v = b %} {% endif %} {{ v }}'
The traces let me see the actual numbers being passed to automations and service calls so I can make sure it is working as I expect it to.
That is my understanding, an automation that has a trigger where an entity has to be in a certain state for a period of time before the automation is executed, is not running, so I can’t see why it should affect it. Every entity has a last_changed attribute which makes it easy to calculate how long an entity has been in the desired state, it’s only a core restart that resets all of that.
EDIT: If it does indeed affect automations with triggers that require a certain state for a period of time, it is not something that has ever caused me any issues, and I edit automations constantly…
@ServiceXp , there are some people out there, who will try to remind your mistakes all the time, you can safely ignore these people. That is my learning with my last 1 year experience. Focus on the results.
Do not worry, either you are a veteran or a new joiner, it is always ok to make a mistake, as long as it is not intentional. Enjoy your solution thanks to helpful community members.
The “for:” option in the trigger is effectively the same as adding a “delay:” or “wait_for_trigger:”, etc. and it suffers from the same limitations as all of the other timer functions in HA - they are all impacted by an automations reload or restart of HA.
The way the “for:” option works is that the automation listens for the state to change to the desired state and then it starts the wait for the “for:” time. So even tho the automation hasn’t technically triggered yet there is still stuff going on in the background waiting for the time to expire after the state change before it runs the actions. And that waiting period will be cancelled on the above mentioned restart/reload events.
It would make sense if the “for:” in the trigger worked the way you thought (so did I for a long time) but unfortunately it doesn’t.
There are literally no reliable timed functions in HA that aren’t affected by a reload of automations, etc.
EDIT:
I actually tried to make a change to the documentation to add a warning to users of the limitations of HA timer functions but the powers-that-be didn’t like that it was too informational (I guess…?, ) and when I couldn’t come up with a more succinct way to get the point across it has been languishing in PR purgatory ever since.
So they can list automations dynamically by area and device, so they know what devices and things are involved, but they can’t check all the relevant trigger conditions on a reload. That is stupid, it’s surely less overhead to check the state’s last changed time and then calculate what time it would be when the requirement would be met, and then check then - instead of having an internal timer.
Ah yes, those people who clearly point out why this simple problem took dozens of posts to resolve. Their advice should be ignored because it’s far better to talk circles around the problem and drag out its resolution.
Very true. What’s needed is the concept of an incremental reload where only new/modified automations are reloaded (by default); unmodified automations are left undisturbed. FWIW, this already exists in other products, including the 20 year-old automation software I use in addition to Home Assistant.
I feel I mentioned this in a Feature Request but don’t recall which one (probably in the one for reducing the need for complete restarts … and a great deal of that has been implemented).
Anyway, the current state of affairs means ought to employ certain design patterns in one’s automations to mitigate the “reset” behavior of Reload Automations. However, that’s out of scope for this thread.
)
) and when I couldn’t come up with a more succinct way to get the point across it has been languishing in PR purgatory ever since. 