So... the good news is that after many many hours of toiling over Remote S v2.0, I finally got my app to execute code even though it's set in the background and the device's screen is turned off. My push notification server is all set up and running well. It fires a signal to Remote S every 15 minutes to tell it to try to execute code (and that code will be whatever you set it to be - such as: start charging at 6 AM, for example). However, it appears that Apple throttles the amount of times that the app will execute code. And the problem is that it's quite random and there's no documentation from Apple as to what the throttle is. Developers have tried to ask and Apple says that they will not disclose that information. It is based on 1) how much batteries the app uses during this background execution 2) whether or not the device is charging 3) whether or not the device is on WIFI 4) signal strength of the cell 5) how often the app is used 6) How much bandwidth the app used during background execution.
I managed to get the app to execute code reliably in every 15 min interval in the following three situations:
1) The device is connected to WIFI (almost 100% chance)
or 2) The app is running in the foreground (100% chance that it'll run)
or 3) Signal strength of the cell tower is full (unsure of the chances but it worked for at least an hour and a half during my test)
In all cases the battery levels were close to 100%. From what I read from the other experiences of developers is that battery level affects the reliability as well. So the most reliable background scheduling would be if the device is connected to a strong WIFI signal and is plugged into the charger.
When it's on weak signal strength (3 bars or less), the app seems to only execute code in the background once every 40 minutes or even several hours. Apple says that developers should not rely on this method to get an exact time of executing code. But unfortunately, this is probably the best method to get background execution to work - short of working for Tesla and adding it directly to the car's firmware and/or servers.
This limitation set by Apple led to many frustrating moments early on in development when I didn't understand why the code would only execute sometimes and not always. And that in turn made me think that there was something wrong with my setup when there actually wasn't. So for the past several day/night, it felt like I was trying to find a needle in a haystack that doesn't have a needle - and I didn't know that the needle wasn't there. Because of this, I was close to scrapping background scheduling and giving up on it. But I remembered how much you guys wanted a background scheduling function, so I kept going. I will try to finish it. Knowing these limitations, I'm going to have to ask users to not give me an exact time of execution, but instead to give me a block of time when it's acceptable to execute the code (because I really don't have control over when Apple lets the app run its background code if the device is not connected to a strong WIFI signal).
So this is how I envision background scheduling will work:
The user must give me a timeframe of when it's acceptable to execute the code. The longer the timeframe, the higher the chances of the app actually firing the code needed. Let's take the "plug in reminder" example. So the user must set a timeframe of say 8 PM to 10 PM. Then the app will keep attempting to check if the car is plugged in that timeframe and warn the user to plug in the car if the car is not plugged in.
And if this seems unacceptable, users can just plug their phones in the charger and connect to wifi, and the background execution will happen very reliably every 15 minutes. OR, here's a better idea: Users with old or unused iPhones/iPads/iPod touches can recycle them by putting the Remote S app in that phone and then just leaving it at home plugged in and connected to wifi. Then you can run the background scheduler on that device without worrying about losing signal on your actual iPhone and risk the background scheduler not working.
This is how far I've come with Background Scheduling. I can tell you that I was very excited and had an eureka moment when everything fell in place and the code kept firing every 15 minutes. I was a bit disappointed by the limitations that Apple put forth. But I can see why (they want to protect users from Apps that drain too much batteries or use too much bandwidth). I just hope that most users will understand that these limitations when not on WIFI is out of my hands and that this is the best that I can do with the tools that are given to me. I can already picture the bad reviews/ratings now from users who do not understand this and then complain that the background scheduler didn't work at exactly when they wanted it to. But hopefully, you guys who were nice enough to read all of this will understand why.
Anyway, I need to catch some ZZZs. Haven't been able to sleep much while working day and night, weekdays and weeknights on this app.
Looks wonderful. Does the charge percentage data have decimal places? Would be nice to see a decimal place. Making it more entertaining on reaching the desired target perhaps? I can't recall but doing a full range charge would we see 99.x for a while (where it seems it rounds to 100% at ~ 99.5 and still charging).
It doesn't have decimal places from the Tesla servers, but it doesn't matter, because if you look at the ideal miles, it has decimal places (I add them as an option to display them). As I was charging at the supercharger, it was fun to watch the decimal places move up even though you don't see the whole miles move up. It gives a better sense of how fast it's charging, since the whole miles don't change until about a minute afterwards, whereas the decimal places change every few seconds.
Scheduling wise I would love to be told I forgot to plug my car in before my usual charge time.
Also, doubt its possible, but, would be great to tell the app my car is at the airport, etc so its not pinging me about the charger when its nowhere near it. Maybe that could be GPS based?
Instead of checking if it's at an airport, it is possible for me to get the GPS location of the car at the scheduled time and then check to see that it's within a certain distance from your house or whatever location you set. And then fire the notification based on that.
Looking good! For scheduling, I would like to see climate functions and charging start/stop. I'm not sure this is possible with Tesla's existing APIs, but I would like to also turn range mode on or off. Thanks again for the great work!
I can't access range mode settings. But can you be more detailed about what you want to see for the climate functions and charging start/stop? What specifically are you trying to accomplish? I want to know so that I can make sure that my app can support it.
