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

Remote S: Tesla app for Apple Watch, iPhone, iPad, and iPod Touch

This site may earn commission on affiliate links.
Status
Not open for further replies.
Congrats on the app. A little feedback -

The UI is pretty but I find it a little confusing and it makes me nervous because it's not immediately clear what is a control and what is a display. I am kind of afraid I'm going to accidentally unlock the car or open the roof when I didn't intend to. I realize that your app is more in line with the iOS 7 style than the original Tesla app but I think it's particularly important in this case that things that act like buttons or controls be visually distinguishable. Grouping all of the controls into one panel at the bottom instead of two separate ones might make this a little clearer... but they are awfully small targets with no borders and some important side effects.

Just some hopefully constructive feedback. Again, good work.

This is being addressed in the version 2.0 UI overhaul. In version 2.0, the commands would be in a menu that you'd activate by tapping the top-left corner button. Buttons will have better feedback, so you know that you touched it. Version 1.x's UI for the iOS devices was a quick job to get the Apple Watch app out as quick as possible so that people didn't want to wait. The other reason why it was a quick job was that I honestly was not expecting so many non-Watch iOS users, since an iOS Tesla app already exists.

Version 2.0 is supposed to be where I have more time to fully polish the UI of the iOS app using the feedback given on this thread. What you suggested is more or less inline what with everyone else suggested and what I'm going to end up doing.

BTW, many of us know that you are about to undergo some major medical stuff, and fully expect you to be taking a break from your work & this app. When you do, please just let us all know, so that we can all lay off and not bug you until you give us the 'all clear'.

Many, many thanks again for both a great app but also your very active support.

The surgery will take place at the end of June. Version 1.1 will come out any day now (I predict that it'll come out tomorrow or the day after). Then I hope to get version 2.0 out by mid-June. And then you guys got one week to tell me what needs to be fixed in version 2.0 (hopefully not much, since most bugs will be fixed in version 2.0), and I'll submit version 2.1 a few days before my surgery.

That's very considerate of you to remember that I have surgery in a few weeks. I know that I haven't given much details about my surgery, because it's my own personal battle and I'm not looking for anyone to feel sorry for me. But I guess I should give details about my schedule, so you guys aren't wondering why I haven't updated the app:

After the surgery at the end of June, I will be pretty much in and out of a hospital and have physical therapy for four-five months. I booked a hotel room down the block by the hospital and will be staying there from June til October. I'll be on pain killers and prescription narcotics for a while, but I should still be able to work. However, as much as I loved working on this app, the priority is to focus on my recovery in those critical first few months after the operation. If I mess up the recovery, I'd be condemning myself to a lifetime of pain and/or disability. I'll still be online here, though, to answer questions and what not and maybe even shoot out a version 2.2 if there are any critical bugs found. Former patients of this surgery have told me that it helps to talk to people during my recovery, because besides the extreme pain during physical therapy, there'll be a lot of mental anguish with being condemned to a hotel room by yourself for months.

- - - Updated - - -

Can the fan speed be controled via the API? I've always found it strange that even when it's 124 degrees in the car the HVAC wont turn the fan speed up to the max....

It's not in the API unfortunately. But can you manipulate it by changing the temperature setting? It's not hot enough where I am to test this. Also, what kind of AC settings do you have? Is it in range mode? Is it in auto mode? Are both temperature settings low?
 
It's not in the API unfortunately. But can you manipulate it by changing the temperature setting? It's not hot enough where I am to test this. Also, what kind of AC settings do you have? Is it in range mode? Is it in auto mode? Are both temperature settings low?

The temp is set to 70 and the internal temperature is 124 when I head out to my car after work. Even when I turn on the HVAC it uses whatever the last fan speed setting was when I got out of the car (7 in this case). This happens even when the fan is set to AUTO.
 
The temp is set to 70 and the internal temperature is 124 when I head out to my car after work. Even when I turn on the HVAC it uses whatever the last fan speed setting was when I got out of the car (7 in this case). This happens even when the fan is set to AUTO.

I went ahead and tested it. You can manipulate the fan speed by changing the temperature setting. It's not very hot right now in NYC, so my interior is at 83 degrees. When I started the HVAC, my temp settings was set to 70 degrees, and the fan speed was at 5. When I changed the temperature setting to 63 degrees (this is the lowest, and you can do this quickly by tapping the Remote S and then tapping the 63 degrees preset), the fan speed jumped to 7. The the interior dropped to 78 degrees. I then changed the temp settings to 70 degrees (again, you can do this quickly with the temp presets), and the fan speed dropped to 3.

Try it next time your car is 124 degrees, and let me know if it works for you. My Fan is set to AUTO.
 
This may or may not qualify as a bug but...when I push the "start HVAC" button sometimes it will work and change the display to "stop HVAC" as it's supposed to, but sometimes it will require a second push to make that happen, and sometimes it will briefly change to "stop HVAC" and the revert back to "start HVAC" and require a second push.
 
This may or may not qualify as a bug but...when I push the "start HVAC" button sometimes it will work and change the display to "stop HVAC" as it's supposed to, but sometimes it will require a second push to make that happen, and sometimes it will briefly change to "stop HVAC" and the revert back to "start HVAC" and require a second push.

Are you talking about the Watch app or the iOS app?

If you're talking about the iOS app:
When that happens, you might not need a second push. It might have just reverted back to "start HVAC", because the HVAC didn't start up yet when the car status update happened. So the app got a readout by the car that the HVAC isn't on. Anyway, this issue should be fixed in version 1.1, which has a strong performance upgrade over version 1.0. When version 2.0 comes out, it will come with error messages in the rare case that a command failed. Someone mentioned that the HVAC can fail to turn on if the charge is less than 15%.
 
This may or may not qualify as a bug but...when I push the "start HVAC" button sometimes it will work and change the display to "stop HVAC" as it's supposed to, but sometimes it will require a second push to make that happen, and sometimes it will briefly change to "stop HVAC" and the revert back to "start HVAC" and require a second push.

When that happens, you might not need a second push. It might have just reverted back to "start HVAC", because the HVAC didn't start up yet when the car status update happened. So the app got a readout by the car that the HVAC isn't on. Anyway, this issue should be fixed in version 1.1, which has a strong performance upgrade over version 1.0. When version 2.0 comes out, it will come with error messages in the rare case that a command failed. Someone mentioned that the HVAC can fail to turn on if the charge is less than 15%.

FYI, even the official Tesla app sometimes requires you to tap the "TURN ON" button in the Climate page twice to successfully turn the climate controls on.

I haven't figured out an exact pattern as to why this happens yet, but when it does happen, the first tap causes the app to display the interior temperature if it wasn't already being displayed.

It's almost as though the app wants you to first get a read of the interior temp before you decide and confirm that you do want to turn the climate controls on.

Anyway, just thought I'd mention this in case the API is behaving this way for all clients. I've also experienced this in VisibleTesla, by the way, when attempting to turn on HVAC manually.
 
FYI, even the official Tesla app sometimes requires you to tap the "TURN ON" button in the Climate page twice to successfully turn the climate controls on.

I haven't figured out an exact pattern as to why this happens yet, but when it does happen, the first tap causes the app to display the interior temperature if it wasn't already being displayed.

It's almost as though the app wants you to first get a read of the interior temp before you decide and confirm that you do want to turn the climate controls on.

Anyway, just thought I'd mention this in case the API is behaving this way for all clients. I've also experienced this in VisibleTesla, by the way, when attempting to turn on HVAC manually.

Yes, I've experienced this before as well. It's definitely an issue with the API server and not a bug with my app. Maybe it's because the car was asleep? I could theoretically "patch" their bug by having my app send the HVAC On command twice (nothing bad happens if you turn the HVAC on while it's already on). But without this bug happening reliably, I'd never know whether I successfully patched the bug or not. I'd need some way to reliably duplicate the bug. If anyone can figure it out, let me know. Otherwise, I'm going to just try sending the HVAC On command a second time if it finds that the HVAC didn't turn on the first time around. And then hope that that fixes things.
 
Yes, I've experienced this before as well. It's definitely an issue with the API server and not a bug with my app. Maybe it's because the car was asleep? I could theoretically "patch" their bug by having my app send the HVAC On command twice (nothing bad happens if you turn the HVAC on while it's already on). But without this bug happening reliably, I'd never know whether I successfully patched the bug or not. I'd need some way to reliably duplicate the bug. If anyone can figure it out, let me know. Otherwise, I'm going to just try sending the HVAC On command a second time if it finds that the HVAC didn't turn on the first time around. And then hope that that fixes things.

If I can make a suggestion, I think a better user experience (UX) would be to mimic what the official app does. That is, do NOT update the app's state until the car has confirmed a change, and do NOT allow the user to make a change until the previously sent command is either confirmed to have gone through (or confirmed not to have gone through).

Let me be specific: when the TURN ON command is sent for climate control in the official app, that button changes to a spinning circle that takes a few seconds to revert to either TURN OFF (if the climate control ON command was successful, which also changes the car graphic to indicate HVAC is on) or to say TURN ON again (if the climate control ON command was NOT successful).

This makes it very clear to the user what the result of their action was. It's a great UX to indicate to the user that his/her action was taken into account, then give feedback as to what the app is doing with that action. And only when the car confirmed the command went through, update the app's state. This way, the app and the car are always in agreement (the app properly reflects the car's state), which defines good UX.

Another example, if I may suggest, is the lock/unlock status of the car lock. If the car is locked, I would indicate this with a closed lock icon inside the car, and if it's unlocked, an opened lock icon (I personally don't like the opened passenger door indication).
If the car is locked, hitting the unlock command should give feedback that the action is being taken into account then only show the open lock icon (and making the lock button available) when the unlock command was confirmed to have gone through. And vice-versa for the unlock command.
If you play around with the official app, which also updates the LOCK and UNLOCK buttons with spinning circles, you'll see what I mean about good UX.

Please let me know what you think of these suggestions. And thanks again for your hard work on this!
 
Last edited:
Some improved error handling would also be nice. I tried to turn HVAC on but the car refused because the tailgate was open. I did not receive an error message. So I switched to the tesla app and tried again, and it did provide an error message.
 
If I can make a suggestion, I think a better user experience (UX) would be to mimic what the official app does. That is, do NOT update the app's state until the car has confirmed a change, and do NOT allow the user to make a change until the previously sent command is either confirmed to have gone through (or confirmed not to have gone through).

Let me be specific: when the TURN ON command is sent for climate control in the official app, that button changes to a spinning circle that takes a few seconds to revert to either TURN OFF (if the climate control ON command was successful, which also changes the car graphic to indicate HVAC is on) or to say TURN ON again (if the climate control ON command was NOT successful).

This makes it very clear to the user what the result of their action was. It's a great UX to indicate to the user that his/her action was taken into account, then give feedback as to what the app is doing with that action. And only when the car confirmed the command went through, update the app's state. This way, the app and the car are always in agreement (the app properly reflects the car's state), which defines good UX.

Another example, if I may suggest, is the lock/unlock status of the car lock. If the car is locked, I would indicate this with a closed lock icon inside the car, and if it's unlocked, an opened lock icon (I personally don't like the opened passenger door indication).
If the car is locked, hitting the unlock command should give feedback that the action is being taken into account then only show the open lock icon (and making the lock button available) when the unlock command was confirmed to have gone through. And vice-versa for the unlock command.
If you play around with the official app, which also updates the LOCK and UNLOCK buttons with spinning circles, you'll see what I mean about good UX.

Please let me know what you think of these suggestions. And thanks again for your hard work on this!

Some improved error handling would also be nice. I tried to turn HVAC on but the car refused because the tailgate was open. I did not receive an error message. So I switched to the tesla app and tried again, and it did provide an error message.

In my app, the commands will just assume that it worked, and the buttons will change to the other state, in case you want to do the opposite immediately afterwards. For example, sometimes I turn on and off the HVAC to get the interior temp to show up. If I were to wait until the car tells me that the HVAC is on, we'd have to wait a whole 5+ seconds for me to be able to turn the HVAC off again. Whereas now, I can press the HVAC On button, and it immediately turns to the HVAC off button. The thing is, the HVAC turns on almost immediately, whereas getting the car state is not as immediately. So the ability to blindly turn off the HVAC without waiting for a car status update is a feature I like about my app over the official app. I actually dislike the whole car spinning thing that blocks you from making additional commands or seeing stats.

But, what if the command fails? In version 1.0 (and improved in version 1.1), the car status is queried and will display the correct car status when it finishes getting the update. In version 1.1, where the queries are improved to every 5 seconds (as opposed to every 15 seconds), it makes the whole process seem seamless. My plan for version 2.0 is to introduce error messages that will display to the user in the case where a command fails, and allows you to resend the command after you corrected the error. I just need to figure out all the different errors that could possibly happen. So far I have:

1) HVAC can't turn on if the charge is less than 15%.
2) HVAC can't turn on if the tailgate is open.

Am I missing any other error messages?
 
The data in my glance is six hours out of date, although the data in the actual app is fine. I get the little rotating star symbol on the glance that makes me think it is trying to update, but it never seems to do so. (Caveat: I've had the watch for like 20 hours, so I might be doing something crazy)
 
The data in my glance is six hours out of date, although the data in the actual app is fine. I get the little rotating star symbol on the glance that makes me think it is trying to update, but it never seems to do so. (Caveat: I've had the watch for like 20 hours, so I might be doing something crazy)

Apple Watch Glances are a bit buggy in that it doesn't always force the Glance to update (or it tries to, but gets stuck in that rotating star symbol thing you're talking about). And the bug affects other apps (including Apple's own weather app) as well:

Glances not updating | Apple Support Communities
Glances not updating | Apple Support Communities

Version 1.1's faster car status update rate helps a bit with this bug, as I noticed that my Remote S 1.1 update frequency is quite satisfactory. Can't wait for you guys to get version 1.1 to see what I'm talking about.
 
Also can there be some indication of when the app is updating, there is indication when updating in glances but not in app. Also is it possible to see if car is plugged in/charging etc?
It's not necessary after version 1.1 comes out, because it updates so frequently that you can just assume that it's updating. To keep the interface clean, I don't want to keep displaying an updating message every five seconds to the user. The user can just assume that it is working its magic in the background.

As for the second question, yes, I plan to create graphics for all scenarios of whatever the state of the car is in, including plugged in or not. Charging or not is already represented. You'll see a "charging" text where it used to say "charge".
 
Status
Not open for further replies.