We've made some progress getting OVMS working on the Leaf, thanks to some hard work at the recent #hackaleaf day in UK. We're now using a custom cable which delivers the single EV-CAN bus to the OVMS module. The cable also brings out the CAR-CAN bus, but we only have one CAN controller in the v2 OVMS module so are hoping to be able to do what we need with just the EV-CAN bus (with active polling through to the CAR-CAN bus for the few things we need there).
Below are the items we are looking for, and our current approach. Apologies for the long-post - just want to put it down in one place. Any advise/recommendation appreciated. What mentioning CAN ID numbers, we mean 11bit can messages with the ID in 0x... hex format, and the Dx data byte indexes are D1..D8 (starting at 1 not 0).
It would be nice to be able to identify the car type (2011, 2012, 2013, etc). Presumably this can be retrieved from the VIN, but we've done nothing for this, yet.
This is the alpha-numeric VIN number. It is supposedly available by active polling on the CAR-CAN bus, via the EV-CAN we are on. We did some basic work on this, using standard OBDII PIDs and poll types, but couldn't get anything. One poster on the active-polling thread mentioned they have managed to get it using the leaf-style 0x21 poll type, but we haven't had a chance to try yet.
car_gpslock, car_stale_gps, car_latitude, car_longitude, car_direction, car_altitude
OVMS has a built-in GPS, so we're just going to use that and ignore anything the car has on this.
car_stale_tpms, car_tpms_t (0..3), car_tpms_p (0..3)
TPMS values (stale, temperatures and pressures) would be nice to have, but we've done nothing on this yet. These are nice-to-have, but not essential.
Set if the car ignition is ON. At the moment we're using 0x56e D1=0x86 for car is driving, else not.
We don't have this at the moment. We see some wheel speeds on the EV-CAN bus, but no direct speedometer reading. This could be retrieved via GPS, but it would be good to be able to get this from the car.
We haven't found either of these on the EV-CAN bus. They are nice-to-have, but not essential.
car_stale_ambient, car_ambient_temp, car_stale_temps, car_tpem, car_tmotor, car_tbattery
These are the ambient, PEM (AC-DC and DC-AC electronics), Motor, and Battery temperatures. We don't have any of these, but haven't started looking yet.
Door status (front-left, front-right, bonnet, trunk, rear-left, rear-right), Handbrake status, Headlight status, lock/unlock status, alarm status
We haven't start looking yet. Presumably these are on the CAR-CAN bus, and will require active polling to retrieve.
Vehicle awake/sleep status
This is trivial to get via activity (or lack of activity) on the EV-CAN bus.
We will generate these timers internally based on cellular network time and an internal clock.
We're currently getting these from 0x5bc, derived from the GIDs. We realise there are several competing ways of calculating SOC from GIDs and will offer a configuration setting to support them all.
This is the ideal range of the car, based on current SOC. It should be based on the standard testing cycle figure for the car. So if, for example, the testing cycle says 84 miles, then at 50% SOC the ideal range is 42 miles. At the moment, we're just using a simple SOC% x ideal range for this.
This is the estimated range of the car, based on current SOC and current/recent driving behaviour. We can either show here what the car is showing, or derive our own. We haven't done this yet.
This is some indication of the overall health of the battery. The meaning changes with each supported vehicle. For the Tesla Roadster, 160 is a new battery, and after 3 1/2 years my car is 152.28 today. For the Nissan Leaf, we can probably use GIDS/281 at full charge (or something like that) - but open to suggestions.
Charging Status - pilot signal
We need an indication that there is a pilot signal (i.e.; the charge cable has been connected and the EVSE is offering power). At the moment we are using 0x5bf D3 != 0 AND D4 != 0. It seems to work ok.
Charging Status - car is charging, charge limit, line voltage, charge current
We need an indication of if the charging is in progress, and if it is what voltage and current are being provided by the wall.
Currently, for charge status (charging or not), we are using the same as the pilot signal (0x5bf D3 != 0 AND D4 != 0). For charge completion, as well as looking for EV-CAN bus data to tell us the charge has completed, we're also looking at a timeout of 10 seconds with no EV-CAN bus activity (car has gone to sleep, so charging must have completed).
For charge limit (the current limit that the EVSE advertises), we are using 0x5bf D3/5 (in Amps). We tried this at various different values, and it seemed to match what the EVSE was offering quite well. The only issue is that it seemed to be capped at D3=0x5A (which would be 18A). Values we've seen for D3 are 0x00, 0x27, 0x28, 0x32, 0x33, and 0x5A.
We haven't managed to find the line voltage and charge current data at all. We can see current/voltage of the battery, but not from the wall. This is very useful, and we are still looking for this.
We need the car_chargeduration (in minutes), but we can calculate this ourselves. We also need the car_chargekwh (which is the amount of kWh put into the battery / taken from the wall during the charge session) - which we would normally calculate ourselves based on line voltage and charge current over time.
This would be nice to have, but we haven't found it yet.
car_stale_timer, car_timermode, car_timerstart
These are the car charge timer values. We haven't started looking yet.
Commands for pre-cool, pre-heat, lock, unlock, etc.
We haven't started on this yet, but it looks promising based on what is shown here. The only issue may be co-existing with the on-board telemetry unit. The OVMS module has some digital I/O pins available, so we can most likely offer a hardware tap for wakeup on pre-2013 cars.
We'd really like to expose all the other stuff on the car (like GIDs, etc). For that, we're going to use custom-metrics tags so we can send them to the apps directly, as well as do logging in a similar way to the way it was done on the Renault Twizy.
The above is really a laundry-list of everything we _want_. What we _need_ now is the VIN (active polling messages), speed, estimated range, cac100 (battery health), charging line voltage and current drawn. Any suggestions you guys have for these would be most appreciated. It would also be helpful if you could check our working for 0x5bf D3/5 (as EVSE pilot signal advertised current), as that seems to make sense for us but we are not sure if the calculation is correct or not (not enough data to be certain).