[RELEASE] cast-web v1.2.1 - Chromecast Integration (EDGE Driver discussion begins in post 1668)

I’ve had the same problem, Google TTS was working, and then stopped, unfortunately I can’t pinpoint when this happened.

Slightly annoying as I much preferred the voice from the google TTS. It seems highly likley google have broken something again.

I’m getting this same error. I used cast-web-api --hostname=[ip address] --port=8080 and it seems to have gotten rid of the error but if I close the Node.js Command Prompt and reopen it the port is reset to 3000.

I can’t get the Cast Web app to discover any devices and if I use the Test API tool it just spins and spins.

Update:

I found that multiple Node.js processes were running. Closed them all down and restarted Node.js.

This eliminated the port error. The Cast Web app still can’t locate any devices.

If I visit the ip address on the computer that Node.js is running on I can get responses from the app.

Both of these address provided good responses in both the browser and in the Node.js Command Prompt

http://192.168.xx.xx:3000/device/
http://192.168.xx.xx:3000/device/discover

I tried visiting the ip address from my phone’s browser and it couldn’t reach the page. Both the desktop that Node.js is running on and my phone are on the same network. The desktop is wired and the phone is wireless.

Updated - Resolved

Resolved device discovery issue by correcting the Windows Firewall settings to allow Node.js through on my private network.

Don’t know if this is better for the WebCoRE community or here, but in WebCoRE, what’s the difference between “Speak” and "Speak text?

So I had everything up and working just fine, everything was great for about a week. Then, for some unknown reason I lost my Insignia Google Home Device and had to set it up. Upon setup, it created it as a new device giving me a duplicate of the same device. I deleted them both, the did the setup again. I then assumed that this would break my cast-web setup so I went in and did a discover and sure enough, it found the “new” device and added it. Which then created a duplicate device in SmartThings. I then went into my devices and deleted the old one. Then went back into the Cast web - service manager and all I’m getting now is “Something’s Wrong We can’t load your screen right now” with a “retry” button that just repeats that same message over and over again. I can’t delete it. I can create a new one, which successfully connects to the cast-web-api and discovers devices, but when I try to “save” the devices, it throws another error.

Any help would be appreciated.

Well… I went in and deleted the last remaining component, cast-web-api, from my device list. I then went back into the Cast-web - service manager and it was now functional. I deleted it, then removed it, then readded it. I was able to reconfigure it with my IP address and everyting looked good. It discovered all 11 of my devices successfully. I then “saved”. All seemed good until I went back to my device list… There was now a cast-web-api device and 6 "cast-web-device’ devices listed below it. I repeated by deleting all of the cast-web-devices and the cast-web-api and went through the deleting and adding of the smart app again… and now this time there were 8 ‘cast-web-devices’ listed. Scratching my head and looking through the list, I noticed only 3 of my actual devices were listed and it occured to me that maybe they weren’t ghosts left from previous installs but were my actual devices that weren’t get configured correctly. So I went to one of the devices and did “Ok Google, Play some music” hoping to see one of the devices to go from “Inactive” to “Playing”. It didn’t but one of the 8 ‘cast-web-devices’ disappeard… and sure enough, showed up in the list with the correct name now. I then checked the Cast-web service manager and saw the other 7 ‘cast-web-device’ there in the list. I tapped on one of them and hit “next” then “next” then “save” and it took me back to the service manager with the device name now set correctly. I did this for all of the devices that were named ‘cast-web-device’ and it fixed all of them by giving them the proper name. I was able to confirm that all of them are now working correctly.

Definitley some wonky behavior, but I was glad to have figured it out.

I’ve got this working and it’s pretty awesome, thanks! I just bought a Lenovo SmartDisplay and now, I’m trying to figure out how to cast my security camera (rtsp stream). Do I simply tell webcore to “Play a track” and provide the rtsp url?

1 Like

Is there a way to clear the notification logo that comes up on Google displays after they have been broadcasted to? I have to manually swipe it away after each notification

@iderdik I could never get rtsp working correctly with Chromecast. If you can get your camera stream in mjpeg the media type is image/jpeg.

@vervallsweg can you please add image/jpeg to the media type pull down in the present generator site. It’s a huge undertaking to modify every present manually.

I am using the node.js in my android mobile phone. It needs to have the “start” pushed and then it means it is running, but the problem is that frequently it stops. Is there a way to keep it running all the time ?

Hello,

I’ve installed the Raspberry Pi components, then installed the SmartThings components as per https://vervallsweg.github.io/cast-web/installation-cast-web-api/

Cannot get a successful ‘Test API connection’
nor does Service Manager Discover Devices.

Not sure anything is returning from ‘sendHttpRequest’, any help would be greatly appreciated.

Thanks

849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎52‎ ‎PM: debug discoveryPage(), refresh
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎52‎ ‎PM: debug Executing ‘sendHttpRequest’ host: 192.168.0.XX:3000 path: /device
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎52‎ ‎PM: debug Executing ‘getDevices’
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎40‎ ‎PM: debug discoveryPage(), refresh
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎40‎ ‎PM: debug Executing ‘sendHttpRequest’ host: 192.168.0.XX:3000 path: /device
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎40‎ ‎PM: debug Executing ‘getDevices’
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎20‎ ‎PM: debug discoveryPage(), refresh
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎20‎ ‎PM: debug Executing ‘sendHttpRequest’ host: 192.168.0.XX:3000 path: /device
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎20‎ ‎PM: debug Executing ‘getDevices’
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎09‎ ‎PM: debug discoveryPage(), refresh
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎09‎ ‎PM: debug Executing ‘sendHttpRequest’ host: 192.168.0.XX:3000 path: /device
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎49‎:‎09‎ ‎PM: debug Executing ‘getDevices’
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎58‎ ‎PM: debug discoveryPage(), refresh
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎58‎ ‎PM: debug Executing ‘sendHttpRequest’ host: 192.168.0.XX:3000 path: /device
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎58‎ ‎PM: debug Executing ‘getDevices’
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎57‎ ‎PM: debug getChildDevices(false), children=0
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎56‎ ‎PM: debug getChildDevices(false), children=0
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎55‎ ‎PM: debug getChildDevices(false), children=0
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎53‎ ‎PM: debug checkApiConnectionPage(), refresh
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎53‎ ‎PM: debug Executing ‘sendHttpRequest’ host: 192.168.0.XX:3000 path: /device
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎53‎ ‎PM: debug Executing ‘getDevices’
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎42‎ ‎PM: debug checkApiConnectionPage(), refresh
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎42‎ ‎PM: debug Executing ‘sendHttpRequest’ host: 192.168.0.XX:3000 path: /device
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎42‎ ‎PM: debug Executing ‘getDevices’
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎31‎ ‎PM: debug checkApiConnectionPage(), refresh
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎31‎ ‎PM: debug Executing ‘sendHttpRequest’ host: 192.168.0.XX:3000 path: /device
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎31‎ ‎PM: debug Executing ‘getDevices’
849a291f-e33e-4ad1-ae8a-6c77934d5261 ‎12‎:‎48‎:‎30‎ ‎PM: debug getChildDevices(false), children=0

I can’t get the 1.1.0 branch to complete discovery on Windows Server 2012 R2. Are you behind on pushing commits to the mdns-cast-browser repo or is it just that unstable right now?

After you start up your API it should tell you what IP and port it is running on. It won’t be 192.168.0.XX like in your log. That’s not valid. That is the URL you should have in the SmartApp.

Did you guys figure out what was going on with Google TTS? I thought it was a problem with the Hubitat driver I was using until I finally used Postman to hit the API directly.

TTS is broken for me as well for the past days…

I’m having the same issue here, identical version of cast-web-api.

http://192.168.x.x:3000/device/ returns []
http://192.168.x.x:3000/device/discover returns {"response":"ok"}

“Cast web – services” app reports Connected OK: 200 when testing API, but never finds any of my devices when “Discover Devices” is pressed, even if I wait overnight.

Node.js terminal can see the phone trying to scan for devices I think… last 5 outputs here:
2018-12-11T08:02:47.537Z on("request"): /device
2018-12-11T08:02:57.702Z on("request"): /device
2018-12-11T08:03:07.856Z on("request"): /device
2018-12-11T08:03:18.005Z on("request"): /device
2018-12-11T08:03:28.192Z on("request"): /device

1 Like

Mine is working properly.

Can you reach the API from a browser on your network?

On Android it’s tricky but I believe I’ve got it going. Power saving or battery optimization needs to be off for whatever app you’re running the installed npm process.

The DORY app has a restart API on system restart option that works well with some sort of scheduled reboot. My API was going down about every 40 hours or so but now it’s up 95%. The forever npm was great on my computer but I couldn’t get it going well on the old Android tablet. Also, never sleep in Android settings would help keep it alive. Of course you’d want the host client plugged into power.

1 Like

This is great! I was using LANnouncer to receive TTS from BigTalker on a Raspberry Pi 3 running Emteria OS (Android) connected to my intercom system audio input. I like the Chromecast Audio for this better than the Pi 3 EXCEPT… The Pi 3 running Emteria OS had finally gotten my door announcement delay down to almost nothing (less than half a second). The Chromecast Audio is lighter weight/cheaper and better in other ways too. I especially like that I now have a way to cast audio and have it play through my intercom. BUT… I can’t stand a 3 second delay for door announcements.

I am going to now see if there is a way to input the audio from the Chromecast Audio into the Pi 3. I could use the Pi 3 for door announcements to keep the delay down and have the Chromecast Audio attached to it so that I can receive casted audio. I had looked at various apps that make an Android device act as a Chromecast receiver, but they all expect to cast video. I only want the Audio here.

If this device handler simply didn’t have the delay then it would be almost perfect for my purposes.

1 Like