So I attempted to get some of this working again.
When I added scanned for devices, only half came in. When I did it again a few minutes later, the rest came in. Some of the audio groups came in again. Could it be that the devices that didn’t come in he first time weren’t connected at that moment? I believe earlier you mentioned that the devices seems to disconnect often.
Once I got the devices in, I started the testing.
Many of the devices I was able to send notifications. I still can’t send a notification to an audio group.
I can’t turn off a Google tv using a routine.
Audio controls seem to not behave great. It seems to keep on jumping back to 0 on the device status. When I make a change and then ask Google what the volume was, it didn’t give the correct answer.
If your router is being glitchy, it could be causing these problems. And yes, beyond that, I’ve experienced devices disconnecting. I don’t know for sure if it’s an issue with the cast-web-api connection or with the device itself dropping from wifi. I’ve heard Google products are somewhat notorious for having wifi issues.
I’ll do some more testing on this.
I don’t think that will be possible without the Assistant integration working.
It’s possible this is a symptom of your connection problems.
Keep an eye on the Status field (bottom field on the device Controls screen) to see how often it is going into a ‘disconnected’ state as you try to use the device.
I don’t now if it has any difference, but my cast-web api is running on a rpi3
Another thing I noticed today in the history of Google Cast Manager, status in very short time shows “Shutdown” up to 3 times pr. hour throughout the day, but it doesn’t reflect on connected device playback behavior
There is definitely something wrong there. The driver is getting restarted by Edge, and that’s usually due to a hub reboot. Would it be possible to run some logs with the CLI?
I’ve pushed a refresh to the Edge driver. Version 2022-12-29T20:47:23.346264684
Key updates are:
handling of older versions of cast-web-api
changes to volume should no longer lose other status fields
improvements to resume handling & fixes to miscellaneous problems
groups: fixed status field updating; confirmed notification sent to group works
One observation: if you have something playing to a group of speakers and you change the media to something else on one of the group members, then play stops on all other members. I guess this is just the way that Google Cast works, as I don’t think there is anything I can do to change this.
Also remember that resume after a notification can only resume preset media initiated by the driver. If something else is playing (initiated by the Google App or directly on the device), then that cannot be resumed.
Thank you for your continued effort. I confirmed I now have the new driver. Even with the old one, the devices thatbworked last night no longer worked this morning. I’m not checking all of my many devices, but I am noticing this discrepency. I also noticed the below log showing history with the dates later than the current time (see time on top of the screenshot).
The above screenshot is from an audio group. I’m not sure that would mean anything.
Are there any if statements in your code that won’t send commands or add devices if it thinks it is disconnected from the cast service? It could be that sending the command would work anyway. I’m just theorizing why the old system worked great for me with audio notifications and this one is not.
There is clearly something wrong with the stability of your driver. It should not be showing all those ‘Connected to cast-web-api’ messages and random device info.
The wrong times in your history is a SmartThings platform issue.
If you have a Windows machine on your LAN, then the simpliest path is to download the Windows installer for the CLI and run it to install the CLI on your machine.
Once you get it installed, you can reference this post for details on testing it and running some commands (ignore the older instructions for download a zip file to install; you’re using the windows installer (.msi file) instead).
Great! If you have the CLI working ok then you should be able to use this command:
smartthings edge:drivers:logcat
Provide your hub’s IP when prompted and select the Google cast driver. You should start to get log output and you can see if there are errrors.
If you want to show me a log, please send me a direct message instead of posting it here in this topic. Also, when you paste it into here, be sure to precede the log text with 3 back-ticks (```), and then at the end of the log, include another 3 back-ticks. This will ensure proper formatting.
To all testing my Edge driver: I’ve observed that the SmartThings device stops being updated by the cast-web-api after a period of time. It’s like the cast-web-api doesn’t stay connected to the device unless it receives a periodic status request from the driver. It works fine if you play a preset, since that initiates a command and forces cast-web-api to reconnect. But if something was played on the speaker either through a voice command or from the Google app, then the SmartThings devices may show disconnected and/or not get updated with the current media being played.
So one thing I am going to do implement in my next update is a periodic status request to cast-web-api in order to try and keep the connection going. Hopefully this will address this.
I’ve also noticed that the swipe-down refresh function is not working in my latest driver, so I need to fix that, since a manual refresh would be another way to ‘wake up’ cast-web-api and force it to reconnect to the device.