OK. I've just committed v2.5.4 and pushed to github. I've also tagged it (as v2.5.4) and upload pre-built .hex files in the vehicle/firmware directory. Short story: v2.5.4 seems stable to me, and has most of the bugs that I know about fixed. I’m still having trouble tracking down a random charge-time-estimate bug that is affecting CHARGEBY ACC profiles, but other than that is seems fine to me. Big caveat: this is testing code, please don't use ACC if you _really_ need that charge to get to work / school / the beach / wherever. Don't blame me if your car doesn't start the charge as scheduled. Warning: this is a long mail. Firstly, the v2.5.x change log: 2013-10-11 2.5.4 Firmware 2.5.4 # Make MINSOC drive NET_NOTIFY_CHARGE (rather than NET_NOTIFY_STAT) # Input GPIO control for input RA2..RA5, and output RC0..RC3 # ThinkCity: Updates to Think City support # iMiev: Updates to Mitsubishi vehicle support # Think City: Added support for switching on/off external heater/auxilary via Valet Mode button # ACC: Aggressively stop charge if cooldown is done # ACC: If we are waiting for a charge, but the charge is started, then stop it # Range and SOC limits stop exactly ON the limit # Think City: car_parktime added # Fix for command handler with net_msg_cmd_msg # Tesla Roadster: fix for mins remain estimate if SOC limit but no RANGE limit # Use <=0, not ==-1, as indication range limit is not set # ACC: Move old STAT command to PARAMS?, and add a new STAT command to show true status # ACC: If charge is done, in acc location, and unplugged, transition to parked-in state # ACC: Repeat tx charge mode and limit commands, during cooldown and acc charge, if necessary # Tesla Roadster: Disable cooldown on boot # ACC: Race condition for charge finishes before cooldown flag is cleared # ACC: Setting params now returns a summary # ACC: Reset acc state, if enable/disable or setting parameters # ACC: Integer/Byte overflow workarounds # ACC: Workaround race condition where charge may take a few seconds to actually start (when commanded) # Tesla Roadster: Provide defaults for range, soc and cac in charge estimates # Support car_chargeestimate # ACC: rework to use new car_chargeestimate 2013-09-18 2.5.3 Firmware 2.5.3 ## Updates to thinkcity ## Remove DIAG and add ACC to V1_Production build config ## Remove InternalGPS from V2_TR_Production build config, as not required ## Cooldown: safety check (only recycle if charging), and revise cooldown current to 13A ## Support definition of location in SMS commands ## Tesla Roadster: HVAC#1 should be 0x8F not 0x87 ## Logging: Don't reserve a log slot if the respective logging option is disabled ## Improve cooldown status reporting on SMS STAT ## Tidy-up of minSOC ## Move chargelimit charge stop to common vehicle.c function (not acc) ## Tesla Roadster: Updates to Tom's charge-time-predictor, with thanks ## Log cooldown charges as mode=5, and fix excessive-logging-bug related to cooldown cycles ## Logging: Send log messages one-by-one, to avoid buffer overflows ## ACC: Number homelinks from 1..3 ## Tesla Roadster: support for chargelimits ## Make SMS "RESET" reset the module completely ## Complete rework and expansion of checkpoint numbers ## Stop charge after cooldown, if no subsequent charge requested ## Report CAC as part of charge log record ## Typos in acc for net_state_enter ## Show debug checkpoint, for DIAG SMS with debugcrash ## Support vehicle_fn_minutestocharge ## Add a timezone parameter (-)HH:MM ## ACC: Support timed charges ## Move car_cooldown_wascharging to global, and make use of it in ACC ## Introduce some delays to allow car to wake up 2013-08-27 2.5.2 Firmware 2.5.2 ## Updates to vehicle_thinkcity.c (getting to a pretty usable vehicle module) ## Make car_tbattery signed integer, and integrate thinkcity changes ## Only report range and soc limits if >0 ## Merge thinkcity changes: Think City AC-line voltage/current in SMS STAT SMS migrated from standard handler to vehicle_thinkcity.c ## Tesla Roadster: Don't stop charge after cooldown, if previously the car was already charging ## Log cooldown charges that become normal charges as two separate charges ## Tidy up diag, by removing temp test code T1 T2 T3 ## Create individual configs for TeslaRoadster and RenaultTwizy (to allow all features for these cars) ## Add TRACK (type XX) vehicle that just tracks GPS ## string_to_mode utility function ## Rework vehicle inclusions. Tesla Roadster, Renault Twizy and Volt/Ampera are production. Everything else is experimental ## Add experimental vehicle Kyburz DXP ## Add HVAC message details ## Support HVAC bit in car_doors5, and cooldown cycles ## Range and charge limits handled by ACC ## Basic ACC implementation, but without timed charges 2013-08-16 2.5.1 Firmware 2.5.1 ## Framework to build logging module in experimental modes ## FIsLatLongClose utiliy function (courtesy of Tom Saxton) ## Twizy: Mi/Km conversions updated to new functions ## Switch to use macros, for clarity and maintainability ## ACC integration to build environment ## Parameter support for base64 encoded parameters ## utils support for mode display ## ACC support for net_sms ## Switch logging system to use new "h" historical data submission, with acknowledgement ## Go from 4->6 log records, based on free space ## Tesla Roadster: Notify server if charge limit is changed ## Tesla Roadster: Notify server if charge mode is changed ## v2.5.1 protocol guide ## Add core support for cooldown ## Tesla Roadster support for cooldown ## Stub implementation, with basic functionality, for ACC ## Zero logging records on init, plus other safety checks ## Only initialise logging on a normal power up ## Standardise 3 diag tests: T1, T2 and T3 ## Only send logging msgs if link is connected ## Fix logging prefix and some logging tests ## Revisions to CAR_IS_CHARGING logic ## Misc bug-fixes for logging ## Report distance in miles (rather than 10ths of miles) ## Remove dr++ and cr++ sequence numbers, as not required ## Make ACC commands case insensitive ## Fix bug acknowledging log record #0 ## Move digital speedo feature (Tesla Roadster) from experimental to fully supported, and implement opt-in feature bits ## Honour opt-in flags for logging ## Only report debug crash reason if not normal power up, and only report once As you can see, a lot has changed. The key points are: Some restructuring of the build targets: V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware V2_RT_production.hex V2 Hardware Module, Renault Twizy full firmware V2_TR_production.hex V2 Hardware Module, Tesla Roadster full firmware Support for LOGGING (charge and drive) Support for ACC (Advanced Charge Control) - Tesla Roadster only at the moment Lots of other little nice fixes and enhancements Apart from overall reliability testing (making sure it is stable in the cars), the two things I need help with are the LOGGING and ACC functions. [1] Logging The logging code is enabled by setting opt-in feature (#13) bit 1 (to log drives) and/or bit 2 (to log charges). Or, you can just set feature #13 to 255 and opt-in to everything :-) Once you've opted in, whenever you complete a charge or drive, the car will submit a summary record to be stored on the server. You can then use the prototype HTTP API, or perl client, to retrieve those records for your own purposes. Note that there is a privacy concern here, as both record types (drive and charge) store GPS locations - this is the reason why it is opt-in. The testing I need done is just to ensure that this works for you, and that the resulting logged drives/charges match what you are expecting. It would also be useful to confirm if this works on all supported cars (which it should). [2] Advanced Charge Control The Advanced Charge Control system is designed to supplement the (aka take over from) vehicle's own charge scheduling. It should support any vehicle with charge control, but at the moment that means only Tesla Roadster. It has some pretty sophisticated features. For the moment, it is setup via SMS, but in future we will allow smartphone Apps to do this. Once setup, it runs autonomously, and doesn't even require a cellular connection. ACC works from the concept of a 'charge location'. This is a geofenced location that is used for charging, and you can configure up to 4 of these (numbered #1 through #4). To define the car's current location as a 'charge location', sms "ACC HERE" to the car, and it will allocate a free slot and reply to you with it. You can use "ACC NOTHERE" to clear the current location. If you want to clear a particular ACC location, you can sms "ACC CLEAR n" (to clear one location), or "ACC CLEAR" (to clear all locations). You can show the current status off ACC with “ACC STAT”. You can show the ACC details for the current location by sms "ACC PARAMS?" (or for a particular location by "ACC PARAMS? n" - which is very useful if you have crappy cellular connectivity like I do). The ACC parameters for a particular location are configured with the "ACC PARAMS" SMS. You can list a location number (1, 2, 3 or 4) as the first parameter - or don't specify location if you just want to configure the current location the car is at. After 'ACC PARAMS", you can set the parameters you would like, from the following: COOLDOWN - perform a cooldown charge (13A range mode, with cooling cycles) when the car is plugged in at this ACC location NOCOOLDOWN - don't do a cooldown charge (default) HOMELINK n - activate homelink when the vehicle drives to within 100m of an ACC location (the idea is to open our garage door / gate automatically as you approach) NOHOMELINK - don't activate homelink (default) CHARGEPLUGIN - charge the car on plugin (but after cooldown, if enabled) CHARGEAT HH:MM - schedule charge to start at the specified time (hours:minutes, 24hour clock) CHARGEBY HH:MM - schedule charge to complete by the specified time (hours:minutes 24hour clock) NOCHARGE - don't charge (default) LIMIT n - limit charge current to n Amps - must be specified for all CHARGE* actions MODE m - set charge mode (where "m" is STA(NDARD), STO(RAGE), RAN(GE) or PER(FORMANCE)) - must be specified for all CHARGE* actions STOPRANGE r - stop charge when range "r" is reached (specified in vehicle units, set to 0 (default) to not limit). STOPSOC s - stop charge when SOC "s" is reached (specified as a percentage, set to 0 (default) to not limit). The actions to take at a particular ACC location must be enabled with "ACC ENABLE" (or "ACC ENABLE n") before they will work. You can also disable with "ACC DISABLE" (or "ACC DISABLE n"). If you are using CHARGEAT or CHARGEBY, you need to specify the timezone of the vehicle. This is parameter #23 and is specified as HH:MM offset from GmT (with an optional leading "-" if west of Greenwich). The default temperature limit for cooldown is 31Celcius, and time limit is 60 minutes. If you want to change these, you can set parameter #15 to templimit:timelimit (e.g.; "31:60"). Note that you can also cooldown manually, while charging, with the SMS command "COOLDOWN", and see the status with SMS "STAT". I've spent quite some time testing CHARGEPLUGIN, CHARGEAT, COOLDOWN, LIMIT, MODE, STOPRANGE and STOPSOC - hopefully those are ok now, but the control logic does need wider testing. The CHARGEBY option is still giving me random problems, related to the charge time estimated - I am still working on that. I've also been unable to test HOMELINK and would be very interested to see if that works. Some notes on cooldown on Tesla Roadster The cooldown algorithm is to start a range mode charge at 13Amps, and to monitor the HVAC system of the car. Once the HVAC starts, runs for some time, then stops, we call it a 'cooling cycle'. We keep a record of how many such cycles have occurred. Once we detect that the HVAC has stopped, we try to start it again. The logic at the moment is to switch to performance mode for ten seconds, then back to range mode, once every minute until the HVAC starts again. The _best_ way of starting the HVAC is to stop and start the charge, but that is painful on the contactors, so we don't do it. Switching Range->Performance->Range seems to be the second best, but I remain unconvinced that it makes much difference. In Hong Kong summer weather, I get one cooldown cycle every ten minutes or so. I can drop 6 to 8 celcius in one hour. The cooldown will stop after either the desired temperature is hit (based on the temperature of the hottest brick in the battery) or the cooldown has been ongoing for the time limit. Conclusions I'm happy that the code is reasonably stable now, but really need help testing this in a larger number of cars. If you do see a problem, please get me (by eMail to OVMS developers mailing list, or my personal address): Output of "SMS STAT" for the specified location Your vehicle id Output of base64 parameter string (from the cellphone app) - copy-and-paste Date/Time you entered the ACC location (with timezone) Date/Time you plugged in at the ACC location (with timezone) In the smartphone app, call up the Features and Parameters screens (so the server logs those, and I can check) Description of the problem you have Please also share success stories. It is good to know what works. Regards, Mark.
I've been trying this a bit. Me-ACC HERE OVMS-ACC #2 set Me-ACC PARAMS CHARGEBY 16:30 MODE RAN LIMIT 48 OVMS-ACC #0 - No ACC defined here Me-ACC ENABLE 2 OVMS-ACC enabled Me-ACC PARAMS 2 OVMS-ACC#2 (lat/long) Enabled Mode:standard(0A) Me-ACC PARAMS 2 MODE RAN LIMIT 48 CHARGEBY 16:30 OVMS-ACC#2 (lat/long) Enabled Charge by time 16:30:00 Mode:performance (48A) Me-ACC PARAMS 2 MODE RANGE (No response) Me-ACC PARAMS? OVMS-ACC#2 (lat/long) Enabled Charge by time 16:30:00 Mode: performance (48A) The iPhone app shows the car charging in range mode at 48 amps. Jack
Jack, Seems to be a bug in display of RANGE mode for ACC. I need to check what the mode number should be (as setting mode uses 0,1,3,4 but displaying mode uses 0,1,2,3 - which is why your range mode is being shown as performance). I think the mode set is the correct one, and even though it says 'performance' it will actually be a range mode charge. I'm not sure why your first 'ACC PARAMS' command did not find the location. The code looks ok and works for me. Maybe the GPS location is not locked or off by too much from the ACC location (car in a garage?). Regards, Mark. On 16 Oct, 2013, at 1:11 am, Jack West <jackduncanwest@gmail.com> wrote:
I've been trying this a bit.
Me-ACC HERE OVMS-ACC #2 set Me-ACC PARAMS CHARGEBY 16:30 MODE RAN LIMIT 48 OVMS-ACC #0 - No ACC defined here Me-ACC ENABLE 2 OVMS-ACC enabled Me-ACC PARAMS 2 OVMS-ACC#2 (lat/long) Enabled Mode:standard(0A) Me-ACC PARAMS 2 MODE RAN LIMIT 48 CHARGEBY 16:30 OVMS-ACC#2 (lat/long) Enabled Charge by time 16:30:00 Mode:performance (48A) Me-ACC PARAMS 2 MODE RANGE (No response) Me-ACC PARAMS? OVMS-ACC#2 (lat/long) Enabled Charge by time 16:30:00 Mode: performance (48A)
The iPhone app shows the car charging in range mode at 48 amps.
Jack
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
A little more background. OVMS V2 TR2.5. The car is in the city with typically great reception, but it is parked in a parking garage, on the outside edge with a view. The app did show that the car was charging in range mode so that part works. Just the SMS report was wrong. It is interesting that I got the ACC #0 (not a typo) no ACC defined here- as I thought the ACC's are 1-4. Perhaps I caused some bug to occur by trying to set the ACC PARAMS before the car was at the location and the ACC HERE was issued. I did have some unexpected responses after that. If you think that might be relevant I could send the transcript of commands I used and OVMS' response. To follow up on the CHARGEBY command, I think the charge finished about two hours early. I'm not positive I have the time set correctly and so I will look into that. All in all I'd have to say you ROCK! The charge to 50% was the perfect solution to the short commute but still want to plug in scenario. Jack On Oct 15, 2013, at 5:48 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Jack,
Seems to be a bug in display of RANGE mode for ACC. I need to check what the mode number should be (as setting mode uses 0,1,3,4 but displaying mode uses 0,1,2,3 - which is why your range mode is being shown as performance).
I think the mode set is the correct one, and even though it says 'performance' it will actually be a range mode charge.
I'm not sure why your first 'ACC PARAMS' command did not find the location. The code looks ok and works for me. Maybe the GPS location is not locked or off by too much from the ACC location (car in a garage?).
Regards, Mark.
On 16 Oct, 2013, at 1:11 am, Jack West <jackduncanwest@gmail.com> wrote:
I've been trying this a bit.
Me-ACC HERE OVMS-ACC #2 set Me-ACC PARAMS CHARGEBY 16:30 MODE RAN LIMIT 48 OVMS-ACC #0 - No ACC defined here Me-ACC ENABLE 2 OVMS-ACC enabled Me-ACC PARAMS 2 OVMS-ACC#2 (lat/long) Enabled Mode:standard(0A) Me-ACC PARAMS 2 MODE RAN LIMIT 48 CHARGEBY 16:30 OVMS-ACC#2 (lat/long) Enabled Charge by time 16:30:00 Mode:performance (48A) Me-ACC PARAMS 2 MODE RANGE (No response) Me-ACC PARAMS? OVMS-ACC#2 (lat/long) Enabled Charge by time 16:30:00 Mode: performance (48A)
The iPhone app shows the car charging in range mode at 48 amps.
Jack
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Jack,
OVMS V2 TR2.5. The car is in the city with typically great reception, but it is parked in a parking garage, on the outside edge with a view.
The ACC#0 is intended - #0 means the location could not be found. If you don't specify a location number to the params command, it tries to find the acc location at the current co-ordinates. In your case, it couldn't find one (even though you had just created one with ACC HERE). Very strange. I can only think that the car location was 'jumping around' looking for gps lock.
The app did show that the car was charging in range mode so that part works. Just the SMS report was wrong.
Yes, I found the bug and fixed already in github. Fix will make it to the 2.5.5 build.
To follow up on the CHARGEBY command, I think the charge finished about two hours early. I'm not positive I have the time set correctly and so I will look into that.
CHARGEBY is still buggy, and driving me crazy. I am sure that Tom's Charge Time Predictor function is working perfectly, but something in the way that ACC is calling it is getting the wrong results. If possible, after plugging in the car, try ACC STAT and it will tell you its prediction and the time it schedules to charge to meet that prediction (plus 30 mins safety margin). I did find one possible reason last night (seems to be that if the car goes to sleep, the pilot signal indicator goes off even if plugged in and ready to charge, and ACC treated that as an unplug). Tom is helping me try to find the other possible causes of the problem.
All in all I'd have to say you ROCK! The charge to 50% was the perfect solution to the short commute but still want to plug in scenario.
Thanks. This is going to be incredibly useful once I get the bugs worked out. The COOLDOWN is my favorite feature - when I get home, my car now cools itself down then charges to 80% before going to sleep for the night (literally - at 30C-35C ambient the car would never go to sleep before I started using cooldown). Homelink is also pretty cool - having the car automatically open your gate as you drive up, without having to press any buttons. Regards, Mark. On 16 Oct, 2013, at 12:34 pm, Jack West <jackduncanwest@gmail.com> wrote:
A little more background.
OVMS V2 TR2.5. The car is in the city with typically great reception, but it is parked in a parking garage, on the outside edge with a view.
The app did show that the car was charging in range mode so that part works. Just the SMS report was wrong.
It is interesting that I got the ACC #0 (not a typo) no ACC defined here- as I thought the ACC's are 1-4. Perhaps I caused some bug to occur by trying to set the ACC PARAMS before the car was at the location and the ACC HERE was issued. I did have some unexpected responses after that. If you think that might be relevant I could send the transcript of commands I used and OVMS' response.
To follow up on the CHARGEBY command, I think the charge finished about two hours early. I'm not positive I have the time set correctly and so I will look into that.
All in all I'd have to say you ROCK! The charge to 50% was the perfect solution to the short commute but still want to plug in scenario.
Jack
On Oct 15, 2013, at 5:48 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Jack,
Seems to be a bug in display of RANGE mode for ACC. I need to check what the mode number should be (as setting mode uses 0,1,3,4 but displaying mode uses 0,1,2,3 - which is why your range mode is being shown as performance).
I think the mode set is the correct one, and even though it says 'performance' it will actually be a range mode charge.
I'm not sure why your first 'ACC PARAMS' command did not find the location. The code looks ok and works for me. Maybe the GPS location is not locked or off by too much from the ACC location (car in a garage?).
Regards, Mark.
On 16 Oct, 2013, at 1:11 am, Jack West <jackduncanwest@gmail.com> wrote:
I've been trying this a bit.
Me-ACC HERE OVMS-ACC #2 set Me-ACC PARAMS CHARGEBY 16:30 MODE RAN LIMIT 48 OVMS-ACC #0 - No ACC defined here Me-ACC ENABLE 2 OVMS-ACC enabled Me-ACC PARAMS 2 OVMS-ACC#2 (lat/long) Enabled Mode:standard(0A) Me-ACC PARAMS 2 MODE RAN LIMIT 48 CHARGEBY 16:30 OVMS-ACC#2 (lat/long) Enabled Charge by time 16:30:00 Mode:performance (48A) Me-ACC PARAMS 2 MODE RANGE (No response) Me-ACC PARAMS? OVMS-ACC#2 (lat/long) Enabled Charge by time 16:30:00 Mode: performance (48A)
The iPhone app shows the car charging in range mode at 48 amps.
Jack
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On Oct 15, 2013, at 9:11 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
The ACC#0 is intended - #0 means the location could not be found. If you don't specify a location number to the params command, it tries to find the acc location at the current co-ordinates. In your case, it couldn't find one (even though you had just created one with ACC HERE). Very strange. I can only think that the car location was 'jumping around' looking for gps
I had previously tried to set ACC#2 PARAMS before the car was at the intended location and before issuing an ACC HERE. OVMS responded with ACC #2- no ACC defined here. But when the car did arrive at the location (my second location)and I again tried to set the PARAMS after setting ACC HERE, the PARAMS were set in ACC#3. I wonder if this somehow left ACC#2 in some weird state so that at the next location (my third location) it was corrupted. To clarify, I was in the process of setting up each of our four normal charge locations (wow! Four places to charge in Alaska. Who would have thought...). The first location programmed fine. The second got screwed up and was programmed into #3. The third location was stored in #2. Nothing like a developer to put the software through some unexpected twists and turns. Maybe this will help to sort out what might be going on but of course like you said maybe it was just gps jumping around. Best, Jack
You can "ACC CLEAR n" to clear location #n (1..4). Also, "ACC PARAMS? n" (1..4) to look at the GPS co-ordinates and whatever else is set for that location. Regards, Mark. On 16 Oct, 2013, at 1:36 pm, Jack West <jackduncanwest@gmail.com> wrote:
On Oct 15, 2013, at 9:11 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
The ACC#0 is intended - #0 means the location could not be found. If you don't specify a location number to the params command, it tries to find the acc location at the current co-ordinates. In your case, it couldn't find one (even though you had just created one with ACC HERE). Very strange. I can only think that the car location was 'jumping around' looking for gps
I had previously tried to set ACC#2 PARAMS before the car was at the intended location and before issuing an ACC HERE. OVMS responded with ACC #2- no ACC defined here. But when the car did arrive at the location (my second location)and I again tried to set the PARAMS after setting ACC HERE, the PARAMS were set in ACC#3. I wonder if this somehow left ACC#2 in some weird state so that at the next location (my third location) it was corrupted. To clarify, I was in the process of setting up each of our four normal charge locations (wow! Four places to charge in Alaska. Who would have thought...). The first location programmed fine. The second got screwed up and was programmed into #3. The third location was stored in #2. Nothing like a developer to put the software through some unexpected twists and turns.
Maybe this will help to sort out what might be going on but of course like you said maybe it was just gps jumping around.
Best,
Jack _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi Mark, I am running the v1 HW on my TR and upgraded to 2.5.4. ACC seems not work at all. When sending ACC HERE command I get confirmation from app it is received but no feedback by SMS. Groet / Regards Wiro Zijlmans
Op 11 okt. 2013 om 15:12 heeft Mark Webb-Johnson <mark@webb-johnson.net> het volgende geschreven:
OK. I've just committed v2.5.4 and pushed to github. I've also tagged it (as v2.5.4) and upload pre-built .hex files in the vehicle/firmware directory.
Short story: v2.5.4 seems stable to me, and has most of the bugs that I know about fixed. I’m still having trouble tracking down a random charge-time-estimate bug that is affecting CHARGEBY ACC profiles, but other than that is seems fine to me.
Big caveat: this is testing code, please don't use ACC if you _really_ need that charge to get to work / school / the beach / wherever. Don't blame me if your car doesn't start the charge as scheduled.
Warning: this is a long mail.
Firstly, the v2.5.x change log:
2013-10-11 2.5.4 Firmware 2.5.4 # Make MINSOC drive NET_NOTIFY_CHARGE (rather than NET_NOTIFY_STAT) # Input GPIO control for input RA2..RA5, and output RC0..RC3 # ThinkCity: Updates to Think City support # iMiev: Updates to Mitsubishi vehicle support # Think City: Added support for switching on/off external heater/auxilary via Valet Mode button # ACC: Aggressively stop charge if cooldown is done # ACC: If we are waiting for a charge, but the charge is started, then stop it # Range and SOC limits stop exactly ON the limit # Think City: car_parktime added # Fix for command handler with net_msg_cmd_msg # Tesla Roadster: fix for mins remain estimate if SOC limit but no RANGE limit # Use <=0, not ==-1, as indication range limit is not set # ACC: Move old STAT command to PARAMS?, and add a new STAT command to show true status # ACC: If charge is done, in acc location, and unplugged, transition to parked-in state # ACC: Repeat tx charge mode and limit commands, during cooldown and acc charge, if necessary # Tesla Roadster: Disable cooldown on boot # ACC: Race condition for charge finishes before cooldown flag is cleared # ACC: Setting params now returns a summary # ACC: Reset acc state, if enable/disable or setting parameters # ACC: Integer/Byte overflow workarounds # ACC: Workaround race condition where charge may take a few seconds to actually start (when commanded) # Tesla Roadster: Provide defaults for range, soc and cac in charge estimates # Support car_chargeestimate # ACC: rework to use new car_chargeestimate
2013-09-18 2.5.3 Firmware 2.5.3 ## Updates to thinkcity ## Remove DIAG and add ACC to V1_Production build config ## Remove InternalGPS from V2_TR_Production build config, as not required ## Cooldown: safety check (only recycle if charging), and revise cooldown current to 13A ## Support definition of location in SMS commands ## Tesla Roadster: HVAC#1 should be 0x8F not 0x87 ## Logging: Don't reserve a log slot if the respective logging option is disabled ## Improve cooldown status reporting on SMS STAT ## Tidy-up of minSOC ## Move chargelimit charge stop to common vehicle.c function (not acc) ## Tesla Roadster: Updates to Tom's charge-time-predictor, with thanks ## Log cooldown charges as mode=5, and fix excessive-logging-bug related to cooldown cycles ## Logging: Send log messages one-by-one, to avoid buffer overflows ## ACC: Number homelinks from 1..3 ## Tesla Roadster: support for chargelimits ## Make SMS "RESET" reset the module completely ## Complete rework and expansion of checkpoint numbers ## Stop charge after cooldown, if no subsequent charge requested ## Report CAC as part of charge log record ## Typos in acc for net_state_enter ## Show debug checkpoint, for DIAG SMS with debugcrash ## Support vehicle_fn_minutestocharge ## Add a timezone parameter (-)HH:MM ## ACC: Support timed charges ## Move car_cooldown_wascharging to global, and make use of it in ACC ## Introduce some delays to allow car to wake up
2013-08-27 2.5.2 Firmware 2.5.2 ## Updates to vehicle_thinkcity.c (getting to a pretty usable vehicle module) ## Make car_tbattery signed integer, and integrate thinkcity changes ## Only report range and soc limits if >0 ## Merge thinkcity changes: Think City AC-line voltage/current in SMS STAT SMS migrated from standard handler to vehicle_thinkcity.c ## Tesla Roadster: Don't stop charge after cooldown, if previously the car was already charging ## Log cooldown charges that become normal charges as two separate charges ## Tidy up diag, by removing temp test code T1 T2 T3 ## Create individual configs for TeslaRoadster and RenaultTwizy (to allow all features for these cars) ## Add TRACK (type XX) vehicle that just tracks GPS ## string_to_mode utility function ## Rework vehicle inclusions. Tesla Roadster, Renault Twizy and Volt/Ampera are production. Everything else is experimental ## Add experimental vehicle Kyburz DXP ## Add HVAC message details ## Support HVAC bit in car_doors5, and cooldown cycles ## Range and charge limits handled by ACC ## Basic ACC implementation, but without timed charges
2013-08-16 2.5.1 Firmware 2.5.1 ## Framework to build logging module in experimental modes ## FIsLatLongClose utiliy function (courtesy of Tom Saxton) ## Twizy: Mi/Km conversions updated to new functions ## Switch to use macros, for clarity and maintainability ## ACC integration to build environment ## Parameter support for base64 encoded parameters ## utils support for mode display ## ACC support for net_sms ## Switch logging system to use new "h" historical data submission, with acknowledgement ## Go from 4->6 log records, based on free space ## Tesla Roadster: Notify server if charge limit is changed ## Tesla Roadster: Notify server if charge mode is changed ## v2.5.1 protocol guide ## Add core support for cooldown ## Tesla Roadster support for cooldown ## Stub implementation, with basic functionality, for ACC ## Zero logging records on init, plus other safety checks ## Only initialise logging on a normal power up ## Standardise 3 diag tests: T1, T2 and T3 ## Only send logging msgs if link is connected ## Fix logging prefix and some logging tests ## Revisions to CAR_IS_CHARGING logic ## Misc bug-fixes for logging ## Report distance in miles (rather than 10ths of miles) ## Remove dr++ and cr++ sequence numbers, as not required ## Make ACC commands case insensitive ## Fix bug acknowledging log record #0 ## Move digital speedo feature (Tesla Roadster) from experimental to fully supported, and implement opt-in feature bits ## Honour opt-in flags for logging ## Only report debug crash reason if not normal power up, and only report once
As you can see, a lot has changed. The key points are:
Some restructuring of the build targets: V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware V2_RT_production.hex V2 Hardware Module, Renault Twizy full firmware V2_TR_production.hex V2 Hardware Module, Tesla Roadster full firmware Support for LOGGING (charge and drive) Support for ACC (Advanced Charge Control) - Tesla Roadster only at the moment Lots of other little nice fixes and enhancements
Apart from overall reliability testing (making sure it is stable in the cars), the two things I need help with are the LOGGING and ACC functions.
[1] Logging
The logging code is enabled by setting opt-in feature (#13) bit 1 (to log drives) and/or bit 2 (to log charges). Or, you can just set feature #13 to 255 and opt-in to everything :-)
Once you've opted in, whenever you complete a charge or drive, the car will submit a summary record to be stored on the server. You can then use the prototype HTTP API, or perl client, to retrieve those records for your own purposes.
Note that there is a privacy concern here, as both record types (drive and charge) store GPS locations - this is the reason why it is opt-in.
The testing I need done is just to ensure that this works for you, and that the resulting logged drives/charges match what you are expecting. It would also be useful to confirm if this works on all supported cars (which it should).
[2] Advanced Charge Control
The Advanced Charge Control system is designed to supplement the (aka take over from) vehicle's own charge scheduling. It should support any vehicle with charge control, but at the moment that means only Tesla Roadster. It has some pretty sophisticated features. For the moment, it is setup via SMS, but in future we will allow smartphone Apps to do this. Once setup, it runs autonomously, and doesn't even require a cellular connection.
ACC works from the concept of a 'charge location'. This is a geofenced location that is used for charging, and you can configure up to 4 of these (numbered #1 through #4). To define the car's current location as a 'charge location', sms "ACC HERE" to the car, and it will allocate a free slot and reply to you with it. You can use "ACC NOTHERE" to clear the current location.
If you want to clear a particular ACC location, you can sms "ACC CLEAR n" (to clear one location), or "ACC CLEAR" (to clear all locations).
You can show the current status off ACC with “ACC STAT”.
You can show the ACC details for the current location by sms "ACC PARAMS?" (or for a particular location by "ACC PARAMS? n" - which is very useful if you have crappy cellular connectivity like I do).
The ACC parameters for a particular location are configured with the "ACC PARAMS" SMS. You can list a location number (1, 2, 3 or 4) as the first parameter - or don't specify location if you just want to configure the current location the car is at. After 'ACC PARAMS", you can set the parameters you would like, from the following:
COOLDOWN - perform a cooldown charge (13A range mode, with cooling cycles) when the car is plugged in at this ACC location NOCOOLDOWN - don't do a cooldown charge (default) HOMELINK n - activate homelink when the vehicle drives to within 100m of an ACC location (the idea is to open our garage door / gate automatically as you approach) NOHOMELINK - don't activate homelink (default) CHARGEPLUGIN - charge the car on plugin (but after cooldown, if enabled) CHARGEAT HH:MM - schedule charge to start at the specified time (hours:minutes, 24hour clock) CHARGEBY HH:MM - schedule charge to complete by the specified time (hours:minutes 24hour clock) NOCHARGE - don't charge (default) LIMIT n - limit charge current to n Amps - must be specified for all CHARGE* actions MODE m - set charge mode (where "m" is STA(NDARD), STO(RAGE), RAN(GE) or PER(FORMANCE)) - must be specified for all CHARGE* actions STOPRANGE r - stop charge when range "r" is reached (specified in vehicle units, set to 0 (default) to not limit). STOPSOC s - stop charge when SOC "s" is reached (specified as a percentage, set to 0 (default) to not limit).
The actions to take at a particular ACC location must be enabled with "ACC ENABLE" (or "ACC ENABLE n") before they will work. You can also disable with "ACC DISABLE" (or "ACC DISABLE n").
If you are using CHARGEAT or CHARGEBY, you need to specify the timezone of the vehicle. This is parameter #23 and is specified as HH:MM offset from GmT (with an optional leading "-" if west of Greenwich).
The default temperature limit for cooldown is 31Celcius, and time limit is 60 minutes. If you want to change these, you can set parameter #15 to templimit:timelimit (e.g.; "31:60").
Note that you can also cooldown manually, while charging, with the SMS command "COOLDOWN", and see the status with SMS "STAT".
I've spent quite some time testing CHARGEPLUGIN, CHARGEAT, COOLDOWN, LIMIT, MODE, STOPRANGE and STOPSOC - hopefully those are ok now, but the control logic does need wider testing. The CHARGEBY option is still giving me random problems, related to the charge time estimated - I am still working on that. I've also been unable to test HOMELINK and would be very interested to see if that works.
Some notes on cooldown on Tesla Roadster
The cooldown algorithm is to start a range mode charge at 13Amps, and to monitor the HVAC system of the car. Once the HVAC starts, runs for some time, then stops, we call it a 'cooling cycle'. We keep a record of how many such cycles have occurred.
Once we detect that the HVAC has stopped, we try to start it again. The logic at the moment is to switch to performance mode for ten seconds, then back to range mode, once every minute until the HVAC starts again. The _best_ way of starting the HVAC is to stop and start the charge, but that is painful on the contactors, so we don't do it. Switching Range->Performance->Range seems to be the second best, but I remain unconvinced that it makes much difference. In Hong Kong summer weather, I get one cooldown cycle every ten minutes or so. I can drop 6 to 8 celcius in one hour.
The cooldown will stop after either the desired temperature is hit (based on the temperature of the hottest brick in the battery) or the cooldown has been ongoing for the time limit.
Conclusions
I'm happy that the code is reasonably stable now, but really need help testing this in a larger number of cars. If you do see a problem, please get me (by eMail to OVMS developers mailing list, or my personal address):
Output of "SMS STAT" for the specified location Your vehicle id Output of base64 parameter string (from the cellphone app) - copy-and-paste Date/Time you entered the ACC location (with timezone) Date/Time you plugged in at the ACC location (with timezone) In the smartphone app, call up the Features and Parameters screens (so the server logs those, and I can check) Description of the problem you have
Please also share success stories. It is good to know what works.
Regards, Mark. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Wiro, Do you get any SMS responses? Such as a response to "STAT"... Try "ACC STAT". I don't understand about 'confirmation from the app it is received' - do you mean you see the parameter updated? Regards, Mark. On 16 Oct, 2013, at 1:41 am, Wiro Zijlmans <wirozijlmans@gmail.com> wrote:
Hi Mark, I am running the v1 HW on my TR and upgraded to 2.5.4. ACC seems not work at all. When sending ACC HERE command I get confirmation from app it is received but no feedback by SMS.
Groet / Regards Wiro Zijlmans
Op 11 okt. 2013 om 15:12 heeft Mark Webb-Johnson <mark@webb-johnson.net> het volgende geschreven:
OK. I've just committed v2.5.4 and pushed to github. I've also tagged it (as v2.5.4) and upload pre-built .hex files in the vehicle/firmware directory.
Short story: v2.5.4 seems stable to me, and has most of the bugs that I know about fixed. I’m still having trouble tracking down a random charge-time-estimate bug that is affecting CHARGEBY ACC profiles, but other than that is seems fine to me.
Big caveat: this is testing code, please don't use ACC if you _really_ need that charge to get to work / school / the beach / wherever. Don't blame me if your car doesn't start the charge as scheduled.
Warning: this is a long mail.
Firstly, the v2.5.x change log:
2013-10-11 2.5.4 Firmware 2.5.4 # Make MINSOC drive NET_NOTIFY_CHARGE (rather than NET_NOTIFY_STAT) # Input GPIO control for input RA2..RA5, and output RC0..RC3 # ThinkCity: Updates to Think City support # iMiev: Updates to Mitsubishi vehicle support # Think City: Added support for switching on/off external heater/auxilary via Valet Mode button # ACC: Aggressively stop charge if cooldown is done # ACC: If we are waiting for a charge, but the charge is started, then stop it # Range and SOC limits stop exactly ON the limit # Think City: car_parktime added # Fix for command handler with net_msg_cmd_msg # Tesla Roadster: fix for mins remain estimate if SOC limit but no RANGE limit # Use <=0, not ==-1, as indication range limit is not set # ACC: Move old STAT command to PARAMS?, and add a new STAT command to show true status # ACC: If charge is done, in acc location, and unplugged, transition to parked-in state # ACC: Repeat tx charge mode and limit commands, during cooldown and acc charge, if necessary # Tesla Roadster: Disable cooldown on boot # ACC: Race condition for charge finishes before cooldown flag is cleared # ACC: Setting params now returns a summary # ACC: Reset acc state, if enable/disable or setting parameters # ACC: Integer/Byte overflow workarounds # ACC: Workaround race condition where charge may take a few seconds to actually start (when commanded) # Tesla Roadster: Provide defaults for range, soc and cac in charge estimates # Support car_chargeestimate # ACC: rework to use new car_chargeestimate
2013-09-18 2.5.3 Firmware 2.5.3 ## Updates to thinkcity ## Remove DIAG and add ACC to V1_Production build config ## Remove InternalGPS from V2_TR_Production build config, as not required ## Cooldown: safety check (only recycle if charging), and revise cooldown current to 13A ## Support definition of location in SMS commands ## Tesla Roadster: HVAC#1 should be 0x8F not 0x87 ## Logging: Don't reserve a log slot if the respective logging option is disabled ## Improve cooldown status reporting on SMS STAT ## Tidy-up of minSOC ## Move chargelimit charge stop to common vehicle.c function (not acc) ## Tesla Roadster: Updates to Tom's charge-time-predictor, with thanks ## Log cooldown charges as mode=5, and fix excessive-logging-bug related to cooldown cycles ## Logging: Send log messages one-by-one, to avoid buffer overflows ## ACC: Number homelinks from 1..3 ## Tesla Roadster: support for chargelimits ## Make SMS "RESET" reset the module completely ## Complete rework and expansion of checkpoint numbers ## Stop charge after cooldown, if no subsequent charge requested ## Report CAC as part of charge log record ## Typos in acc for net_state_enter ## Show debug checkpoint, for DIAG SMS with debugcrash ## Support vehicle_fn_minutestocharge ## Add a timezone parameter (-)HH:MM ## ACC: Support timed charges ## Move car_cooldown_wascharging to global, and make use of it in ACC ## Introduce some delays to allow car to wake up
2013-08-27 2.5.2 Firmware 2.5.2 ## Updates to vehicle_thinkcity.c (getting to a pretty usable vehicle module) ## Make car_tbattery signed integer, and integrate thinkcity changes ## Only report range and soc limits if >0 ## Merge thinkcity changes: Think City AC-line voltage/current in SMS STAT SMS migrated from standard handler to vehicle_thinkcity.c ## Tesla Roadster: Don't stop charge after cooldown, if previously the car was already charging ## Log cooldown charges that become normal charges as two separate charges ## Tidy up diag, by removing temp test code T1 T2 T3 ## Create individual configs for TeslaRoadster and RenaultTwizy (to allow all features for these cars) ## Add TRACK (type XX) vehicle that just tracks GPS ## string_to_mode utility function ## Rework vehicle inclusions. Tesla Roadster, Renault Twizy and Volt/Ampera are production. Everything else is experimental ## Add experimental vehicle Kyburz DXP ## Add HVAC message details ## Support HVAC bit in car_doors5, and cooldown cycles ## Range and charge limits handled by ACC ## Basic ACC implementation, but without timed charges
2013-08-16 2.5.1 Firmware 2.5.1 ## Framework to build logging module in experimental modes ## FIsLatLongClose utiliy function (courtesy of Tom Saxton) ## Twizy: Mi/Km conversions updated to new functions ## Switch to use macros, for clarity and maintainability ## ACC integration to build environment ## Parameter support for base64 encoded parameters ## utils support for mode display ## ACC support for net_sms ## Switch logging system to use new "h" historical data submission, with acknowledgement ## Go from 4->6 log records, based on free space ## Tesla Roadster: Notify server if charge limit is changed ## Tesla Roadster: Notify server if charge mode is changed ## v2.5.1 protocol guide ## Add core support for cooldown ## Tesla Roadster support for cooldown ## Stub implementation, with basic functionality, for ACC ## Zero logging records on init, plus other safety checks ## Only initialise logging on a normal power up ## Standardise 3 diag tests: T1, T2 and T3 ## Only send logging msgs if link is connected ## Fix logging prefix and some logging tests ## Revisions to CAR_IS_CHARGING logic ## Misc bug-fixes for logging ## Report distance in miles (rather than 10ths of miles) ## Remove dr++ and cr++ sequence numbers, as not required ## Make ACC commands case insensitive ## Fix bug acknowledging log record #0 ## Move digital speedo feature (Tesla Roadster) from experimental to fully supported, and implement opt-in feature bits ## Honour opt-in flags for logging ## Only report debug crash reason if not normal power up, and only report once
As you can see, a lot has changed. The key points are:
Some restructuring of the build targets: V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware V2_RT_production.hex V2 Hardware Module, Renault Twizy full firmware V2_TR_production.hex V2 Hardware Module, Tesla Roadster full firmware Support for LOGGING (charge and drive) Support for ACC (Advanced Charge Control) - Tesla Roadster only at the moment Lots of other little nice fixes and enhancements
Apart from overall reliability testing (making sure it is stable in the cars), the two things I need help with are the LOGGING and ACC functions.
[1] Logging
The logging code is enabled by setting opt-in feature (#13) bit 1 (to log drives) and/or bit 2 (to log charges). Or, you can just set feature #13 to 255 and opt-in to everything :-)
Once you've opted in, whenever you complete a charge or drive, the car will submit a summary record to be stored on the server. You can then use the prototype HTTP API, or perl client, to retrieve those records for your own purposes.
Note that there is a privacy concern here, as both record types (drive and charge) store GPS locations - this is the reason why it is opt-in.
The testing I need done is just to ensure that this works for you, and that the resulting logged drives/charges match what you are expecting. It would also be useful to confirm if this works on all supported cars (which it should).
[2] Advanced Charge Control
The Advanced Charge Control system is designed to supplement the (aka take over from) vehicle's own charge scheduling. It should support any vehicle with charge control, but at the moment that means only Tesla Roadster. It has some pretty sophisticated features. For the moment, it is setup via SMS, but in future we will allow smartphone Apps to do this. Once setup, it runs autonomously, and doesn't even require a cellular connection.
ACC works from the concept of a 'charge location'. This is a geofenced location that is used for charging, and you can configure up to 4 of these (numbered #1 through #4). To define the car's current location as a 'charge location', sms "ACC HERE" to the car, and it will allocate a free slot and reply to you with it. You can use "ACC NOTHERE" to clear the current location.
If you want to clear a particular ACC location, you can sms "ACC CLEAR n" (to clear one location), or "ACC CLEAR" (to clear all locations).
You can show the current status off ACC with “ACC STAT”.
You can show the ACC details for the current location by sms "ACC PARAMS?" (or for a particular location by "ACC PARAMS? n" - which is very useful if you have crappy cellular connectivity like I do).
The ACC parameters for a particular location are configured with the "ACC PARAMS" SMS. You can list a location number (1, 2, 3 or 4) as the first parameter - or don't specify location if you just want to configure the current location the car is at. After 'ACC PARAMS", you can set the parameters you would like, from the following:
COOLDOWN - perform a cooldown charge (13A range mode, with cooling cycles) when the car is plugged in at this ACC location NOCOOLDOWN - don't do a cooldown charge (default) HOMELINK n - activate homelink when the vehicle drives to within 100m of an ACC location (the idea is to open our garage door / gate automatically as you approach) NOHOMELINK - don't activate homelink (default) CHARGEPLUGIN - charge the car on plugin (but after cooldown, if enabled) CHARGEAT HH:MM - schedule charge to start at the specified time (hours:minutes, 24hour clock) CHARGEBY HH:MM - schedule charge to complete by the specified time (hours:minutes 24hour clock) NOCHARGE - don't charge (default) LIMIT n - limit charge current to n Amps - must be specified for all CHARGE* actions MODE m - set charge mode (where "m" is STA(NDARD), STO(RAGE), RAN(GE) or PER(FORMANCE)) - must be specified for all CHARGE* actions STOPRANGE r - stop charge when range "r" is reached (specified in vehicle units, set to 0 (default) to not limit). STOPSOC s - stop charge when SOC "s" is reached (specified as a percentage, set to 0 (default) to not limit).
The actions to take at a particular ACC location must be enabled with "ACC ENABLE" (or "ACC ENABLE n") before they will work. You can also disable with "ACC DISABLE" (or "ACC DISABLE n").
If you are using CHARGEAT or CHARGEBY, you need to specify the timezone of the vehicle. This is parameter #23 and is specified as HH:MM offset from GmT (with an optional leading "-" if west of Greenwich).
The default temperature limit for cooldown is 31Celcius, and time limit is 60 minutes. If you want to change these, you can set parameter #15 to templimit:timelimit (e.g.; "31:60").
Note that you can also cooldown manually, while charging, with the SMS command "COOLDOWN", and see the status with SMS "STAT".
I've spent quite some time testing CHARGEPLUGIN, CHARGEAT, COOLDOWN, LIMIT, MODE, STOPRANGE and STOPSOC - hopefully those are ok now, but the control logic does need wider testing. The CHARGEBY option is still giving me random problems, related to the charge time estimated - I am still working on that. I've also been unable to test HOMELINK and would be very interested to see if that works.
Some notes on cooldown on Tesla Roadster
The cooldown algorithm is to start a range mode charge at 13Amps, and to monitor the HVAC system of the car. Once the HVAC starts, runs for some time, then stops, we call it a 'cooling cycle'. We keep a record of how many such cycles have occurred.
Once we detect that the HVAC has stopped, we try to start it again. The logic at the moment is to switch to performance mode for ten seconds, then back to range mode, once every minute until the HVAC starts again. The _best_ way of starting the HVAC is to stop and start the charge, but that is painful on the contactors, so we don't do it. Switching Range->Performance->Range seems to be the second best, but I remain unconvinced that it makes much difference. In Hong Kong summer weather, I get one cooldown cycle every ten minutes or so. I can drop 6 to 8 celcius in one hour.
The cooldown will stop after either the desired temperature is hit (based on the temperature of the hottest brick in the battery) or the cooldown has been ongoing for the time limit.
Conclusions
I'm happy that the code is reasonably stable now, but really need help testing this in a larger number of cars. If you do see a problem, please get me (by eMail to OVMS developers mailing list, or my personal address):
Output of "SMS STAT" for the specified location Your vehicle id Output of base64 parameter string (from the cellphone app) - copy-and-paste Date/Time you entered the ACC location (with timezone) Date/Time you plugged in at the ACC location (with timezone) In the smartphone app, call up the Features and Parameters screens (so the server logs those, and I can check) Description of the problem you have
Please also share success stories. It is good to know what works.
Regards, Mark. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, Other commands seem to work. E.g. Stat, version, see attached picture. What I mean with message from app is a notification that shows up at my phone as notification of message receipt. There is no change of parameters in the app itself. Groet / Regards Wiro Zijlmans
Op 16 okt. 2013 om 03:34 heeft Mark Webb-Johnson <mark@webb-johnson.net> het volgende geschreven:
Wiro,
Do you get any SMS responses? Such as a response to "STAT"...
Try "ACC STAT".
I don't understand about 'confirmation from the app it is received' - do you mean you see the parameter updated?
Regards, Mark.
On 16 Oct, 2013, at 1:41 am, Wiro Zijlmans <wirozijlmans@gmail.com> wrote:
Hi Mark, I am running the v1 HW on my TR and upgraded to 2.5.4. ACC seems not work at all. When sending ACC HERE command I get confirmation from app it is received but no feedback by SMS.
Groet / Regards Wiro Zijlmans
Op 11 okt. 2013 om 15:12 heeft Mark Webb-Johnson <mark@webb-johnson.net> het volgende geschreven:
OK. I've just committed v2.5.4 and pushed to github. I've also tagged it (as v2.5.4) and upload pre-built .hex files in the vehicle/firmware directory.
Short story: v2.5.4 seems stable to me, and has most of the bugs that I know about fixed. I’m still having trouble tracking down a random charge-time-estimate bug that is affecting CHARGEBY ACC profiles, but other than that is seems fine to me.
Big caveat: this is testing code, please don't use ACC if you _really_ need that charge to get to work / school / the beach / wherever. Don't blame me if your car doesn't start the charge as scheduled.
Warning: this is a long mail.
Firstly, the v2.5.x change log:
2013-10-11 2.5.4 Firmware 2.5.4 # Make MINSOC drive NET_NOTIFY_CHARGE (rather than NET_NOTIFY_STAT) # Input GPIO control for input RA2..RA5, and output RC0..RC3 # ThinkCity: Updates to Think City support # iMiev: Updates to Mitsubishi vehicle support # Think City: Added support for switching on/off external heater/auxilary via Valet Mode button # ACC: Aggressively stop charge if cooldown is done # ACC: If we are waiting for a charge, but the charge is started, then stop it # Range and SOC limits stop exactly ON the limit # Think City: car_parktime added # Fix for command handler with net_msg_cmd_msg # Tesla Roadster: fix for mins remain estimate if SOC limit but no RANGE limit # Use <=0, not ==-1, as indication range limit is not set # ACC: Move old STAT command to PARAMS?, and add a new STAT command to show true status # ACC: If charge is done, in acc location, and unplugged, transition to parked-in state # ACC: Repeat tx charge mode and limit commands, during cooldown and acc charge, if necessary # Tesla Roadster: Disable cooldown on boot # ACC: Race condition for charge finishes before cooldown flag is cleared # ACC: Setting params now returns a summary # ACC: Reset acc state, if enable/disable or setting parameters # ACC: Integer/Byte overflow workarounds # ACC: Workaround race condition where charge may take a few seconds to actually start (when commanded) # Tesla Roadster: Provide defaults for range, soc and cac in charge estimates # Support car_chargeestimate # ACC: rework to use new car_chargeestimate
2013-09-18 2.5.3 Firmware 2.5.3 ## Updates to thinkcity ## Remove DIAG and add ACC to V1_Production build config ## Remove InternalGPS from V2_TR_Production build config, as not required ## Cooldown: safety check (only recycle if charging), and revise cooldown current to 13A ## Support definition of location in SMS commands ## Tesla Roadster: HVAC#1 should be 0x8F not 0x87 ## Logging: Don't reserve a log slot if the respective logging option is disabled ## Improve cooldown status reporting on SMS STAT ## Tidy-up of minSOC ## Move chargelimit charge stop to common vehicle.c function (not acc) ## Tesla Roadster: Updates to Tom's charge-time-predictor, with thanks ## Log cooldown charges as mode=5, and fix excessive-logging-bug related to cooldown cycles ## Logging: Send log messages one-by-one, to avoid buffer overflows ## ACC: Number homelinks from 1..3 ## Tesla Roadster: support for chargelimits ## Make SMS "RESET" reset the module completely ## Complete rework and expansion of checkpoint numbers ## Stop charge after cooldown, if no subsequent charge requested ## Report CAC as part of charge log record ## Typos in acc for net_state_enter ## Show debug checkpoint, for DIAG SMS with debugcrash ## Support vehicle_fn_minutestocharge ## Add a timezone parameter (-)HH:MM ## ACC: Support timed charges ## Move car_cooldown_wascharging to global, and make use of it in ACC ## Introduce some delays to allow car to wake up
2013-08-27 2.5.2 Firmware 2.5.2 ## Updates to vehicle_thinkcity.c (getting to a pretty usable vehicle module) ## Make car_tbattery signed integer, and integrate thinkcity changes ## Only report range and soc limits if >0 ## Merge thinkcity changes: Think City AC-line voltage/current in SMS STAT SMS migrated from standard handler to vehicle_thinkcity.c ## Tesla Roadster: Don't stop charge after cooldown, if previously the car was already charging ## Log cooldown charges that become normal charges as two separate charges ## Tidy up diag, by removing temp test code T1 T2 T3 ## Create individual configs for TeslaRoadster and RenaultTwizy (to allow all features for these cars) ## Add TRACK (type XX) vehicle that just tracks GPS ## string_to_mode utility function ## Rework vehicle inclusions. Tesla Roadster, Renault Twizy and Volt/Ampera are production. Everything else is experimental ## Add experimental vehicle Kyburz DXP ## Add HVAC message details ## Support HVAC bit in car_doors5, and cooldown cycles ## Range and charge limits handled by ACC ## Basic ACC implementation, but without timed charges
2013-08-16 2.5.1 Firmware 2.5.1 ## Framework to build logging module in experimental modes ## FIsLatLongClose utiliy function (courtesy of Tom Saxton) ## Twizy: Mi/Km conversions updated to new functions ## Switch to use macros, for clarity and maintainability ## ACC integration to build environment ## Parameter support for base64 encoded parameters ## utils support for mode display ## ACC support for net_sms ## Switch logging system to use new "h" historical data submission, with acknowledgement ## Go from 4->6 log records, based on free space ## Tesla Roadster: Notify server if charge limit is changed ## Tesla Roadster: Notify server if charge mode is changed ## v2.5.1 protocol guide ## Add core support for cooldown ## Tesla Roadster support for cooldown ## Stub implementation, with basic functionality, for ACC ## Zero logging records on init, plus other safety checks ## Only initialise logging on a normal power up ## Standardise 3 diag tests: T1, T2 and T3 ## Only send logging msgs if link is connected ## Fix logging prefix and some logging tests ## Revisions to CAR_IS_CHARGING logic ## Misc bug-fixes for logging ## Report distance in miles (rather than 10ths of miles) ## Remove dr++ and cr++ sequence numbers, as not required ## Make ACC commands case insensitive ## Fix bug acknowledging log record #0 ## Move digital speedo feature (Tesla Roadster) from experimental to fully supported, and implement opt-in feature bits ## Honour opt-in flags for logging ## Only report debug crash reason if not normal power up, and only report once
As you can see, a lot has changed. The key points are:
Some restructuring of the build targets: V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware V2_RT_production.hex V2 Hardware Module, Renault Twizy full firmware V2_TR_production.hex V2 Hardware Module, Tesla Roadster full firmware Support for LOGGING (charge and drive) Support for ACC (Advanced Charge Control) - Tesla Roadster only at the moment Lots of other little nice fixes and enhancements
Apart from overall reliability testing (making sure it is stable in the cars), the two things I need help with are the LOGGING and ACC functions.
[1] Logging
The logging code is enabled by setting opt-in feature (#13) bit 1 (to log drives) and/or bit 2 (to log charges). Or, you can just set feature #13 to 255 and opt-in to everything :-)
Once you've opted in, whenever you complete a charge or drive, the car will submit a summary record to be stored on the server. You can then use the prototype HTTP API, or perl client, to retrieve those records for your own purposes.
Note that there is a privacy concern here, as both record types (drive and charge) store GPS locations - this is the reason why it is opt-in.
The testing I need done is just to ensure that this works for you, and that the resulting logged drives/charges match what you are expecting. It would also be useful to confirm if this works on all supported cars (which it should).
[2] Advanced Charge Control
The Advanced Charge Control system is designed to supplement the (aka take over from) vehicle's own charge scheduling. It should support any vehicle with charge control, but at the moment that means only Tesla Roadster. It has some pretty sophisticated features. For the moment, it is setup via SMS, but in future we will allow smartphone Apps to do this. Once setup, it runs autonomously, and doesn't even require a cellular connection.
ACC works from the concept of a 'charge location'. This is a geofenced location that is used for charging, and you can configure up to 4 of these (numbered #1 through #4). To define the car's current location as a 'charge location', sms "ACC HERE" to the car, and it will allocate a free slot and reply to you with it. You can use "ACC NOTHERE" to clear the current location.
If you want to clear a particular ACC location, you can sms "ACC CLEAR n" (to clear one location), or "ACC CLEAR" (to clear all locations).
You can show the current status off ACC with “ACC STAT”.
You can show the ACC details for the current location by sms "ACC PARAMS?" (or for a particular location by "ACC PARAMS? n" - which is very useful if you have crappy cellular connectivity like I do).
The ACC parameters for a particular location are configured with the "ACC PARAMS" SMS. You can list a location number (1, 2, 3 or 4) as the first parameter - or don't specify location if you just want to configure the current location the car is at. After 'ACC PARAMS", you can set the parameters you would like, from the following:
COOLDOWN - perform a cooldown charge (13A range mode, with cooling cycles) when the car is plugged in at this ACC location NOCOOLDOWN - don't do a cooldown charge (default) HOMELINK n - activate homelink when the vehicle drives to within 100m of an ACC location (the idea is to open our garage door / gate automatically as you approach) NOHOMELINK - don't activate homelink (default) CHARGEPLUGIN - charge the car on plugin (but after cooldown, if enabled) CHARGEAT HH:MM - schedule charge to start at the specified time (hours:minutes, 24hour clock) CHARGEBY HH:MM - schedule charge to complete by the specified time (hours:minutes 24hour clock) NOCHARGE - don't charge (default) LIMIT n - limit charge current to n Amps - must be specified for all CHARGE* actions MODE m - set charge mode (where "m" is STA(NDARD), STO(RAGE), RAN(GE) or PER(FORMANCE)) - must be specified for all CHARGE* actions STOPRANGE r - stop charge when range "r" is reached (specified in vehicle units, set to 0 (default) to not limit). STOPSOC s - stop charge when SOC "s" is reached (specified as a percentage, set to 0 (default) to not limit).
The actions to take at a particular ACC location must be enabled with "ACC ENABLE" (or "ACC ENABLE n") before they will work. You can also disable with "ACC DISABLE" (or "ACC DISABLE n").
If you are using CHARGEAT or CHARGEBY, you need to specify the timezone of the vehicle. This is parameter #23 and is specified as HH:MM offset from GmT (with an optional leading "-" if west of Greenwich).
The default temperature limit for cooldown is 31Celcius, and time limit is 60 minutes. If you want to change these, you can set parameter #15 to templimit:timelimit (e.g.; "31:60").
Note that you can also cooldown manually, while charging, with the SMS command "COOLDOWN", and see the status with SMS "STAT".
I've spent quite some time testing CHARGEPLUGIN, CHARGEAT, COOLDOWN, LIMIT, MODE, STOPRANGE and STOPSOC - hopefully those are ok now, but the control logic does need wider testing. The CHARGEBY option is still giving me random problems, related to the charge time estimated - I am still working on that. I've also been unable to test HOMELINK and would be very interested to see if that works.
Some notes on cooldown on Tesla Roadster
The cooldown algorithm is to start a range mode charge at 13Amps, and to monitor the HVAC system of the car. Once the HVAC starts, runs for some time, then stops, we call it a 'cooling cycle'. We keep a record of how many such cycles have occurred.
Once we detect that the HVAC has stopped, we try to start it again. The logic at the moment is to switch to performance mode for ten seconds, then back to range mode, once every minute until the HVAC starts again. The _best_ way of starting the HVAC is to stop and start the charge, but that is painful on the contactors, so we don't do it. Switching Range->Performance->Range seems to be the second best, but I remain unconvinced that it makes much difference. In Hong Kong summer weather, I get one cooldown cycle every ten minutes or so. I can drop 6 to 8 celcius in one hour.
The cooldown will stop after either the desired temperature is hit (based on the temperature of the hottest brick in the battery) or the cooldown has been ongoing for the time limit.
Conclusions
I'm happy that the code is reasonably stable now, but really need help testing this in a larger number of cars. If you do see a problem, please get me (by eMail to OVMS developers mailing list, or my personal address):
Output of "SMS STAT" for the specified location Your vehicle id Output of base64 parameter string (from the cellphone app) - copy-and-paste Date/Time you entered the ACC location (with timezone) Date/Time you plugged in at the ACC location (with timezone) In the smartphone app, call up the Features and Parameters screens (so the server logs those, and I can check) Description of the problem you have
Please also share success stories. It is good to know what works.
Regards, Mark. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Wiro, I see the problem. I will fix in github tonight and commit. Can you build from source? If not, you will need to wait for 2.5.5, or I can build you a private firmware? Regards, Mark. On 16 Oct, 2013, at 2:54 pm, Wiro Zijlmans <wirozijlmans@gmail.com> wrote:
Mark, Other commands seem to work. E.g. Stat, version, see attached picture. What I mean with message from app is a notification that shows up at my phone as notification of message receipt. There is no change of parameters in the app itself.<image.png>
Groet / Regards Wiro Zijlmans
Op 16 okt. 2013 om 03:34 heeft Mark Webb-Johnson <mark@webb-johnson.net> het volgende geschreven:
Wiro,
Do you get any SMS responses? Such as a response to "STAT"...
Try "ACC STAT".
I don't understand about 'confirmation from the app it is received' - do you mean you see the parameter updated?
Regards, Mark.
On 16 Oct, 2013, at 1:41 am, Wiro Zijlmans <wirozijlmans@gmail.com> wrote:
Hi Mark, I am running the v1 HW on my TR and upgraded to 2.5.4. ACC seems not work at all. When sending ACC HERE command I get confirmation from app it is received but no feedback by SMS.
Groet / Regards Wiro Zijlmans
Op 11 okt. 2013 om 15:12 heeft Mark Webb-Johnson <mark@webb-johnson.net> het volgende geschreven:
OK. I've just committed v2.5.4 and pushed to github. I've also tagged it (as v2.5.4) and upload pre-built .hex files in the vehicle/firmware directory.
Short story: v2.5.4 seems stable to me, and has most of the bugs that I know about fixed. I’m still having trouble tracking down a random charge-time-estimate bug that is affecting CHARGEBY ACC profiles, but other than that is seems fine to me.
Big caveat: this is testing code, please don't use ACC if you _really_ need that charge to get to work / school / the beach / wherever. Don't blame me if your car doesn't start the charge as scheduled.
Warning: this is a long mail.
Firstly, the v2.5.x change log:
2013-10-11 2.5.4 Firmware 2.5.4 # Make MINSOC drive NET_NOTIFY_CHARGE (rather than NET_NOTIFY_STAT) # Input GPIO control for input RA2..RA5, and output RC0..RC3 # ThinkCity: Updates to Think City support # iMiev: Updates to Mitsubishi vehicle support # Think City: Added support for switching on/off external heater/auxilary via Valet Mode button # ACC: Aggressively stop charge if cooldown is done # ACC: If we are waiting for a charge, but the charge is started, then stop it # Range and SOC limits stop exactly ON the limit # Think City: car_parktime added # Fix for command handler with net_msg_cmd_msg # Tesla Roadster: fix for mins remain estimate if SOC limit but no RANGE limit # Use <=0, not ==-1, as indication range limit is not set # ACC: Move old STAT command to PARAMS?, and add a new STAT command to show true status # ACC: If charge is done, in acc location, and unplugged, transition to parked-in state # ACC: Repeat tx charge mode and limit commands, during cooldown and acc charge, if necessary # Tesla Roadster: Disable cooldown on boot # ACC: Race condition for charge finishes before cooldown flag is cleared # ACC: Setting params now returns a summary # ACC: Reset acc state, if enable/disable or setting parameters # ACC: Integer/Byte overflow workarounds # ACC: Workaround race condition where charge may take a few seconds to actually start (when commanded) # Tesla Roadster: Provide defaults for range, soc and cac in charge estimates # Support car_chargeestimate # ACC: rework to use new car_chargeestimate
2013-09-18 2.5.3 Firmware 2.5.3 ## Updates to thinkcity ## Remove DIAG and add ACC to V1_Production build config ## Remove InternalGPS from V2_TR_Production build config, as not required ## Cooldown: safety check (only recycle if charging), and revise cooldown current to 13A ## Support definition of location in SMS commands ## Tesla Roadster: HVAC#1 should be 0x8F not 0x87 ## Logging: Don't reserve a log slot if the respective logging option is disabled ## Improve cooldown status reporting on SMS STAT ## Tidy-up of minSOC ## Move chargelimit charge stop to common vehicle.c function (not acc) ## Tesla Roadster: Updates to Tom's charge-time-predictor, with thanks ## Log cooldown charges as mode=5, and fix excessive-logging-bug related to cooldown cycles ## Logging: Send log messages one-by-one, to avoid buffer overflows ## ACC: Number homelinks from 1..3 ## Tesla Roadster: support for chargelimits ## Make SMS "RESET" reset the module completely ## Complete rework and expansion of checkpoint numbers ## Stop charge after cooldown, if no subsequent charge requested ## Report CAC as part of charge log record ## Typos in acc for net_state_enter ## Show debug checkpoint, for DIAG SMS with debugcrash ## Support vehicle_fn_minutestocharge ## Add a timezone parameter (-)HH:MM ## ACC: Support timed charges ## Move car_cooldown_wascharging to global, and make use of it in ACC ## Introduce some delays to allow car to wake up
2013-08-27 2.5.2 Firmware 2.5.2 ## Updates to vehicle_thinkcity.c (getting to a pretty usable vehicle module) ## Make car_tbattery signed integer, and integrate thinkcity changes ## Only report range and soc limits if >0 ## Merge thinkcity changes: Think City AC-line voltage/current in SMS STAT SMS migrated from standard handler to vehicle_thinkcity.c ## Tesla Roadster: Don't stop charge after cooldown, if previously the car was already charging ## Log cooldown charges that become normal charges as two separate charges ## Tidy up diag, by removing temp test code T1 T2 T3 ## Create individual configs for TeslaRoadster and RenaultTwizy (to allow all features for these cars) ## Add TRACK (type XX) vehicle that just tracks GPS ## string_to_mode utility function ## Rework vehicle inclusions. Tesla Roadster, Renault Twizy and Volt/Ampera are production. Everything else is experimental ## Add experimental vehicle Kyburz DXP ## Add HVAC message details ## Support HVAC bit in car_doors5, and cooldown cycles ## Range and charge limits handled by ACC ## Basic ACC implementation, but without timed charges
2013-08-16 2.5.1 Firmware 2.5.1 ## Framework to build logging module in experimental modes ## FIsLatLongClose utiliy function (courtesy of Tom Saxton) ## Twizy: Mi/Km conversions updated to new functions ## Switch to use macros, for clarity and maintainability ## ACC integration to build environment ## Parameter support for base64 encoded parameters ## utils support for mode display ## ACC support for net_sms ## Switch logging system to use new "h" historical data submission, with acknowledgement ## Go from 4->6 log records, based on free space ## Tesla Roadster: Notify server if charge limit is changed ## Tesla Roadster: Notify server if charge mode is changed ## v2.5.1 protocol guide ## Add core support for cooldown ## Tesla Roadster support for cooldown ## Stub implementation, with basic functionality, for ACC ## Zero logging records on init, plus other safety checks ## Only initialise logging on a normal power up ## Standardise 3 diag tests: T1, T2 and T3 ## Only send logging msgs if link is connected ## Fix logging prefix and some logging tests ## Revisions to CAR_IS_CHARGING logic ## Misc bug-fixes for logging ## Report distance in miles (rather than 10ths of miles) ## Remove dr++ and cr++ sequence numbers, as not required ## Make ACC commands case insensitive ## Fix bug acknowledging log record #0 ## Move digital speedo feature (Tesla Roadster) from experimental to fully supported, and implement opt-in feature bits ## Honour opt-in flags for logging ## Only report debug crash reason if not normal power up, and only report once
As you can see, a lot has changed. The key points are:
Some restructuring of the build targets: V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware V2_RT_production.hex V2 Hardware Module, Renault Twizy full firmware V2_TR_production.hex V2 Hardware Module, Tesla Roadster full firmware Support for LOGGING (charge and drive) Support for ACC (Advanced Charge Control) - Tesla Roadster only at the moment Lots of other little nice fixes and enhancements
Apart from overall reliability testing (making sure it is stable in the cars), the two things I need help with are the LOGGING and ACC functions.
[1] Logging
The logging code is enabled by setting opt-in feature (#13) bit 1 (to log drives) and/or bit 2 (to log charges). Or, you can just set feature #13 to 255 and opt-in to everything :-)
Once you've opted in, whenever you complete a charge or drive, the car will submit a summary record to be stored on the server. You can then use the prototype HTTP API, or perl client, to retrieve those records for your own purposes.
Note that there is a privacy concern here, as both record types (drive and charge) store GPS locations - this is the reason why it is opt-in.
The testing I need done is just to ensure that this works for you, and that the resulting logged drives/charges match what you are expecting. It would also be useful to confirm if this works on all supported cars (which it should).
[2] Advanced Charge Control
The Advanced Charge Control system is designed to supplement the (aka take over from) vehicle's own charge scheduling. It should support any vehicle with charge control, but at the moment that means only Tesla Roadster. It has some pretty sophisticated features. For the moment, it is setup via SMS, but in future we will allow smartphone Apps to do this. Once setup, it runs autonomously, and doesn't even require a cellular connection.
ACC works from the concept of a 'charge location'. This is a geofenced location that is used for charging, and you can configure up to 4 of these (numbered #1 through #4). To define the car's current location as a 'charge location', sms "ACC HERE" to the car, and it will allocate a free slot and reply to you with it. You can use "ACC NOTHERE" to clear the current location.
If you want to clear a particular ACC location, you can sms "ACC CLEAR n" (to clear one location), or "ACC CLEAR" (to clear all locations).
You can show the current status off ACC with “ACC STAT”.
You can show the ACC details for the current location by sms "ACC PARAMS?" (or for a particular location by "ACC PARAMS? n" - which is very useful if you have crappy cellular connectivity like I do).
The ACC parameters for a particular location are configured with the "ACC PARAMS" SMS. You can list a location number (1, 2, 3 or 4) as the first parameter - or don't specify location if you just want to configure the current location the car is at. After 'ACC PARAMS", you can set the parameters you would like, from the following:
COOLDOWN - perform a cooldown charge (13A range mode, with cooling cycles) when the car is plugged in at this ACC location NOCOOLDOWN - don't do a cooldown charge (default) HOMELINK n - activate homelink when the vehicle drives to within 100m of an ACC location (the idea is to open our garage door / gate automatically as you approach) NOHOMELINK - don't activate homelink (default) CHARGEPLUGIN - charge the car on plugin (but after cooldown, if enabled) CHARGEAT HH:MM - schedule charge to start at the specified time (hours:minutes, 24hour clock) CHARGEBY HH:MM - schedule charge to complete by the specified time (hours:minutes 24hour clock) NOCHARGE - don't charge (default) LIMIT n - limit charge current to n Amps - must be specified for all CHARGE* actions MODE m - set charge mode (where "m" is STA(NDARD), STO(RAGE), RAN(GE) or PER(FORMANCE)) - must be specified for all CHARGE* actions STOPRANGE r - stop charge when range "r" is reached (specified in vehicle units, set to 0 (default) to not limit). STOPSOC s - stop charge when SOC "s" is reached (specified as a percentage, set to 0 (default) to not limit).
The actions to take at a particular ACC location must be enabled with "ACC ENABLE" (or "ACC ENABLE n") before they will work. You can also disable with "ACC DISABLE" (or "ACC DISABLE n").
If you are using CHARGEAT or CHARGEBY, you need to specify the timezone of the vehicle. This is parameter #23 and is specified as HH:MM offset from GmT (with an optional leading "-" if west of Greenwich).
The default temperature limit for cooldown is 31Celcius, and time limit is 60 minutes. If you want to change these, you can set parameter #15 to templimit:timelimit (e.g.; "31:60").
Note that you can also cooldown manually, while charging, with the SMS command "COOLDOWN", and see the status with SMS "STAT".
I've spent quite some time testing CHARGEPLUGIN, CHARGEAT, COOLDOWN, LIMIT, MODE, STOPRANGE and STOPSOC - hopefully those are ok now, but the control logic does need wider testing. The CHARGEBY option is still giving me random problems, related to the charge time estimated - I am still working on that. I've also been unable to test HOMELINK and would be very interested to see if that works.
Some notes on cooldown on Tesla Roadster
The cooldown algorithm is to start a range mode charge at 13Amps, and to monitor the HVAC system of the car. Once the HVAC starts, runs for some time, then stops, we call it a 'cooling cycle'. We keep a record of how many such cycles have occurred.
Once we detect that the HVAC has stopped, we try to start it again. The logic at the moment is to switch to performance mode for ten seconds, then back to range mode, once every minute until the HVAC starts again. The _best_ way of starting the HVAC is to stop and start the charge, but that is painful on the contactors, so we don't do it. Switching Range->Performance->Range seems to be the second best, but I remain unconvinced that it makes much difference. In Hong Kong summer weather, I get one cooldown cycle every ten minutes or so. I can drop 6 to 8 celcius in one hour.
The cooldown will stop after either the desired temperature is hit (based on the temperature of the hottest brick in the battery) or the cooldown has been ongoing for the time limit.
Conclusions
I'm happy that the code is reasonably stable now, but really need help testing this in a larger number of cars. If you do see a problem, please get me (by eMail to OVMS developers mailing list, or my personal address):
Output of "SMS STAT" for the specified location Your vehicle id Output of base64 parameter string (from the cellphone app) - copy-and-paste Date/Time you entered the ACC location (with timezone) Date/Time you plugged in at the ACC location (with timezone) In the smartphone app, call up the Features and Parameters screens (so the server logs those, and I can check) Description of the problem you have
Please also share success stories. It is good to know what works.
Regards, Mark. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, I am not too much in programming myself but have no problem with waiting until 2.5.5 is released. Groet / Regards Wiro Zijlmans
Op 16 okt. 2013 om 10:16 heeft Mark Webb-Johnson <mark@webb-johnson.net> het volgende geschreven:
Wiro,
I see the problem. I will fix in github tonight and commit.
Can you build from source? If not, you will need to wait for 2.5.5, or I can build you a private firmware?
Regards, Mark.
On 16 Oct, 2013, at 2:54 pm, Wiro Zijlmans <wirozijlmans@gmail.com> wrote:
Mark, Other commands seem to work. E.g. Stat, version, see attached picture. What I mean with message from app is a notification that shows up at my phone as notification of message receipt. There is no change of parameters in the app itself.<image.png>
Groet / Regards Wiro Zijlmans
Op 16 okt. 2013 om 03:34 heeft Mark Webb-Johnson <mark@webb-johnson.net> het volgende geschreven:
Wiro,
Do you get any SMS responses? Such as a response to "STAT"...
Try "ACC STAT".
I don't understand about 'confirmation from the app it is received' - do you mean you see the parameter updated?
Regards, Mark.
On 16 Oct, 2013, at 1:41 am, Wiro Zijlmans <wirozijlmans@gmail.com> wrote:
Hi Mark, I am running the v1 HW on my TR and upgraded to 2.5.4. ACC seems not work at all. When sending ACC HERE command I get confirmation from app it is received but no feedback by SMS.
Groet / Regards Wiro Zijlmans
Op 11 okt. 2013 om 15:12 heeft Mark Webb-Johnson <mark@webb-johnson.net> het volgende geschreven:
OK. I've just committed v2.5.4 and pushed to github. I've also tagged it (as v2.5.4) and upload pre-built .hex files in the vehicle/firmware directory.
Short story: v2.5.4 seems stable to me, and has most of the bugs that I know about fixed. I’m still having trouble tracking down a random charge-time-estimate bug that is affecting CHARGEBY ACC profiles, but other than that is seems fine to me.
Big caveat: this is testing code, please don't use ACC if you _really_ need that charge to get to work / school / the beach / wherever. Don't blame me if your car doesn't start the charge as scheduled.
Warning: this is a long mail.
Firstly, the v2.5.x change log:
2013-10-11 2.5.4 Firmware 2.5.4 # Make MINSOC drive NET_NOTIFY_CHARGE (rather than NET_NOTIFY_STAT) # Input GPIO control for input RA2..RA5, and output RC0..RC3 # ThinkCity: Updates to Think City support # iMiev: Updates to Mitsubishi vehicle support # Think City: Added support for switching on/off external heater/auxilary via Valet Mode button # ACC: Aggressively stop charge if cooldown is done # ACC: If we are waiting for a charge, but the charge is started, then stop it # Range and SOC limits stop exactly ON the limit # Think City: car_parktime added # Fix for command handler with net_msg_cmd_msg # Tesla Roadster: fix for mins remain estimate if SOC limit but no RANGE limit # Use <=0, not ==-1, as indication range limit is not set # ACC: Move old STAT command to PARAMS?, and add a new STAT command to show true status # ACC: If charge is done, in acc location, and unplugged, transition to parked-in state # ACC: Repeat tx charge mode and limit commands, during cooldown and acc charge, if necessary # Tesla Roadster: Disable cooldown on boot # ACC: Race condition for charge finishes before cooldown flag is cleared # ACC: Setting params now returns a summary # ACC: Reset acc state, if enable/disable or setting parameters # ACC: Integer/Byte overflow workarounds # ACC: Workaround race condition where charge may take a few seconds to actually start (when commanded) # Tesla Roadster: Provide defaults for range, soc and cac in charge estimates # Support car_chargeestimate # ACC: rework to use new car_chargeestimate
2013-09-18 2.5.3 Firmware 2.5.3 ## Updates to thinkcity ## Remove DIAG and add ACC to V1_Production build config ## Remove InternalGPS from V2_TR_Production build config, as not required ## Cooldown: safety check (only recycle if charging), and revise cooldown current to 13A ## Support definition of location in SMS commands ## Tesla Roadster: HVAC#1 should be 0x8F not 0x87 ## Logging: Don't reserve a log slot if the respective logging option is disabled ## Improve cooldown status reporting on SMS STAT ## Tidy-up of minSOC ## Move chargelimit charge stop to common vehicle.c function (not acc) ## Tesla Roadster: Updates to Tom's charge-time-predictor, with thanks ## Log cooldown charges as mode=5, and fix excessive-logging-bug related to cooldown cycles ## Logging: Send log messages one-by-one, to avoid buffer overflows ## ACC: Number homelinks from 1..3 ## Tesla Roadster: support for chargelimits ## Make SMS "RESET" reset the module completely ## Complete rework and expansion of checkpoint numbers ## Stop charge after cooldown, if no subsequent charge requested ## Report CAC as part of charge log record ## Typos in acc for net_state_enter ## Show debug checkpoint, for DIAG SMS with debugcrash ## Support vehicle_fn_minutestocharge ## Add a timezone parameter (-)HH:MM ## ACC: Support timed charges ## Move car_cooldown_wascharging to global, and make use of it in ACC ## Introduce some delays to allow car to wake up
2013-08-27 2.5.2 Firmware 2.5.2 ## Updates to vehicle_thinkcity.c (getting to a pretty usable vehicle module) ## Make car_tbattery signed integer, and integrate thinkcity changes ## Only report range and soc limits if >0 ## Merge thinkcity changes: Think City AC-line voltage/current in SMS STAT SMS migrated from standard handler to vehicle_thinkcity.c ## Tesla Roadster: Don't stop charge after cooldown, if previously the car was already charging ## Log cooldown charges that become normal charges as two separate charges ## Tidy up diag, by removing temp test code T1 T2 T3 ## Create individual configs for TeslaRoadster and RenaultTwizy (to allow all features for these cars) ## Add TRACK (type XX) vehicle that just tracks GPS ## string_to_mode utility function ## Rework vehicle inclusions. Tesla Roadster, Renault Twizy and Volt/Ampera are production. Everything else is experimental ## Add experimental vehicle Kyburz DXP ## Add HVAC message details ## Support HVAC bit in car_doors5, and cooldown cycles ## Range and charge limits handled by ACC ## Basic ACC implementation, but without timed charges
2013-08-16 2.5.1 Firmware 2.5.1 ## Framework to build logging module in experimental modes ## FIsLatLongClose utiliy function (courtesy of Tom Saxton) ## Twizy: Mi/Km conversions updated to new functions ## Switch to use macros, for clarity and maintainability ## ACC integration to build environment ## Parameter support for base64 encoded parameters ## utils support for mode display ## ACC support for net_sms ## Switch logging system to use new "h" historical data submission, with acknowledgement ## Go from 4->6 log records, based on free space ## Tesla Roadster: Notify server if charge limit is changed ## Tesla Roadster: Notify server if charge mode is changed ## v2.5.1 protocol guide ## Add core support for cooldown ## Tesla Roadster support for cooldown ## Stub implementation, with basic functionality, for ACC ## Zero logging records on init, plus other safety checks ## Only initialise logging on a normal power up ## Standardise 3 diag tests: T1, T2 and T3 ## Only send logging msgs if link is connected ## Fix logging prefix and some logging tests ## Revisions to CAR_IS_CHARGING logic ## Misc bug-fixes for logging ## Report distance in miles (rather than 10ths of miles) ## Remove dr++ and cr++ sequence numbers, as not required ## Make ACC commands case insensitive ## Fix bug acknowledging log record #0 ## Move digital speedo feature (Tesla Roadster) from experimental to fully supported, and implement opt-in feature bits ## Honour opt-in flags for logging ## Only report debug crash reason if not normal power up, and only report once
As you can see, a lot has changed. The key points are:
Some restructuring of the build targets: V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware V2_RT_production.hex V2 Hardware Module, Renault Twizy full firmware V2_TR_production.hex V2 Hardware Module, Tesla Roadster full firmware Support for LOGGING (charge and drive) Support for ACC (Advanced Charge Control) - Tesla Roadster only at the moment Lots of other little nice fixes and enhancements
Apart from overall reliability testing (making sure it is stable in the cars), the two things I need help with are the LOGGING and ACC functions.
[1] Logging
The logging code is enabled by setting opt-in feature (#13) bit 1 (to log drives) and/or bit 2 (to log charges). Or, you can just set feature #13 to 255 and opt-in to everything :-)
Once you've opted in, whenever you complete a charge or drive, the car will submit a summary record to be stored on the server. You can then use the prototype HTTP API, or perl client, to retrieve those records for your own purposes.
Note that there is a privacy concern here, as both record types (drive and charge) store GPS locations - this is the reason why it is opt-in.
The testing I need done is just to ensure that this works for you, and that the resulting logged drives/charges match what you are expecting. It would also be useful to confirm if this works on all supported cars (which it should).
[2] Advanced Charge Control
The Advanced Charge Control system is designed to supplement the (aka take over from) vehicle's own charge scheduling. It should support any vehicle with charge control, but at the moment that means only Tesla Roadster. It has some pretty sophisticated features. For the moment, it is setup via SMS, but in future we will allow smartphone Apps to do this. Once setup, it runs autonomously, and doesn't even require a cellular connection.
ACC works from the concept of a 'charge location'. This is a geofenced location that is used for charging, and you can configure up to 4 of these (numbered #1 through #4). To define the car's current location as a 'charge location', sms "ACC HERE" to the car, and it will allocate a free slot and reply to you with it. You can use "ACC NOTHERE" to clear the current location.
If you want to clear a particular ACC location, you can sms "ACC CLEAR n" (to clear one location), or "ACC CLEAR" (to clear all locations).
You can show the current status off ACC with “ACC STAT”.
You can show the ACC details for the current location by sms "ACC PARAMS?" (or for a particular location by "ACC PARAMS? n" - which is very useful if you have crappy cellular connectivity like I do).
The ACC parameters for a particular location are configured with the "ACC PARAMS" SMS. You can list a location number (1, 2, 3 or 4) as the first parameter - or don't specify location if you just want to configure the current location the car is at. After 'ACC PARAMS", you can set the parameters you would like, from the following:
COOLDOWN - perform a cooldown charge (13A range mode, with cooling cycles) when the car is plugged in at this ACC location NOCOOLDOWN - don't do a cooldown charge (default) HOMELINK n - activate homelink when the vehicle drives to within 100m of an ACC location (the idea is to open our garage door / gate automatically as you approach) NOHOMELINK - don't activate homelink (default) CHARGEPLUGIN - charge the car on plugin (but after cooldown, if enabled) CHARGEAT HH:MM - schedule charge to start at the specified time (hours:minutes, 24hour clock) CHARGEBY HH:MM - schedule charge to complete by the specified time (hours:minutes 24hour clock) NOCHARGE - don't charge (default) LIMIT n - limit charge current to n Amps - must be specified for all CHARGE* actions MODE m - set charge mode (where "m" is STA(NDARD), STO(RAGE), RAN(GE) or PER(FORMANCE)) - must be specified for all CHARGE* actions STOPRANGE r - stop charge when range "r" is reached (specified in vehicle units, set to 0 (default) to not limit). STOPSOC s - stop charge when SOC "s" is reached (specified as a percentage, set to 0 (default) to not limit).
The actions to take at a particular ACC location must be enabled with "ACC ENABLE" (or "ACC ENABLE n") before they will work. You can also disable with "ACC DISABLE" (or "ACC DISABLE n").
If you are using CHARGEAT or CHARGEBY, you need to specify the timezone of the vehicle. This is parameter #23 and is specified as HH:MM offset from GmT (with an optional leading "-" if west of Greenwich).
The default temperature limit for cooldown is 31Celcius, and time limit is 60 minutes. If you want to change these, you can set parameter #15 to templimit:timelimit (e.g.; "31:60").
Note that you can also cooldown manually, while charging, with the SMS command "COOLDOWN", and see the status with SMS "STAT".
I've spent quite some time testing CHARGEPLUGIN, CHARGEAT, COOLDOWN, LIMIT, MODE, STOPRANGE and STOPSOC - hopefully those are ok now, but the control logic does need wider testing. The CHARGEBY option is still giving me random problems, related to the charge time estimated - I am still working on that. I've also been unable to test HOMELINK and would be very interested to see if that works.
Some notes on cooldown on Tesla Roadster
The cooldown algorithm is to start a range mode charge at 13Amps, and to monitor the HVAC system of the car. Once the HVAC starts, runs for some time, then stops, we call it a 'cooling cycle'. We keep a record of how many such cycles have occurred.
Once we detect that the HVAC has stopped, we try to start it again. The logic at the moment is to switch to performance mode for ten seconds, then back to range mode, once every minute until the HVAC starts again. The _best_ way of starting the HVAC is to stop and start the charge, but that is painful on the contactors, so we don't do it. Switching Range->Performance->Range seems to be the second best, but I remain unconvinced that it makes much difference. In Hong Kong summer weather, I get one cooldown cycle every ten minutes or so. I can drop 6 to 8 celcius in one hour.
The cooldown will stop after either the desired temperature is hit (based on the temperature of the hottest brick in the battery) or the cooldown has been ongoing for the time limit.
Conclusions
I'm happy that the code is reasonably stable now, but really need help testing this in a larger number of cars. If you do see a problem, please get me (by eMail to OVMS developers mailing list, or my personal address):
Output of "SMS STAT" for the specified location Your vehicle id Output of base64 parameter string (from the cellphone app) - copy-and-paste Date/Time you entered the ACC location (with timezone) Date/Time you plugged in at the ACC location (with timezone) In the smartphone app, call up the Features and Parameters screens (so the server logs those, and I can check) Description of the problem you have
Please also share success stories. It is good to know what works.
Regards, Mark. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (3)
-
Jack West -
Mark Webb-Johnson -
Wiro Zijlmans