Overcurrent feature: delay required

[glynhudson]

I've been testing the overcurrent feature implemented in 5.0.0 60b5083

It works well, however, there is a false positive when the openevse reduces the set charging rate while the car is charging (this can happen automatically during solar PV divert).

The EV takes a finite period of time to react to the change of pilot signal to reduce the charging rate. Before the EV gets a chance to reduce it's currently the openevse triggers an overcurrent error since momentarily the EV is drawing more current than the pilot signal is set.

This could be easily fixed by adding a 'grace period' to allow the EV to re-adjust.

Is there enough memory to make such an addition? I think something around 3 to 5s would be more than enough grace period.

Also is there any way to detect an overcurrent hard error via RAPI? I don't currently think there is a way to display an overcurrent error on the WiFi interface. This is not a big deal, but it would be good to be able to show that the openevse has entered an error state on the wifi interface. Since currently when an overcurrent error is triggered the wifi interface becomes unresponsive.

[jeremypoulter]

Hi, It may be better to add allow the charge level to be set independently from the max current that the system can handle, over current detection is not really something you want a delay in for the real positive cases, fires and death and all that ;-) but then again I guess folks have an RCD or similar for that case and this is just a warning the car is miss-behaving. Jeremy

…

On Thu, 4 Oct 2018, 02:59 Glyn Hudson, ***@***.***> wrote: I've been testing the overcurrent feature implemented in 5.0.0 60b5083 <60b5083> It works well, however, there is a false positive when the openevse reduces the set charging rate while the car is charging (this can happen automatically during solar PV divert). The EV takes a finite period of time to react to the change of pilot signal to reduce the charging rate. Before the EV gets a chance to reduce it's currently the openevse triggers an overcurrent error since momentarily the EV is drawing more current than the pilot signal is set. This could be easily fixed by adding a 'grace period' to allow the EV to re-adjust. Is there enough memory to make such an addition? I think something around 3 to 5s would be more than enough grace period. Also is there any way to detect an overcurrent hard error via RAPI? I don't currently think there is a way to display an overcurrent error on the WiFi interface. This is not a big deal, but it would be good to be able to show that the openevse has entered an error state on the wifi interface. Since currently when an overcurrent error is triggered the wifi interface becomes unresponsive. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#95>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF1WgPbm0cTgn9iMAuZSX3aJfoyijYSvks5uhWtqgaJpZM4XHPE5> .

[glynhudson]

All EVSE's must be connected through an RCD, this will protect against short circuits. No other EVSE's check to see that the EV is only drawing the correct amount of current as instructed by the CP. However, since we have the ability on the openevse to monitor current I thought it would be a good idea to add this feature as a belt and braces approach. In practice, it would be very unlikely that an EV charging system would disobey the pilot signal. See this issue for discussion on the feature: #87

[lincomatic]

RAPI sends out an async notification message whenever there's an EVSE state change. also, since over current is an EVSE state, it should be able to be queried, just like any other state, let me know if that's not true.

What do you mean the WiFI interface is unresponsive during over current? Why would that be? AFAIK, I am treating it the same as any other fault. Sorry, too busy to look at the code, but if it behaves differently from other faults, let me know

[glynhudson]

I'll have to investigate further the issue with the web interface. It should easily be possible to handle the error if the RAPI sends out an async notification the same as the other errors. @jeremypoulter would you be able to take a look at this?

The main reason I opened this issue is the open_evse controller triggering a false negative ovecurrent error due to the finite time taken by an EV to reduce it's charge rate when the pilot signal is reduced while a charge is active. A simple delay introduced in the overcurrent detection should fix the issue? Is this something you would be happy to add?

[lincomatic]

Hmm. I just looked at the code, and there's already a timeout implemented, currently set to 5sec in open_evse.h:

// if OVERCURRENT_THRESHOLD is defined, then EVSE will hard fault in
// the event that the EV is pulling more current than it's allowed to
// declare overcurrent when charging amps > pilot amps + OVERCURRENT_THRESHOLD
#define OVERCURRENT_THRESHOLD 5 // A
// go to error state overcurrent by OVERCURRENT_THRESHOLD amps
// for OVERCURRENT_TIMEOUT ms
#define OVERCURRENT_TIMEOUT 5000UL // ms

[glynhudson]

Ah great, I'll have a go at increasing this to 10s. Will report back...

[glynhudson]

Ok, I've done some testing increasing OVERCURRENT_TIMEOUT to 10s. But the issue remained.

I now don't think that the timeout is the issue since the overcurrent errors occurs immediately and always at 21A.

After the error has triggered the openevse continues charging and the unit is locked up. Even pushing the menu button does not stop the charge. The only way to recover from this state is to restart the controller.

See video: https://photos.app.goo.gl/9rAV4g77GrwbHMJ7A

[lincomatic]

Sorry, I currently don't have access to the hardware. I attempted a fix in the test1 branch.
Could you give it a whirl and let me know if it resolves the issue?

[glynhudson]

Fantastic, just tested test1 branch and the issue has been fixed. I no longer can trigger a false overcurrent error when reducing the charge rate while a charge is active. Nice work 👍

[lincomatic]

Does it still detect overcurrent properly after the specified timeout?

[glynhudson]

Yes, it still properly directs overcurrent but doesn't stop the charge when overcurrent is detected.

…

On Mon, 15 Oct 2018 at 21:48, lincomatic ***@***.***> wrote: Does it still detect overcurrent properly after the specified timeout? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAuUPBlfg1r5a9dW3CKU-yz__TGu26Taks5ulPSDgaJpZM4XHPE5> .

-- Glyn Hudson https://openenergymonitor.org http://zerocarbonadventures.co.uk

[lincomatic]

hmm. that's incorrect behavior. it's supposed to hard fault if it overcurrent lasts longer than the timeout. what do you mean by it properly detects it?

[glynhudson]

It displayed over a current error on the LCD but contactor doesn't open. See video to illustrate: https://photos.app.goo.gl/c4dXqSLJGnCfV3ir5

[lincomatic]

Thanks. I forgot to open the relay. I just pushed a fix. Please let me know if it works correctly now

[glynhudson]

Yah! Nice work, this has fixed the issue. The contactor now opens on an overcurrent fault and the original issue of overcurrent being incorrectly detected is still fixed 👍

I reckon test1 branch is ready to be merged into the dev branch and this issue closed.

[lincomatic]

Yes, it's already been pushed to development. Thanks for the assistance!