Nissan Leaf, GPIO and "Stop Charging", "Lock/Unlock" commands.
I picked up a 2015 Leaf about 3 weeks ago, and found this project a few days later. My 3.1 hardware should arrive from FastTech this week. I've been browsing through the git repos and manuals, and hope to make some small contributions in the future. How interested are you devs in code contributions that require hardware modifications to the vehicle? :) Two things that I am interested in are remotely toggling the door locks, and stopping/disabling an ongoing charge. Neither are currently supported functions in the Leaf, as (if it is possible at all) the codes are unknown. However, both functions are trivially available outside of the car network. To disable charging, it should be quite easy to fake the charge computer into thinking that the J1772 connector is about to be removed -- there is a connector under the hood, just past the L1/L2 socket that carries the socket ground and (low voltage) proximity pin signal to the VCM (Or BCM?). Adding a 330 ohm resistance to the proximity pin tells the car that power is about to be removed, and to stop charging. Door locks will have a fairly easy to locate pair of wires in the front doors that will trigger locking and unlocking. Three GPIO assignments and three opto isolated 12V relays should easily enable the desired functionality. Assuming I can walk this walk, would there be interest in the code? This would be a bit more involved than the single wire connection between the OVMS module and the TCU that is needed to enable the vehicle wake up signal on 2011 and 2012 models..... I'm very impressed with this project, BTW. I've been around open source for years, but I've never seen open hardware development at this level. Brian. -- Brian Greenberg grnbrg@grnbrg.org
On Tue, Aug 28, 2018 at 09:16:04PM -0500, Brian Greenberg wrote:
I picked up a 2015 Leaf about 3 weeks ago, and found this project a few days later. My 3.1 hardware should arrive from FastTech this week. I've been browsing through the git repos and manuals, and hope to make some small contributions in the future.
How interested are you devs in code contributions that require hardware modifications to the vehicle? :)
I have the same model as you and I am interested experimenting in this direction.
Two things that I am interested in are remotely toggling the door locks, and stopping/disabling an ongoing charge. Neither are currently supported functions in the Leaf, as (if it is possible at all) the codes are unknown.
Did you see this thread about door locks? http://lists.openvehicles.com/pipermail/ovmsdev/2018-May/005165.html It works for some, but not for me, though I still haven't got around to trying it with the TCU unplugged (mostly because I haven't figured out where the TCU is on my right-hand drive model!). As for charging, I suspect it'll be easy to find some CAN message(s) that will cause it to stop; the problem might be that doing so triggers some fault detection that could also upset things. But we have lots of logs to get ideas from, so it's certainly worth having a go.
... Three GPIO assignments and three opto isolated 12V relays should easily enable the desired functionality.
Assuming I can walk this walk, would there be interest in the code? This would be a bit more involved than the single wire connection between the OVMS module and the TCU that is needed to enable the vehicle wake up signal on 2011 and 2012 models.....
That would be great; it seems like there should be generic functions to deal with the ESP32's GPIO pins (things like switch on/off, toggle for n milliseconds); that the vehicle-specific layer could just call as required.
On 29 Aug 2018, at 10:02, Robin O'Leary <ovmsdev@caederus.org> wrote:
On Tue, Aug 28, 2018 at 09:16:04PM -0500, Brian Greenberg wrote:
I picked up a 2015 Leaf about 3 weeks ago, and found this project a few days later. My 3.1 hardware should arrive from FastTech this week. I've been browsing through the git repos and manuals, and hope to make some small contributions in the future.
How interested are you devs in code contributions that require hardware modifications to the vehicle? :)
I have the same model as you and I am interested experimenting in this direction.
Two things that I am interested in are remotely toggling the door locks, and stopping/disabling an ongoing charge. Neither are currently supported functions in the Leaf, as (if it is possible at all) the codes are unknown.
Did you see this thread about door locks?
http://lists.openvehicles.com/pipermail/ovmsdev/2018-May/005165.html
It works for some, but not for me, though I still haven't got around to trying it with the TCU unplugged (mostly because I haven't figured out where the TCU is on my right-hand drive model!).
Door locks only works on 2016 or later.
As for charging, I suspect it'll be easy to find some CAN message(s) that will cause it to stop; the problem might be that doing so triggers some fault detection that could also upset things. But we have lots of logs to get ideas from, so it's certainly worth having a go.
I´m also interested in a Stop-charge function. Have anyone done logging of the CAN-bus when the car stops charging at 80% ? (removed in 2016 and later)
... Three GPIO assignments and three opto isolated 12V relays should easily enable the desired functionality.
Assuming I can walk this walk, would there be interest in the code? This would be a bit more involved than the single wire connection between the OVMS module and the TCU that is needed to enable the vehicle wake up signal on 2011 and 2012 models.....
That would be great; it seems like there should be generic functions to deal with the ESP32's GPIO pins (things like switch on/off, toggle for n milliseconds); that the vehicle-specific layer could just call as required. _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On Wed, Aug 29, 2018 at 10:09:09AM +0200, Stein Arne Sordal wrote:
I´m also interested in a Stop-charge function. Have anyone done logging of the CAN-bus when the car stops charging at 80% ? (removed in 2016 and later)
I'm doing so now :-)
On Wed, Aug 29, 2018 at 3:09 AM Stein Arne Sordal <ovms@topphemmelig.no> wrote:
On 29 Aug 2018, at 10:02, Robin O'Leary <ovmsdev@caederus.org> wrote:
Did you see this thread about door locks?
http://lists.openvehicles.com/pipermail/ovmsdev/2018-May/005165.html
It works for some, but not for me, though I still haven't got around to trying it with the TCU unplugged (mostly because I haven't figured out where the TCU is on my right-hand drive model!).
Door locks only works on 2016 or later.
That is certainly (currently) true for unlocking the doors the "right" way, via a CAN bus command. Faking the actuation of the lock/unlock buttons on one of the doors with a relay should work on any vehicle with power locks. It's not as elegant, and will be useful to fewer people due to the required hardware modifications to the vehicle wiring harness, but it should work.
As for charging, I suspect it'll be easy to find some CAN message(s)
that will cause it to stop; the problem might be that doing so triggers some fault detection that could also upset things. But we have lots of logs to get ideas from, so it's certainly worth having a go.
Have anyone done logging of the CAN-bus when the car stops charging at 80% ? (removed in 2016 and later)
I'm sure there has been work done to try and find the CAN-bus codes, but so far without success, which is why I'm looking at brute force. Simply disconnecting the the Control Pilot and Proximity Pin while charging doesn't work -- it throws a DTC and puts the Leaf in turtle mode. Thank god for Leaf Spy. :) But it's not a complicated circuit ( https://upload.wikimedia.org/wikipedia/commons/b/b6/J1772_signaling_circuit....) and it should be straightforward to determine a combination of open circuit and resistance values on the CP and PP lines that is functionally equivalent to unplugging and replacing the charge connector.
That would be great; it seems like there should be generic functions to deal with the ESP32's GPIO pins (things like switch on/off, toggle for n milliseconds); that the vehicle-specific layer could just call as required.
There is a console command (epgio(port, level)) and the internal function MyPeripherals->m_max7317->Output((uint8_t) port,(uint8_t) level) defined in ..../max73717.cpp, so the hard work is done. One of my main questions regarding implementation... Should I look at setting up named "CommandLock" functions (which might make access via apps more straightforward) or should I just leave the firmware alone entirely, and just use the epgio() command? It will be moot for a while, though, at least until I can get the hardware installed and tested, and figure out the build environment. Brian. -- Brian Greenberg grnbrg@grnbrg.org
participants (3)
-
Brian Greenberg -
Robin O'Leary -
Stein Arne Sordal