Limiting charging to 80% and fixing the other few things on my wish list

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Mitchell

Active member
Joined
Jun 2, 2015
Messages
28
Location
Toronto, Canada
I've had my 2016 Leaf SL for over a year now and there are a few things I've wanted to fix:

  1. 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%.

  2. 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).

  3. 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).

  4. 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've seen how easy others make such development appear (such as Macchina and this Alexa skill -- though she is just explaining how to implement the developer's software). But for me this has been months of work, thousands of dollars (I treated myself to a digital storage oscilloscope to resolve some difficult problems), and including test routines I wrote over 2,500 lines of code for this project and being a hardware and data communications guy, I'm slow at writing code.

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.

The Project
There are three hardware components to the project:

  1. 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.

  2. 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.

  3. 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.
All communications between these three uses Wi-Fi (I found that I already had good Wi-Fi coverage in my garage).

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.
On the next line I display whether the charge cable is currently plugged-in. I spent much time looking through the CAR-bus messages and eventually determined that if the fifth data byte of message 0x390 is 0x88 or 0x98 then the charge cable is plugged-in. I spent a huge amount of time looking at messages to find what I needed:
  • 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.
As this is a touch-screen, all interaction with the Wi-Fi Remote is through touching the LCD screen.

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.

  1. On the left side is a toggle for whether to terminate the charge at 80% or allow the Leaf to fully charge.

  2. 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.

  3. 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.
    Since the Carloop wakes up the Leaf's CAR-bus every seven minutes, the Carloop may learn that the charge is above 80% after it has already a few percent higher, which is shown here. This shows that the Carloop has terminated charging and the last charge session had a duration of 1 hour and three minutes, during which the Leaf's battery charge increased by 29%, and charging was terminated 12 minutes and 55 seconds earlier (this increments every second).
The Carloop
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.
 
This is so cool. I actually purchased a photon a while back, for a similar project.

Do you have any idea what the max power consumption is? I'm mostly worried about draining the 12V battery when parked.

I guess you could at least put it into low power mode when the voltage is dropping too low.
 
Mitchell said:
I've had my 2016 Leaf SL for over a year now and there are a few things I've wanted to fix:

  1. 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%.

  1. Unfortunately, the charge to 80% option was removed from US Leafs (and it looks like Canadian ones too) starting w/model year 2014.

    http://insideevs.com/2014-nissan-leaf-mostly-unchanged-as-range-technically-moves-up-to-84-miles/

    It apparently still exists on 2015 Leafs in Ireland. Not sure if the US/North America were the only regions to get the removal.
 
Unfortunately, the charge to 80% option was removed from US Leafs (and it looks like Canadian ones too) starting w/model year 2014.

You didn't read the whole post? The OP apparently knows this, and found a (complicated) way around it, using a smart EVSE and a web-connected monitor in the OBDII port.
 
LeftieBiker said:
Unfortunately, the charge to 80% option was removed from US Leafs (and it looks like Canadian ones too) starting w/model year 2014.

You didn't read the whole post? The OP apparently knows this, and found a (complicated) way around it, using a smart EVSE and a web-connected monitor in the OBDII port.
Whoops. :oops: No, I didn't.

Yes, I know about what he's getting at w/his solution. It's unfortunate we have to resort to stuff like that or mucking w/charging timers.
 
This, along with the terrible high beams, are the two main reasons I'm not looking to lease a 2017 Leaf cheap. It looks like I'll have to wait for "Leaf 2", which appears to be little more than a facelifted Leaf 1 with more capacity and (hopefully) better headlights, because Nissan couldn't be bothered to fix those two easily-fixed things. I wish the OP luck. Maybe there will soon be a workaround that consists of an app, a hardwired EVSE timer, and a port dongle...
 
Nice!

Nifty project and great description. Telling the car to stop charging at 80% seems like it should be simple --- but it is not, and I appreciate the insight into what goes on behind the scenes to hack the car. Why was an oscilloscope required ?
 
IIama said:
This is so cool. I actually purchased a photon a while back, for a similar project.

Do you have any idea what the max power consumption is? I'm mostly worried about draining the 12V battery when parked.

I guess you could at least put it into low power mode when the voltage is dropping too low.
I never measured the current draw myself, but the Photon datasheet says average power consumption is 80 mA to 100 mA (higher spikes when the Wi-Fi is used, but that is very brief). I would hope that newer Leaf's automatically charge the 12v battery from the main battery if needed, so power consumption should not be a problem (there are many threads about this, I don't recall what the conclusion for newer Leafs is).
 
SageBrush said:
Nice!

Nifty project and great description. Telling the car to stop charging at 80% seems like it should be simple --- but it is not, and I appreciate the insight into what goes on behind the scenes to hack the car. Why was an oscilloscope required ?
There was one odd problem where starting the Carloop caused a transient on the serial port (likely because my test-bench power supply was too weak) and this caused a junk character on the serial line to my Arduino display I used during testing. This confused the simple routine I was using to receive test data on the serial line (the first two characters specified the X and Y position for the character). Once I saw what caused the transient, I moved the Carloop initialization to before starting the serial line.

Another example was at the very beginning when I was having trouble sending anything my test CAN-bus was the Carloop sending to a Konwei OBD dongle. It turns out the Konwei doesn't Ack messages so the Carloop would retransmit and time-out and I couldn't tell if the Carloop was actually transmitting or not. The oscilloscope showed what was happening.

But the main advantage of the Oscilloscope (I got a Picoscope) for later parts of the project is that it can decode CAN-bus messages, time them to the microsecond, and export this to an Excel file. This was very valuable for checking the intervals at which the CAN-bus messages were sent, determining how many different types of messages there are, watching how the bus wake-up happens and what happens when a remote Climate Control command is sent from the Nissan servers. I realize there are other ways of capturing CAN-bus messages, but I've run into other needs for a storage oscilloscope lately so having all this capability in one device that can be powered from a USB port is great.
 
Hi Mitchell - I am at the beginning of exactly the project you describe here (though admittedly hadn't thought of the remote display). I have the Carloop/Photon and have started playing with it (actually, didn't know about the Photon and have been derailed a bit as I played more with it). I also have an OpenEVSE installed on my garage wall, waiting on further control :). My longer term plan is to replace the Photon with an Electron so I can monitor charge state at work where we have free charging but no WiFi (in the parking lot).

In the meantime, it would help me greatly to see example code, showing how you're retrieving charge state/etc vi the Photon. Is there any chance you could post a .zip file or have a github repository somewhere? My apologies if I missed this somewhere - its very exciting to see such a similar project pop up very recently :)

Thanks in advance!
Jeff
 
Very nice work! Might look a lot closer at this once I have access to my '15 SV (hoping for delivery this week).

With your system would it be possible to add smarts for when to kick-off the charge?

I'd like a system that allows me to keep the car plugged in at home but only kick off charging once I hit 30% SoC and then only charge to 70%. That way I could always leave the car plugged in and know that I have enough range for the next day.

/Robert
 
Can you share the code? I want to implement easy climate control via bluetooth OBDII dongle using android app.
 
I have posted the Particle code here. Everything is in that one file.

The code works, but it has not been reliable. It may be that I need to handle the Wi-Fi with more error-checking and retries, or I need to do more error-checking on the Leaf data received after the vehicle starts.

Some of the code is specific to the Wi-Fi remote LCD display, and some is specific to the OpenEVSE, to which I send a Wi-Fi command to stop charging, so these may not be helpful to others. There is also much debugging code in there, some turned off by commenting-out calls from the main loop (the last routine in the file), or by #if statements, also as shown in that main loop.

I have not been able to get back into this project for many months, so I won't remember anything about it and cannot answer questions.
 
Thank you for sharing your project, i find the touchscreen TFT display very interesting!
 
Thank you for the details on your project.

Can you tell me what happens when you send 0x68c message over CAR Can?
Any chance that you have a log of messages that are send over the CAN bus when you wake it up?
I am trying to get details about charging (battery temperature, cell voltage, etc.) while the car is charging, however the bus wakes up only for about 2 seconds and all my messages sent (0x79B) are left without any response. Hence no additional data.
 
This is a fascinating older thread.

Does anyone know if you can use obd2 to set the charge timer to stop the charging at 80? The OP found car-bus had what he needed, but maybe this is a function on ev-bus. It could solve the 80% problem for most people by pushing out the charge timer and then if it expires, pushing it out again.
 
To the OP, I have to bought a particle photon and carloop. Would you mind sharing the source you have dev'd so far so that this useful functionality can be shared more widely. Maybe setup a git hub repo online?

Thanks for sharing your success and progress.

kind regards Andy
from the UK

I have 3kw solar, two first gen leafs and am trying to make Time of day charging soak up as much of it as possible.
One has a muxsan extender battery (first UK car installed with it)
 
Back
Top