tomsax
Member
Of course they could do it later. In fact, the 2010 Roadsters have a GSM modem built in, so those cars have all of the required hardware for two-way communication. Tesla could build a service to relay info and commands through a web service and enable those features through a web browser or smart phone.
This is a frequently requested feature and much more important than a cool convenience when you are charging on a road trip through an outlet of unknown reliability. I personally know two owners who have been rudely surprised in the morning to find their overnight charge stopped a few minutes after they stopped watching it. It's something we all think about on long trips and could be solved with an SMS message from the car any time a charge stops early.
So far Tesla has been unreceptive to requests for this feature.
This is a frequently requested feature and much more important than a cool convenience when you are charging on a road trip through an outlet of unknown reliability. I personally know two owners who have been rudely surprised in the morning to find their overnight charge stopped a few minutes after they stopped watching it. It's something we all think about on long trips and could be solved with an SMS message from the car any time a charge stops early.
So far Tesla has been unreceptive to requests for this feature.
Last edited:
kgb
Member
Just like apple has the "Where's my iPhone?" app, a "Where's my Tesla?" app would be nice too. For when I reluctantly let the wife drive it, or the valet, I was too drunk to drive home last night, or if it's not where I left it, etc...
tdelta1000
Active Member
tomsax
Member
Please explain. Technology to do which of the several tasks we've discussed in this thread? An example would be nice, too.
kgb
Member
There are car tracking devices available. I'm sure that is the technology of which tdelta refers. But that does not use the internal network connection. You'd have to install your own tracker and get a cellular network service contract for your device.
tomsax
Member
tdelta1000
Active Member
tomsax
Member
The iPhone part is easy. I'd do it myself if there was a way to talk to the car.
I already have an app on the store that lets you control a robot over WiFi. It's just a client for a bit of specialized hardware that lets FTC students control their VEX robot controller over WiFi. If we had the equivalent gizmo for our cars, using either WiFi or SMS, this problem would be solved.
I also have an iPhone app I use to track EV energy use, efficiency, etc. Maybe someday I'll get it to a nice enough state to submit it to the App Store.
That's awesome. Have you talked to anyone at Tesla to see what their thoughts are on such an app or why it already hasn't happened? Thanks.
VDS Can bus Messages
Actually, talking to the car is easy. I've analyzed many of the VDS messages on the CAN bus. The problem is providing a connection to the Internet/SMS. If you use the iPhone, then you have to leave it with the car and you'd need another phone/iphone to receive the status.
I'm currently using a $300 HP 1050 netbook with a built in EVDO/UMTS data card and a usb to canbus adapter.
I run a small VC++ app on the HP netbook that listens to the VDS CANbus and sends UDP message to my web server. The webserver updates a status page that is always available. It's one way, so I do not send commands to the car, I just monitor the status of the car. I have perl script to send email/sms, but I have not added it to my server yet. I'm working on a better/simpler way to do this, but this was my first hack at it.
So here's some info to get you started. You can access the VDS CAN bus via a connector at the back of the VDS. The red wire is CAN_H and the blue wire is CAN_L. (It's a standard TYCO connector, so you can get the male/female and build a Y-cable.)
Status messages to the VDS are sent on CAN ID # 0x100. The first byte (B1) is a sub_message index. The bitrate is 1Mbps. A simplification of the messages you need and their interpretation is as follows:
Bytes are numbered B1 to B8 not B0-B7
bits are numbered bit0 to bit7
Byte pairs are in little endian order (e.g B4*256+B3)
Charger V1.5
Charger settings
Charger interface
Doors
Range
messages from the VDS are sent on CAN ID # 0x102.
Set Charge mode
Start/Stop charge
HVAC sits on the battery (ESS) can bus. So I don't think it will be possible to control it without a separate connection to the ESS can bus.
-Scott
Disclaimer: My CAN bus interpretation could be wrong. I don't work for Tesla nor have any friends that do. I'm just passionate about Tesla's products and understanding how they work. The data is the result of my own analysis of my 2008 roadster. CAN bus messages on the 2010 are slightly different (e.g V2.0 charge mode is on B6 bits 7-4 not B5 and the UTC start time offset is in minutes).
Actually, talking to the car is easy. I've analyzed many of the VDS messages on the CAN bus. The problem is providing a connection to the Internet/SMS. If you use the iPhone, then you have to leave it with the car and you'd need another phone/iphone to receive the status.
I'm currently using a $300 HP 1050 netbook with a built in EVDO/UMTS data card and a usb to canbus adapter.
I run a small VC++ app on the HP netbook that listens to the VDS CANbus and sends UDP message to my web server. The webserver updates a status page that is always available. It's one way, so I do not send commands to the car, I just monitor the status of the car. I have perl script to send email/sms, but I have not added it to my server yet. I'm working on a better/simpler way to do this, but this was my first hack at it.
So here's some info to get you started. You can access the VDS CAN bus via a connector at the back of the VDS. The red wire is CAN_H and the blue wire is CAN_L. (It's a standard TYCO connector, so you can get the male/female and build a Y-cable.)
Status messages to the VDS are sent on CAN ID # 0x100. The first byte (B1) is a sub_message index. The bitrate is 1Mbps. A simplification of the messages you need and their interpretation is as follows:
Bytes are numbered B1 to B8 not B0-B7
bits are numbered bit0 to bit7
Byte pairs are in little endian order (e.g B4*256+B3)
Charger V1.5
- B1=0x95
- B2=State (1=charging, 2=top off, 4=done, 13=preparing to charge, 21-25=stopped charging)
- B3=Sub State (2=scheduled start, 3=by request, 7=connect power cable, 9=xxMinutes-yyKWHrs,)
- B5=Mode (0=standard, 1=storage,3=range,4=performance)
- B8=Charging KWhrs (see sub state 9)
Charger settings
- B1=0x88
- B7=Charge limit
- B2=Charging current
- B3 & B4 Charge duration in minutes (see charger V1.5 sub state 9)
Charger interface
- B1=0x89
- B3&B4= Vline
- B6=Iavailable(from pilot PWM)
Doors
- B1=0x96
- bit2 of B2 = Charge port (open=1/closed=0)
- bit3 of B2 = Pilot present (true=1/false=0)
- bit4 of B2 = Charging (true=1/false=0)
Range
- B1=0x80
- B2= Adjusted state of charge
- B3&B4= Ideal range
- B7&B8= Estimated range
messages from the VDS are sent on CAN ID # 0x102.
Set Charge mode
- B1=0x5
- B2=0x19
- B5=Mode (0=standard, 1=storage,3=range,4=performance)
Start/Stop charge
- B1=0x05
- B2=0x03
- B3=0x00
- B4=0x00
- B5=(Stop=0x00, Start=0x01)
- B6=0x00
- B7=0x00
- B8=0x00
HVAC sits on the battery (ESS) can bus. So I don't think it will be possible to control it without a separate connection to the ESS can bus.
-Scott
Disclaimer: My CAN bus interpretation could be wrong. I don't work for Tesla nor have any friends that do. I'm just passionate about Tesla's products and understanding how they work. The data is the result of my own analysis of my 2008 roadster. CAN bus messages on the 2010 are slightly different (e.g V2.0 charge mode is on B6 bits 7-4 not B5 and the UTC start time offset is in minutes).
Last edited:
SByer
'08 #383
Cool. Hardware-wise I'd be thinking an Arduino w/ a cell modem module, though I can't seem to find a ready-made kit. It sure would be fun to play around with this if I wasn't already stacked up a couple of software projects deep at home...
-Scott
-Scott
Can I request an Android based app at the same time which I suspect will be less arduous than an Apple based app?
tomsax
Member
If Tesla would create a secure web service that would allow us to communicate with our cars over the Internet, then I'll bet owners would write (or fund) apps for all the mobile platforms. It seems like Tesla shouldn't have to develop expertise on Mac, Windows, iPhone, Android, Blackberry and Windows mobile. Create a web platform and the developers will take care of the apps.
That's a good idea. I e-mailed my sales person and he said it's been brought up many times but wasn't sure where it stood with the engineers. I happen to have an iPhone and I imagine a lot of other people do too but I agree, supporting as many platforms with your method would be the best. Maybe it's a security issue (even with a secure connection) that they're worried about someone messing something up when they log in?
Why would it be less arduous? Apps on the iPhone are not hard to use at all. In fact, Nissan and GM's apps are pretty much the same on both platforms, and I suspect Tesla would be no different.
Similar threads
