You are absolutely right, I do not know why it happened… anyway I will repeat the same tests and I will place here the right traces.
I noticed something strange for me, looking at the trace these trace files.
‘’’ YAML
“timestamp”: {
“start”: “2022-11-29T21:21:30.625858+00:00”,
“finish”: “2022-11-29T21:21:36.381221+00:00”
‘’’
“”" YAML
“timestamp”: {
“start”: “2022-11-29T21:21:32.706740+00:00”,
“finish”: “2022-11-29T21:21:35.758982+00:00”
},
“”"
Firstly, the two scripts do not start at the same time, the second thing is that they last several minutes…is it normal? If I make a second announce while the script is not finished, what will happen?
Anyway, please explain me again how to put the code in the same way you do, because…I cannot understand where I am wrong…
The helper script is started by the main script. So first then main script is triggered, it does some stuff like store the current state of the devices, perform the actions etc. Then the helper script is started per device to actually perform the resume.
And the difference between these start and end timestamps is not several minutes, it’s several seconds.
The helper script has to wait until the TTS message has finished to perform the resume, and then has to wait until it is playing again to perform some final actions.
The main script waits until the helper scripts are finished.
It is very strange, I make a tts call in my office, where I have the old version yaml which before worked with only one device Ufficio_speaker…today it does not work anymore…it didn’t resume.
I do not know what it is happening.
I made a remote test on my devices at home where there is the new yaml code and I test with the second case, it does the same as yesterday. The camerastudio device goes in idle after. If I call the group tss, all the 3 devices turn off after…I cannot find the logic…
Anyway, later when I will be at home, I will do again the same test and I will send you the traces. If you have any suggestions to some additional test that I could do, to help you to understand more, please let me know.
yes, I have two servers. One is in the office and the other one is at home. In the office I have only a google nest mini device, at least for now. While at home I have several devices.
Well, we start again with some tests.
I put the radio on camerastudio and spotify on salottomini. I called the tts service on camerastudio. It does not resume, while the spotify on salottomini continued.
These are the traces : salottomini&camerastudio - Pastebin.com salottomini&camerastudio helper - Pastebin.com
I take also the values from the two devices before and after executing the script :
So definitively in this case it seems that there is something going in conflict with spotify…if spotify is active on a device, the resume it does not work on the other device.
Executing two different radios, one on camerastudio and the other one on salottomini, calling the tts message as group, it resumes on both devices. I noticed one thing…on salottomini I choosed the radio from the HA integration while for camerastudio I put the radio with my voice directly on the google device. On the HA dashboard there is a picture of the radio per camerastudio, while there is not any picture for salottomini. You can see also here below :
Test 1:
The Helper script was not completed yet, It was still waiting for a state change on the player.
When you only target the camerastudio entity, the salottomini player will not be affected by the script. It will not not be stopped, so there is no need to take any action on it.
Please allow the script to complete before sending the traces.
As the salottomini player was not involved, it has nothing to do with Spotify. The data in the helper script looked fine, it has all the information that it was playing on TuneIn and that is should be resumed.
It was still waiting on a state change of the player.
Test 2:
The TuneIn cast integration on the speaker itself provides a picture, which is also used after the resume (proably a picture of the song which was playing, which will now remain static).
The stream started by HA doesn’t have a picture before the resume, so it won’t have a picture after the resume as well.
General:
I don’t see anything related to Spotify here. Can you retest the scenario which didn’t work and send traces after the script is completed.
I will repeat the test a second time and I will wait more…anyway I have pasted you also the values of the objects before and after starting the script, just to show you the time within. We are speaking for around 30 seconds. How much time I have to wait to finish the script?
I made the same test 1, but I waited more…at least 5 minutes.
These are the results from the object values (you can see how much time has been passed between the two values check):
For the helper i noticed the same as yesterday, but I didn’t pay so much attention why it took so much time. In the explorer It was like seeing a download when it tries to start the download, but it does not start immediately…usually happens if the server for such a reason cannot immediately give the start…what I am thinking is that probably the helper was still running. After a couple of other minutes, it downloaded the file.
You can clearly see the helper script was still running on line 5 of the trace
It keeps hanging on this step:
- alias: "Wait until player is idle again, and all other scripts are finished"
wait_template: >
{%- set current = expand(states.group
| selectattr('entity_id', 'search', 'group.resume_script_target_')
| rejectattr('entity_id', 'search', context)
| map(attribute='entity_id')
| list) | map(attribute='entity_id') | list
%}
{%- set checklist = [player.entity_id] + player.members %}
{{
dashboard_cast or
expand(checklist) | rejectattr('state', 'in', ['idle', 'off', 'paused']) | list | count == 0
and current | select('eq', player.entity_id) | list | count == 0
}}
Could you check in Developer Tools > States if there are existing entities which start with group.google_home_ and have this media_player entity as it’s member?
as stated above, it returned at the moment I call back the script. Afterwards I turned off the google home device on which I started the script and the groups disappeared again.
I would like to point you that this happen, only if on one of the devices is active Spotify and I do not need to call the tts message on the device which is running Spotify. I have just now load on camerastudio a radio, I tried the script and immediately it resumed.
I found the reason why your groups are acting weird. Something changed in the cast integration, and now groups are showing as playing when only one member is playing, or when they are all playing different things.
I think this is the cause of your problems. I’m currently working on it.
I’m testing this new version, if everything works correct I will release it in as version 2022.12.0
2022.12 Happy Holidays; let’s bring the family together
It’s December which is the time to come together with your family for the holidays. That is exactly what this version does, it brings all scripts together into one package!
GENERAL
Improvements
All scripts related to the Google Home devices are now combined in one package. This brings toghether the Google Home Resume, Google Home Voice and Google Home Event script. For me it makes it easier to update them, I can make more efficient usage of YAML anchors,so I don’t need to update templates and settings in 3 places.
Instructions on installation and usage of the package moved to GitHub
A lot of bigger and smaller template fixes
More usage of YAML anchors, which also reduces the total number of lines for the combined scripts
RESUME SCRIPT
Improvements
Template to generate the target_list has been improved
Apparantly Google Home Speaker groups now show as playing when a member is playing media. Not only when the group has been targeted. The template to generate the player_data has been amended to avoid showing groups as playing when they are not.
Bug fixes
There was bug when using the automation which would start the script for a group member when that was the target of a service call, but the group was playing. This caused the resume to fail.
GENERAL
Improvements
RESUME SCRIPT
Bug fixes