Chromecast integration, Thanks HE Team!


#41

Yes, music player is a capability of its own, each defined capability has it's own set of commands and attributes.
When a given capability is implemented in a driver the expectation is that all the commands and attributes will be implemented as well.
Since most of the music player capabilities could not be implemented in the chromecast driver at this time, that capability wasn't included.


#42

Okay...I'm not completely sure why a TTY stream would be any different than any other media type. I am using Cobra's MP3 event app to play MP3 notification sounds on my GH speakers using Cast-Web-API now.
It using the cast methodology and it works fine. I was just hoping to get rid of the need for a separate server to run Cast-Web-API, is all. But if it's not supported I'll just keep everything the way it is for now. Thanks,


#43

What app is this? Message central?


#44

No, MP3 event.

It works with my Cast-Web-API Chromecast speakers like a charm. If I use the Whole Home group I created the sound is even synced across all my devices.


#45

Thanks, I still have my Pi connected, but because it said Sonos I never read that thread.


#46

@Ryan780
I don’t really support mp3 event player any more as this is now built in to Message Central (which does have speech synth capabilities)

I wrote mp3 event player right at the beginning before bringing MC to hubitat
I didn’t think anyone was using it any more

Andy


#47

@Ryan780
Which triggers are you using in mp3 event player?


#48

Mm this is too bad. I regularly send music and tones to be casted. Guess cast-web-api lives to fight another day.


#49

They're all by switch triggers. But the triggers isn't the issue, it's the speakers. Ill checkout MC though. Just didn't need all the extra functionaloty. MP3 event works perfect.


#50

Except it was written for music players not speech synth.
Major rewrite to get it to do that.


#51

Okay, I'll stick with the Cast-Web-API for my Google Home devices then. Sounds like that's going to be easier than trying to use the native implementation until it supports more than TTY. Thanks!


#52

I tried Message Central but it doesn't find the native chromecast devices when you select MP3 play event the same as the MP3 Event Player app. So, it looks like the native integration won't support it with either app.


#53

Has anyone run into a small issue where you cannot adjust the volume of a "speaker group" using the custom command or for any device that uses the "chromecast audio" driver?

I am only able to adjust the volume of the devices using the "chromecast video" driver?


#54

Did you create the custom command from CC video device? I think you need another for CC audio device, not sure, but try.


#55

Your theory was correct, using a "chromecast audio" device to setup the custom command seems to work.


#56

Really? Interesting. I wouldn't have thought that was necessary, but I guess they ARE technically different device types.


#57

It could be that I had setup the command incorrectly in the first place, not sure


#58

I think my problem was that I hadn't "woke" the device so it wasn't accepting the command. Any best practices to set a louder volume before an announcement and then restore it to a lower volume afterward?

It seems you have to send a "speak" before you can adjust volume (assuming HE is not connected at the time) which makes adjusting the volume before the announcement awkward?


#59

You can probably send a refresh 1st, instead of speak, to wake it up.

I haven't needed to do any kind of wakeup on my mini's of Hub, but I haven't been changing my volume on voice commands - just leaving it alone. I will say 100% of my speak events have gone through, which is cool.

I then use WATO to send a stop command when the hub goes back idle (@Ryan780 's idea) to let my Hub display go back to normal.


#60

Yeah...and mine stopped working yesterday. The device never changes from Idle anymore. Let's just say, I think the Chromecast beta has a lot of room for improvement.