I was about to suggest the same...or provide a Clear Queue command button.
I would think a timeout would be more valuable. Like, if the TTS broadcast is in the queue for longer than 10 minutes automatically clear it out.
Yeah, I like this one, it doesn't require any user intervention, in conjunction with clearing on initialize also makes sense.
Ding! Ding! We have a winner!
(I'll take anything. Thanks)
After clearing it out, can you force a re-initialization to restore connectivity automagically as well? I have had a Google Home Mini go silent at least a dozen times. Each time I click INITIALIZE on the repective device's detail page and the queue of TTS messages plays.
That's the issue here though, @mike.maxwell . The "device" isn't "offline." In my case it's not a device.
it's a speaker group. And while the HE might think it's offline it isn't. Cast-web-api continues to see it and TTS from ST continues uninterrupted WHILE the HE sits and queues commands. I can cast to it, etc. I don't think the HE integration fully understands how speaker groups behave or maybe have a bug if they are just following a defined Google implementation. I never have the problem with an individual speaker in HE. It's only groups.
Also, for troubleshooting I have turned off the ST and shutdown the node cast-web-api server for several days and STILL had the issue with HE where it starts queuing messages to a speaker group instead of sending them. In another thread I talked about this. I re-did my entire Google Home (deleted the home and all speaker groups, factory reset a handful of Google Assistant devices, etc.) just to see if the problem was on the Google side. I did this twice even because I wanted to know what happened if I never introduced cast-web-api or anything from ST. It still occurs.
HE eventually loses a speaker group and the only way to get it back is to manually hit initialize on that group. Rediscovering devices and rebooting the hub also work but they take longer.
I should knock on wood right now because it hasn't happened for probably around a week (along side cast-web-api and ST TTS. I'll move this stuff over as soon as WebCoRE is more stable). Hopefully I'm not just on a hot streak and somehow things have settled down.
Speaker groups don’t work on mine when I try using it in with rules manager. I have to select each chrome cast device and then there is a lag as the message plays in between all of them. Too bad the group doesn’t work
There are some known issues with groups. There also some fixes planned.
Anyone want to guess what made me search out this thread?
dev:2602019-04-08 01:00:22.253 am infoOffice Mini is idle
dev:2602019-04-08 01:00:21.875 am infoOffice Mini is playing
dev:2602019-04-08 01:00:20.742 am infoOffice Mini is idle
dev:2602019-04-08 01:00:20.314 am infoOffice Mini is playing
dev:2602019-04-08 01:00:19.214 am infoOffice Mini is idle
dev:2602019-04-08 01:00:18.779 am infoOffice Mini is playing
dev:2602019-04-08 01:00:17.648 am infoOffice Mini is idle
dev:2602019-04-08 01:00:17.253 am infoOffice Mini is playing
dev:2602019-04-08 01:00:16.136 am infoOffice Mini is idle
dev:2602019-04-08 01:00:15.740 am infoOffice Mini is playing
dev:2602019-04-08 01:00:14.634 am infoOffice Mini is idle
dev:2602019-04-08 01:00:14.214 am infoOffice Mini is playing
dev:2602019-04-08 01:00:13.113 am infoOffice Mini is idle
dev:2602019-04-08 01:00:12.669 am infoOffice Mini is playing
dev:2602019-04-08 01:00:11.516 am infoOffice Mini is idle
dev:2602019-04-08 01:00:11.130 am infoOffice Mini is playing
dev:2602019-04-08 01:00:08.518 am infoOffice Mini is idle
dev:2602019-04-08 01:00:08.410 am infoOffice Mini is playing
dev:2602019-04-08 01:00:07.168 am infoOffice Mini is idle
dev:2602019-04-08 01:00:06.818 am infoOffice Mini is playing
dev:2602019-04-08 01:00:05.743 am infoOffice Mini is idle
dev:2602019-04-08 01:00:05.386 am infoOffice Mini is playing
dev:2602019-04-08 01:00:04.216 am infoOffice Mini is idle
dev:2602019-04-08 01:00:03.835 am infoOffice Mini is playing
dev:2602019-04-08 01:00:02.686 am infoOffice Mini is idle
dev:2602019-04-08 01:00:02.338 am infoOffice Mini is playing
dev:2602019-04-08 01:00:01.185 am infoOffice Mini is idle
dev:2602019-04-08 01:00:00.819 am infoOffice Mini is playing
dev:2602019-04-08 12:59:59.663 am infoOffice Mini is idle
dev:2602019-04-08 12:59:59.224 am infoOffice Mini is playing
dev:2602019-04-08 12:59:58.129 am infoOffice Mini is idle
dev:2602019-04-08 12:59:57.753 am infoOffice Mini is playing
dev:2602019-04-08 12:59:56.620 am infoOffice Mini is idle
dev:2602019-04-08 12:59:56.267 am infoOffice Mini is playing
dev:2602019-04-08 12:59:55.158 am infoOffice Mini is idle
dev:2602019-04-08 12:59:54.661 am infoOffice Mini is playing
dev:2602019-04-08 12:59:53.633 am infoOffice Mini is idle
x1000+, 15m of messages...
Yeah, so mine stopped chatting a few days back and I decided to troubleshoot tonight, reran discovery... well you know the story. Anyway, keeping a close eye out on this thread.
tldr; +1
I just installed hubitat today and this can't find any of my Google devices. All my Google devices are on their own vlan, could that be the issue? The vlans can communicate with each other.
I'm fairly certain that the Hubitat Hub and your Google Home's need to be on the same subnet for discovery to work.
Not sure if this will help anyone, but I've been working on this for the past few days. I think i have working solutions for me, your results may vary!
I find that the google home hubs respond nicely to commands almost all the time. The regular homes not so much. I believe this is on google's end.
Announcements
In order to keep announcements working, I have dedicated a speaker group of minis specifically for announcements. Every 3 minutes, rule machine initializes the speaker group, pauses for a second, then sends a " " text string. (I'm not quite sure if you need the initialize or not). You don't hear the blank string, and no connection chime is made because the connection is still open. Sending the blank string keeps the connection open.
As I stated in another post, the only issue I seem to have with this is if the " " happens to coincide with an announcement. I'm going to change things up a bit so every time an announcement is made it resets the 3 minute timer.
With this method, I can send announcements to the speaker group, or control any speaker individually (like volume) in that group. However, you can not control other groups that those speakers are in.
This is really only working because the speakers are dedicated for announcements and only Hubitat connects to the speaker group, and keeps connecting to it. All of their microphones are on mute so no one accidentally issues it a command that could lose the connection.
My current project
I'm currently working on volume control for my non-announcement speakers. It seems, if something is playing on the speaker and you initialize, it will then accept a volume command from hubitat.
If nothing is playing, I need to send the " " string to the speaker, and then I have control of it. I'm working on rules and using the WATO app to check on the current state of each speaker before changing the volume in order to decide whether I just need to initialize or send a " " string. Initialize is preferred as it doesn't make a connection noise and won't stop what is currently playing.
This only works if you never use your speakers for anything other than announcements from Hubitat. Otherwise, whatever you are doing will be interrupted by the space you keep sending it.
And volume control is available via the Cast-Web-API. might want to look at that project to see how it is being achieved.
This only works if you never use your speakers for anything other than announcements from Hubitat. Otherwise, whatever you are doing will be interrupted by the space you keep sending it.
Correct! I was having issues with that, which is why I dedicated some minis specifically for announcements only.
And volume control is available via the Cast-Web-API. might want to look at that project to see how it is being achieved.
Correct, it has volume control without sending text first. However, it is available there because the library is smarter about how it sends messages and keeps track of connections. AndyM is (and all of us are) working at one level above the library level. We only have workarounds and playing a " " is a workaround to keep the connection alive. We would need Mike Maxwell to look at the Cast-Web-API project and implement some of its features. We can @ him but I've talked with him about that before and it's not high on his list of priorities.
After we spoke he was able at least to fix speaker groups with some of the information I gave him so they would stop disappearing on us.
If Mike does happen to pull features from the cast-web-api project I hope he uses the project before vervallsweg added Google Assistant Broadcast API support. It was perfectly stable before that. Now it's unusable and I don't prioritize figuring out why its node server is crashing because I have a good enough workaround with SpeakerCentral and the OOB Chromecast integration. I definitely would move away from SpeakerCentral if I couldn't configure it to leave the speakers alone between messages though. I use all speakers for music and ambient sounds and things and not just announcements.
I have been using the latest version of Cast-web since it was in alpha. No problems here. I have it adjusting the volumes of my speakers at certain times of day or if rooms are occupied. For example, in my bathroom, when i turn the fan on, the speaker automatically goes to 75% so i can hear announcements or my music while in the shower.
Did you take the latest version as well as get an API key from Google and set up all of that? Maybe I'll blow it all up and start fresh. I'm assuming you're still using it through ST because the latest version is not compatible with the driver or app that @jp0550 ported. I ported the new app and driver over but didn't keep them because of how unstable the node server was. If you are using it in ST is there a virtual speaker device through HubLink or are you manually playing things by URL against the API from HE?
I have modified the drivers that were ported over to add some functionality. For volume control, the setLevel command has to be modified to the hubitat method which doesn't just pass the level but the fade time as well. Plus there were a few other functions as well that were added but as built, the driver works fine. The latest version of cast-web is built using the latest release version of node rather than the older version. So, that might have been part of your problem. I am not using it though hublink it is linked to Hubitat.
Hi,
I would like to know if my TV is switched on and I thought of using the Chromecast which is powered from the TV's USB out.
Would be possible to add a "online" attribute please?
Thanks,
Mark
@mike.maxwell - Is it possible to add next / previous track to the chromecast integration? - if so please add this to the list!