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.
All - I’m pushing out a driver update with a couple changes:
Restored ‘swipe-down’ gesture refresh for cast device Control screen
Implemented automatic refresh request for each device every 10 minute as an attempt to keep the cast-web-api connection with the device alive
Fixed an issue where creation of multiple devices could fail (thank you @swdeason)
VERSION: 2023-01-02T03:27:44.705820217
If you’ve had problems getting your devices discovered/created, this update may fix that for you, so try an Add device / Scan for nearby devices again once you have this on your hub.
I have to say I’m pretty frustrated trying to get this to work reliably. There are just too many weird glitches with the cast-web-api app to make it work consistently. A couple more findings:
Trying to send a group notification to devices that aren’t in group play mode seems to create problems with the cast-web-api disconnecting
Sending an individual device notification to a device that is playing as part of group seems to cause similar problems
Initiating a group media play from the Google app can result in disconnects
Generally, I continue to have frequent disconnects reported by the cast-web-api. It takes a few minutes for it to be restored.
I’m honestly not sure how much further I can take this driver, as I’m going around in circles trying to get everything to work consistently. But I will do a fresh read-through of the groovy driver code to see if there’s anything more I can pick up from there.
hi first thanks for the continued great work ,
i am still having a problem with the presets , i have a routine that plays a preset when the back door is opened , it works great but when a notification from another routine hapens on the same speaker the last preset played plays after the notification
i did a logcat but its too long to post seems like a ping thing every .2 of a second
will try and split it up
