- Charging should stop automatically at 80%. I hate that I'm needlessly wearing down my brakes and also the car feels like it is getting away from me with the reduced regenerative braking when the SoC is above 80%.
- The car should warn when starting to drive when the headlights are not set to Auto or On (our other car has the wipers on the left stalk, so this confusion sometimes results in my wife or daughter turning the headlights off of Auto).
- The car should warn when putting it in gear with the parking brake set (I figured there must be CAR-bus messages indicating both that the parking brake is set and that the car is in gear, so it should be possible to sound a beeper for this -- and why doesn't the Leaf do this already).
- I use LEAF Manager to check the SoC and turn on Climate Control and it is much faster than the Nissan EV app, but LEAF Manager is still too slow (which is not the app's fault, the servers and cell phone data communications to the car are just too slow), and it seems too often there is a server or some other problem. When I'm at home I'd like to be able to quickly; turn on Climate Control, see the SoC without having to fiddle with my cell phone, and more easily confirm the car is charging. Also, I'd like to choose to charge to 100% if I have a longer trip the next day.
I now have a solution to all these goals, I'll describe some of what I did and what I learned. The quick summary is a Carloop Basic is plugged-in to the Leaf's OBDII port and this monitors the CAN messages on the Leaf's CAR-bus for the SoC and other messages. During charging, when the SoC is more than 80% the Carloop uses Wi-Fi to send a message to my OpenEVSE to stop charging the Leaf. A small colour LCD display with touch-screen in my house allows me to view the charging progress and status and also to start the Climate Control, using Wi-Fi messages to the Carloop in the car.
There are three hardware components to the project:
- The main work is done by a Carloop Basic, which plugs into the Leaf's OBDII port. While I have some concerns about the Carloop itself (for example, it ties signal ground to chassis ground), it is based on the Particle Photon which is an amazing processor and development environment. For example, the processor has a huge amount of memory, programs are downloaded over Wi-Fi (so it can be plugged in my car in the cold garage while I work on the software and much of the trouble-shooting from my PC upstairs), and it programs faster than an Arduino.
I spent much time deciding whether to monitor the EV-bus or the CAR-bus, and even built a circuit (and found the connectors) to isolate the Leaf's TCU to try to confirm which messages it sends and receives. But after much testing decided that monitoring (and sometimes sending messages on) the CAR-bus is all I needed for this project.
- For the in-house display I used an Adafruit Feather with a colour LCD touch-screen (both amazing products from a fantastic company). Here's a view of the back of it. It has built-in Wi-Fi, so I call this the Wi-Fi Remote (the Feather processor/Wi-Fi board has the Micro-USB cable and is plugged-in to the back of the LCD touch-screen). Some day I'll put it into a case.
- As others have, I spent much time trying to find a CAN-bus way of stopping the Leaf charging and while it may be possible to do this by falsely reporting high battery temperature or some other error condition, that would likely result in unresolvable warranty arguments. Fortunately, I use an OpenEVSE and it has a simple web-server interface. By programming the Carloop to be a web client, I can stop charging the Leaf when the SoC reaches 80% by having the Carloop send the $FD command to the OpenEVSE.
The Wi-Fi Remote
A photograph of the Wi-Fi Remote display during charging is here, this shows ...
At the top is the current State of Charge of the Leaf's battery. This is the same number as is displayed on the car's dashboard. I know that some prefer the "internal" value in message 0x55B, and some prefer GIDs, but I decided that since I only use the dash SoC when I'm driving, I should also display this "dash SoC" on the Wi-Fi Remote. After much testing I found this is in the first data byte of message 0x50D (it is also in the fifth data byte of message 0x1DB on the EV-bus).
On the next line I display the range, both with and without Climate Control. This value matches that displayed on the Leaf's dashboard (if you toggle Climate Control on and off to see both values). I found this information in message 0x5A9, already in km, which is what I wanted.
- I know that the canmsgs.xls spreadsheet shows this as a percentage of range (where a count of 4,095 would be 508 miles) but I found the simpler way to interpret this is to take the 8-bit value from the second data byte as the most-significant part and the top four bits from the third data byte as the least-significant part, then to divide this 12-bit value by five. That provides the range in km for the current state of whether Climate Control is running or not.
- The first data byte in message 0x5A9 is the range change if the Climate Control was changed. After much time I found the way to interpret this is to take the one's complement of the value and if the MS bit is set the Climate Control is currently on so the remaining seven bits of this value is the range increase if Climate Control was turned off. If the MS bit is not set then the remaining seven bits is the two's complement of the range reduction if the Climate Control was turned on.
- For example, I eventually found that the second data byte of message 0x390 has the charge current where 0x3C (decimal 60) represents the maximum charging current of 27.5 amps. The sixth data byte shows the maximum current the EVSE will provide.
- I also found that setting the LS bit of the first data byte of message 0x56E unlocks the Leaf's doors (and turns on the dome light) for a minute. Setting the MS bit of the second data byte of message 0x56E locks the doors and flashes the turn signals. Presumably Nissan included this to allow them to unlock your doors remotely, using the TCU (for example, if you locked your keys in the car and they offered such a service as General Motors started for their OnStar service for Cadillac many years ago). I don't think disclosing this is a security problem since this vulnerability would only happen for people that somehow have Wi-Fi access to their OBDII port and did not set any Wi-Fi security.
By touching this top-half of the screen a query is sent to the Carloop to get updated values. Touching the very top-right part of the screen also displays some diagnostic information such as the Wi-Fi signal strength for both the Wi-Fi Remote and Carloop. In very small text, at the top-right I also display the elapsed time since the last communication with the Carloop. And as shown here, I display a blue circle after a query is sent to the Carloop, this is cleared when a reply is received or displayed as a red circle if no reply is received. The Carloop can also initiate communications to the Wi-Fi Remote if it has changed data or has just come into Wi-Fi range, and receipt of such "push" data from the Carloop is displayed on the Wi-Fi Remote with a green circle.
Now for the three "buttons" at the lower half of the screen.
- On the left side is a toggle for whether to terminate the charge at 80% or allow the Leaf to fully charge.
- Below that toggles starting/stopping the Climate Control. When the Climate Control actually starts, as reported by the Leaf's CAR-bus (typically within 10 seconds), the icon changes, such as shown here (I display "A/C on" with a blue background when the Air Conditioning has been remotely started. Other than waking-up the CAR-bus to get updated information (charge amps, dash SoC ...), I think this is the only message sent by the Carloop to the CAR-bus, and it was difficult to get working as it is duplicating the message the TCU would send to start/stop Climate Control. So while the Carloop is asking for the Climate Control to start, the TCU is sending a message (every 100 ms) to the Climate Control to not change, and the Leaf's VCM would not be expecting to receive such conflicting messages. After much testing I found that it usually works to send the 0x56E messages more often than the TCU, and send them for longer than the TCU would when it starts the Climate control. I settled on sending the bus wake-up (0x68C 00) , followed 50 ms later by 0x56E 4E 08 12 00 to turn on Climate Control, then delaying another 20 ms and repeating this Climate Control command another 45 times at 60 ms intervals.
- The button to the right toggles sending charge start and stop commands to the OpenEVSE. I have set my OpenEVSE's internal charge timer start charging every night at 1:00 am and stop six hours later, though the Carloop stops charging sooner if I'm only charging to 80%.
- When charging, the display is of this format. The touch-area changes to red and the top line is "Charging". Below that is the increase in charge during this charge session, below that is the duration of this charge session (seconds displayed incrementing every second), and below that is the current charging current.
- So this display shows that the Leaf has been charging for 17 minutes and 41 seconds and during this time the Leaf's battery charge has increased by 8% to a dash SoC of 62%. The Leaf charges about 3% every 7½ minutes, so the Carloop wakes-up the Leaf's CAR-bus every seven minutes. Therefore, the charge (and range) numbers are updated approximately every 3% charge increase. For a while I had the Carloop wake-up the Leaf's CAR-bus every minute, then you get to see the charge percent increase by one count every two minutes or so.
I used a flat OBDII extension cable and mounted the Carloop in a small case, shown here. I considered trying to use the Leaf's own alert tones for when the parking brake is on or headlights are off, but the triggering method appears to be quite complicated (CAR-bus message data bytes seem to cycle quickly through many values) and anyways, it is best to not impact the car's safety features. So I installed a small speaker on the outside of the Carloop's case.
The beeper sounds when the Leaf is put in Drive or Reverse (message 0x174) if the headlights are not in Auto or On (message 0x60D), and also if the parking brake is set (bit 2 of the first data byte of message 0x5C5).
The 3.5 mm phone plug is used to both power the Carloop for testing when out of the car and also to send serial data to an external Arduino-based display I used during software development and testing. While convenient, using this type of connector was a bad choice as I seem to have damaged the Carloop's serial transmitter with the brief jolts of 5v power from the external Arduino as I plugged and unplugged the display while restarting the Carloop to test triggering pushing data to the Wi-Fi Remote when the Carloop establishes the Wi-Fi connection.
The Carloop mounted in a case is shown here. The switch turns off the Carloop. It apparently draws about 100 mA and I have not had any problems with it draining the Leaf's battery. The Photon has power-down modes, but I have not tried using those. The LED beside the switch is for trouble-shooting, I've used it to show CAR-bus activity, Wi-Fi connection status, and communication with the Wi-Fi Remote.
Current Project Status
While the above all works, there are still some intermittent software problems that I'm still trouble-shooting, so the software will change.
Also, it would take much extra work to make this into a product for others to use (and given all the hardware needed, it would be expensive). For example, there are three IP addresses that need to be set in both the Carloop and Wi-Fi Remote as they need to communicate with each other and with the OpenEVSE (and the Carloop doesn't have a user interface for such configuration, so it is currently hard-coded into the software). So unfortunately, this is a somewhat complicated solution as it requires Wi-Fi communications between three different devices, so helping with others trouble-shooting would be difficult.
Another problem with others using this is that limiting charging the Leaf to 80% requires using the OpenEVSE, and it seems not many people have this particular EVSE. So for now I don't plan on releasing the software.
One Leaf thing that still bugs me which I wasn't able to fix was to get the Leaf to default to B regenerating braking mode rather the D drive mode. I did find the first data byte of CAR-bus message 0x421 reports D mode (0x20) and B mode (0x38), but I wasn't able to simulate moving the shifter to D to change this using CAR-bus messages. This is probably a good thing as that would be too dangerous anyways.
I appreciate the expertise and work done and shared by others on this forum, which is why I wanted to contribute the details above.