I use my Google Home a lot to send audio to my Chromecast Audio. In doing so I also ask the Google Home to turn on my amp and set it to the correct input. This is now 3 commands of which GH only allows 2 to be combined into the 1 sentence. (The last two are done via an IR transmitter because the amp is not network connected) This all works fine but since this is all supposed to be about ‘automation’ I would really like it if my voice command to play audio (this is generally a genre on Spotify or an artist from my Google Play Music) would be ‘intercepted’ so to speak so that HA would know I have requested music to be played from the Chromecast Audio and therefore automatically send the ‘amp on’ and ‘amp input’ commands.
Is this possible?
Part of me thinks I may be possible by tracking the status of the chromecast audio as playing and then sending the IR commands… I literally just thought of this now… but in general, I think that an intercep of the voice command for other use cases would be handy (to allow automatic tasks from a single spoken command)
You could write a script named “play music” that contained all of the desired actions (assuming HA can access them all), then expose that script to GA. Then you could say “Hey google, activate [or start] play music”.
Edit: sorry didn’t read closely enough. I think your idea is a good one. You could write an automation that triggered when the chromecast changed to playing, and whose actions were 1) pause the chromecast, 2) turn on receiver, 3) set the input, 4) play the chromecast again.
Yeah, my issue is that the music can be so varied. ie: one day I might say “Hey Google, play Chilled Hits from Spotify on the lounge speakers” and the next it could be “Hey Google, play Prodigy from Google Play Music on the lounge speakers”… In each instance I want the Amp turned ON and set to the input for the Chromecast Audio.
I think that tracking the status of the Chromecast audio is going to be my best bet. I will also need to ensure I track the Amp power so that I don’t toggle it OFF if it was already ON. From memory it has different IR codes so this should be OK.
But as for other use cases, intercepting the Google Home commands could be useful so that HA could conduct certain tasks based on a voice command including a particular phase, without having to write an automation for every possible variation of that phase.
I agree - do you have a way of tracking the amp power state? I would have thought if you are controlling it via IR that you wouldn’t know if it was off or on.
If you do know the power state, Node-red could be helpful here as you could create a flow to skip turning the power on if already on and only setting the input. In HA, I think you’ll need to use two automations - one with the condition “amp on” that only sets input, and another with condition “amp off” that both turns on and sets input.
If you don’t know the power state, then you may be a little screwed unless (as you think) the amp has different on and off codes, in which case you wouldn’t even need to know power state since you could always send “on” without worrying that it would screw something up.
I can install a z-wave power switch in the feed to the amp to track its state based on current consumption (i have a few spares), but I will check when I get back home regarding the IR codes. I know the remote does have a separate ON and STANDBY button but haven’t confirmed if pressing the ON when it is already ON doesn’t actually toggle it OFF/STANDBY. I think I will be OK on that one, luckily.
I have an automation that does just what you describe. The only issue that’s arisen is that when I play to a chromecast audio group, none of the individual chromecast audios show as anything other than off. But if your just playing to a single chromecast audio entity, this works fine. This is for a multi-room amp driving 4 chromecast audios, so it’s a bit lengthy.
I have second automation that turns everything off when nothing is playing on any of the any of the chromecasts. That gets really tricky because there’s no NOT condition (for NOT ‘Playing’), and I’m not good enough with the value templates yet to figure it out a simpler way (although I’m sure one exists).
#Turn on downstairs amp when music played
alias: Downstaris Amp On
trigger:
platform: state
entity_id: media_player.dining_room
to: ‘playing’
platform: state
entity_id: media_player.living_room
to: ‘playing’
platform: state
entity_id: media_player.kitchen
to: ‘playing’
platform: state
entity_id: media_player.patio
to: ‘playing’
As a follow up, after spending all day yesterday trying to figure out a workaround for the google cast group issue, I ended up commenting out the above automation. It worked perfectly for casting to individual speakers, but we cast to groups quite frequently. It quickly became irritating to have to remember to do the double voice command in some circumstances, but not others:
Cast to kitchen: “Listen to today’s top hits” with Google play music set as default and the kitchen speakers set as default audio for the Kitchen Google Home worked great.
Cast to kitchen area (a group that included kitchen and den): “Listen to today’s top hits in kitchen area and turn on downstairs amp”. Not really a good WAF.
Because of the amp “turn off” component to the automation, I really can’t even workaround with shortcuts and IFTTT for the groups.
There really has to be some further work done on pychromecast to be able to A) pull in and entity-ize cast groups consistently, or B) recognize the individual statuses of the entities within the group. As to B), if you look at the individual chromecasts within the groups in the Google Home app, they have little music notes on the cards signifying that they are doing something, so my hope is that this is a possibility.
While I have zero experience with python coding, I have a robust google cast implementation. I have 10 Chromecast Audios, 4 Google Homes, 1 Chromecast built-in Sony speaker, 1 Chromecast built-in Insignia speaker, 2 Nvidia Shields, and 1 1st gen Chromecast Video. I would be happy to make myself available to test any further development.