@vervallsweg Thanks for this great app! I created a snap for it, which makes installing it in any Linux distribution very easy. I’m currently using it on my raspberry pi running ubuntu core. I thought i should share this in case someone else finds it useful. To install you just need to run snap install cast-web-api the daemon will automagically start in port 3000.
3 Likes
I’m using a Raspberry Pi 3b. No multiple NICs, unless you count the one wired and one wireless connection. They’re not both hooked up (running wireless at the moment, but have tried both ways with same results). Thoughts?
Whatever the latest npm and node.js versions were as of yesterday (seems like 6.5 and 11.6-ish comes to mind? I’m not at the house right now, but I’ll look into it.
As for pinging the ST hub from the pi, I’ll take a look. I’ve been able to ping everything I try from everything I’ve tried, but whether I’ve recently tried to ping the ST Hub form the pi I don’t remember. Will report.
As for the Pi reporting as only 1 IP: you mean like via ifconfig? --As far as I kow, yes. My google wifi router certainly only shows it once, and with the reserved IP I’ve given it.
API version: 1.02 or whatever the latest is from the official install instructions.
Will test all these things again when I get back home and report what I find. Thanks for continuing to help out!
Got some results here:
So, yes, as you can see here, 6.5.0, 11.6.0, 1 IP address, and yes, I can ping my ST hub (second screenshot showing I have the right IP address. Don’t get hung up on that it says Bedroom TV… That’s just the friendly name I gave my Shield for home automation purposes. You can see at the bottom that it’s the SHIELD, which is also my ST hub).
I keep hoping it’s going to be some big red flag, but literally every detail of the process is going perfectly, if you go back and look… It just seems that, for whatever reason, the API itself decides to talk back to everything at 0.0.0.0:0, even though it’s clearly taking commands from and listing everything out perfectly.
1 Like
I was just playing around with the SmartThings app Speaker Companion and noticed it has the ability to change the voice that is spoken. Is that possible to do using WebCoRE?
I’m still rooting for you, you’re so close! Is your smartthings hub the USB dongle that attaches to the Shield? If so you might be the only one in this thread that has that setup.
Have you tried modifying the castWebApi.js file? There is a line in there where you can set the hostname, honestly I’m not sure if thats something you should mess with but its worth a try.
[EDIT] “hostname” is just a loopbaack address so probably dont want to mess with that.
Just a shot in the dark but try disabling IPv6 on your router, I believe that caused issues with other google api’s (assistant relay)
I appreciate that!
Yes, the SmartThings Link…though, to be clear, really, the SHIELD is the hub, and the USB dongle thing just adds a ZWave and Zigbee radio. My understanding is that the firmware is in the Shield and the Shield would work just fine as a SmartThings hub controlling devices that don’t require those kinds of radios. Nonetheless…I’ve suspected that you may be right, that no one else on here is testing with this setup, and it may explain why nobody else’s fixes have been applicable to me.
That said, I’ve never had an issue whatsoever with any device, service, automation, etc. that I’ve set up, and it’s pretty diverse. So, while I don’t think (and haven’t found in my research) there to be any limitation with the Shield’s capabilities as a ST hub, it has occurred to me that this particular API might not have been coded with it in mind as a test platform, and there could be some trivial thing in the code that could make it compatible. --But those possibilities are definitely more @vervallsweg territory.
Thanks for the IPv6 reco. That one occurred to me the other day, but alas, it is disabled by default on Google WiFi. I did have it enabled on my Shield at one point, but it was doing nothing anyway, since my network doesn’t support it, so I turned it off.
1 Like
ok, so the logging is set to “4” does it show the errors in the live logging in the IDE?
I haven’t live logged the IDE for this yet. Do you see somewhere above that I have logging set to 4, or are you just telling me to set it to 4 and live log the IDE?
My kid has an orchestra performance I have to go to now, but I’ll try to get on with the IDE tonight and see what’s up with the live logging. Thanks! (And when you say logging set to 4…where exactly should I set this? I have tried so many things over time, there’s no way anything I had set in a screenshot above is still set that way.) 
i see it’s set to “1”, yes set the logging for service manager to 4 and check out the live logs in the IDE, locations>mylocation>livelogging I bet the issue shows up there. If I remember right, it’s a firewall issue that can cause these problems? Seems to me like the one of the DTHs (device handlers) aren’t working right. Here are some tidbits of the similar problem and solutions:
1.> In the “Installed Devices” section, only my speaker groups have their names showing within the smartapp- the rest are “cast-web-device”. Does that change on their own?
Hmm… I know how this happens, but not why. It shouldn’t. You could speed things up by going to devices > cast-web-api > tap the ‘reconnect’ button. This should be done on install. Don’t know why this didn’t happen completely for you and matt.
Then hit ‘next’ ‘next’ ‘save’ and the device name populated in the ST app under things and at the bottom of the SM app, and now i can touch the ‘thing’ and it opens properly in the ST app. I had to repeat for each google home/mini.
Ahhh… you basically triggered a manual refresh of each device
. I trigger this through code on install. Don’t know why this doesn’t work 100%. As said you can do the whole thing automatically by going to the cast-web-api device in ST [app] and hit the refresh button there. It just loops through all the devices and calls .refresh() on them.
-
Another function that didn’t work at first was when the GH Minis were all called “cast-web-device”. When I would go into each device, the Android app would crash (the iOS app would not). When it finally started to work was after creating the firewall rule (in windows 7), BUT I had just removed the SmartApp and the two DHs from the IDE and did a fresh install, so it could have been due to that.
Mostly no errors…
A couple of times “Resync Failed code=429”, but looking through the logs, I’m not sure that’s related to cast-web-api at all…seems to be in relation to other devices I have installed.
A log below of me installing the web app, finding 12 devices, adding 4 of them, and saving the configuration:
[logs redacted]
I should’ve filtered. I’ll do that next. Poking around, messing with everything in the app just to get it to log, I got Cast-web Service manager to throw 2 more errors:
[logs redacted]
But that’s it…for the most part, no errors…just a bunch of info that seems to indicate everything’s talking.
Man, this makes me wanna cry. I’m SO CLOSE!
OK WAIT…
Maybe this is something?
I just started over with installing the smart app, and filtered only Cast web - Service Manager as I discovered 12 and installed 4 devices… In the log, you’ll see that it says “no cast-web-api installed”…
And indeed, even though my Cast web - service manager generated logs, and each cast-web-device generated logs, cast-web-api NEVER DID…even though it DOES show up in my things list…and I definitely did install the device handler. And when I click the refresh button inside it, it still doesn’t generate a log, nor does it seem to throw errors on my api running on the pi anymore…
Could it be that somehow my cast-web-api device is isolated? Even though it’s being generated freshly when I install the smart app (and God only knows how many times I’ve freshly installed the DTH), it seems like it’s just not passing the info through like it should? Logs below:
[logs redacted]
1 Like
i saw that too, no cast web api installed. I feel like you’re getting close. So I have 2 DTHs and 1 smart app. That’s your setup as well right?
Also, I was poking around on the GIT and I saw a similar issue
> physicalgraph.device.Device,B---------4]; default message [{0} must be unique]
> [@line](https://github.com/line) 126 (addDevices)
> 9:16:52 PM: debug getChildDevices(false), children=0
> 9:16:52 PM: debug No cast-web-api installed
Any ideas as to what may be causing this?
Thanks!
kurtwarwick commented 15 days ago
Found others had the same issue in the thread and got it sorted out. It was because I had a bridge installed with the the same networkid.
Yes sir, and EUREKA…I think I’ve figured it out!
It seems that, as of a couple of updates ago, the Nvidia Shield started blocking ports and broke all kinds of smartthings stuff! This is just one example of several threads I found…
The issues they are having sound EXACTLY like the issues I have…ST can talk to the device, but the device can’t talk back to ST…gets refused, returns 0.0.0.0:0, etc. HOWEVER…as of 2 versions ago (very recently), it was supposedly addressed “Resolves port blocking issue with SmartThings on SHIELD”, but I’m on 7.2.2 (which may be a preview release?), and I’m still having the issue.
I checked with nc -vz 192.168.86.68 3000 and I get “failed: Connection refused.”
I ran a port scanner on my Shield IP address and only found 2 open ports…if I try nc -vz on those ports, I get succeeded. SO…it definitely looks like my Shield is BLOCKING PORTS! Grrrrr…
So, what to do now? Obviously I don’t love the idea of having to buy a new ST hub and manually port everything over…Some people say it’s possible to open ports internally on the Shield? Like they ran Kodi and it opened 8080, for example…
At least this is something. Another path to look down, anyway. Credit where credit is due for those above who mentioned it could be the Shield.
Interesting. I’m still catching up on your third octet .86 Lan ip addressing. Is it so you can have 2 separate subnets?
That’s just how Google WiFi comes out of the box.
Just for shits & giggles, tonight I turned off my Google WiFi setup and swapped in my old Linksys set to defaults with all 192.168.1.x, and had the exact same issues… No progress to be had.
Oh I wasn’t troubleshooting, just commenting. It’s sad really how rare a 3rd octet that isn’t 1 or 0 on a home network is lol.
Ha.
So, I just looked in the IDE after reading a few more threads such as this one, and noticed that, yep…my hub is listed as having the ip address 0.0.0.0
Lemme guess…that’s not normal. And I’ve been wondering all this time why my API kept trying to talk back to 0.0.0.0:0. Where was it getting this IP from? I guess from SmartThings…
Now, obviously, my Shield/ST hub has an IP and a MAC address…but it’s just not reporting it to the IDE, I guess, so…unless anyone has any bright ideas about how to make this report its real status, I guess I’m dead in the water without a new hub.
nice find! Doesn’t look good. You could maybe hard code the actual hub IP?
For anyone else in this situation (for nearly 5 months)…
The Shield Experience 7.2 update got pushed today and…it did NOT include a fix for the Link’s IP address bug. I think it’s pretty obvious now why the ST staff has been so quiet on the timeline for the fix. Either NVIDIA has super-long development timelines, or it’s never coming at all.