<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Aug 29, 2018 at 3:09 AM Stein Arne Sordal <<a href="mailto:ovms@topphemmelig.no" target="_blank">ovms@topphemmelig.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> On 29 Aug 2018, at 10:02, Robin O'Leary <<a href="mailto:ovmsdev@caederus.org" target="_blank">ovmsdev@caederus.org</a>> wrote:<br>
> <br>> Did you see this thread about door locks?<br>
> <br>
>       <a href="http://lists.openvehicles.com/pipermail/ovmsdev/2018-May/005165.html" rel="noreferrer" target="_blank">http://lists.openvehicles.com/pipermail/ovmsdev/2018-May/005165.html</a><br>
> <br>
> It works for some, but not for me, though I still haven't got around to<br>
> trying it with the TCU unplugged (mostly because I haven't figured out<br>
> where the TCU is on my right-hand drive model!).<br>
<br>
Door locks only works on 2016 or later.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> As for charging, I suspect it'll be easy to find some CAN message(s)<br>
> that will cause it to stop; the problem might be that doing so triggers<br>
> some fault detection that could also upset things.  But we have lots of<br>
> logs to get ideas from, so it's certainly worth having a go.<br>
<br>
Have anyone done logging of the CAN-bus when the car stops charging at 80% ? (removed in 2016 and later)<br></blockquote><div> </div><div>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 (<a href="https://upload.wikimedia.org/wikipedia/commons/b/b6/J1772_signaling_circuit.gif" target="_blank">https://upload.wikimedia.org/wikipedia/commons/b/b6/J1772_signaling_circuit.gif</a>) 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.</div> <br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> That would be great; it seems like there should be generic functions<br>
> to deal with the ESP32's GPIO pins (things like switch on/off, toggle<br>
> for n milliseconds); that the vehicle-specific layer could just call<br>
> as required.<br></blockquote><div><br></div><div>There is a console command (epgio(port, level)) and the internal function 
MyPeripherals-><span class="m_-4892122855778144557m_-2680197804224251973gmail-pl-smi">m_max7317</span>-><span class="m_-4892122855778144557m_-2680197804224251973gmail-pl-c1">Output</span>((<span class="m_-4892122855778144557m_-2680197804224251973gmail-pl-c1">uint8_t</span>) port,(<span class="m_-4892122855778144557m_-2680197804224251973gmail-pl-c1">uint8_t</span>) 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?</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Brian.<br></div></div>-- <br><div dir="ltr" class="m_-4892122855778144557m_-2680197804224251973gmail_signature">Brian Greenberg<br><a href="mailto:grnbrg@grnbrg.org" target="_blank">grnbrg@grnbrg.org</a></div></div></div>