Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

New Windows Phone Tesla App

This site may earn commission on affiliate links.
If there are many people writing to ownership we may have a chance to get a response, I’m certain this is not about a security concern since the credentials are very well protected within the app and sandboxed, and the cloud service doesn’t store the credentials either, at least would be nice to know the reason why was blocked.
 
If there are many people writing to ownership we may have a chance to get a response, I’m certain this is not about a security concern since the credentials are very well protected within the app and sandboxed, and the cloud service doesn’t store the credentials either, at least would be nice to know the reason why was blocked.

Ownership replied to me saying they were sending it to Engineering and quite a few people have e-mailed this week about Windows Phone. Keep e-mailing!

-m
 
I might have missed it in previous posts.

Can you briefly describe your query pattern? I'm curious what might be unique about it such that they haven't (AFAIK) blocked all of the Windows Phone apps and my logger continues to run properly.

non-streaming

streaming

The App will keep functional but only with the basic functionality, if you look on your app all features provided by the clod service stopped working.

Live tiles, email alerts, notifications, scheduling and any update related to the Tesla address book are not longer functional since at this moment the cloud service is down.
 
Could they be filtering calls from Azure? To test that, does anyone here log data from an Azure VM?

I haven't tried to change the service static IP yet, however even if that works it won't help much since it is futile try to go around Tesla if they mean to block my App.

- - - Updated - - -

Mine's on Azure.

Sorry I may have missed something, if you are talking about Tesla Companion then it is blocked since looks like was a targeted block, however if you have your own service running on Azure then probably you are ok.
 
The App will keep functional but only with the basic functionality, if you look on your app all features provided by the clod service stopped working.

Live tiles, email alerts, notifications, scheduling and any update related to the Tesla address book are not longer functional since at this moment the cloud service is down.
I was referring to the sequence of REST calls -- which ones, what ordering and what frequency -- not the app behavior that runs on top of them.
 
I was referring to the sequence of REST calls -- which ones, what ordering and what frequency -- not the app behavior that runs on top of them.

The sequence is relative since I had a pool of 10 simultaneous threads making requests for the registered users so that the service can process at least one user every 5 to 6 minutes interval.
The calls also are targeted to what the user needed, if the user didn't have set scheduling then the REST API to get the climate information was not send for that particular user.
Probably the load was the reason since to serve all current users the service was sending many requests per second.
 
The sequence is relative since I had a pool of 10 simultaneous threads making requests for the registered users so that the service can process at least one user every 5 to 6 minutes interval.
The calls also are targeted to what the user needed, if the user didn't have set scheduling then the REST API to get the climate information was not send for that particular user.
Probably the load was the reason since to serve all current users the service was sending many requests per second.
Ah. Yes, in a conversation with a Tesla representative recently I passed along the suggestion that their load throttling (presumably IP based) should also include user ID in the load analysis. Otherwise, any app/service/router/etc. that happens to process multiple users will pretty likely trigger the load-based blocking.
 
Ah. Yes, in a conversation with a Tesla representative recently I passed along the suggestion that their load throttling (presumably IP based) should also include user ID in the load analysis. Otherwise, any app/service/router/etc. that happens to process multiple users will pretty likely trigger the load-based blocking.

I agree, but the thing is (from my experience) Tesla doesn't want people building these services. From who I have spoken to, Tesla wants no third parties to use the REST API. Have you heard differently?
 
I agree, but the thing is (from my experience) Tesla doesn't want people building these services. From who I have spoken to, Tesla wants no third parties to use the REST API. Have you heard differently?
During that conversation, the SDK was mentioned. I didn't use the term vaporware, but I made it clear that I think using the SDK as an excuse for keeping REST working for people and improving it is the wrong direction. I think I said something like "if you just do a little bit with REST, a lot of us don't mind if the SDK takes a bit longer to come out". I also passed along some other suggestions for improvements to the REST API.

There was no discussion of third parties using the REST API in that conversation. The focus was more about how people (like me) running loggers or other tools in Azure or in apartment complexes, etc. will likely end up funneling through a common IP address and the user ID should be part of the blocking criteria.

- - - Updated - - -

I really believe that Tesla needs to figure this out and come up with an SDK and a set of usage policies. Enabling others to add value to the Tesla ecosystem should be a win.
I think they plan to do that but they aren't first and foremost an application or SDK company so it's lower on the priority list.
 
Tesla Companion cloud service was unblocked, a small modification on the service has to be done before go live again, all cloud services will be back operational about 2am PST.

Tesla Companion project for Windows 8 tablets and desktops is resumed and there will be exciting news coming soon.

Thanks to all users for the support given,
Castor
 
It is related to the load and frequency put on the server for the rest APIs, basically make sure an account is not checked with a frequency less than 5 minutes independently how long take to process all the accounts, this have a big impact on services with many accounts, if all the accounts takes 1 minute to process then sleep for another 4 minutes before process them again.

However on a client app this won’t be a problem since a client app usually wait at least 30 seconds or more and this should not be an issue.

I don’t know the exact metrics used to determine if you are above the allowed quota or not, but the message is clear to not overload the server with unnecessary REST APIs calls.

By unnecessary means for example a thousand accounts could be requested as quick as possible and probably it is ok, however a single account making requests every 5 seconds could be banned.

It is not black and white but apply good criteria when you really need the data.