New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
40kWh 2018+ Nissan LEAF support? #323
Comments
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. |
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.
|
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 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. |
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. |
Thank you for taking the step @sharph ! There are two ways to get OVMS working on the 2018+ Leaf.
|
Hi I have a 2019 Nissan Leaf ZE1 and I am trying to read the SoC using the polling method. 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 The dash on the car shows state of charge is at 65%. Thanks |
@BojanG72 I would so want a ZE1 to experiment with! Maybe it is in this location? (1601485859.065120) can0 7BB#210288FFFFFB79FF = 64,8% SOC is usually 10bits long, so can be hard to spot from raw hex. Maybe post another point at some other SOC? |
I'll try and collect some more data over the next few days. Possibly, right now I'm leaning towards this one |
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?
|
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 (1601653726.937543) can0 743#03220E2E00000000 (1601653731.489510) can0 743#03220E2D00000000 Range = 218 (1601655704.066370) can0 743#03220E2E00000000 (1601655720.519401) can0 743#03220E2D00000000 Additionally I collected data using the 79B command, but I didn't see and obvious candidates for SoC. I'll post the previous data --New Data-- (1601654256.913278) can0 79B#0221010000000000 ---Previous Data---- (1601485858.880592) can0 79B#0221010000000000 |
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#05620E2E00**DD**FFFF ------> 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.
|
Hi @caederus-ovms , do you know LEAF40HVBATT_R01 variables' meaning as well? |
Hi all, |
Has anyone had any success with OVMS 2018+ 40kWh/62KWh LEAF support? |
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. 1638401544.945804 1CXX Info Type:vfs Format:crtd(discard) Filter:off Vehicle:NL Path:/sd/can.crtd |
Anybody knows where 743 02 21 01 00 00 00 00 00 come from? What are they? I can't find any references in the OVMS files. |
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
<#323 (comment)>,
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
|
Hi @glynhudson , yes I know Dala and his work! Unfortunately his files are not useful when you do active polling. 758 doesn't seem to be any known ECU's ID. |
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 |
@dalathegreat For me, this would be a good solution. Are there any schematics available for this mod? |
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! |
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?
|
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. 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? Note for this to work I have the following xnl config from my ZE1 e+: |
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! |
Hi @aidehuazi and all the others, |
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. |
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. I (9043) netmanager: WIFI client has good signal quality (-85.3 dBm); connect |
No more word on getting official support for the ZE1 leaf? |
Hi, please could someone send me can logs from ZE1 CAR CAN in charging mode (when charger wake up the car) or waked up via nissan remote command ? Thanks. |
Here is all my can logging data from last year. Sorry I don't have time at the moment to figure out how to set up the logging again. https://drive.google.com/drive/folders/1KgSCeS5VRyIokIbVBJE_g6lh-6dCZZ_1?usp=sharing |
Thank you very much. |
Hello OVMS friends, I would like to give you another Tip if anyone is interested. I have the OVMS Active Polling firmware running without the Hardware Modification. The old known Problem is that you dont get a Status if the Car is off. I will know the SOC because i load the CAR over the PV. If you send a Request via the Connect API you will receive a current status via OVMS. I have an Automation that queries the Position for my ZE1 via the Connect API every 10 minutes when I charge the car and then you also get a current SOC via OVMS. Maybe one or the other can work with it. |
Hi @1onord I would appreciate some more detail on this.... |
Hi, oh yes you are right, i dont know that. Nissan Connect seems not to be available in NZ. Without the 2 Wire Mod to the OBD Port you only got a Status if the Car is on, for me it wasn't that bad either. But of course it is nicer for energy Management if you know the SOC exactly. You can currently only achieve this via Connect, or you have to use the cable Mod, then the OVMS works like the ZE0 Leaf. |
Joining the conversation to register interest in this. Recently picked up a 2018 Japanese import 40kwh Leaf. I live in NZ and so have no Nissan Connect services. I have some development background but mostly only in UI and ASP.NET, probably not super helpful here.... Nonetheless, happy to test anything or help out in any way. I'd also be open to performing a hardware mod but would only be brave enough with some pretty clear instructions and a list of known limitations or dangers. Big fan of this project and it's potential! (Also a Home Assistant user, like others in this thread) |
Same as @WMTaylor3 here. I have a 2018 SL in Canada, and I will happily do some hardware modifications, but I would need some fool-proof step by step instructions. With pictures™ @cods4 how successful have you been with your mod? Does it make the OVMS fully compatible with the ZE1? Any limitations? If all good, would you consider building a how-to for people like me and @WMTaylor3 ? |
@1onord , to use the Connect API I'm assuming you need a recent model year Leaf (2022) that uses 4g service to connect, separately from the OVMS connection, is that right? |
@cods4 thank you for sharing the wiring info! I think I follow most of it but could you share more about how and where you connected to the ev CAN and distinguish between H and L in both ev and car CAN connections? And also specifically where you are using connectors versus tapping into an existing wire. |
@cods4 since you've had your hands on the wiring, do you think there's enough room to use something like this to tap onto the CAN wires? Brightfour Low Voltage Wire splice connectors - Pack of 12 Quick Solderless T Tap Connector 1 Pin,Rock Solid Connector for 24-20 AWG Cable for Vehicle/audio/video/Lighting and Automotive Uses https://a.co/d/7l6141t |
You absolutely can, but thisis using leaf spy and a perma mounted phone. while level 2 charging you need the do something like leave the parking lights on to keep the CANbus awake. Probably not relevant for this discussion though |
2018 40kWh leaf owner and former IoT dev working in F#, C#, C, Python, JS/TS and the Zigbee stack. Could probably pick up CAN pretty quickly and chip in a little bit to this effort. Seeing as car companies have become straight-up comic book villains, I intend not to buy a new car for as long as I can. |
Hi, Nissan leaf 2020 owner, attaching what I have found and tried to attach to connector M55 pins 28 & 29 to get to EV-CAN (I have simple SoC hardware posting data from my second car Nissan ZE0 and it works there) - but no luck so far. |
Whilst I have no real technical knowledge, leafspy software will function on the ZE1 if the car is powered on, but not while charging unless the parking lights, or hazard lights are active. There may be other triggers that also work, but not that I've found. Hope that helps |
@honzakadlec Check out cods4's post about tapping into the CANBUS behind the CAN gateway. |
aaah, I spot people are reffering to it, was not able to find it though, thank you @Jerther ! |
@honzakadlec no problem! Please do keep us posted about your project if you can, successful or not ;) |
Hi @Jerther I'm building my own EVSE so I can limit the power going to car by surplusses in PV plant. I have now the SoC data in my OpenHab and I can use it to control the EVSE output power. Thank you again for support! Jan |
@honzakadlec wow, this seems great. Could this be used by a novice like me to get OVMS working on my 2020 leaf S? If so, could you tell me how? |
I don't think this will help with the 2018+ Leaf, since you need to patch into the two can buses on the other side of the gateway from where that cable connects to the obd2 connector. I was able to make connections using clip on T-Taps on my 2020 Leaf and it works great with latest build. The taps create a little insulated spade lug that you can clip or un clip to. If needed the taps could be removed without damaging the original wire. I tapped into both ev and car can buses at the vehicle control module which is s sitting right behind the glove box on my left hand drive model. I'll share more details and pictures when I get time:
![image](https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/assets/575053/a8a263ee-734e-4636-a7cf-2bba33423427)
![image](https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/assets/575053/37c530bc-b648-479f-9718-269d46a0c6e4)
![image](https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/assets/575053/0d724a04-2052-424b-8c67-bb40ce0faf9a)
![image](https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/assets/575053/262289e0-df5d-4af6-930d-855bb59f5158)
|
@ehilfer this looks completely reasonable to do and has made me confident enough now to order a OVMS for my car. And you confirmed it works with 2020 and with the latest build. awesome. Those pictures are incredibly helpful! |
I've been using the iOS app and the following have been working well, and some changes I'd like to make in the firmware to improve metrics that show in the app:
|
Also - for power to the OVMS module I used same type of T-Taps to clip onto 12V and ground wires behind the car's ODB2 connector and ran the wires across behind the dashboard. Here's the tap connectors I used for all of the connections: https://www.amazon.com/gp/product/B0C9C54F87/ |
@ehilfer how did you find the correct wires? I can follow what wires you tapped into in the pictures, and im going to buy a multimeter for this project, but if i had a guide/diagram/another picture with wire colors that would be helpful with connecting to the OBD2 connector so i know which wires im plugging in. besides that it seems very straight forward to me. Thank you for the great work and information so far |
I'll post wiring diagrams and color codes. Also, my apologies about my comment about that CAN bus splice connector. I misunderstood and thought it was an obd2 connector. That connector would definitely work great to catch the ev CAN as shown in their picture, but doesn't have access to the car CAN so what I ended up doing gets you access to both CANs in the same place. |
@ehilfer if you can get those and post them here you should also consider compiling everything and making a post on the OVMS forums as thorough as you can. It's a huge step towards official support finally after these cars being out for over a half decade. Really appreciate the work everybody has contributed towards this despite the challenges there are. |
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: caederus-ovms@66906c0).
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 , openvehicles/Open-Vehicle-Android#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?
The text was updated successfully, but these errors were encountered: