Web Requests are not working, can't access API's etc?


Is anyone else getting web request issues?

All my pistons seem to be working fine since people were having problems on the 8th of September - however today (and probably from about the 8th) any piston that tries to do a web request, accessing an API etc just doesn’t do anything.

I get no errors in full logging, in fact it doesn’t spit out anything - I can click test on a web request and it just says “testing” then stops but nothing actually happens.

Anyone have any ideas? I’m at an absolute loss.

Tesla API Access

Just checked one of mine that ran an hour ago and it looks ok (uk based)

Someone had a problem a few days ago with web requests not working, I think they ended up resetting the hub. I’m not sure if that would require you to re add all your devices and pistons etc, so would not recommend it as a solution at this point.


Oh god yeah I don’t want to reset it.

Actually i’ve just realised my Octopus API’s are working fine. It’s literally just my webrequests to Tesla’s API’s that are not working. Really odd. It’s just a URL so I can’t understand why it’s not working.


I’m experiencing a broad range of failures this morning. In fact, I can click ‘Test’ on some of my pistons and the trace shows no execution of any kind taking place. I don’t think this is just a web request issue.


Okay, this one really has me baffled.


Is it something broken with Webcore itself do you think?


I think the biggest clue is:


It appears to be that way though @bthrock might have issues with other things?

There’s nothing wrong with the Tesla API if just seems these specific pistons won’t do anything.


Yeah, that’s not really a clue. Firing a piston that worked up until two days ago with the test button and having nothing happen in the trace, log, or otherwise does not suggest this is a matter of a failed web request.

With that said, when I have time, I will perform some Tesla-related web requests outside of webCoRE and look at the other pistons that have been failing at the same time.


I do not have a Tesla, so I have not used your piston, but I would be tempted to try testing the Tesla API with a new, single command piston. (well, a single command plus a log $response to console)

If the test piston works, then we know the API link is good, and the issue may lie with the ST update… (since the piston was working for a long time prior)

If the test piston fails, then something may have changed on the Tesla side…
(although it could still be the ST changes here as well)

From a quick skim, my first thought is an authorization failure…
(which kind of makes sense with all the recent changes)


My best guess—and it’s only a guess—is that it may be the same thing I’ve run into before, and that is webCoRE’s inability to handle lengthy json responses from web requests.

Smartthings has been messing with so many things lately, though, it’s hard to be sure.


No, I will test the API outside of webCoRE with the existing credentials, then I will know exactly how Tesla responds. I expect that will tell me everything I need to know.


Sorry, I thought that was already done. Yes, that should be the first step.


The GET and POST web requests are working outside of webCoRE. However, when I attempt to invoke one of these requests via the TEST button in webCoRE I get the following error in the IDE under live logging:

java.lang.reflect.UndeclaredThrowableException @line 1304 (api_intf_dashboard_piston_test)

And I have no idea what to do with that.


Would this suggest ST has broken something with Webcore recently?

@bthrock as a side to this - I don’t mind running scripts on my own server and then feeding the basic information into webcore if it makes webcore more reliable? Eg I don’t mind running a script on my own server that just spits out the battery level in plain text that webcore can use. I do that currently for my electricity API.


What this suggests is that I’m in over my head. :rofl:

It’s possible we may be chasing more than one moving target. Tesla is in the process of enabling 2FA, which probably explains why the format of the tokens appeared to have changed slightly. SmartThings is also making a lot of fundamental changes right now—none of which should affect any of this, but ST has behaved very inconsistently for me and others within the last 30-60 days.

There have been other posts on this forum of late with people having issues with web requests, but none of them seem to match exactly what we’re seeing here.

I’m going to take another look at this later this week when I have more time, but I’m hesitant to do much while Tesla is still making changes for 2FA.


This is true, if I manually write some simple scripts, they’ll probably break with 2FA, unless the tokens will work the same and it’ll just require 2FA to active them, which again might mean our Webcore solution doesn’t work at all.

Is Webcore working a lot better on hubitat or is it par for par at the moment?


I did some more digging, and we are not the only ones having trouble with failed connections to the Tesla API on SmartThings. However, this does appear to be an ST issue, as GET and POST requests appear to be affected only for those using the ST platform. Users on Hubitat are reportedly not affected (nor are requests made outside of ST/webCoRE on any platform).

There have also been a couple of reports of intermittent success in ST, which if true, gives me some hope this issue will be resolved eventually. At this point, however, working outside of ST appears to be the only solution.


I’m sure you’re aware by now, but just to close out this thread, this issue is now resolved.


I didn’t know this, but thanks, I can get the car plugged back in properly now and stop it just charging up automatically at the most expensive rates!