I've been using the same code for a few months now, then suddenly it decides to stop working. I searched through SO and Google and couldn't find an answer.
When I try to set nest to away using curl, I get this response back:
{"error":"Device is unable to service this request at this time"}
If I use the exact same code and just change the away value to home, it works fine, only setting it to away gives that error. I can also get and set the temperatures of all the devices without any problems.
This error response occurs when a device has been rate limited. Since setting home/away is at a structure level and affects all thermostats in your that structure. If any one thermostat is rate limited you will be blocked as indicated.
Are you sure you are able to control the thermostat temperature for all thermostats in that structure during the time that you are receiving this error?
Related
I have been trying to externally log data to my home server with a little GSM modem and InfluxDB2 HTTP API- it is far away and needs to be external, just checking water levels and other system stuff.
I am struggeling to understand the correct payload and keys to give it in order for it to accept my data.
I am using an ESP32 and the requests module on Micro Python, using MicroPython_ESP32_psRAM_LoBo.
The GSM library I am using makes everything work as if I was connected to Wifi, I am pretty certian that my problem has nothing to do with the GSM side of things.
The system uses InfluxDB2 and Python3 ( Micro Python to be exact )
Current Setup
payload = {"header":"Authorization: Token CrAzYlOnG_ToKeN", "data-raw":"WaterWatcher1 Level=532,Volume=752.22,BattV=3.768,Temperature=25.36 1621434110"}
response = requests.post("http://xxx.xxx.xxx.xxx:8086/api/v2/write?org=Home_Org&bucket=BackYardInfo&precision=s", params=payload)
( xxx Replaced with my correct IP - Yes I have made sure this is correct and got my ISP to set it to static )
This gives me a constant Auth error :
W (3390149) HTTP_CLIENT: This request requires authentication, but does not provide header information for that
I have read over the InfluxDB2 docs and I still cant seem to get it correct, I seem to think that if I did this in InfluxDB Ver 1 it would have been easier but now I just want to try learn it this way.
I have entered the exact same data manually and that works fine ( changed the time stamps though )
I am pretty sure it boils down to me just not knowing how to send the data correctly with the requests module, any pointers and explanations would be a great help.
I managed to find a solution after days of searching and trying new things.
Basically I used the mrequests lib
( https://github.com/SpotlightKid/mrequests )
With this I managed to get the whole thing working as expected using the following code - Done in Micropython
I did make a free account with No-IP to set my ISP external IP to a URL, I dont think this has a massive change but it is worth noting.
I did try the older methods with this new URL and they still did not work.
Here is the new code with the mrequest lib.
import mrequests
url = "http://ni-ip-address:8086/api/v2/write?org=Home_org&bucket=backYardData&precision=s"
token = "Token CrazyLongToken"
DataString = "WaterWatcher1 Level=888,Volume=888.88,BattV=8.888,Temperature=25.36 1621694039"
res = mrequests.request("POST", url, headers={"Authorization":token}, data=DataString)
This works perfectly for me.
On a side note, I can also upload multiple points if I read them from a file but I had to put the newline char "\n" at the front of each of my lines not the end or Influx would not pars the data.
I think it boiled down to the urequest lib not being able to do headers as I needed them in post requests.
I may have just been using it wrong but I feel that I did give it more than a fair go at getting it right where as this mrequests lib just worked perfectly.
Hope this helps anyone else out there one day.
I use "CORS Anywhere":
https://github.com/Rob--W/cors-anywhere
Everything worked just fine until a few days ago.
Now, every request I make returns the same error:
Missing required request header. Must specify one of: origin,x-requested-with
for example:
https://cors-anywhere.herokuapp.com/https://www.instagram.com/adidas/
You can try for yourself, every request returns the same error.
I uploaded the code to my server and i still have the same problem.
I think CORS anywhere's owner got finally fed up with people abusing his service, kindly and freely provided for development purposes only:
Please see the related issue: https://github.com/Rob--W/cors-anywhere/issues/301
The demo server of CORS Anywhere (cors-anywhere.herokuapp.com) is meant to be a demo of this project. But abuse has become so common that the platform where the demo is hosted (Heroku) has asked me to shut down the server, despite efforts to counter the abuse (rate limits in #45 and #164, and blocking other forms of requests). Downtime becomes increasingly frequent (e.g. recently #300, #299, #295, #294, #287) due to abuse and its popularity.
EDIT: Turns out that I'm a few years too late, oh well, better late than never :D
I am working on an RESTful API in Node.js as a contractor, which is currently being used by a couple of blackberry apps written by other contractors. The stack is very common: Node, Express and Mongoose, running on heroku.
Consider the following API call:
curl "https://my-app.herokuapp.com/v2/rest/documents/?view=tree&annotate=ratings,accessible"
When a Blackberry app written in Java makes this call, it works fine every time.
Now consider this one:
curl "https://my-app.herokuapp.com/v2/rest/documents/?view=tree&annotate=ratings%2Caccessible%2CcontentSize"
When an Adobe Air Blackberry app makes this call, it often gets an HTTP 503 from Heroku with the Heroku Error code H12, which means that the request timed out. Although, on the BB app it does display "501 Error" when this happens. The logs show no 501s, only a 503.
However, if I make the same call to the server using curl, the response is successful, and for a while afterwards it is successful on the same BB app which previously had trouble with it, too. Almost as if the response succeeded, was cached on Heroku's side and then stayed cached for a while (this is speculation).
The main difference is the inclusion of contentSize in the annotate query-string parameter. But clearly, it isn't slowing it down too much since it seems to work fine when called through curl.
Sadly, I do not have access to the source code of either of the BB apps, and the developers are generally quite slow to respond since it is not their only project.
So I was hoping that somebody on SO might have some experience with this kind of a problem and maybe point me in the right direction.
Thanks!
Is the app in question scaled enough to prevent idling? I ask in particular as the "curl-ing then allows BB to work for a while". Perhaps the timeouts are occurring when BB app is trying to access the idled service? Not sure off the top of my head outside of that, but might be a good place to start looking at least.
I am trying to get avatars for game center friends using the loadPhotoForSize: withCompletionHandler: but it keeps throwing GKErrorDomain Code=3 "The requested operation could not be completed due to an error communicating with the server.
Does this method not work on Sandbox Game Center?
For me, it always gives this error if the player does not have a photo, but if I add a photo, the error goes away and it loads the photo correctly. I have only tested this in sandbox though, so I'm not sure if it works the same outside of sandbox.
I use the Google weather API in my web site, and today I get an error that the API link doesn't return any data.
When I check the link directly I get an (Error 403).
Here is the link.
Can anyone please tell me a solution for this and provide me another link for the API?
Every now and then the API stops working for short periods of time, the last days more often a 403 is trown. For my site, last night it happened 13 times. But the site tries immediately again and the second or third time, the data loads without problems. As the API is unofficial, not sure what’s causing the 403.
Make sure you cache the data as the API will block your IP temporary when you make too much requests. In my case, I cache for 20 minutes and if no data can retrieved, the site will not try more than 10 times to reload the API. Once I forgot to turn caching on after debugging and as my site did many hundred requests (with every visitor), the IP was blocked within an hour. If a remember correct, the error was not a 403. Fortunately, the block lasts for less than a half day.
There is currently an intermittent 403 Forbidden response to the Google Weather API that you are using. See Google Weather API 403 Error
The reason for the intermittent 403 response is not known but has been a problem since the 7th of August 2012.