[Ovmsdev] Nissan Leaf, GPIO and "Stop Charging", "Lock/Unlock" commands.

[Brian Greenberg]

On Wed, Aug 29, 2018 at 3:09 AM Stein Arne Sordal <ovms at topphemmelig.no>
wrote:

> > On 29 Aug 2018, at 10:02, Robin O'Leary <ovmsdev at 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.gif)
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 at grnbrg.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180829/1774295f/attachment.htm>