Overcurrent cutout?

[glynhudson]

Since the openevse has the ability to monitor the actual current being drawn by the EV has an over current cutout been discussed? I.e if the real-time current being drawn the the EV is greater than the pilot setting the openevse could stop the charge and throw a error.

I admit that in practice this is unlikely to happen, unless there was a serious fault with an EV, however since we have the ability to measure real time current I think this would be a good fail save feature to add.

This was particularly apparent today when I was testing PP_AUTO_AMPACITY (which works very well 👍 ), when I simulated a non-tethered 13A charging cable with a 1.5K ohm resistor between PP>GND the openevse limited the pilot signal to 13A, great. However, there is nothing stopping a faulty EV that disregards the pilot signal drawing more current.

Here I was drawing 22A with the pilot signal set to 13A by PP_AUTO_AMPACITY:

It could be argued that the evse should be installed using a power outlet with a MCB/fuse rating to match the max output of the evse. Therefore if overcurrent occurs the MCB/fuse would trip. However if the evse is non-tethered and the pilot signal was set to the rating of the cable e.g 13A by PP_AUTO_AMPACITY if an EV then draws 32A it will be within the supply limit of the evse but not the cable limit. In this scenario the evse would continue the charge regardless of the current being drawn damaging the cable.

If you think this is a good idea I'm happy to try and have a go at implementing.

[lincomatic]

I discussed this with Chris before, and he didn't think it was necessary. If you want to take a stab at implementing it, by all means, we can at least have it as an option.

[lincomatic]

There are two ways to do this:

1. hard fault - EVSE will not charge again until the EV is unplugged
2. soft fault - implement retries and if EV keeps violating then hard fault

Since this is a serious safety issue, I think (1) is a better bet.

[lincomatic]

We have about 1K code space left. (1) will take less space, and is quicker to implement

[lincomatic]

OK, I went ahead and implemented (1). We are not officially almost completely out of code space.
Depending on what features are enabled, we could actually already be too big and out of RAM.

To enable over current monitoring, uncomment #define OVERCURRENT_THRESHOLD
Right now, with OVERCURRENT_THRESHOLD,DELAYTIMER, PP_AUTO_AMPACITY, and MENNEKES_LOCK
my version of the compiler is showing:

Sketch uses 32418 bytes (98%) of program storage space. Maximum is 32768 bytes.
Global variables use 1581 bytes (77%) of dynamic memory, leaving 467 bytes for local variables. Maximum is 2048 bytes.

I hope we are not out of RAM.. need stability testing. Also, depending on what version of the compiler and libraries are used, we could already be running into issues.

Please give it a whirl.. in test branch again

[glynhudson]

Fantastic, that's great. I'll try and do some testing over the weekend

[lincomatic]

Did some clean up and tweaking of the code and put it all in the development branch as D5.0.0.
Saved a little bit more code/RAM in the process

Sketch uses 32366 bytes (98%) of program storage space. Maximum is 32768 bytes.
Global variables use 1579 bytes (77%) of dynamic memory, leaving 469 bytes for local variables. Maximum is 2048 bytes.

[lincomatic]

pushed fix to dev branch in D5.0.0