40kWh 2018+ Nissan LEAF support?

[glynhudson]

I was under the impresssion that the 2018 40kWh Leaf is currently not suported by OVMS since the OBD port in the 2018 LEAF is now behind a gateway, so it no longer hears any passive CAN traffic requires active polling to obtain metrics, see: http://lists.openvehicles.com/pipermail/ovmsdev/2019-September/006340.html

e.g here is a test modification to enable active polling to test obtaining data from the 40kWh LEAF: https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/commit/66906c0eee858208e729608ed6adcc7a03343f0e).

I tested OVMS myself with a 40kWh leaf in October 2019 running edge build and confirmed support was not available. Since then I've not seen any commits to suggest that support for active polling has been added.

However, issues and PR's by @dalathegreat suggest the 40kWh Nissan LEAF is working with ovms .eg #312 , https://github.com/openvehicles/Open-Vehicle-Android/pull/97

What is the current status of the 40kWh leaf? It would be really great if support has been added. If so, what metrics are currently supported?

[dalathegreat]

I only confirmed that the 40kWh battery was working, the rest of the car I test on is a 2015 "24kWh" model.

The active polling branch looks good, we should continue with this. I don't have access to any ZE1 40/62kWh Leaf, so I cannot help much.

[glynhudson]

Interesting, so you connect OVMS directly to a 40kwh battery?

Since the 40kWh LEAF is still not supported via the ODB2 port. I reckon we should hide the images from the Android app, it's caused some confusion since some users now think the 40kWh leaf is supported since the images of the car are shown in the app.

I have accesss to a 40kWh leaf so can help with testing if required. With the help of Robin O'Leary I ran the active polling branch linked above I managed to capture canbus data in a 40kWh leaf. The firmware and pre-compiled active-polling FW is attached below.

driving.crtd
- 76% Soc - 63%

rapid-charge.crtd
- 63% soC - 75%
- 41kW start

driving2.crtd
- 75% - 75% Soc
- 1.5 miles

7kw-ac-chargin.crtd
- 75% -76% soc
- car on
- heating on

CAN-log.crtd.zip

ovms3-activepolling-firmware.zip

[dalathegreat]

Great progress!

Yes, OVMS reads the 40kWh data directly, but my testing data is not so good for the masses, since I first pass the CAN data thru a Muxsan CAN-bridge, so that the car will accept the battery. So think of it like a truncated version. I drop 0x633 0x1C2 0x5EB completely, these messages never leave the battery. I also re-format many messages so they fit the older gen Leaf.

I don't think we need to hide the images in the Android app. Anyone installing an OVMSv3 system should read the support page, and find out which features are currently applicable to their vehicle. By having the images ready we are also getting techies interested in improving OVMS for the ZE1 40/62kWh Leaf.

[sharph]

I own a 62kWh 2019 Leaf, and just bought OVMS HW knowing full well that getting it to work may very well be an adventure. Though -- I was surprised to see no CAN traffic when I enabled logging on the monitor, which I guess the "gateway" on the OBD port explains.

I'm going to give the posted firmware a try tonight. I'm happy to test and do what I can to further development.

[dalathegreat]

Thank you for taking the step @sharph ! There are two ways to get OVMS working on the 2018+ Leaf.

1. Is to extend the EV-CAN wiring to reach the OBD2 port. This can be done with two wires, ran from the LH-side footwell, up to the OBD2 port. This will make the OBD2 port work like on the old LEAF. Oh, and a section of CAR-CAN is also needed to really get everything. After this starting of remote heating should also work.
2. We need to step up as OVMS devs, and implement all the data monitoring via polling the canbus available on the OBD2 port.

[BojanG72]

Hi I have a 2019 Nissan Leaf ZE1 and I am trying to read the SoC using the polling method. I have been able to get a successful response from the car, but I am not exactly sure which bytes are supposed to represent the state of charge.

According to everything I have read online it supposed to be bytes 5-7 on the fifth line of the response. But the numbers I am reading does not match what is shown on the vehicle dash.

So my question is, am I reading the correct bytes? and if not do you know if it changed in the 2019 Nissan Leaf?

Here are the CAN msgs I am reading from my car

(1601485858.880592) can0 79B#0221010000000000 (1601485858.885052) can0 7BB#10356101FFFFFC18 (1601485859.063325) can0 79B#3000000000000000 (1601485859.065120) can0 7BB#210288FFFFFB79FF (1601485859.079208) can0 7BB#22FFF0601B584650 (1601485859.085033) can0 7BB#23904E3287038600 (1601485859.098547) can0 7BB#24017000270F000A (1601485859.105193) can0 7BB#257FA70019F07E80 (1601485859.120629) can0 7BB#260001FFFFFB79FF (1601485859.125149) can0 7BB#27FFFC9201AEFFFF

The dash on the car shows state of charge is at 65%.

Thanks

[dalathegreat]

@BojanG72 I would so want a ZE1 to experiment with! Maybe it is in this location?

(1601485859.065120) can0 7BB#210288FFFFFB79FF = 64,8% or (1601485859.085033) can0 7BB#23904E3287038600 = 64,7%

SOC is usually 10bits long, so can be hard to spot from raw hex. Maybe post another point at some other SOC?

[BojanG72]

I'll try and collect some more data over the next few days.

Possibly, right now I'm leaning towards this one (1601485859.098547) can0 7BB#24017000270F000A = 655,294,474

[caederus-ovms]

On Thu, Oct 01, 2020 at 06:16:43AM -0700, BojanG72 wrote:

Hi I have a 2019 Nissan Leaf ZE1 and I am trying to read the SoC using the polling method. I have been able to get a successful response from the car, but I am not exactly sure which bytes are supposed to represent the state of charge.

According to everything I have read online it supposed to be bytes 5-7 on the fifth line of the response. But the numbers I am reading does not match what is shown on the vehicle dash.

I suspect you are looking at findings for the older models, which respond to query 0x79b, 0x21, 0x01 with a 39-byte reply. The new models respond with a 51-byte reply.

So my question is, am I reading the correct bytes? and if not do you know if it changed in the 2019 Nissan Leaf? The longer reply seems to mostly have the same values in the same order as before, but at least one of them has got more bits, meaning that some offsets are different.

Here are the CAN msgs I am reading from my car

(1601485858.880592) can0 79B#0221010000000000 (1601485858.885052) can0 7BB#10356101FFFFFC18 (1601485859.063325) can0 79B#3000000000000000 (1601485859.065120) can0 7BB#210288FFFFFB79FF (1601485859.079208) can0 7BB#22FFF0601B584650 (1601485859.085033) can0 7BB#23904E3287038600 (1601485859.098547) can0 7BB#24017000270F000A (1601485859.105193) can0 7BB#257FA70019F07E80 (1601485859.120629) can0 7BB#260001FFFFFB79FF (1601485859.125149) can0 7BB#27FFFC9201AEFFFF

I believe that the SOC is at byte offset 30 to 33 of the reassembled frame (the last 2 bytes of reply sequence 4 and the first 2 bytes of reply sequence 5). i.e. 000A 7FA7 in your log.

The dash on the car shows state of charge is at 65%. 0x000a7fa7 = 688039 or 68.8039%, which is plausible, as there is often a discrepancy between the various internal SOC-like values and what is displayed on the dash.

Some time ago, I added some extra polls to OVMS, which Glyn Hudson used to get some logs from a 40kWh LEAF driving and charging. Those logs also confirm that bytes 30..33 are SOC. That (rather stale) code is here: https://github.com/caederus-ovms/Open-Vehicle-Monitoring-System-3/tree/active Although the poll to 0x743, 0x763 didn't work, the others did, which gives us most of the useful metrics (lots of battery stats, various temperatures, speed, type pressures, door status).

I am happy to help move this forwards; perhaps the OVMS Developers list ovmsdev@lists.openvehicles.com would be a better place for discussion?

[BojanG72]

Thanks everyone, I found the SOC and range using 743 commands instead of 79B.

I ran 2 tests just to be sure, during the first test the range was 221km and the SoC was 58%. During the second test range was 218km and the SoC was 57%.

Range = 221 SOC = 58%

(1601653726.937543) can0 743#03220E2E00000000 (1601653726.953204) can0 763#05620E2E00DDFFFF ------> Range

(1601653731.489510) can0 743#03220E2D00000000 (1601653731.503573) can0 763#1016620E2D052412 (1601653731.505970) can0 743#3000000000000000 (1601653731.513103) can0 763#210A646400000000 (1601653731.533383) can0 763#22000000003A0000 ----> SOC (1601653731.553206) can0 763#230000FFFFFFFFFF

Range = 218 SOC = 57%

(1601655704.066370) can0 743#03220E2E00000000 (1601655704.079444) can0 763#05620E2E00DAFFFF -----> Range

(1601655720.519401) can0 743#03220E2D00000000 (1601655720.540148) can0 763#1016620E2D052412 (1601655720.543408) can0 743#3000000000000000 (1601655720.547998) can0 763#210A646400000000 (1601655720.568381) can0 763#2200000000390000 -----> SOC (1601655720.588017) can0 763#230000FFFFFFFFFF

Additionally I collected data using the 79B command, but I didn't see and obvious candidates for SoC. I'll post the previous data and the new data if anyone wants to take a crack at it.

--New Data-- Range = 221 km SOC = 58%

(1601654256.913278) can0 79B#0221010000000000 (1601654256.923555) can0 7BB#10356101FFFFFE8A (1601654257.703975) can0 79B#3000000000000000 (1601654257.705940) can0 7BB#210288FFFFFD52FF (1601654257.713860) can0 7BB#22FFF7371B584650 (1601654257.725930) can0 7BB#238D4A3299038600 (1601654257.738364) can0 7BB#2401700026F70009 (1601654257.746220) can0 7BB#25870B0019F07E80 (1601654257.753787) can0 7BB#260005FFFFFD52FF (1601654257.766060) can0 7BB#27FFFE6601AEFFFF

---Previous Data---- SoC = 65%

(1601485858.880592) can0 79B#0221010000000000 (1601485858.885052) can0 7BB#10356101FFFFFC18 (1601485859.063325) can0 79B#3000000000000000 (1601485859.065120) can0 7BB#210288FFFFFB79FF (1601485859.079208) can0 7BB#22FFF0601B584650 (1601485859.085033) can0 7BB#23904E3287038600 (1601485859.098547) can0 7BB#24017000270F000A (1601485859.105193) can0 7BB#257FA70019F07E80 (1601485859.120629) can0 7BB#260001FFFFFB79FF (1601485859.125149) can0 7BB#27FFFC9201AEFFFF

[caederus-ovms]

On Fri, Oct 02, 2020 at 11:00:59AM -0700, BojanG72 wrote:

Thanks everyone, I found the SOC and range using 743 commands instead of 79B. 0x743/0x763 is the instrument cluster (0x79b/0x7bb is HV battery).

I ran 2 tests just to be sure, during the first test the range was 221km and the SoC was 58%. During the second test range was 218km and the SoC was 57%.

Range = 221 SOC = 58%

(1601653726.937543) can0 743#03220E2E00000000 (1601653726.953204) can0 763#05620E2E00DDFFFF ------> Range ...

In my brief test, I only got responses to UDS queries 0x743 0x22.0e00 and 0x22.0e01---which I have not decoded, as I only ever saw constant values (0 and 0x7ce respectively). I did not explore any higher data IDs. Did you get responses on any other IDs? Although they are obviously in a different format, it may be that we can find some similarities to the older meter, which responds to UDS query 0x743 0x21.01 with 128 bytes containing a lot of useful information including speed, odometer, warnings, doors, lights, drive, motor, cruise control, battery state, temperature, economy, charge times, range (with and without climate control).

Additionally I collected data using the 79B command, but I didn't see and obvious candidates for SoC. I'll post the previous data and the new data if anyone wants to take a crack at it.

I think HVBATT only reports its own idea of SOC, which is different from the slightly more convervative value shown on the instrument cluster, but may be more useful for some purposes, as it is higher resolution.

--New Data-- Range = 221 km SOC = 58%

(1601654256.913278) can0 79B#0221010000000000 (1601654256.923555) can0 7BB#10356101FFFFFE8A (1601654257.703975) can0 79B#3000000000000000 (1601654257.705940) can0 7BB#210288FFFFFD52FF (1601654257.713860) can0 7BB#22FFF7371B584650 (1601654257.725930) can0 7BB#238D4A3299038600 (1601654257.738364) can0 7BB#2401700026F70009 (1601654257.746220) can0 7BB#25870B0019F07E80 (1601654257.753787) can0 7BB#260005FFFFFD52FF (1601654257.766060) can0 7BB#27FFFE6601AEFFFF

My decoding of this log gives:

Fri 2020-10-02 16:57:37.766 .B376:32 0xfffffe8a LEAF40HVBATT_R01.CURRENT1_32b -0.365234A Fri 2020-10-02 16:57:37.766 .B360:16 0x288 LEAF40HVBATT_R01.B360 648 Fri 2020-10-02 16:57:37.766 .B328:32 0xfffffd52 LEAF40HVBATT_R01.CURRENT2_32b -0.669922A Fri 2020-10-02 16:57:37.766 .B296:32 0xfffff737 LEAF40HVBATT_R01.B296 -2249 Fri 2020-10-02 16:57:37.766 .B280:16 0x1b58 LEAF40HVBATT_R01.BAT_UNK2 280 Fri 2020-10-02 16:57:37.766 .B264:16 0x4650 LEAF40HVBATT_R01.MOTOR_MAX_POWER 180kW Fri 2020-10-02 16:57:37.766 .B248:16 0x8d4a LEAF40HVBATT_R01.VOLTAGE1 361.7V Fri 2020-10-02 16:57:37.766 .B232:16 0x3299 LEAF40HVBATT_R01.LVBAT_VOLT 12.953V Fri 2020-10-02 16:57:37.766 .B216:10 0x386 LEAF40HVBATT_R01.INSULATION 902 Fri 2020-10-02 16:57:37.766 .B184:32 0x17000 LEAF40HVBATT_R01.B184 94.208 Fri 2020-10-02 16:57:37.766 .B168:16 0x26f7 LEAF40HVBATT_R01.HX1 99.75% Fri 2020-10-02 16:57:37.766 .B136:32 0x9870b LEAF40HVBATT_R01.SOC_32b 62.4395% Fri 2020-10-02 16:57:37.766 .B104:32 0x19f07e LEAF40HVBATT_R01.HX2_32b 169.997A·hour Fri 2020-10-02 16:57:37.766 .B88:16 0x8000 LEAF40HVBATT_R01.CHARGE_CURRENT UNDEF Fri 2020-10-02 16:57:37.766 .B82:1 0x1 LEAF40HVBATT_R01.FLASH on Fri 2020-10-02 16:57:37.766 .B80:1 0x1 LEAF40HVBATT_R01.MODE on Fri 2020-10-02 16:57:37.766 .B48:32 0xfffffd52 LEAF40HVBATT_R01.B48 -686 Fri 2020-10-02 16:57:37.766 .B16:32 0xfffffe66 LEAF40HVBATT_R01.B16 -410 Fri 2020-10-02 16:57:37.766 .B0:16 0x1ae LEAF40HVBATT_R01.B0 430

SoC = 65%

(1601485858.880592) can0 79B#0221010000000000 (1601485858.885052) can0 7BB#10356101FFFFFC18 (1601485859.063325) can0 79B#3000000000000000 (1601485859.065120) can0 7BB#210288FFFFFB79FF (1601485859.079208) can0 7BB#22FFF0601B584650 (1601485859.085033) can0 7BB#23904E3287038600 (1601485859.098547) can0 7BB#24017000270F000A (1601485859.105193) can0 7BB#257FA70019F07E80 (1601485859.120629) can0 7BB#260001FFFFFB79FF (1601485859.125149) can0 7BB#27FFFC9201AEFFFF

Wed 2020-09-30 18:10:59.125 .B376:32 0xfffffc18 LEAF40HVBATT_R01.CURRENT1_32b -0.976562A Wed 2020-09-30 18:10:59.125 .B360:16 0x288 LEAF40HVBATT_R01.B360 648 Wed 2020-09-30 18:10:59.125 .B328:32 0xfffffb79 LEAF40HVBATT_R01.CURRENT2_32b -1.13184A Wed 2020-09-30 18:10:59.125 .B296:32 0xfffff060 LEAF40HVBATT_R01.B296 -4000 Wed 2020-09-30 18:10:59.125 .B280:16 0x1b58 LEAF40HVBATT_R01.BAT_UNK2 280 Wed 2020-09-30 18:10:59.125 .B264:16 0x4650 LEAF40HVBATT_R01.MOTOR_MAX_POWER 180kW Wed 2020-09-30 18:10:59.125 .B248:16 0x904e LEAF40HVBATT_R01.VOLTAGE1 369.42V Wed 2020-09-30 18:10:59.125 .B232:16 0x3287 LEAF40HVBATT_R01.LVBAT_VOLT 12.935V Wed 2020-09-30 18:10:59.125 .B216:10 0x386 LEAF40HVBATT_R01.INSULATION 902 Wed 2020-09-30 18:10:59.125 .B184:32 0x17000 LEAF40HVBATT_R01.B184 94.208 Wed 2020-09-30 18:10:59.125 .B168:16 0x270f LEAF40HVBATT_R01.HX1 99.99% Wed 2020-09-30 18:10:59.125 .B136:32 0xa7fa7 LEAF40HVBATT_R01.SOC_32b 68.8039% Wed 2020-09-30 18:10:59.125 .B104:32 0x19f07e LEAF40HVBATT_R01.HX2_32b 169.997A·hour Wed 2020-09-30 18:10:59.125 .B88:16 0x8000 LEAF40HVBATT_R01.CHARGE_CURRENT UNDEF Wed 2020-09-30 18:10:59.125 .B82:1 0 LEAF40HVBATT_R01.FLASH off Wed 2020-09-30 18:10:59.125 .B80:1 0x1 LEAF40HVBATT_R01.MODE on Wed 2020-09-30 18:10:59.125 .B48:32 0xfffffb79 LEAF40HVBATT_R01.B48 -1159 Wed 2020-09-30 18:10:59.125 .B16:32 0xfffffc92 LEAF40HVBATT_R01.B16 -878 Wed 2020-09-30 18:10:59.125 .B0:16 0x1ae LEAF40HVBATT_R01.B0 430

This decoding assumes that most things are the same as in the older model, and we have no guarantee that they do---but things do seem to match up pretty well, with only a few exceptions: .B296:32 has value -4000 (old model always 0) .B184:32 looks like it might be a 32-bit value, where the old model had a 16-bit value. Dividing the new value by 1000 puts it in the same range as the old value (more samples would be useful). .B48:32, .B16:32, .B0:16 don't appear in the older model; I don't know what they represent.

Note: .Bx:y means a value of length y bits, starting with least-significant bit x of the reassembled ISO-TP frame. In this case, the ISO-TP frame is 53 bytes long; the first two bytes are the UDS service 0x21 ("Read data by ID") and ID 0x01, leaving 51 UDS data bytes. The least-significant bit of the last UDS data byte (ISO-TP[52] or UDS[50]) is .B0, and the most significant bit of the first UDS data byte (ISO-TP[2] or UDS[0]) is .B407.

[gorghino]

Hi @caederus-ovms , do you know LEAF40HVBATT_R01 variables' meaning as well? Maybe @dalathegreat , you know where @caederus-ovms got those?

[gorghino]

Hi all, I uploaded a PDF with all the active queries I've found so far for 2018+ Leaf here on mynissanleaf with some open challenges I'm facing. I hope this may help you.

[glynhudson]

Has anyone had any success with OVMS 2018+ 40kWh/62KWh LEAF support?

[aidehuazi]

I have a 2020 ZE1 and I’ve started having a go at getting ZE1 active poling working and can see active poling has been introduced to the main branch a while back so is in the latest versions of the code. I will try work out how to switch it on as logs don’t show any of the active poling codes. Using the posted activepolling firmware above, I can see the transmitted 79B but don’t see any received messages, no 7BB or any other Recieved for that matter. I tried logging leaf spy and it sends 79B and gets 7BB responses on can2, so I don’t think it’s a problem with the can bus or my OVMS connection. Is there a parameter I’m missing? Any hints to get me started would be greatly appreciated.
Here’s my log using the above posted firmware.

1638401544.945804 1CXX Info Type:vfs Format:crtd(discard) Filter:off Vehicle:NL Path:/sd/can.crtd 1638401544.946772 CXX OVMS CRTD 1638401563.384139 2T11 79B 02 21 02 00 00 00 00 00 1638401565.379302 2T11 745 02 21 09 00 00 00 00 00 1638401579.379566 2T11 79B 02 21 01 00 00 00 00 00 1638401581.379515 2T11 743 02 21 01 00 00 00 00 00 1638401589.379549 2T11 79B 02 21 04 00 00 00 00 00 1638401603.379637 2T11 744 02 21 10 00 00 00 00 00 1638401607.379629 2T11 758 02 21 10 00 00 00 00 00 1638401622.379436 2T11 743 02 21 01 00 00 00 00 00 1638401638.379506 2T11 79B 02 21 02 00 00 00 00 00 1638401644.379483 2T11 745 02 21 09 00 00 00 00 00 1638401648.379551 2T11 79B 02 21 01 00 00 00 00 00

[gorghino]

Anybody knows where

743 02 21 01 00 00 00 00 00 758 02 21 10 00 00 00 00 00

come from? What are they? I can't find any references in the OVMS files.

[glynhudson]

Have you had look at @dalathegreat https://github.com/dalathegreat/leaf_can_bus_messages

On Mon, 13 Dec 2021 at 17:27, Davide Aguiari @.***> wrote:

Anybody knows where

743 02 21 01 00 00 00 00 00 758 02 21 10 00 00 00 00 00

come from? What are they? I can't find any references in the OVMS files.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/323#issuecomment-992704003, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFZIPA66I6UCM2VROZKGITUQYUG7ANCNFSM4KHXO7BA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Glyn Hudson

https://openenergymonitor.org http://zerocarbonadventures.co.uk

[gorghino]

Hi @glynhudson , yes I know Dala and his work! Unfortunately his files are not useful when you do active polling. I use active polling for my OBD project but among the queries @aidehuazi posted, I don't know two of them.

758 doesn't seem to be any known ECU's ID. I use 743 to get range and Tires pressure, but payload is different from 02 21 01.

[dalathegreat]

For anyone wanting to continue the development, I have updated the section about Active Polling on github: https://github.com/dalathegreat/leaf_can_bus_messages#what-about-active-can-polling

Here is also a link to all the metrics that Leafspy polls for: https://drive.google.com/file/d/1jH9cgm5v23qnqVnmZN3p4TvdaokWKPjM/view

[alibahba]

There are two ways to get OVMS working on the 2018+ Leaf.

1. Is to extend the EV-CAN wiring to reach the OBD2 port. This can be done with two wires, ran from the LH-side footwell, up to the OBD2 port. This will make the OBD2 port work like on the old LEAF. Oh, and a section of CAR-CAN is also needed to really get everything. After this starting of remote heating should also work.

@dalathegreat For me, this would be a good solution. Are there any schematics available for this mod?

[aidehuazi]

I’ve managed to get most of the ZE1 polling to metrics code solved, just need to resolve : Cabin Temp, can’t find a TXID / PID Speed, nearly there might have the wrong metric ms_v_pos_speed or timing might need to be adjusted TPMS all 4 measures are 0 in 79A OE 25-28, so not sure if thats just my vehicle, would be good if someone with TPMS working in car or Leaf spy can check this. Plug state is flakey at best, along with charging, the slide to charge appears randomly. Haven’t started on things like doors as no poling codes available. If anyone has any more detail on the above issues or codes, would be very welcome, I can implement and we can pull request an update, although someone may want to review my code due to my lack of cpp skills. I’ll post the firmware for others to test and review? Here’s where it’s at.

[mjkapkan]

We lived a long time with no cabintemp for the previous model. So it will work perfectly without it as well. Anyway great job in getting this stuff!

[alibahba]

I've dont think polling is the right way to go.

''The official documentation even says the car should not be operated or charged during a CONSULT session, which is the only moment debug messages are requested. This is also one of the reasons there are extremely rare instances of the car getting into a fault state when driving with Leaf Spy." https://www.mynissanleaf.com/viewtopic.php?f=44&t=4131&start=640#p601398 (Thanks to MUX)

We can just get directly on the ev-can bus and just listen, but that requires bypassing the OBD port. Is there anyone who has done that yet?

[aidehuazi]

Ok think I have a useful version of the firmware for ZE1's , mostly due previous work done on the polling elements of the code already in the current master, so thanks to those who put in all that hard work.

I've spent a bit of time trying to sort out a way to have polling switched on when the car turns on and off when it's off, but haven't managed to nail that yet, but will continue to work on it as it's about saving the acc battery when the car is idle. I still believe polling is the only way to make this palatable for the ZE1 and as many vehicles are or will soon be going down this route of can gateways, polling is the future. I've tested this version in the 2011 and made sure polling is off for any pre 2019 model ZE1 Leaf.

On a side note, I've noticed that the 3.3 build has something going on with excessive can messages on can1 and can2 in my 2011 at least, which is not present in the ZE1, for obvious reasons. In the 3.3 Firmware theres also vehicle.charge.pilot.off and vehicle.charge.pilot.on executing multiple times a second in the ZE0 Leaf. This can be seen on the OVMS's Web server, on the Status Page-Live Events section. This issue is also be in the branch that has the 2011-2012 Climate control fix and likely in 3.3 branches before that. So for that reason I wouldn't suggest running this firmware OR any 3.3 fw build on a ZE0 or AZE0 yet, other than to test it to see if you see the same issues as I've seen. Note you won't notice these messages or excessive can bus traffic if you don't turn on can or OVMS logging or check out the status or shell web page. It operates fine and the App behaves as per normal, no polling, all passive can analysis.

Anyhoo, anyone here who's interested, please try this firmware on a ZE1 and let me know what you think. I'll talk to the OVMS and Leaf guys and work out where to next, unless someone here can advise? Might be worth getting some of the other features like remote climate and locking working before any of this gets pulled into he master.

Note for this to work I have the following xnl config from my ZE1 e+: canwrite: yes maxGids: 775
modelyear: 2020 newCarAh: 176 soc.newcar: no soh.newcar: true < required as existing code to populate the range on the App is used. ovms3.bin.zip

[glynhudson]

Nice work guys! This is very exciting, I reckon if you have the basic metrics working e.g SoC and charging status we should get this released in beta, so users can help to test. Also, even having basic metrics is very useful. IMO door status is very low of the list of useful features!

[christian-nolte]

Hi @aidehuazi and all the others, thanks for your great work to make the 2018+ Nissan Leaf working with OVMS. I downloaded the firmware 3.3.001-104-gcbdc6f05-dirty form the comment above, but it didn't run with my Nissan Leaf 40kwh MY21. I can see the 12V Battery, but not more. Could you give me some hints or what I have to configure, sry, I'm an absolute newbie with OVMS, CAN and OBDII.

[aidehuazi]

Have you checked your setting either on the gui or in the shell? You need the following which can be obtained from the shell under tools or via ssh :

Each entry can be set using the following format:

config set xnl soc.newcar true

And a listing can be obtained by

config list xnl

canwrite: yes maxGids: 500 modelyear: 2021 newCarAh: 112.6 soc.newcar: no soh.newcar: true Or in the gui menu Nissan Leaf - Features

Via the gui is easier if you're not used to shell commands. ?Just Set and save

[aidehuazi]

I recently provided a later build for another ZE1 user with a few things cleaned up, which might help. I still haven't got round to creating a seperate branch, so have provided it here, both bin and code. Let me know if the config or this firmware changes things, otherwise I can provide a build with a bit of debug to work out what is going on.

[christian-nolte]

Thanks for your support, I changed the maxGids from 502 to 500 and the newCarAh from 115 to 112.6, the other parameters was similar to yours. It didn't work, so I tried your newer firmware, but it doesn't work, too. But there are some errors in the shell.

I (9043) netmanager: WIFI client has good signal quality (-85.3 dBm); connect I (9043) netmanager: Interface priority is st1 (192.168.1.13/255.255.255.0 gateway 192.168.1.254) I (9043) netmanager: Set DNS#1 0.0.0.0 I (9043) netmanager: Set DNS#2 0.0.0.0 I (9043) netmanager: WIFI client up (with MODEM down): starting network with WIFI client I (9053) time: Starting SNTP client I (9053) ovms-server-v2: Status: Network is up, so attempt network connection I (11043) ovms-server-v2: Connection is ovms.dexters-web.de:6870 Toni I (11043) ovms-server-v2: Status: Connecting... I (12043) v-nissanleaf: vehicle.charge.pilot.off: using ms_v_door_chargeport false 1 I (13813) webserver: HTTP POST /cfg/firmware I (13823) webserver: HandleLogin: 'admin' logged in, sid af0f06f4db29aa9e I (13863) webserver: HTTP GET /menu I (13933) ovms-server-v2: Connection successful I (13933) ovms-server-v2: Status: Logging in... I (13933) ovms-server-v2: Sending server login: MP-C 0 Toni I (13943) webserver: HTTP GET /cfg/firmware I (14423) ovms-server-v2: Got server response: MP-S 0 * ** I (14423) ovms-server-v2: Server token is * and digest is ** I (14433) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (14433) ovms-server-v2: Shared secret key is ***** (44 bytes) I (14433) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (14463) ovms-server-v2: Incoming Msg: MP-0 Z0 I (15043) ovms-server-v2: Send MP-0 S0,K,0,0.00,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,284,0,0.00,0.00,0,0.00,100.00,0.00,0.0 I (15043) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,715257,0,0,1,1,14.68,0,12.7,16,0,0,0 I (15043) ovms-server-v2: Send MP-0 L0,0,0,0,0,0,0,0,0,0,0,0,0,100,,0,0,0 I (15053) ovms-server-v2: Send MP-0 Y4,FL,FR,RL,RR,0,-1,0,-1,0,-1,0,-1 I (15053) ovms-server-v2: Send MP-0 W0,0,0,0,0,0,0,0,-1 I (15053) ovms-server-v2: Send MP-0 F3.3.001-116-gf80b3878-dirty/ota_0/main (build idf v3.3.4-848-g1ff5e24b1 Jan 30 2022 11:59:39),,19,0,NL,Landhaus,-1,-1,OVMS WIFI BLE BT cores=2 rev=ESP32/3 I (18043) cellular: State: Enter PoweredOff state I (22043) v-nissanleaf: vehicle.charge.pilot.off: using ms_v_door_chargeport false 1 I (32043) v-nissanleaf: vehicle.charge.pilot.off: using ms_v_door_chargeport false 1 I (35813) webserver: HTTP GET /status I (42043) v-nissanleaf: vehicle.charge.pilot.off: using ms_v_door_chargeport false 1 I (52043) v-nissanleaf: vehicle.charge.pilot.off: using ms_v_door_chargeport false 1 I (55773) webserver: HTTP GET /shell I (62043) v-nissanleaf: vehicle.charge.pilot.off: using ms_v_door_chargeport false 1 I (72043) v-nissanleaf: vehicle.charge.pilot.off: using ms_v_door_chargeport false 1 E (81913) can: can2: intr=2 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=27 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=10 txfail=0 wdgreset=0 errreset=0 W (81913) mcp2515: can2 EFLG: RX_Err_Passv RX_Err_Warn EWARN E (81913) can: can2: intr=3 rxpkt=0 txpkt=0 errflags=0xa00b10a0 rxerr=135 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=10 txfail=0 wdgreset=0 errreset=0 E (81913) can: can2: intr=4 rxpkt=0 txpkt=0 errflags=0x800b1080 rxerr=135 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=10 txfail=0 wdgreset=0 errreset=0 I (82053) v-nissanleaf: vehicle.charge.pilot.off: using ms_v_door_chargeport false 1 E (85053) can: can2: intr=31174 rxpkt=0 txpkt=0 errflags=0x800b1080 rxerr=135 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=11 txfail=0 wdgreset=0 errreset=0 I (92043) v-nissanleaf: vehicle.charge.pilot.off: using ms_v_door_chargeport false 1

[aidehuazi]

Looks like there is nothing received on the can bus. What cable are you using? Is it plugged into the odb2 port. Try removing and re seating both ends of the cable, if you haven’t already done so. Have you ever used the odbii port for leafspy or any other diagnostics?

[christian-nolte]

So I checked the cable and changed the way it was connected. This changes nothing. But then I start the car to drive and now the values are there and the OVMS has all the necessary data. I don't know if reconnecting the cable, the parameter changes, or the new firmware was the game changer. Many thanks for the support.

But currently the OVMS does not recognize when I charge the vehicle and therefore does not update the values during the charging process. In the shell I can see that OVMS gets the event to start charging the 12v battery and stop charging the 12v battery. But nothing about the main battery. Is there a firmware issue with the OVMS while loading 2018+ Nissan Leaf?

[aidehuazi]

I’m not sure what you mean by loading? Maybe you mean charging? I haven’t worked out the charging side yet, what you see is what is available so far.

[christian-nolte]

Yes, I mean charging, sry for my bad english.

Ok, maybe it's possible in an easy way to start/stop polling the can bus with the start/stop 12v battery charging event.

I would support you, but I have only experience in Java.

[cods4]

It sounds like this is getting close to release. Is that accurate?

I have just bought a 2017 JDM 40kWh leaf and I want to interface the car with Home Assistant.

I see talk about connecting directly into the CAN-BUS by wiring it back to the OBD2 connector, is this still an option, or will it require further development of OVMS to make it work as the registers are all different to the older cars?

I would have no issues with doing the wiring if it gave me full functionality, I have some shielded twisted pair cable which would be suitable. The only challenge would be finding somewhere to tap in that is 300mm from the OBD2 connector, or else finding the end of the bus and extending that to reach the OBD2 connector and moving the terminating resistor if there is one.

[aidehuazi]

Yes it’s close to release but I’m struggling to find time at the moment to add the rest of the functionality. I wouldn’t be surprised if you follow some of the guides for the ze0 to locate the EV Can bus (try Dala’s Video on installing the canbridge) , you’ll find it’s still there in the ZE1 . Tapping into that should give you most of the battery functionality in the current master release. I’d give it a crack to confirm, but just haven’t had time. Will let you know if I do happen to try it.

[cods4]

Yes it’s close to release but I’m struggling to find time at the moment to add the rest of the functionality. I wouldn’t be surprised if you follow some of the guides for the ze0 to locate the EV Can bus (try Dala’s Video on installing the canbridge) , you’ll find it’s still there in the ZE1 . Tapping into that should give you most of the battery functionality in the current master release. I’d give it a crack to confirm, but just haven’t had time. Will let you know if I do happen to try it.

Thanks, I will look into getting an OVMS unit.

[cods4]

Thanks, I will look into getting an OVMS unit.

Still waiting on my OVMS from Fasttech, but shouldn't be far away now.

I have done a little bit more reading, and understand there is a CAR CAN BUS and EV CAN BUS and I would want access to both of these for full functionality.

Are both of these busses behind the gateway when connecting via the OBD2 port? And therefore, do they both need to be wired directly to the OVMS unit?

I guess the EV CAN is the one that Dala taps in to for his canbridge, and I'm guessing this would be wired back to the secondary CAN pins on the OBD2 port (pins 12 & 13), or back to CAN1 on the OVMS?

And the CAR CAN should be connected to the main CAN pins on the OBD port (6 & 14), or back to CAN2 on the OVMS?

Now I'd rather not modify how the existing OBD2 port is wired, so I have 2 options, I could either duplicate the OBD2 port with the two CAN busses connected directly to their corresponding pins on the second OBD2 port, or I could make an adaptor harness with a 4 or 6 pin connector that takes the 2 can bus networks to the DB26 port on the OVMS (along with the EV SYSTEM ACTIVATION REQUEST SIGNAL from the TCU if it exists on the 40kWh model)

Have I got all this right? Or am I missing something?

And can someone point me to the wiring diagram for the leaf specific OBD2 to DB9 adaptor cable?

[dalathegreat]

It's not that simple. I just stumbled over more 2018+ LEAF info, and they use a 6channel gateway:

This will be legendary difficulty level to add those wires back, along with making the code changes required.

Better to just continue with the polling strategy.

[cods4]

Thanks for your input Dala. I'm obviously not as familiar with CAN (or these cars) as you are, but why does that mean we can't connect to the two CAN busses directly? Are you saying something like this wouldn't work?

[cods4]

Yes it’s close to release but I’m struggling to find time at the moment to add the rest of the functionality. I wouldn’t be surprised if you follow some of the guides for the ze0 to locate the EV Can bus (try Dala’s Video on installing the canbridge) , you’ll find it’s still there in the ZE1 . Tapping into that should give you most of the battery functionality in the current master release. I’d give it a crack to confirm, but just haven’t had time. Will let you know if I do happen to try it.

Thanks for all your work on this aidehuazi. I have it up and running using your code at the moment. This is giving me most of what I need.

The main issue I have noticed is that the sometimes the vehicle won't respond to lock/unlock commands from the key fob or the buttons on the doors. I have to press the button many times before it will eventually unlock or lock. I guess this could be an issue the the CAR-CAN being overloaded or getting errors.

And another issue is that none of this works when the car is off or charging. I only get updates when the car is on.

I haven't disconnected the TCU yet, does this need to be disconnected on the ZE1? And do I need to wire the EXT_12V connection to the OVMS unit as was required on the early models?

[aidehuazi]

No, that’s not required for the ZE1. The unit works by polling on the ZE1 , which is only available when the vehicle is on. I haven’t got round to doing any more on this. Hoping someone else might take an interest in finding a solution.

Sent from my iPhone

On 28 Jun 2022, at 5:39 am, cods4 @.***> wrote:

 Yes it’s close to release but I’m struggling to find time at the moment to add the rest of the functionality. I wouldn’t be surprised if you follow some of the guides for the ze0 to locate the EV Can bus (try Dala’s Video on installing the canbridge) , you’ll find it’s still there in the ZE1 . Tapping into that should give you most of the battery functionality in the current master release. I’d give it a crack to confirm, but just haven’t had time. Will let you know if I do happen to try it.

Thanks for all your work on this aidehuazi. I have it up and running using your code at the moment. This is giving me most of what I need.

The main issue I have noticed is that the sometimes the vehicle won't respond to lock/unlock commands from the key fob or the buttons on the doors. I have to press the button many times before it will eventually unlock or lock. I guess this could be an issue the the CAR-CAN being overloaded or getting errors.

And another issue is that none of this works when the car is off or charging. I only get updates when the car is on.

I haven't disconnected the TCU yet, does this need to be disconnected on the ZE1? And do I need to wire the EXT_12V connection to the OVMS unit as was required on the early models?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[cods4]

the vehicle is on. I haven’t got round to doing any more on this. Hoping someone else might take an interest in finding a solution.

I hope so too. I am an electrical engineer, but not really great with programming. I should be able to help with CAN message sniffing and testing when I have some more time though.

[cods4]

Does anyone have any idea how we might communicate with the CAN gateway when the car is off or charging?

[glynhudson]

Does anyone have any idea how we might communicate with the CAN gateway when the car is off or charging?

The modules should be awake when the car is charging. When the car is switched off there is no need to communicate, metrics will only change when the car is on or charging. In fact OVMS should not try to wakeup the car (apart from remote climate) since this will cause excessive 12V drain.

[cods4]

Does anyone have any idea how we might communicate with the CAN gateway when the car is off or charging?

The modules should be awake when the car is charging. When the car is switched off there is no need to communicate, metrics will only change when the car is on or charging. In fact OVMS should not try to wakeup the car (apart from remote climate) since this will cause excessive 12V drain.

I've just done some further testing, and my car definitely stops responding to queries a few minutes after it is turned off, whether it is Level 2 charging or not.

[cods4]

So I got OVMS working almost perfectly in my 2017 40kWh ZE1. It was just a matter of connecting directly to the two canbus networks, EV-CAN and CAR-CAN to bypass the CAN gateway.

The only issues I have are some of the temperatures are not reading correctly, including charger temp, and batt-temp. Valet mode doesn't work, and I can't turn on the A/C when the car is not plugged in (perhaps by design??).

The wiring was fairly tricky in that I had to find the CAN bus wires and carefully tap into them. But since I had all the necessary tools and most of the materials already, It was well worth it for me.

For anyone else that wants to do it, here is a brief writeup.

Parts I used.

• OBD2 female connector (Aptiv P/N 12110250)
• Metripack 150 contacts (Aptiv P/N 12129484) - I would have been better off using 12129373 which is meant for smaller wire, but these weren't available at the time.
• I used some shielded twisted 2c cable that I harvested from an old subaru wiring harness I had in the garage, these were used for the ABS senors. You don't need shielded cable, but it does need to be twisted to use it for CAN (you can make this using single core wire and twisting two lengths together by hand or using an electric drill).
• And I used some single core 20awg cable for power and ground.
• Open barrel splices (TE P/N 63130-2) I used these as I had them for another project, there are a number of ways you can do it, including soldering, but I believe soldering should only be used for circuit boards...
• Kapton tape and electrical tape to wrap up the connections. (Ideally I would have used heatshrink, but because I decided to not cut the existing wiring harness, this wasn't an option).

I used the following tools

• Sargent 3187 for crimping open barrel splices
• SG Tool Aid 18910 for crimping the metri-pack terminals
• Ideal stripmaster 45-097 wire strippers (any wire strippers will do, but I highly recommend these ones if you do a lot of automotive wiring)
• Box cutter for carefully stripping back the insulation on the factory CAN wiring so I didn't have to cut and rejoin it.

• **Firstly, make sure you disconnect the battery before hacking at your wiring, once you have the wires exposed that you think you need, reconnect the battery and confirm the voltages and polarity. (CAN wires should be around 2.5V, CAN-H will be a little bit higher voltage than CAN-L, there is only a ~2-300mV difference.

Once you have your wiring all done, and before you plug in the OVMS unit, reconnect the battery and check all the voltages at your DB9 or OBD2 connector to make sure you are not going to feed 12V to your CAN network or something like that.**

# # #

I connected to the EV-CAN at the same point that Dala uses to install his CAN bridge. In hindsight there is probably a better place to do this as we don't need to interrupt the CAN connection to the battery, we are just 'Teeing' off.

And I connected to the CAR-CAN at the BCM connector (M24) pins 21 & 22, which for my RHD car is located behind the glovebox. Note the factory wiring diagram shows that the CAN is connected to pins 39 & 40, which is incorrect, look out for the pink and blue twisted wires.

The rest of the wiring is fairly straightforward. It is just a matter of comparing the wiring diagrams for the OBD2 connector, and the OVMS to make sure you get the CAN wires connected to the right place. You want to connect EV-CAN to 'primary CAN'/'CAN1', and CAR_CAN to 'alternate CAN'/'CAN2'

You also need a 12V+ and 12V- supply, which I took from the existing OBD2 wiring harness. I just spliced into the wires behind the connector, and ran the wires from the drivers side to the passengers side. I managed to get this through a gap behind the head unit without removing the head unit.

Hopefully I have included all the diagrams you need below.

Pages from 2021 Leaf Wiring Diagram - North America.pdf

[Samuel12321]

What's the current state of this for people who don't want to modify their cars?

[cods4]

What's the current state of this for people who don't want to modify their cars?

Aidehuazi's code works well when the car is on. But for me it stops responding soon after the car is turned off. That includes when it is level 2 charging.

[Samuel12321]

Is there any plan to bring this to the beta and stable releases?

[cods4]

Is there any plan to bring this to the beta and stable releases?

Not that I know of. I think Aidehuazi has lost interest.