MennekesLock
glynhudson opened this issue · comments
I've been testing the MennekesLock feature. Currently, as far as I can tell the MennekesLock is toggled each time there is a state change:
This does not provide the correct functionality e.g currently MennekesLock unlocked when the state changed from 'charging' to 'connected'. The MennekesLock should remain locked until the EV is disconnected from the other end of the cable 'no-connected.
I would like to propose the following for MennekesLock states:
- First Power up / power cycle: UNLOCKED
- EV connected: LOCKED
- Charging Locked: LOCKED
- Diode / vent error / temperature error: LOCKED
- EV not-connected: UNLOCKED
If MennekesLock unlocks when the charging session has finished (EV connected state) there is potential the cable could be stolen. The EVSE should keep the cable connected until the EV disconnects.
Sorry, I don't know how the cable setup, so it's hard for me to grasp exactly what you want.
I thought the EV couldn't be disconnected while it's locked, so there wouldn't be a way to transcation to unlocked.
I think I'm probably not visualizing how the cable & lock are used.
In any case, distilling it down.. I think all you want is:
EV not connected -> EV connected transition: lock Mennekes
EV connected -> disconnected transition: unlock Mennekes
It seems like the above behavior would cover everything in your bullet list properly. Am I missing something?
I am not sure even @glynhudson request is correct. If the goal is to prevent the cable from being stolen then the unlock should be controlled based on a pin, password, key, RFID card, OCPP, generally some form of access control. Just being based on the vehicle being connected means someone just has to unplug the cable from the car.
So probably this is more a job for the WiFi module I would think, so probably adding a RAPI command to lock/unlock may be the best solution.
I was wondering if the cable is locked at the EV end as well, because if not, yeah, all you have to do is unplug the EV from the cable, and then the EVSE will also release it.
If you just want manual control of the MENNEKES lock, I can add a new RAPI command
IMHO I think that would make sense as I don't think you can sensibly derive the lock/unlock from the state of the EVSE @glynhudson what do you think
Random anecdotal input:
I was wondering if the cable is locked at the EV end as well
Depends on the EV.
For example early leaf does not lock the EV end at all. Later models have two modes where one unlocks automatically when state is changed to any state but charging and the last mode keeps it locked until manually unlocked.
Majority of public chargers here (Norway) follow the EV and unlocks the EVSE end when the EV end is disconnected - the locking solenoids are also usually fail open so during power outages cables can be removed from EVSE and if the EV then automatically unlock the cable when no longer charging the cable can be stolen. Some EVSE (notably Zaptec) have the socket at an angle and combined with power outage, fail open locking solenoids, and gravity cable can disconnect on its own - and if the EV then unlocks automatically there is a real possibility to find the EV with the cable gone (has happened). A few public chargers unlock when charge changes state to Connected to allow another EV to use the EVSE if needed - this does not work well with charge timers if enabled inadvertently.
I'm just waiting for @glynhudson to chime in and let me know what he wants.
Is the proposed manual lock/unlock RAPI command the best solution?
What is the verdict on this? If I don't get some feedback on what you guys want, I am just going to close this issue. @glynhudson hasn't been replying here or to my emails, despite offering to fund this change.
Sorry guys, I went away in July and totally dropped the ball on this. I'm still keen to implement this.
All IEC 62196 (Type-2 European standard) EVs lock the cable at the vehicle end, to unlock the vehicle end requires unlocking the vehicle and pushing a button on the dashboard or keyfob. It's impossible for anyone to unplug the cable from the vehicle end without the vehicle keyfob or mobile app.
The purpose of also locking the cable at the charge point end is to stop an unauthorised person unplugging the cable and therefore stopping the charge. It's also a safety feature to ensure the cable is not unplugged while current is flowing. Yes, the pilot pin is shorter than the current pins so the EVSE should stop the charge before an electrical arc can occur, but this is not deemed sufficient, especially for three-phase.
The lock mechanism should have an automatic and a manual mode. I stand by my proposal for the following automatic mode MennekesLock states:
- First Power up / power cycle: UNLOCKED
- EV connected: LOCKED
- Charging: LOCKED
- Diode / vent error / temperature error: LOCKED
- EV not-connected: UNLOCKED
In manual mode where the user can toggle the lock status from the WiFi interface / RAPI / OCPP
Properly implementing a lock will require a hardware change to the controller, since currently the lock control pins hijack the ISP pins which is a bit hacky and difficult to connect. Ideally we should be able to read the status from lock mechanism, this will require an extra digital pin.
@glynhudson this does not match my experience, particularly with commercial chargers. For those the lock/unlock seems to be dictated by you starting/stopping the charge (in my case from an app) and the cable will remain locked at the EVSE side irrespective of the car side being plugged in (leading to several calls to EVSE support personnel)
So even if we implement the logic suggested I think it should be done in the WiFi module with just a RAPI command to lock/unlock. This would also allow us to implement the recommended OCPP features.
Also for what it is worth my car has a type 1 connector with no locking or the car side.
All charge points should unlock the cable at the EVSE end when the car end is unplugged, any public charge point that does not adhere to this is doing it wrong! I think the issue here the Type-1 connector, since this allows the car end to be unplugged while a charging session is active, while type-2 connectors require the vehicle to stop the charging session before the car end can be unplugged.
However, I can see the benefit of having an automatic lock mode (as I outlined above) and a manual mode where the user can toggle the lock status from the WiFi interface / RAPI / OCPP. This will be useful for home charge points where the user wants to keep the cable permanently locked to the EVSE to avoid it being stolen from their driveway when the EV is not connected, the Zappie has this function.
Ah, I guess that makes sense....
The manual locking is the same use case as OpenEVSE/openevse_esp32_firmware#189.
So what would the advantages be of implementing both modes on the EVSE module vs just the manual RAPI commands and adding the automatic in the WiFi module.
So what would the advantages be of implementing both modes on the EVSE module vs just the manual RAPI commands and adding the automatic in the WiFi module.
I guess, either implementation would work. The automatic lock is a safety feature and therefore should be handed by the EVSE controller. However, all EVSE units now include a Wifi module as standard and the WiFi module has been proved to be reliable, therefore I don't mind. Which do you think would be the easiest and most robust implementation?
From the POV of implementing on the WiFi module I don't think it would be too much effort, but I do see your point about it being a safety feature so maybe it does make sense to implement the default mode on the EVSE, @lincomatic any thoughts?
I'm OK w/ implementing default behavior... but what do you guys want it to do, and how do we keep it from overriding whatever RAPI is doing?
Maybe something similar to the LCD? A RAPI command to enable/disable the automatic mode and a RAPI command to lock/unlock?
That sounds good to me
Here is the documentation for the current state of the Mennekes lock as referenced in the branch above
Mennekes lock is the mechanism for locking a charging cable into a non-tethered socket (IEC 62196-2). The purpose of the lock is to avoid the hazard of the cable being disconnected during a charging session and secure the cable to avoid theft.
IEC 62196-2 enabled vehicles (all vehicles sold in Europe) also lock the cable at the vehicle end, usually there is a button on the keyfob and or dashboard to unlock the vehicle end of the cable which also stops the changing session.
Firmware
This documentation references openevse controller firmware
Controller Firmware: V8.1.0a
RAPI: V5.2.0
Commit: 2b53190
Issue: #141
To enable Mennekes lock uncomment #define MENNEKES_LOCK in open_evse.h
Hardware connections
Mennekes lock currently uses the ISP pins as digital out pins
MOSI - Pin A - LOCK
MISO - Pin B - UNLOCK
Mennekes lock requires a 12V H-bridge, tested with L298N duel H-bridge drive
Operation
Mennekes lock has both automatic and manual operation
Automatic
The Mennekes lock will be activated (locked) when a vehicle is connected and will be unlocked when a vehicle is disconnected. To disconnect a vehicle the vehicle end of the cable should be unlocked first. Automatic is default mode,
Manual
Manuel operation mode was introduced to allow the Mennekes lock to be controlled by ESP32 WiFi module via RAPI. Manual mode could be controlled via OCPP, HTTP API manually via the web interface. Manual mode could allow the user to permanently lock the cable into the socket, e.g to prevent cable theft for home use when the cable is left permanently in between charging sessions. Manual mode is volatile, the unit will always boot into automatic mode
RAPI
S5 A|M|0|1 - Mennekes lock setting
A = enable automatic mode - locked when connected, unlocked otherwise
M = enable manual control mode
0 = unlock (valid only in manual mode)
1 = lock (valid only in manual mode)
n.b. requires MENNEKES_LOCK. manual mode is volatile - always boots in automatic mode
G5 - get Mennekes settings
response: $OK state mode
state: 0 = unlocked
1 = locked
mode: A = automatic mode - locked when connected, unlocked otherwise
M = manual control mode
Note: lock mode is also indicated by ECVF_MENNEKES_MANUAL
n.b. requires MENNEKES_LOCK
Is the Ammeter calibration now not supported? 5dde798
ran out of bits. ammeter cal doesn't fit into regular production builds, anyway. you should just use an old version to do calibration tasks
Since the Mennekes stuff has been addressed and merged, I'm closing this