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

App idea / missing feature - Fire and forget climate control start...

This site may earn commission on affiliate links.
I'd like to be able to open an app, hit a button to turn on climate control, and then put my phone away confident in the knowledge that the app will wait around for contact with the car and do the right thing... If the app cannot contact the car within a reasonable period of time (e.g. before background processing times out, etc.) then it should notify me of that situation with a push or local notification... As it stands now we have to wait for an indeterminate period of time for the car to be contacted before the climate control screen is activated. I see why they do this in the Tesla app - because it has toggle buttons, etc and wants to know the car's current state. But given the nature of the communications with the car I think it would be much better to have a button that signals your intent rather than a toggle button, even if less elegant in appearance.

I am considering writing a free app that does only this: one button - owner wants climate on (let him/her know if that fails for some reason). Let me know if anyone is interested.


Pat
 
I have found that after the initial connection to the car, my a/c will turn on right away when hitting the Climate On button in the app, but it will take some time before the app is updated. I figure the initial connection is getting Tesla's servers and the car communicating, and when I press the button, Tesla's servers starts it right way. I've tested this in my garage. While your app will continue to help, perhaps until then, this tidbit can save you a few seconds.
 
I have found that after the initial connection to the car, my a/c will turn on right away when hitting the Climate On button in the app, but it will take some time before the app is updated. I figure the initial connection is getting Tesla's servers and the car communicating, and when I press the button, Tesla's servers starts it right way. I've tested this in my garage. While your app will continue to help, perhaps until then, this tidbit can save you a few seconds.

This should be possible and easily made available in the Tesla app itself. With iOS 7+ you could finally schedule background tasks and in a way keep an app alive after you leave it. Timers, music playing, scheduled HTML sends, etc. Tesla could also do this on the back end by ensuring they capture your pending request and pass it on to car with next contact through a background server. Either way, I'd expect that now or soon.

For example, with Nest, even if I change the temp on our thermostat, I can wait for it to reflect on the app and change to blue/red and kick on, or I can just pop out of app and it still happens within 5-10 seconds or so after leaving the app.

-T
 
With iOS 7+ you could finally schedule background tasks and in a way keep an app alive after you leave it. Timers, music playing, scheduled HTML sends, etc.

-T

How? I'm the app developer for Remote S. Remote S already does what the OP is asking for - minus the local notification on an unsuccessful command send, which I will add in the next update. But I want to know how to schedule a HTML send in the future (say 30 minutes after the app closes). From all the research I've done, even in iOS 8.3, you cannot keep an app alive in the background for more than 3 minutes, unless it has music playing, updates locations, or is a VoIP service. And even with scheduled local notifications, it cannot do any functions unless the users taps okay.
 
How? I'm the app developer for Remote S. Remote S already does what the OP is asking for - minus the local notification on an unsuccessful command send, which I will add in the next update. But I want to know how to schedule a HTML send in the future (say 30 minutes after the app closes). From all the research I've done, even in iOS 8.3, you cannot keep an app alive in the background for more than 3 minutes, unless it has music playing, updates locations, or is a VoIP service. And even with scheduled local notifications, it cannot do any functions unless the users taps okay.

I'm glad to hear that you will consider adding this feature in your app as it will save me from having to create one to do it :) I think you have a couple of options - using the background completion API should provide a few minutes and I think there are further options if you are waiting on a URL / file download completion. Or as the previous poster mentioned the ideal the thing would be to have a simple server accept the request and push a notification on success or failure. You may find that having a server component provides other advantages for your app in terms of scheduling or notifications.
 
How? I'm the app developer for Remote S. Remote S already does what the OP is asking for - minus the local notification on an unsuccessful command send, which I will add in the next update. But I want to know how to schedule a HTML send in the future (say 30 minutes after the app closes). From all the research I've done, even in iOS 8.3, you cannot keep an app alive in the background for more than 3 minutes, unless it has music playing, updates locations, or is a VoIP service. And even with scheduled local notifications, it cannot do any functions unless the users taps okay.

Without turning this into a code discussion, I always thought you could responsibly have your app "fetch" and look for new data. But if you do have something new, you get maybe 30 seconds of time for your app to call a completion handler, thus can execute what to do with the data, and I thought you could even initiate another network NSURL session send - thus notify the car/Tesla to do something if a piece of data has changed. E.g. using --> application:performFetchWithCompletionHandler: method.

(and yes this turn a few characters into a smiley tongue face but you can visualize what the should be).
 
Perhaps, but one of the beauties of rego's app is that, from a user privacy standpoint, nothing ever touches his servers from the app. The app communicates directly with Tesla's servers.

That is true but he wouldn't necessarily have to store any credentials on the server persistently... certainly no passwords. The service could accept the login token from the client and use it only for as long as it took to complete the request... (This mitigates the risk quite a bit).

Anyway - back to the original suggestion - I think a local notification based on background completion would be more than sufficient for this. If the car doesn't respond within a minute or two then I'd say there is a good chance it's not going to respond and a local notification would be warranted.

Even the notification is just a nice to have... the main thing is - button to trigger climate on and the app being smart enough to register for background completion so that it can at least give it a minute or two on your behalf before giving up.

thanks.
 
Without turning this into a code discussion, I always thought you could responsibly have your app "fetch" and look for new data. But if you do have something new, you get maybe 30 seconds of time for your app to call a completion handler, thus can execute what to do with the data, and I thought you could even initiate another network NSURL session send - thus notify the car/Tesla to do something if a piece of data has changed. E.g. using --> application:performFetchWithCompletionHandler: method.

(and yes this turn a few characters into a smiley tongue face but you can visualize what the should be).

Background fetch is already in my app. Problem is that the fetch happens randomly and it's determined by the iOS when to do it. I can't tell it an exact time to do it, which is what I want if I want to add background scheduling to my app. The workaround now is that I have users keeping my app open during the entire scheduled command. If there was a way to get around this, I want to know. My research all points to having to have a server that handles the scheduling, and the app can't do it alone. I thought you knew something other people didn't know.

That is true but he wouldn't necessarily have to store any credentials on the server persistently... certainly no passwords. The service could accept the login token from the client and use it only for as long as it took to complete the request... (This mitigates the risk quite a bit).

Anyway - back to the original suggestion - I think a local notification based on background completion would be more than sufficient for this. If the car doesn't respond within a minute or two then I'd say there is a good chance it's not going to respond and a local notification would be warranted.

Even the notification is just a nice to have... the main thing is - button to trigger climate on and the app being smart enough to register for background completion so that it can at least give it a minute or two on your behalf before giving up.

thanks.

Yea, local notification if a command didn't complete is fine. Shouldn't be too much work to add. Besides not want to store any credentials in my servers, I also don't want to run any commands through my server, because this creates liability issues for me (i.e. what if my server is doing maintenance when a schedule command was supposed to complete). I have a workaround in mind, though. I'm not completely out of ideas.
 
Rego, I just wanted to give an additional thank you to your thought process on the app. As an Engineer, I cringe when some of programers "take the easy way" and, in your case, would simply run a server to sit in the middle of the commands. Not saying you won't end up there or that isn't the best option, but I appreciate that you are investigating the best way to handle this rather than going to the fairly large step of bringing up a whole server for a simple function. I wish more programmers thought out their options like that!