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

Hmm… really interesting. You’re logs show that the responses the hub receives have no mac address. They only show sender ip:port. Honestly though this is the first time I ever saw this.

Do you have any other devices or bridges installed in your ST that use a network connection? Any device that doesn’t use zwave / zigbee should connect over the network.
I think every lan dth relies on mac addresses, at least they should.

Sorry that I cannot help you out here immediately but I just wasn’t expecting something like this.

A lot of people installed node.js on their raspberry already. Also a lot people here use a raspberry to run cast-web-api. Instructions are also available for linux. I admit they’re not really detailed but linux has so many flavors it’s impossible for me to write a detailed node.js install guide for every one of them.

Google how to install node.js for the version of linux on your raspberry and then just follow the mac instructions.

How do you resolve the MAC of the cast devices, arp? Is there a requirement that the cast devices and node server be on the same network? I currently have multicast forwarding between my server network and LAN but ARP will not work… which is most likely the problem.

I don’t know how ST does it. Every response package on ST has a mac address field.

Yes, absolutely. It is designed to run locally and that will probably never change :slightly_frowning_face:

Has anyone had an issue where the devices aren’t saving? All of the devices show up when I select “Discover devices”, but when I select them and press save, they don’t save. The service seems to be running okay, not sure what’s wrong. I’ve tried reinstalling the app, the service, even the device handlers. No luck.

Has anyone had an issue where the devices aren’t saving?

Yes, just having this problem myself after attempting to update everything to v1.

Comment below was the issue/solution for me too. Hadn’t quite made it through the new tutorial yet :X

there are now two device handlers to make this work. Installed the 2nd and it all came to life.

And the final piece of the puzzle for me was to delete the old cast devices and cast-web DTH, then the new one was able to successfully create the new cast devices.

I’m having problems setting up again after upgrading to V1

Node seems to be running fine, testing the API connection returns 200 Connected, but after device discovery I select my devices and click next and I’m presented with a blank page. If I click Save, I get the error:

Error - Bad State. Unable to complete page configuration

The live log shows the following :
error physicalgraph.app.exception.UnknownDeviceTypeException: Device type ‘cast-web-api’ in namespace ‘vervallsweg’ not found. @line 125 (addDevices)

I’ve tried rolling back to Node V6.11.5, removed the smart apps and device managers and re-added them, nothing seems to work.

Can anyone offer assistance please?

EDIT - Nevermind… I just realised there are now two device handlers to make this work. Installed the 2nd and it all came to life.

Thanks Anyway

3 Likes

Thank you for the awesome app! Facing a small issue where the nods js server crashes occasionally and I have to manually start it again via dory node js. Is it possible to restart the server automatically?

using npm forever?

Not sure how exactly using dory node js app for a android. Found out ways to do it using Linux.

nice, yeah I couldn’t find the ‘settings’ docs in the api docs provided in the dory.js android app. I enable ‘start on boot’ and ‘auto restart’ but keep the remaining limits at 0. I could use forever start but command line on android is not fun using virtual keyboard. I also disabled battery app management on the tablet and set a static ip in the wifi menu of the tablet. I’ve had to restart it manually a few times over the past month or so though. Either restart the tablet or script in dory, both work.

1 Like

Any plans to port this to Hubitat?

2 Likes

I’ve installed everything, but when I do device discovery, it doesn’t find anything. The server responds correctly to a /getDevices request, but it doesn’t look like device discovery makes that call. Instead, I just see a bunch of /device calls in the server log.

Server 2.2.2 and the latest DHs and SA from the repo (which I pulled using “Update from repo” in the SmartThings dev portal.

Thanks for any direction!

Looks like a bug: Here’s the line that’s causing the problem. Looks like it was mistakenly(?) changed two months ago in the latest version from /getDevices to /device

Well, even after changing that to /getDevices, I’m running into a new problem. The service manager is now hitting the server, but here’s the log:

7:12:26 PM: debug getChildDevices(false), children=0
7:12:26 PM: debug getChildDevices(false), children=0
  7:12:25 PM: error java.lang.IllegalArgumentException: Maps with null keys can't be converted to JSON
  7:12:25 PM: debug index 1: null, null
  7:12:25 PM: debug index 4: null, null
  7:12:25 PM: debug index 5: null, null
  7:12:25 PM: debug index 2: null, null
  7:12:25 PM: debug index 0: null, null
  7:12:25 PM: debug JSON rcvd: [[deviceFriendlyName:All speakers, deviceName:89220fec-3468-4053-8e2b-69ce8b7fe700, deviceAddress:192.168.2.195, devicePort:42162], [deviceFriendlyName:Bedroom speaker, deviceName:08dff45c8d2a43d258b3d47eba561c24, deviceAddress:192.168.2.195, devicePort:8009], [deviceFriendlyName:Living Room TV, deviceName:7ff1cd1eecd2da7f40d696739edb5fde, deviceAddress:192.168.2.170, devicePort:8009], [deviceFriendlyName:Bathroom speaker, deviceName:744cc881f467fdb9d9380ff9eab0d5d5, deviceAddress:192.168.2.79, devicePort:8009], [deviceFriendlyName:Kids room speaker, deviceName:061e478919b0b198a1c61d263a7b9604, deviceAddress:192.168.2.177, devicePort:8009], [deviceFriendlyName:Kitchen speaker, deviceName:eb6339119b38d14e47d4ffc8b10f166e, deviceAddress:192.168.2.14, devicePort:8009]], JSON.size: 6
  7:12:25 PM: debug Parsing 'index:1D, mac:000C294DDB29, ip:C0A8020F, port:0BBB, requestId:e486843a-21ea-4800-81b7-35868894008b, callback:true, headers:SFRUUC8xLjEgMjAwIE9LDQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247IGNoYXJzZXQ9dXRmLTgNCkRhdGU6IFNhdCwgMTQgSnVsIDIwMTggMDI6MTI6MjUgR01UDQpDb25uZWN0aW9uOiBrZWVwLWFsaXZlDQpDb250ZW50LUxlbmd0aDogODM3, body:W3siZGV2aWNlTmFtZSI6Ijg5MjIwZmVjLTM0NjgtNDA1My04ZTJiLTY5Y2U4YjdmZTcwMCIsImRldmljZUZyaWVuZGx5TmFtZSI6IkFsbCBzcGVha2VycyIsImRldmljZUFkZHJlc3MiOiIxOTIuMTY4LjIuMTk1IiwiZGV2aWNlUG9ydCI6NDIxNjJ9LHsiZGV2aWNlTmFtZSI6IjA4ZGZmNDVjOGQyYTQzZDI1OGIzZDQ3ZWJhNTYxYzI0IiwiZGV2aWNlRnJpZW5kbHlOYW1lIjoiQmVkcm9vbSBzcGVha2VyIiwiZGV2aWNlQWRkcmVzcyI6IjE5Mi4xNjguMi4xOTUiLCJkZXZpY2VQb3J0Ijo4MDA5fSx7ImRldmljZU5hbWUiOiI3ZmYxY2QxZWVjZDJkYTdmNDBkNjk2NzM5ZWRiNWZkZSIsImRldmljZUZyaWVuZGx5TmFtZSI6IkxpdmluZyBSb29tIFRWIiwiZGV2aWNlQWRkcmVzcyI6IjE5Mi4xNjguMi4xNzAiLCJkZXZpY2VQb3J0Ijo4MDA5fSx7ImRldmljZU5hbWUiOiI3NDRjYzg4MWY0NjdmZGI5ZDkzODBmZjllYWIwZDVkNSIsImRldmljZUZyaWVuZGx5TmFtZSI6IkJhdGhyb29tIHNwZWFrZXIiLCJkZXZpY2VBZGRyZXNzIjoiMTkyLjE2OC4yLjc5IiwiZGV2aWNlUG9ydCI6ODAwOX0seyJkZXZpY2VOYW1lIjoiMDYxZTQ3ODkxOWIwYjE5OGExYzYxZDI2M2E3Yjk2MDQiLCJkZXZpY2VGcmllbmRseU5hbWUiOiJLaWRzIHJvb20gc3BlYWtlciIsImRldmljZUFkZHJlc3MiOiIxOTIuMTY4LjIuMTc3IiwiZGV2aWNlUG9ydCI6ODAwOX0seyJkZXZpY2VOYW1lIjoiZWI2MzM5MTE5YjM4ZDE0ZTQ3ZDRmZmM4YjEwZjE2NmUiLCJkZXZpY2VGcmllbmRseU5hbWUiOiJLaXRjaGVuIHNwZWFrZXIiLCJkZXZpY2VBZGRyZXNzIjoiMTkyLjE2OC4yLjE0IiwiZGV2aWNlUG9ydCI6ODAwOX1d'
  7:12:21 PM: debug discoveryPage(), refresh
  7:12:21 PM: debug Executing 'sendHttpRequest' host: 192.168.2.15:3003 path: /getDevices
  7:12:21 PM: debug Executing 'getDevices'```

Ok - found the problem. Your master branch looks like it’s your working branch. All of your website docs point to master, though.
Through some trial and error, I think I’ve realized that the correct branch is: cast-web-api-v1.0.0

I definitely recommend updating the website to point to the right branch. Or tag the release.
I also recommend working off of develop, rather than master. master should always be the latest stable code that is deployed to production. Check out git flow for more details.

Thanks for the app!

1 Like

it’s now working on Hubitat…

1 Like

No master is the latest release branch. Not sure what your definition of ‘working’ is :sweat_smile: .
Each name-vX.X.X branch is the development branch for the corresponding release. After it passed testing it is merged into master. So if you use a version branch, it will never update. Master is the correct one if you’re not planning to use a dev version.

Dude, you’re trying to make version 0 api and version 1 dth work. This code change is no accident.

API version 1 is completely different. It changed from /getDevices in v0 to /device/ in v1. So to make the dth and smartapp for v1 work with your api, you need to update it to v1 as well. Or if thats not your intention, use v0 api and dth/sm.
Long story short: use corresponding versions for api and the ST side.

If you’re on v0 (which I assume you’re) and want to update to v1 I wrote an article for that purpose.

Oh and u sure? We’re at v1.X max.

1 Like

I don’t have time for anything really right now. Will probably adjust it in the future, but my priority is ST at the moment.

That’s great news! If there’s anything I need to tweak I’ll do it once my exams are over.

That’s a great summary why Android works, but is not really great :joy: . Sadly there’s not much I can do about it…

Yeah forever manages bg-processes on linux and windows but I guess the issue is android, it’s activity lifecycle and battery management. Probably node itself is killed after a certain time, not just cast-web but node as a whole. As said, there’s not much I can do about it. My next priority is also working on reliability, new TTS features, maybe even DRM playback. Got some ideas how to get that to work. Android is so fragmented I’ll look into it, once cast-web is ‘feature-complete’ :frowning_face:

2 Likes