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.
Couldn't this be accomplished on a not so expensive VPS?
Perhaps. I suspect the more important point is not what physical/virtual mechanism could be used to house the service, but if there is in fact a real business model with enough owners that would incrementally pay for the design, maintenance and ongoing support of such a service to justify Allen's costs and time.

From that purely-business-minded POV, owners and enthusiasts that already have Remote S, don't count unless a new version were introduced with additional one-time or more likely ongoing fees, AND sufficient new capabilities that existing or future Remote S app owners would want to pay for the upgrade or ongoing services. IMHO, it would take a lot of new sales to justify this background server environment for just "camp mode". If there were many other additional services that could be architected and implemented on the same background server without Allen then having to spend inordinate time building and supporting something new and unique each time, there could be a pony here for him, as well as owners that could enjoy the price-they-pay being spread across many individuals. OTOH, if there end-up being only a smaller number of owners that really want one or more of the new capabilities, cost/user will be a lot higher, could price it out of the market, and Allen will loose his shorts if no one continues to buy it, then having to keep the server around for the few that bought-in for some period of time. IMHO it's easy for people to say what they want on forums like this, but when it comes time to put down their cash, especially month-after-month, price sensitivity enters the picture. Even though Tesla Owners put down $65-$150K+ for their vehicle, another couple bucks a month could become a deterrent to some -- some seem to already stress over investing $9.95 for the great Remote S app as it already is. ;) Additionally, some background functions I immediately think of as candidates in a future Remote S background server, are already free from other services like EVTripping that I have turned-on but rarely visit, and some are in other free or relatively low-cost services like what TeslaFi has and some other Tesla Owners already pay for. The problem is, is there a large enough user base willing to pay for new or unique Remote S background functions, or having them all available in one place via Remote S even if some of it could be free if you logon to another site, so a reasonable ongoing service fee could be charged? Compounding that question is, TMC enthusiasts in this forum are likely not representative of tomorrow's broader and perhaps less tech-savy Tesla/Remote S potential buyers that may just want to drive their Tesla, not explore all the underpinnings. In the end, only Allen can decide.

My suggestion to Allen is to give thought to this background server thing in terms of if it could be used for enough functions to possibly justify the investment. Then, consider how many of those things are already free in other services or effectively paid for via ad-serving, patreon, or in other ways -- and which ones are then differentiators for Remote S, vs a "me too" sorta function. Perhaps as I suggested upthread about having a default "simple" interface to Remote S, where a "full-function, compact" interface more like we have today could be turned on via Settings -- Remote S offers a collection of additional services via an in-app purchase that become enabled for a fixed period of time (more/monthly, and less/month for 12 month pay-up-front) to fund all the background server stuff. If those services grow to the point most users are buying the service, some or all could become standard... It's still a gamble if the volume of people willing to pay for the new services can offset the investment and ongoing support costs -- no matter what the mechanism is to house his background services code.​
 
  • Love
Reactions: AllenWong
If there were many other additional services that could be architected and implemented on the same background server

One thing I'd like is some scheduled charging which will start charging with off peak, or sooner if charging will not be completed in time, and will finish charging at a given time and/or when at least a minimum charge has been achieved. I would also like charging to stop when minimum charge has been achieved, and resume some time before required time (to not exceed max charge) so that the battery is warm in winter, full regen available, etc.

(Doing Minimum Charge as early as possible, but sticking to Off Peak, would mean i had enough charge if there was a power cut later int he night)

Dunno if that would a) be popular enough and b) worthwhile enough to be worth building, and having the backend server stuff to support it. For me, it would fit nicely with the existing functionality of the APP.

Example;

I want the car charged to 90% tomorrow at 6AM. Right now its charged to 79%, so its only going to take an hour or so, but the Tesla scheduled charging will start it at midnight (that's when Off Peak starts here), so it will be done long before I set off in the morning.

I would also like, tonight, to be able to schedule the Climate to warm the car ready for 6AM tomorrow - so I don't have to remember to do it the moment I wake up!

elatively low-cost services like TeslaFi

TeslaFi is US$ 50 p.a. - probably a fair bit more than most people naturally expect to pay for "Just an APP". I don't think i have any/many? apps that are more than US$10 on my phone; not that I wouldn't pay, just that there is so much in that price bracket it makes anything else look expensive. If I could write a US$5 APP that 1,000,000 people would pay for I'd be laughing, but a Tesla APP is probably only going to be downloaded by hundreds, maybe a few thousand at a pinch, and its a fair amount of time-cost to build and support. But I dunno how you persuade people that they should pony-up more because the marketplace is small, but I certainly wouldn't want to write a decent Tesla APP with only a market-size of $5,000

"Elon" the early-adopters, maybe? Signature-edition gets a pay-back of XX% of sales in subsequent years ... :rolleyes:
 
One thing I'd like is some scheduled charging which will start charging with off peak, or sooner if charging will not be completed in time, and will finish charging at a given time and/or when at least a minimum charge has been achieved. I would also like charging to stop when minimum charge has been achieved, and resume some time before required time (to not exceed max charge) so that the battery is warm in winter, full regen available, etc.

(Doing Minimum Charge as early as possible, but sticking to Off Peak, would mean i had enough charge if there was a power cut later int he night)

Dunno if that would a) be popular enough and b) worthwhile enough to be worth building, and having the backend server stuff to support it. For me, it would fit nicely with the existing functionality of the APP.

Example;

I want the car charged to 90% tomorrow at 6AM. Right now its charged to 79%, so its only going to take an hour or so, but the Tesla scheduled charging will start it at midnight (that's when Off Peak starts here), so it will be done long before I set off in the morning.

I would also like, tonight, to be able to schedule the Climate to warm the car ready for 6AM tomorrow - so I don't have to remember to do it the moment I wake up!



TeslaFi is US$ 50 p.a. - probably a fair bit more than most people naturally expect to pay for "Just an APP". I don't think i have any/many? apps that are more than US$10 on my phone; not that I wouldn't pay, just that there is so much in that price bracket it makes anything else look expensive. If I could write a US$5 APP that 1,000,000 people would pay for I'd be laughing, but a Tesla APP is probably only going to be downloaded by hundreds, maybe a few thousand at a pinch, and its a fair amount of time-cost to build and support. But I dunno how you persuade people that they should pony-up more because the marketplace is small, but I certainly wouldn't want to write a decent Tesla APP with only a market-size of $5,000

"Elon" the early-adopters, maybe? Signature-edition gets a pay-back of XX% of sales in subsequent years ... :rolleyes:
Yes agree. It is the scheduling stuff that is what I'm interested in not camping mode.
 
  • Like
Reactions: WannabeOwner
One thing I'd like is some scheduled charging which will start charging with off peak, or sooner if charging will not be completed in time, and will finish charging at a given time and/or when at least a minimum charge has been achieved. I would also like charging to stop when minimum charge has been achieved, and resume some time before required time (to not exceed max charge) so that the battery is warm in winter, full regen available, etc.

(Doing Minimum Charge as early as possible, but sticking to Off Peak, would mean i had enough charge if there was a power cut later int he night)

Dunno if that would a) be popular enough and b) worthwhile enough to be worth building, and having the backend server stuff to support it. For me, it would fit nicely with the existing functionality of the APP.

Example;

I want the car charged to 90% tomorrow at 6AM. Right now its charged to 79%, so its only going to take an hour or so, but the Tesla scheduled charging will start it at midnight (that's when Off Peak starts here), so it will be done long before I set off in the morning.

I would also like, tonight, to be able to schedule the Climate to warm the car ready for 6AM tomorrow - so I don't have to remember to do it the moment I wake up!



TeslaFi is US$ 50 p.a. - probably a fair bit more than most people naturally expect to pay for "Just an APP". I don't think i have any/many? apps that are more than US$10 on my phone; not that I wouldn't pay, just that there is so much in that price bracket it makes anything else look expensive. If I could write a US$5 APP that 1,000,000 people would pay for I'd be laughing, but a Tesla APP is probably only going to be downloaded by hundreds, maybe a few thousand at a pinch, and its a fair amount of time-cost to build and support. But I dunno how you persuade people that they should pony-up more because the marketplace is small, but I certainly wouldn't want to write a decent Tesla APP with only a market-size of $5,000

"Elon" the early-adopters, maybe? Signature-edition gets a pay-back of XX% of sales in subsequent years ... :rolleyes:
Agree on the charging requirement, although IMHO, Tesla really needs to be the one to implement this because of the variability, but of course that has been an expressed requirement since MS hit the market. ;) I think for an app to try to do something similar will be problematic and at least have to have a number of caveats especially when one wants to set the "complete the charge BY such-and-such time". At least with my MS, trip charging above about 92-93% is problematic estimating when it will complete. What I assume is pack rebalancing can make the same charge to 100% vary more than 25 minutes in examples I've seen. In more recent code drops including 2.52.22 that I have now, trip charging actually goes to close to 100%, stops displaying % complete, and keeps going for several more minutes.

We're on the same page with cost of existing and future apps. What may have been lost in my dissertation is that if someone has already made a choice to pay for another service (like TeslaFi) or uses a free one with providing similar capabilities that another app like Remote S may also offer for a fee, it will be harder to get the individual to effectively pay for it again unless there is enough benefit to the user with perhaps different data presentation, having all their data in one place, different security, or some other unique thing.
 
... a real business model with enough owners that would incrementally pay for the design, maintenance and ongoing support of such a service to justify Allen's costs and time.

Such a server would be a juicy target for hackers, the prize being (limited) control of a fleet of Teslas. That would be a constant headache with a huge potential downside of massive negative publicity. Any idea what insurance to cover that sort of thing might cost?
 
Such a server would be a juicy target for hackers, the prize being (limited) control of a fleet of Teslas. That would be a constant headache with a huge potential downside of massive negative publicity. Any idea what insurance to cover that sort of thing might cost?
No idea on insurance and the cost. Others have figured-out the security thing though (TeslaFi, EVTripping, others), so Allen would not be the first creating a server and dealing with credentials in a way that could meet at least some customer's expectations.
 
I want the car charged to 90% tomorrow at 6AM. Right now its charged to 79%, so its only going to take an hour or so, but the Tesla scheduled charging will start it at midnight (that's when Off Peak starts here), so it will be done long before I set off in the morning.

I would also like, tonight, to be able to schedule the Climate to warm the car ready for 6AM tomorrow - so I don't have to remember to do it the moment I wake up!

Yes agree. It is the scheduling stuff that is what I'm interested in not camping mode.

What we really need, which should not negatively impact Allen's business, is for someone to pick up the Visible Tesla ball and run with it. I posted in that thread a few weeks ago that I had an email discussion with Joe P., the VT developer, and he is more than happy to answer questions for someone (or a group of someones) willing to overhaul VT. He just doesn't have the time to do it himself.
 
  • Like
Reactions: WannabeOwner
Perhaps. I suspect the more important point is not what physical/virtual mechanism could be used to house the service, but if there is in fact a real business model with enough owners that would incrementally pay for the design, maintenance and ongoing support of such a service to justify Allen's costs and time.

From that purely-business-minded POV, owners and enthusiasts that already have Remote S, don't count unless a new version were introduced with additional one-time or more likely ongoing fees, AND sufficient new capabilities that existing or future Remote S app owners would want to pay for the upgrade or ongoing services. IMHO, it would take a lot of new sales to justify this background server environment for just "camp mode". If there were many other additional services that could be architected and implemented on the same background server without Allen then having to spend inordinate time building and supporting something new and unique each time, there could be a pony here for him, as well as owners that could enjoy the price-they-pay being spread across many individuals. OTOH, if there end-up being only a smaller number of owners that really want one or more of the new capabilities, cost/user will be a lot higher, could price it out of the market, and Allen will loose his shorts if no one continues to buy it, then having to keep the server around for the few that bought-in for some period of time. IMHO it's easy for people to say what they want on forums like this, but when it comes time to put down their cash, especially month-after-month, price sensitivity enters the picture. Even though Tesla Owners put down $65-$150K+ for their vehicle, another couple bucks a month could become a deterrent to some -- some seem to already stress over investing $9.95 for the great Remote S app as it already is. ;) Additionally, some background functions I immediately think of as candidates in a future Remote S background server, are already free from other services like EVTripping that I have turned-on but rarely visit, and some are in other free or relatively low-cost services like what TeslaFi has and some other Tesla Owners already pay for. The problem is, is there a large enough user base willing to pay for new or unique Remote S background functions, or having them all available in one place via Remote S even if some of it could be free if you logon to another site, so a reasonable ongoing service fee could be charged? Compounding that question is, TMC enthusiasts in this forum are likely not representative of tomorrow's broader and perhaps less tech-savy Tesla/Remote S potential buyers that may just want to drive their Tesla, not explore all the underpinnings. In the end, only Allen can decide.

My suggestion to Allen is to give thought to this background server thing in terms of if it could be used for enough functions to possibly justify the investment. Then, consider how many of those things are already free in other services or effectively paid for via ad-serving, patreon, or in other ways -- and which ones are then differentiators for Remote S, vs a "me too" sorta function. Perhaps as I suggested upthread about having a default "simple" interface to Remote S, where a "full-function, compact" interface more like we have today could be turned on via Settings -- Remote S offers a collection of additional services via an in-app purchase that become enabled for a fixed period of time (more/monthly, and less/month for 12 month pay-up-front) to fund all the background server stuff. If those services grow to the point most users are buying the service, some or all could become standard... It's still a gamble if the volume of people willing to pay for the new services can offset the investment and ongoing support costs -- no matter what the mechanism is to house his background services code.​

The mechanism is absolutely important. I pay $10/mo for a VPS with no maintenance or other costs. Conversely, I paid closer to $2k for a Server/NAS that I have to operate and maintain. This server would be sending commands that require very little bandwidth and very little storage to do. The true investment is Allen's time in writing and configuring.

Most people who use Remote S are "power users" who want more than the basic app provides. I would absolutely use this service to configure a custom upper end on temperature to ensure any electronics stored in my car (to include the ones built into the car) don't overheat or to leave my dogs in the vehicle without constantly checking the temperature. This isn't something I'd use on a "camping" trip but would run all the time. Maybe renaming the feature would help sell it if a background feature is implemented.

From a business standpoint, simply making it an in-app purchase or a very small subscription fee would likely justify the effort. However, the question that you posed remains: are there enough commands that could ride this service to make it worth implementation? I don't have a deep enough understanding of the API to answer that.
 
I'm wondering about the Apple Watch complication. I see it listed under "Complicatons" in "My Watch", but it doesn't show up on the menu when I try to add it to a watch face. Is it actually operational right now?
It shows "Remote S" on Watch faces that support it ... at least for me (try one of the longer complication fields,,not the super short ones). But, all the complication does is take you to the app on your watch right now. See posts upthread for more detail as this has been discussed here, but enhancements may come perhaps in a future release. Personally, as it is, I do not use the Remote S complication as I have other more valuable things for the limited real estate on the watch face. I do keep Remote S as one of the 10 in my Apple Watch Dock so it's always just a couple swipes away, and use it from there more often than from my iPhone or iPod.
 
It shows "Remote S" on Watch faces that support it ... at least for me (try one of the longer complication fields,,not the super short ones). But, all the complication does is take you to the app on your watch right now. See posts upthread for more detail as this has been discussed here, but enhancements may come perhaps in a future release. Personally, as it is, I do not use the Remote S complication as I have other more valuable things for the limited real estate on the watch face. I do keep Remote S as one of the 10 in my Apple Watch Dock so it's always just a couple swipes away, and use it from there more often than from my iPhone or iPod.

Thanks. I had read the other posts. I've looked through all the watch faces and complications and am still not seeing it, so maybe there is something else I have to do.
 
Thanks. I had read the other posts. I've looked through all the watch faces and complications and am still not seeing it, so maybe there is something else I have to do.
OK, let me see if I can try to help... I'm not uninstalling and reinstalling Remote S on my iPhone, so will need to try and remember a few steps, but here goes (FOR EVERYONE ELSE, PLEASE SKIP THIS POST, YOU'RE GONNA HATE THE DETAIL):

- Just so we're on the same page, I'm running iOS 10.2.1 on my iPhone 7, watchOS 3.1.3 on my original Apple Watch, and the latest version of Remote S on both devices
- I assume you have Remote S installed and working with your iPhone natively

On your iPhone (parts of this could be done on your watch, but let's keep this relatively simple), go to the Watch App on the phone:
- Scroll the list of apps available for your Watch. You should have Remote S "Installed". If not, touch that app name and flip that switch to "show App on Apple Watch". It can take a few minutes to sync across to your watch and complete. Wait until it does.
- Go back to the My Watch app, towards the top under the various faces, touch Complications
- Remote S should be showing in the top list of apps enabled as a complication. If not, you should see it listed below the section "do not include", and from there you can move it up using the edit function. IIRC, that change if you make it, works quickly.​

Now, here's a couple of possible gotchas...
1. IDK if it's the way watchOS apps are coded, or a bug with watchOS/Remote S, but some complications only seem to work in what I'll call "long" vs "short" fields. "short" many times will also be available in "long" fields, but not vice-versa if you get my drift. The last time I played with it extensively, Remote S works only in the "long" fields (but so do some other apps, so I don't believe it's a Remote S issue per se, perhaps just a design decision when coding their app.)

2. Again, IDK if it's the way watchOS apps are coded or a bug with watchOS/Remote S, but some complications will show both in the iPhone My Watch face editing function, but other complications (like Remote S on some faces) only appear in the pick list if you try to add them via the physical watch interface AND you are trying to add it to a "long" field. I suspect this is what may be biting you if you're trying to do it all on your iPhone, and if so:​

Now, stop using your iPhone to edit the face and go to your Watch.

- Slide Right-to-Left to see either the Mickey Mouse or Utility face (I'm using those for examples here as I've tested the process)
- When the one you want is showing full-screen, hard push the screen until the face minimizes and you see "customize"
- Select "Customize"
- Slide Right-to-Left or Left-to-Right until you see all the complication fields for that face highlighted for modification
- Lightly tap the long complication field at the bottom of the watch face to select it
- Using the Crown, scroll through the available list of complications until you find Remote S. Once you have it, just let the customization screen time-out or press the Crown twice to exit and put everything into operation. You should see "Remote S" on your operational watch face at the bottom of the screen, and when you tap it, it will pull up the Remote S app on your watch -- from there, it's normal business using Remote S with watchOS.​

Good luck. Hope that helps. I tried the process a couple of times while I was writing this using the two watch faces I mentioned, so hopefully it gets you going. I'll be interested if Gotcha #2 is perhaps what has you stymied ;) ...and then after all that if you really choose to leave the Remote S complication in place or just put the app in your dock after all! :)
 
Last edited:
OK, let me see if I can try to help... I'm not uninstalling and reinstalling Remote S on my iPhone, so will need to try and remember a few steps, but here goes (FOR EVERYONE ELSE, PLEASE SKIP THIS POST, YOU'RE GONNA HATE THE DETAIL):

Good luck. Hope that helps. I tried the process a couple of times while I was writing this using the two watch faces I mentioned, so hopefully it gets you going. I'll be interested if Gotcha #2 is perhaps what has you stymied ;) ...and then after all that if you really choose to leave the Remote S complication in place or just put the app in your dock after all! :)

It was Gotcha #2, partially. So, you were right that I had been trying to add it from my iPhone. I'm using the Modular watch face and I was able to see Remote S and add it to both the long middle complication, as well as one of the small lower ones, so the size doesn't seem to matter, at least for that face.

I have had the app in my dock for a while, but found that the extra steps needed to get there meant that I wasn't using it from my watch that often. I think the shortcut from the complication will make it more likely that I will use the app more. We'll see.

Thanks so much for the detailed help. I really appreciate it!
 
  • Like
Reactions: AllenWong and BertL
Somewhere between the latest version of Remote S, and the newest firmware 17.6.15, Remote S is only reporting charge rates in whole integers, even though teslafi/VisibleTesla is able to read the decimal point.

Of course, the new Tesla app is rounding UP no matter what, i.e. 16.2 -> 17mph or 4.1 -> 5 mph. UGH. They haven't learn anything from TMC.
 
Somewhere between the latest version of Remote S, and the newest firmware 17.6.15, Remote S is only reporting charge rates in whole integers, even though teslafi/VisibleTesla is able to read the decimal point.

Of course, the new Tesla app is rounding UP no matter what, i.e. 16.2 -> 17mph or 4.1 -> 5 mph. UGH. They haven't learn anything from TMC.
Thanks for reporting this. I looked into it and fixed it for the next app update. This also affected the instantaneous charge rate, so I fixed it for that as well.
 
  • Like
Reactions: Alain13 and BertL
My fobs aren't working so until I could get the dealer to fix them I'd been using the Tesla app to unlock/drive my MX. Yesterday for the first time I did what I always feared I might do, e.g. Get out of the car without my phone. The minute I closed the door it was too late...

Fortunately I had my watch and called Roadside who unlocked it for me.

But then I figured I'd find an app with an Apple Watch app and found RemoteS and downloaded it yesterday. I like it a lot and am in the camp of liking access to as many functions from one place as possible.

But here's something that always bothered me in the Tesla app and is the same in RemoteS. I can unlock my door but not the trunk.

I have my unlock setting on driver's door only because my recollection is otherwise some fob function didn't work properly. Maybe I'm wrong about that. But is there any way to unlock the trunk? When you have your hands full it's really inconvenient to open the door and then open the trunk from inside. I don't care If it doesn't physically open as long as it unlocks.

Thanks for the good work.
 
My fobs aren't working so until I could get the dealer to fix them I'd been using the Tesla app to unlock/drive my MX. Yesterday for the first time I did what I always feared I might do, e.g. Get out of the car without my phone. The minute I closed the door it was too late...

Fortunately I had my watch and called Roadside who unlocked it for me.

But then I figured I'd find an app with an Apple Watch app and found RemoteS and downloaded it yesterday. I like it a lot and am in the camp of liking access to as many functions from one place as possible.

But here's something that always bothered me in the Tesla app and is the same in RemoteS. I can unlock my door but not the trunk.

I have my unlock setting on driver's door only because my recollection is otherwise some fob function didn't work properly. Maybe I'm wrong about that. But is there any way to unlock the trunk? When you have your hands full it's really inconvenient to open the door and then open the trunk from inside. I don't care If it doesn't physically open as long as it unlocks.

Thanks for the good work.

I believe if the doors are unlocked the trunk is also unlocked. You just have to hit the button on the trunk lid to open it. That may require you set it so all doors unlock and not just the driver door. I have mine set that way and it works fine.
 
  • Like
Reactions: Ulmo
I believe if the doors are unlocked the trunk is also unlocked. You just have to hit the button on the trunk lid to open it. That may require you set it so all doors unlock and not just the driver door. I have mine set that way and it works fine.
Short answer: seems YES.

Long version:

I tested this in car firmware 17.7.2, and it works:
  1. I left my key fob 150 feet away, out of range. If Settings -> Vehicle -> Doors & Locks -> Door Unlock Mode is set to ALL, I press UNLOCK in Remote S app on iPhone directly (not via watch), I walk to rear hatch, press open button on hatch, and it opens (I have automatic hatch, so it opens on its own).
  2. I left my key fob 150 feet away, out of range. If Settings -> Vehicle -> Doors & Locks -> Door Unlock Mode is set to DRIVER, I press UNLOCK in Remote S app on iPhone directly (not via watch), I walk to rear hatch, press open button on hatch, and it opens (I have automatic hatch, so it opens on its own).
  3. My Apple Watch Remote S (on Apple Watch 1, latest firmware, iPhone 6+, latest firmware) did not have any affect on the car; it did not work, to control anything at all (unlock, lock, HVAC, etc.). It took 10 minutes to have the watch refresh from weeks ago data, so I finally got a data snapshot of current status that never got updated again. I assume this has nothing to do with the question at hand, so I count it as irrelevant, but assume that if your Apple Watch Remote S is working at all, that you can indeed use it to unlock the car, then walk up to the rear hatch with bags in hand, reach down, and press the button to open hatch, which it will do.
  4. I lock the car in Remote S app on iPhone, visually confirming. (Important for below tests.)
The only flaw I experienced is my Apple Watch Remote S not working, which I consider a distinct problem. So, I further did this:

I fiddled with my watch, logging out of Remote S on the iPhone, logged back in, then turned off and on my Apple Watch (about 10 minutes process). It is working better. I'm going to go test again.

Ok, back again:
  1. I approached my car with Apple Watch Remote S (and key fob out of range), and hit Unlock. Even though I could not visually see car, I faintly heard it unlock. (In retrospect, I should have waited the last 4 feet until I could see it, for sake of the test.)
  2. Car appears unlocked during my final approach.
  3. I pressed rear hatch open button on hatch. It opens. I press close on hatch. It closes.
  4. The Remote S watch app says the car is locked, but the car clearly is still unlocked.
  5. I press Honk on Remote S watch, and car honks.
  6. The watch still shows car locked. I press unlock. Car stays unlocked.
  7. I press lock on watch. Car finally locks. App finally updates to show car locked after some time.
The car setting at the time was Door Unlock Mode -> ALL. I doubt due to my above tests with iPhone Remote S app that this makes a difference for Watch Remote S, but I mention it for completeness. For now, it is under Schrodinger's Cat, until someone actually opens a hatch with Remote S on Watch when set to Door Unlock Mode -> DRIVER ONLY.

While looking at Remote S on Apple Watch, it said last update was 14:07 even though it was 14:15. I pressed Honk, and heard car honk, and then the last update showed 14:15. I'll have to find a way to update Remote S on Apple Watch more forcefully.
 
Last edited:
Status
Not open for further replies.