Model S REST API

[jayman]

It is happening again today. On the CMD I am getting this below. Again, I can login using the app on a different network. Any ideas?


Oct 09:40:07 - timestamp,speed,odometer,soc,elevation,est_heading,est_lat,est_
ng,power,shift_state,range,est_range
Oct 09:40:08 - [Error: login failed]
Oct 09:40:08 - Warn: no tokens returned, calling wake_up then trying again
Oct 09:40:10 - [Error: login failed]
Oct 09:40:10 - Warn: no tokens returned, calling wake_up then trying again
Oct 09:40:11 - [Error: login failed]
Oct 09:40:11 - Warn: no tokens returned, calling wake_up then trying again
Oct 09:40:13 - [Error: login failed]
Oct 09:40:13 - Warn: no tokens returned, calling wake_up then trying again
Oct 09:40:15 - [Error: login failed]
Oct 09:40:15 - Warn: no tokens returned, calling wake_up then trying again
Oct 09:40:16 - [Error: login failed]
Oct 09:40:16 - Warn: no tokens returned, calling wake_up then trying again

 

[dirkhh]

It is happening again today. On the CMD I am getting this below. Again, I can login using the app on a different network. Any ideas?


Oct 09:40:07 - timestamp,speed,odometer,soc,elevation,est_heading,est_lat,est_
ng,power,shift_state,range,est_range
Oct 09:40:08 - [Error: login failed]
Oct 09:40:08 - Warn: no tokens returned, calling wake_up then trying again
Oct 09:40:10 - [Error: login failed]
Oct 09:40:10 - Warn: no tokens returned, calling wake_up then trying again
Oct 09:40:11 - [Error: login failed]
Oct 09:40:11 - Warn: no tokens returned, calling wake_up then trying again
Oct 09:40:13 - [Error: login failed]
Oct 09:40:13 - Warn: no tokens returned, calling wake_up then trying again
Oct 09:40:15 - [Error: login failed]
Oct 09:40:15 - Warn: no tokens returned, calling wake_up then trying again
Oct 09:40:16 - [Error: login failed]
Oct 09:40:16 - Warn: no tokens returned, calling wake_up then trying again

This is NOT what people are getting who have been blocked. You simply are failing to get tokens from the API. I have had this happen when their authentication server was flaky. But right now it's working well for me.

 

[jayman]

This is NOT what people are getting who have been blocked. You simply are failing to get tokens from the API. I have had this happen when their authentication server was flaky. But right now it's working well for me.

It's just weird that it is happening only with my home IP address and apparently for long periods of time. For instance, it started happening around 4 am and continues to not be able to log in.

 

[dirkhh]

It's just weird that it is happening only with my home IP address and apparently for long periods of time. For instance, it started happening around 4 am and continues to not be able to log in.

That's why I said earlier that I suspect routing issues. I had this happen when I was traveling. Couldn't log in from my laptop that I had with me, but from my server (in Portland) everything was fine. But since I had just arrived at that Hotspot in Austria I was pretty sure I hadn't been blocked, yet

 

[hans]

This is NOT what people are getting who have been blocked. You simply are failing to get tokens from the API. I have had this happen when their authentication server was flaky. But right now it's working well for me.

Nevertheless it's a condition that is concerning because the app is re-trying to call wake_up in a tight loop. Please upgrade to 0.6.53 as I added a 10 second delay in the code so that you won't get blocked for calling wake_up over and over every second.

If you see this again, as it's happening, run "teslacmd --all" and check if you are truly getting a login error, or just not getting tokens.

 

[jayman]

Nevertheless it's a condition that is concerning because the app is re-trying to call wake_up in a tight loop. Please upgrade to 0.6.53 as I added a 10 second delay in the code so that you won't get blocked for calling wake_up over and over every second.

If you see this again, as it's happening, run "teslacmd --all" and check if you are truly getting a login error, or just not getting tokens.

Thanks. I downloaded the newer version and it does appear to be waiting 10 seconds in between failures. This is what I got when I did the "teslacmd --all" : [Error: login failed]

But why would a login fail?

 

[hans]

Thanks. I downloaded the newer version and it does appear to be waiting 10 seconds in between failures. This is what I got when I did the "teslacmd --all" : [Error: login failed]

But why would a login fail?

It can fail for a bunch of reasons including that they have forbidden your IP address from logging in (HTTP 403: Forbidden). This happened to another person using VisibleTesla. Switching to another IP address cleared the problem since the block is by IP and not username.

Try the lowest level debugging which is to execute the curl command for login and see what HTML (if any comes back). Replace USERNAME and PASSWORD with your Tesla Motors credentials.

[SIZE=3][FONT=arial]curl -c cookies.txt -d "user_session[email]=USERNAME&user_session[password]=PASSWORD" https://portal.vn.teslamotors.com/login[/FONT][/SIZE]

 

[jayman]

This is what I got when I used the curl command as above. Here is the scenario I'm hoping is correct. It couldn't reach the car for whatever reason like the car was in a concrete environement without a signal, etc. Then because it couldn't it was doing a loop from the previous version without the fix causing the too many requests blocked?

"You have been blocked for making too many requests!"

 

[hans]

This is what I got when I used the curl command as above. Here is the scenario I'm hoping is correct. It couldn't reach the car for whatever reason like the car was in a concrete environement without a signal, etc. Then because it couldn't it was doing a loop from the previous version without the fix causing the too many requests blocked?

"You have been blocked for making too many requests!"

Another scenario is that they had an outage of their authentication server which just happened to correspond to when you starting streaming. In that case the same wake_up loop would cause too many requests for your car but not other people who already had their streaming tokens and were good for another 30 minutes.

Unfortunately you need to change your IP address, or convince Tesla to remove the block. They may free it up in a day or two if your request traffic dies down again. Sorry about that jayman.

 

[jayman]

Another scenario is that they had an outage of their authentication server which just happened to correspond to when you starting streaming. In that case the same wake_up loop would cause too many requests for your car but not other people who already had their streaming tokens and were good for another 30 minutes.

Unfortunately you need to change your IP address, or convince Tesla to remove the block. They may free it up in a day or two if your request traffic dies down again. Sorry about that jayman.

No problem. I'm just worried that it's something I'm doing wrong as it doesn't appear others are having this issue. I have streaming.cmd running as a service using nssm.exe in windows as another user said that doing it that way has kept his streaming.js from dying. I don't see how that could be it but just racking my brain a bit. The reason I don't think this happened during streaming is that this last time was at 4:50 am meaning my car had not been moving for 8 hours.

 

[hans]

No problem. I'm just worried that it's something I'm doing wrong as it doesn't appear others are having this issue. I have streaming.cmd running as a service using nssm.exe in windows as another user said that doing it that way has kept his streaming.js from dying. I don't see how that could be it but just racking my brain a bit. The reason I don't think this happened during streaming is that this last time was at 4:50 am meaning my car had not been moving for 8 hours.

Tesla often does maintenance late at night so it's not unusual to see an hour or more of downtime in the middle of the night (Pacific timezone). When writing any kind of scripts that poll, or retry in the event of an error, then a delay or a max request counter is probably necessary. I also find that lots of data comes back with "null" values even when other fields in the same response are populated. Applications have to check and handle "null" for any value fetched from Tesla (and of course take care not to confuse null with zero).

 

[jayman]

Well, I can log in again this am using my previously blocked IP. Just about 24 hours later so they must automatically put a block on it for a day. I'm gonna try using it again. Hopefully with the program update it won't be a problem but I'll report back.

 

[rdrcrmatt]

Well, I can log in again this am using my previously blocked IP. Just about 24 hours later so they must automatically put a block on it for a day. I'm gonna try using it again. Hopefully with the program update it won't be a problem but I'll report back.

Do you know what you were doing that caused them to block you?

I pull data A LOT, and I'm always streaming.

 

[jayman]

Do you know what you were doing that caused them to block you?

I pull data A LOT, and I'm always streaming.

No idea. From what I gather I haven't been doing anything different than what others are doing. I'm hoping it was the fact that when the tesla auth server goes down the script was being put in a loop constantly bashing the server and Hans fixed that. The only thing I may be doing differently is that I am using node on windows and nssm to run it as a seevice but how that would make it overload the server I have no idea...

 

[hans]

No idea. From what I gather I haven't been doing anything different than what others are doing. I'm hoping it was the fact that when the tesla auth server goes down the script was being put in a loop constantly bashing the server and Hans fixed that. The only thing I may be doing differently is that I am using node on windows and nssm to run it as a seevice but how that would make it overload the server I have no idea...

I run node in windows with nssm as well and have never been blocked by Tesla (knock on wood). I have streaming running 24x7.

 

[dirkhh]

I run node in windows with nssm as well and have never been blocked by Tesla (knock on wood). I have streaming running 24x7.

And I do the same on a Linux server. 24x7
(I had a development system blocked after a stupid nested bug caused things to cascade over night and cause a truly embarrassing number of requests... enough to earn me an email from a senior person at Tesla... :redface: )

 

[jayman]

I run node in windows with nssm as well and have never been blocked by Tesla (knock on wood). I have streaming running 24x7.

What kind of settings do you have on the service running? For instance, what do you have under recovery for first failure, 2nd failure, etc...?

 

[jayman]

What happens if I have streaming.cmd running 24x7 and then I send a command using teslacmd.cmd to unlock the door and then turn on the air, etc...?

 

[brianman]

What happens if I have streaming.cmd running 24x7 and then I send a command using teslacmd.cmd to unlock the door and then turn on the air, etc...?

I've done this. No issues to report.

I've tried spamming requests to honk the horn for about 30 seconds straight, no interruption in my other logging app.

I haven't done anything more 'rude' than this.

 

[hans]

What kind of settings do you have on the service running? For instance, what do you have under recovery for first failure, 2nd failure, etc...?

Restart, restart, restart.