May 2012 - OvmsDev - Open Vehicles

Volt/Ampera CAN Logs
by R. Scott Perry 28 Jun '12

28 Jun '12

Hi everyone, I'm the RScott from gm-volt.com, and I wrote the page at evtools.info about the Volt and OBD2 data (which I haven't updated in quite some time). I've read the recent posts to the list about the Volt, and thought I would provide information here in response. First, if it would be helpful, I have written a program for Windows to record data from an OBD2 scanner. It is designed to work with scanners that use the ELM327 chip (or are compatible). It saves the timestamp, and saves the data in the format "11:48:45.829: 206 639600". It is run from a command prompt, and not very user friendly. For the SOC, the "206 3 69 C3 00" capture indicates CAN ID 206, with 3 bytes of data. The SOC data only uses the first two bytes, so this would be 0x69C3, or 27075d. Dividing by 4,000 gets 6.769kWh in the battery, or about 42% of the total battery capacity, which should be 4 bars on the display. http://gm-volt.com/forum/showthread.php?5328-Volt-Diagnostic-Tool&p=91868#p… correlates the SOC number here with the bars displayed. The VIN can be constructed by taking the number "1" and converting the CAN IDs 4E9 and 514 to ASCII. So with "4E1 4255313032363839" and "514 4731524436453436", you would end up with 42 55 31 30 32 36 38 39 47 31 52 44 36 45 34 36, where 42 is ASCII for B, 55 is U, etc. The latitude/longitude conversion is almost the same as what you have for the Tesla, with two exceptions -- changing the 2048 to 1000, as noted, and the accounting for negative numbers is different. It seems that the number the Volt supplies is a 31-bit signed integer. The easiest way to handle that, I think, would be to add "latlon = latlon << 1;" before checking for <0, and then "latlon = latlon >> 1;" afterwards. Running the code you have with those two changes seems to work fine. The bad news is that I have checked all my log files (I have been logging almost all the time I have driven for about 8 months now), and the CAN ID 32A (latitude/longitude) has never shown all zeroes. If the GPS data is unobtainable, I believe the car reports the most recent reading. The GPS data comes from the OnStar system, so I am thinking it may only provide the data if the OnStar service has been activated, which could be a problem for owners outside of U.S/Canada. For charging, all I have found so far are some numbers that appear to show electricity flow to/from the battery. If they are positive, electricity is going to the battery; if negative, electricity is leaving the battery. But this will also be positive if the gas engine is on and charging the battery, as well as if the car is going downhill and the regenerative braking is being used. -Scott

5 22

Rafael - Around the world in 80 electric days
by Mark Webb-Johnson 05 Jun '12

05 Jun '12

He had his doubters, but hats off to Rafael for the progress he's made. He left spain on 11th May, drove up to Germany, then DHLed the car to New York, arriving on the 21st. Now, a week later, he's reached Colorado - about 2/3rds the way across the USA. What's the connection to OVMS? Well, he's one of our early OVMS adopters and has OVMS in his car (using a global roaming SIM), uploading status to the servers and his website. He's also using the smartphone app to get alerted to charge interruptions (and he's got a lot of charge stops along the way). The Google Maps tracking data (KML) comes directly from the OVMS status updates. He's also demonstrating and promoting OVMS every opportunity he gets (leaving a wake of impressed Tesla store staff along the way). You can follow his progress at: http://www.1e-race.com/ Unfortunately, he can't get permission to drive through Hong Kong, so I won't get to directly support him, but he's heading to the west coast of USA now, so perhaps you guys in his path could meet up and help him out. Perhaps a convoy? Mark.

1 1

Re: [Ovmsdev] Volt/Ampera CAN Logs
by Michael Jochum 31 May '12

31 May '12

Hi mark, > > Probably best to continue the discussion on the ovmsdev mailing list, as others there are interested in progress (especially dpeillow and Marcus). Yes. answer to the list. > > What you have below is a 'cyclic' log. Good for identifying unique messages (by ID) seen on the bus. Can you see if canhack has a normal logging mode to just log all messages with a time stamp? i will do my best. > > What type of PC do you use? Linux, Mac or Windows? For this first i use a PC with XP. > > From what RScott has written, the can bus you are on looks to have what we want. I understand everything stops when car is turned off. But, can you try recording while charging and see if it still stops? Yes, it stops too when it is charging. > > I think that as a starting point we should target a limited amount of information, to just try to get something working and see how feasible this is. Specifically, I suggest: > > SOC% (CAN ID #206) > GPS Latitude and Longitude (CAN ID #32A) > Vehicle Speed (CAN ID #3E9) > VIN (unknown CAN ID, but supposedly there) > > From the document at: > > http://www.EVtools.info/ChevyVoltOBD2CAN.html > > these should be: > > CAN ID Location Data Units Notes > > > > > 206 Bytes 1-2 Battery SOC .250kWh Units possibly .244kWh > 32A Bytes 1-4 GPS Latitude Milliarcseconds > 32A Bytes 5-8 GPS Longitude Milliarcseconds > 3E9 Bytes 1-2 Speed 1/100 MPH 55MPH would be 5500 (0x157c) > > Looking at your capture, you have: > > 206 3 69 C3 00 at this time the battery was charging. i think ist was between 30 and 40 %. you must know that the lowest usable Battery power is at 30% an full is at 90%. i will got the next log when the battery is full > 32A 8 00 00 00 00 00 00 00 00 > 3E9 8 00 00 00 00 00 00 00 00 > > Probably your car was stationary or in the garage without GPS signal? it was stationary in front of my house with clear view to the sky. > > RScott's sample data is: > > 11:48:49.885: 206 628600 > 11:48:54.955: 206 5FCA00 > 11:48:49.636: 3E9 0BAC01AC0B3C019E [Speed 29.88MPH] > 11:48:49.870: 3E9 0C3B01C20BED01B4 [Speed 31.31MPH] > > Can you try to capture: > > The SOC% in your car, as displayed by the car itself, and matching capture of ID #206. is coming > Drive down a stretch of road at a constant speed, while logging. Then, get the approximate latitude and longitude of your position and speed you were at, and matching capture of ID #32A and ID #3E9. i only have two hands. :-) > Put the car in the open air, so it has a good GPS signal. Then, get the exact latitude and longitude of your location, and matching capture of ID#32 > The VIN number of your car. > > Based on that, we should be able to setup OVMS to capture this and transmit it on to the OVMS server/apps. yes > > Do you want me to create the framework for this in can_voltampera.c? Maybe easier for me to create the first few messages, and then for you to adjust and fix, as I know the code so well. ok, so it looks good. > > This is looking really promising. Your 104 captured IDs seem to match RScott's 105 almost exactly, and most of what we need has already been discovered. Good. Bye michael > > Regards, Mark. > > On 29 May, 2012, at 6:03 AM, Michael Jochum wrote: > >> Hi Mark, >> >> i did the first try to get a CAN Log from my Volt. It works. I got a first small output. Didi it with CANHACK. Unfortunately the Log is not so formated that a Program can read it. A human can. Still waiting for your script. >> But, ... we have a problem! 10 seconds after the car is shut down the is no more traffic on this CAN bus. 12V are still there. >> But there are three (3) more CAN Buses in this car. Really! >> Two at the OBD2 Connector driver side and two at the OBD2 Connector Passenger side. >> I will made me some adapter to get access to this Signals. Hope they still alive after shutdown the car. >> >> Here is the small Log: (i think this is NOT a time based log. it seems that this is a log from all seen messages) >> >> >> Bye >> Michael >> >

4 7

Fwd: Homelink
by Mark Webb-Johnson 31 May '12

31 May '12

Hey, not bad for an amateur :-) Mark

1 0

Volt/Ampera CAN bus - what is known
by Mark Webb-Johnson 29 May '12

29 May '12

Best reference I could find for CAN messages on the Volt/Ampera: http://www.EVtools.info/ChevyVoltOBD2CAN.html from: http://gm-volt.com/forum/showthread.php?9386-30-OBD2-CAN-tool/ Original reference link was from dpeillow. Thanks. I've written to the guy (RScott) to see if he can help out. From what's written in this document, we can get easily SOC, speed, and gps position. And, that is a fantastic start. Michael (in Germany) has started work on this, and his Ampera logs look good. Michael: can we discuss here, on the ovmsdev mailing list, so others know what is going on? Regards, Mark. EVtools.info - Chevy Volt OBD2 CAN Data Summary The Chevy Volt produces an amazing amount of information, that can be obtained with an inexpensive (~$30) OBD2 connector. While OBD2 is typically used to troubleshoot problems by requesting data from the car, the Volt produces a constant stream of data. This includes speed, battery charge, accelerator/brake position, shifter (PRNDL), and latitude/longitude. About OBD2/CAN OBD2 is a protocol that most cars built since 1996 include. It provides a way for tools to find out why the 'Check Engine' light is on, as well as a way of requesting data for troubleshooting. In some cars, like the Volt, it acts like a local area network, where parts of the car communicate with each other. CAN is simply one of many formats that can be used for transferring data. OBD2 usage in the Volt The Volt has 2 connectors (the standard one on the drivers' side, and an extra auxillary one on the passengers' side), with a total of 5 buses: OBD2 Location Pins OBD2 Protocol Data Protocol Speed CAN ID length Use Primary Data Link Connector 1 SAE J2411 (SWCAN) Low Speed GMLAN 33.3kbps ??? Body Electrical Services Primary Data Link Connector 6, 14 Standard CAN (ISO 15765-4, J2284-3) High Speed GMLAN 500kbps 11 bits Primary Powertrain Bus Primary Data Link Connector 12, 13 ??? High Speed GMLAN 500kbps ??? Chassis Expansion Bus Auxillary Data Connector 3, 11 ??? High Speed GMLAN 500kbps ??? High Volt Energy Management Auxillary Data Connector 12, 13 ??? High Speed GMLAN 500kbps ??? High Volt Powertrain Expansion Bus The Primary Powertrain Bus is easily accessible via inexpensive tools. It has been said that all data is gatewayed to the primary DLC, and that the right-hand side was is really only useful for service programming of specific modules. What Tools Can I Use? There are many different OBD2 tools that you can use, depending on what you are looking to do. Just about any should be able to read trouble codes (if the 'check engine' light comes on). If you are looking to get data from the car, there are several known options: DashDaq - The DashDaq is one of the best ways to display Volt data in real-time, where it is visible while driving. The drawback is that it is pricy, with an MSRP of $790 with the Volt license. It can record data onto memory card, but it is unclear if it has a 'Monitor All' mode that can record all data from the Volt, rather than just what is requested. ElmScan 5 - A cable that connects a laptop to the OBD2 port. It includes software, or custom software can be written for it. To use the 'Monitor All' mode, software needs to send a special command to the ELM327 chipset. MSRP is $39.95. Generic ELM327 Cables - The ELM327 chip is commonly used for cables like the ElmScan 5. Most OBD2 software should be able to work with any cable using the ELM327 chip, except that the 'Monitor All' mode requires the ability to switch to 500kbps. As a warning, there are known counterfeits out there, that do not use the real ELM chips. ScanGauge - This has an LCD display (2 lines of 10 characters each) that can display information. Very useful to see data in real-time, but it does not look like it can record data (or take advantage of 'Monitor All'). Prices start at $99.95. MDI, GM-TIS, GDS - MDI (Multiple Diagnostic Interface), GDS (GM's Global Diagnostic System software), GM-TIS. These are various names/components for the official GM tools for accessing the data. It falls into the "If you have to ask, you cannot afford it" pricing category (one source quotes $1,500/year just for the service information). There are likely other products that would work, but the above are known to work with the Chevy Volt. Primary Powertrain Bus - List of CAN IDs The Primary Powertrain Bus -- the one that is easily accessible using many OBD2 tools -- uses CAN 11-bit IDs (which can, in theory, range from 0x000 to 0x7FF, or 0 to 2047). In reality, it appears that there are 105 of them: 096 097 098 0AA 0B1 0B9 0BA 0BB 0BC 0BD 0C1 0C5 0C7 0C9 0D1 0D3 0F1 120 12A 130 135 137 139 140 148 160 17D 182 185 186 1A1 1A3 1C3 1C4 1C5 1C6 1DF 1E1 1E5 1E9 1EB 1ED 1EF 1F1 1F3 1F4 1F5 1FB 200 202 204 206 214 222 224 226 228 230 236 238 287 2C3 2C7 2F1 2F9 32A 348 34A 3C1 3C9 3CB 3D1 3DC 3DD 3E3 3E9 3ED 3F1 3F9 3FB 3FC 451 4C1 4C5 4C7 4C9 4CB 4D1 4D7 4D9 4E1 4E9 4F1 500 514 52A 530 589 770 772 773 778 77D 77F 787 Primary Powertrain Bus - Known Data CAN ID Location Data Units Notes 0C9 Byte 5 Accelerator 0 (0%) to 254 (100%) 0F1 Byte 2 Brake 0 (0%) to Unknown (254?) Typical pressure on brake pedal generates about 30. 135 Byte 1 Drive Position 0=Park, 1=Neutral, 2=Drive/L, 3=Reverse 1A1 Byte 8 Accelerator 0 (0%) to 254 (100%) 1C3 Byte 8 Accelerator 0 (0%) to 254 (100%) 1EF Bytes 3-4 Gas Engine RPM RPM 1F5 Byte 4 Shift Position PRNDL 1=Park, 2=Reverse, N=Neutral, D=Drive, L=Low 206 Bytes 1-2 Battery SOC .250kWh Units possibly .244kWh 32A Bytes 1-4 GPS Latitude Milliarcseconds 32A Bytes 5-8 GPS Longitude Milliarcseconds 3E9 Bytes 1-2 Speed 1/100 MPH 55MPH would be 5500 (0x157c) Data Analysis: Chevy Volt 0 to 60 MPH in 8.53 seconds One of the numbers that people look at for performance cars is the "0 to 60MPH" number (or the closely related "0 to 100KPH" number). I was able to accelerate from 0 to 60MPH (although not in perfect conditions, as I started at a slight angle), taking 8.53 seconds. That was in Sports mode and L. The 0 to 30MPH time was 3.45s (which perhaps was a bit high due to the slight angle I started at). The calculation assumes several things, such as the data I have actually being 1/100MPH units (but it could be offset a bit from reality, as I believe the Volt speedometer reads a couple percent above the true speed). I started the time from the last 0.00MPH reading (which, interestingly, occurs after the accelerator reaches 100%), and end when I hit 60.19MPH (the previous reading was 59.07). It was .468s from the last 0% reading on the accelerator until the car showed >0.0MPH, which would make the 0-60 time 9.0 seconds, if you calculated that way. This was done by an amateur, on the open road, giving safety priority, and wasn't under ideal conditions (specifically, starting at a slight angle, and not perfectly flat). However, it proves that the 8.5s figure that is sometimes quoted seems quite accurate. And when Edmunds tested it at 9.2s, and Consumer Reports at 9.4s, it is likely that they were not using the Sports mode. See below for the analysis of the cost of a jackrabbit start. For the curious, here is most/all of the data that I used (from a file with 188,606 lines in it, as this was part of a longer trip): 11:48:45.829: 206 639600 11:48:45.954: 1A1 00004100000000 11:48:46.110: 1A1 00004100000008 [Accelerator at ~3%] 11:48:46.313: 1A1 000041000000FE [Accelerator at 100%] 11:48:46.422: 3E9 000000FF004E00FB 11:48:46.516: 3E9 00A30100004000FB 11:48:49.636: 3E9 0BAC01AC0B3C019E [Speed 29.88MPH] 11:48:49.870: 3E9 0C3B01C20BED01B4 [Speed 31.31MPH] 11:48:49.885: 206 628600 11:48:54.955: 206 5FCA00 11:48:54.955: 3E9 1783051017350509 [Speed 60.19MPH] The information on the right side are my notes. The CAN ID 206 is the battery SOC, the last 2 numbers of CAN ID 1A1 are the accelerator position, and the first 4 numbers in the CAN ID 3E9 are the speed in 1/100 MPH. Data Analysis: Cost of a Jackrabbit Start Since this is the Volt, I should address energy efficiency of the 0 to 60MPH test, which is the ultimate in jackrabbit starts. For 0-30MPH, it used 0.068kWh of electricity, and for 0-60MPH it used .243kWh of electricity. So it takes 2.5x as much energy to get from 30-60MPH as it does from 0-30MPH. Again, there could be unknown factors here -- it could be, for example, that there is a lag between the time the energy is removed and it is recorded (e.g. if the car reports a number now that is 100ms old). As a comparison, on a similar drive at that location, 0 to 51.5MPH was achieved (at slower acceleration, with the accelerator down an average of less than 20%, versus 100% for the 0 to 60 number) using .254kWh, driving about 1/2 mile. The 0 to 52.5MPH time during the 0-60MPH test was done with just .182kWh, but only going about 200 feet. Adding in the EPA's 37kWh/100 miles, that would be an extra 0.185kWh added to the jackrabbit start, or 0.367kWh to go 1/2 mile versus .254, or a waste of about .1kWh. For those wondering why I had to add those extra .185kWh, it's because with the jackrabbit start you hit the top speed after traveling less distance. So to properly compare the slow start with the fast start, you need to add in the energy that would be used to travel that extra distance. (C) Copyright 2011 EVtools.info

1 0

Car firmware v1.2.7
by Mark Webb-Johnson 29 May '12

29 May '12

Inching towards the v1.3.0 release, I've just committed to github v1.2.7 of the car firmware for OVMS. Changelog since v1.2.2 is: 2012-05-27 1.2.7 Preliminary firmware 1.2.7 Bug fix for off-by-one-can-byte bug in roadster id from VIN Add homelink and charge timer support, plus misc fixes Only send non-empty params to PARAMS? sms command Remove need to RESET after can write change Only NETINIT (not SOFTRESET) after a parameter change Re-label parameters internally to match new user-friendly names Re-work of sms command handlers to be table driven - saving 6% of flash Use the 6% of flash we saved to implement a bunch of SMS commands REGISTER? Report on registered phone REGISTER <modulepass> Register caller phone PASS? Report on module password PASS <modulepass> Set new module password GPS?/GPS [<modulepass>] Report GPS location STAT?/STAT [<modulepass>] Report status PARAMS? [<modulepass>] Report on parameters PARAMS <param2> <param3> .. <paramN> Set parameters MODULE? [<modulepass>] Report on module parameters MODULE <vehicleid> <units> <notifies> Set module parameters GPRS? [<modulepass>] Report on GPRS parameters and status GPRS <gprsapn> <gprsuser> <gprspass> Set GPRS parameters SERVER? [<modulepass>] Report on server parameters SERVER <serverip> <serverpass> <paranoid> Set server parameters DIAG?/DIAG [<modulepass>] Technical diagnostics FEATURES? [<modulepass>] Report on features configured FEATURE <feature> <value> Set specified feature value HOMELINK <button> Activate homelink 0, 1 or 2 LOCK <pin> Lock car (with specified pin) UNLOCK <pin> Unlock car (with specified pin) VALET <pin> Activate valet mode (with specified pin) UNVALET <pin> Deactivate valet mode (with specified pin) CHARGEMODE <mode> <current> Set charge mode (sta, sto, ran, per) and current CHARGESTART [<modulepass>] Start charge immediately CHARGESTOP [<modulepass>] Stop charge immediately VERSION [<modulepass>] Report module firmware version RESET [<modulepass>] Reset module 2012-05-11 1.2.5 Preliminary firmware 1.2.5 LED re-work Support multiple vehicle configurations - TeslaRoadster and VoltAmpera NET driver tidy-ups Auto-support Tesla Roadster v1.5 cars Issue #38 - Prevent user from locking car if car is ON Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode I've managed to do this with very little impact to firmware size. Major user-visible extensions in this firmware include: A huge number of new SMS commands. Support for simplified setup steps (working on with Bennett). New status and error LED arrangement. New diagnostic SMS commands. Various minor bug-fixes and improvements. Homelink support (firmware both SMS and app protocol support - app support will follow). Charge timer support (firmware and app protocol support - app and sms support will follow). This is a major re-work of the SMS sub-system. We now have 27 commands and similar functionality to the GPRS smartphone apps. In particular, charge start/stop and mode setting is now available. I've also added in the homelink commands (courtesy of Fuzzylogic's CAN decoding skills). I've tested this on the bench, and it seems to work. I've also put it in my car 10 minutes ago, and got a network connection. That is pretty much the extent of my testing, so consider this pre-beta and definitely NOT for end-users. I haven't completely tested the setup of a module from scratch with these new REGISTER, PASS, MODULE, SERVER, GPRS commands - I hope Bennett, or someone else, will help with that. I haven't tested homelink support. I hope someone will try that (using SMS "HOMELINK 0" command) and let me know if it works. This is now pretty feature complete for the v1.3.0 firmware. I need to do the CHARGETIMER SMS commands, and want to re-work the social group messages to allow streaming of group location messages (if enabled). So, please test this as you can, and let me know any problems you find. Again, please don't put this on end-user cars yet. There has been a lot go into this and I need a week or so of inevitable bug fixing before it is ready for wider testing. There hasn't been much changes to the net subsystem since 1.2.5, and that seem stable, so I think it is fine to put in developer's cars. Regards, Mark.

3 5

Car remote unlock issue
by Oliver Weidmann 29 May '12

29 May '12

Hi everyone When unlocking my Roadster (2.5, EU-Model) via the OVMS-Android-App, the car acknowledges the unlock-command and unlocks the car (everything seems to work like a charm so far). But after the car is unlocked I cannot open one of the doors without triggering the alarm. As soon as I open the driver or passenger door the alarm goes off. Looks like the OVMS sends the unlock command to the Roadster, but the Roadster does not disable the car alarm system after the unlock. Is that a well knows behavior or can anyone confirm this issue? Thanks Oliver

3 3

OVMS iOS App v1.2.8
by Mark Webb-Johnson 28 May '12

28 May '12

Just approved for release v1.2.8 of the iOS App for OVMS. Enhancements include: v1.2.8 UI improvements (20120520) - Retina vehicle images - Current weather situation indicator - Location vehicle animations - Location lock-to-my-car feature - Location Groups support (preliminary) - UI revamp - App version shown in vehicle info display - Move Control button to car detail screen - Move Info button to car selection screen - Move GSM signal bars to car selection screen - Show car direction on location map - Support display and control of a timer-delayed charge - Use pump status for temp stale - Charge port animations - Stale indicators for ambient, pem, motor, battery and tpms - Various minor bug-fixes and stability enhancements - Cache weather icon - Auto-reconnect 10 seconds after server disconnect - Tidy up parameter naming - Support MMI/USSD codes from iOS App - "Imperial" Temperature display in iOS App - Minor layout revisions - Bring iPad version up to same level as iPhone - Remove Model S images - Change default image of DEMO car to a Tesla Roadster - Change default ovms server to tmc.openvehicles.com This is quite a large update, with a lot of work (and thanks to) Bennett and Felix, as well as testing from a bunch of testflightapp folks. I'd like to point out a few important things: As part of the tidy-up, we've removed the Model S images from the App - so you may have to change the car image for any DEMO cars you have. Social Group support is included - you can now set a group in the car, and see the location of all cars in that group on the map. Streaming mode for location, with direction and movement animation is beautiful. Try car RALLY password RALLY for a demo. We now support MMI/USSD codes. These are like "##107#" and can be used to check cellular balance. If you car is set to "Miles", the temperatures will now appear in Fahrenheit. It should appear in the App stores over the next few hours. Regards, Mark. P.S. This brings the iOS App up to the level of functionality in the Android App. We now hope to work to unify these two apps a bit more, as well as fix the display scaling issues seen by some users of modern high-resolution Android phones.

1 0

Firmware Updates for Non Developers
by Tom Saxton 23 May '12

23 May '12

I've written up instructions for updating the OVMS firmware[/URL] for non-developers. http://www.idleloop.com/tesla/ovms/ I also started a thread on TMC: http://tinyurl.com/cwg265d Developers who want to work on the code have to go through a complex procedure to download the source code and install the tools needed to build and update the firmware. It's a lot of work if you're not going to be partying on the code. Fortunately, there's a much simpler procedure if you just want to update your box to the latest firmware. Once you've been through it once, it's very quick and easy. The hardest part is removing the box from the car and undoing the four screws to get at the circuit board. You'll have to invest about $40 in the gizmo that transfers the bits, but it can be shared if there are other OVMS owners nearby. Tom

1 0

Re: [Ovmsdev] Car lost GPRS connection notification
by Bennett Leeds 21 May '12

21 May '12

On Sat, May 19, 2012 at 8:57 PM, <ovmsdev-request(a)lists.teslaclub.hk> wrote: > > Message: 3 > Date: Sun, 20 May 2012 00:19:35 +0800 > From: Mark Webb-Johnson <mark(a)webb-johnson.net> > Subject: Re: [Ovmsdev] Car lost GPRS connection notification > To: OVMS Developers <ovmsdev(a)lists.teslaclub.hk> > Message-ID: <DBFD9B76-BD5E-4E5C-823E-0B473D9EBCE8(a)webb-johnson.net> > Content-Type: text/plain; charset=iso-8859-1 > > Bennett, > > The only benefit for this is for the user to be informed when his car is > offline. > > Not my requirement, but I guess if the user is charging somewhere critical > (e.g. on a trip, in a hotel) and wants to be informed if the charging is > interrupted, he also wants to be informed if the car can't tell him the > charge has been interrupted (because it is offline with no cellular > coverage). > > Regards, Mark. Does cell coverage vary while the car is stationary in one place? I would have thought that having parked the car, plugged in it, and started charging that the owner would check the charge status right then and there on the App. If he couldn't reach the server, or if the car couldn't reach the server, then he'd know that right away and the message an hour later would be either superfluous or too late. On a related note, I do think the App could do a better job of saying where connection problems lie. This would help during installation as well, when users don't really know if the car isn't talking to the server or if the App isn't talking to the server. Once you know how things work you can figure it out, but the newbies installing for the first time don't know. I'm thinking of the App saying for each car when it heard from it last (or ever), as well as the App saying when it last heard from the server (if ever). And, while I'm at it, an SMS message asking the car when it heard from the server last would be useful for debugging configuration issues as well. - Bennett >

2 1