State: EV Connected / Disconnected while sleeping

[glynhudson]

A user has noticed there is no way to tell if an EV has been connected / disconnected while the EVSE is sleeping. The state remains at 254.

Do you know if there is a work around to detect this?

What are your thoughts on adding another couple of state values to indicate:

• EVSE sleeping no EV connected
• EVSE sleeping EV connected

https://community.openenergymonitor.org/t/request-for-new-input-to-emoncms-from-openevse/10161/4

[lincomatic]

Hmm. Hard to think of a good way to fix it w/o messing up existing clients. If we add a new state, they might break. It's stored in a private flags2 variable:

// J1772EVSEController volatile m_bVFlags2 bits - not saved to EEPROM

define ECVF2_EV_CONNECTED 0x01 // EV connected - valid only when pilot not N12

define ECVF2_EV_CONNECTED_PREV 0x02 // prev EV connected flag

define ECVF2_SESSION_ENDED 0x04 // used for charging session time calc

I could expose it in $GS by tacking it on at the end.

GS - get state response: $OK evsestate elapsed pilotstate vflags vflags2

Also, I've been wanting to replace $ST async notification w/ $AT:

$AT evsestate pilotstate currentcapacity vflags vflags2

Unfortunately, I'm swamped right now and won't be able to work on it in the near future

[glynhudson]

Sure, I can understand the issues adding a new state could cause, It's promising there is a way to detect this which could be used in the future. Not a major issue. Thanks for considering it.

I guess a messy work around using current firmware would be periodically wake up the EVSE, if a charge begins then we know an EV is connected.

[paulbernardr]

The work around I'm using now is for the EVSE user to only plug in an EV by ensuring first that the EVSE is not sleeping. If it is, then to press the EVSE button to wake it up and then plug in the EV. Once a charge starts, my code waits 30s and then puts the EVSE to sleep. The EV will then start charging ok at a later point when the EVSE is 'reset' , (as 'enable' doesn't work). This is all to get over the issue of plugging in an EV to a sleeping EVSE which causes a car fault, (Zoe), caused by the initial connection checks failing. Once this occurs the only resolution is to disconnect the EV and start again.

[lincomatic]

Sorry, my original reply referred to a private m_bVFlags2 variable.. for simplicity, I ended up folding all of the m_bVFlags2 bits into an expanded m_wVFlags variable, and adding the new bits to it, as well:

// J1772EVSEController volatile m_wVFlags bits - not saved to EEPROM
#define ECVF_AUTOSVCLVL_SKIPPED 0x0001 // auto svc level test skipped during post
#define ECVF_HARD_FAULT         0x0002 // in non-autoresettable fault
#define ECVF_LIMIT_SLEEP        0x0004 // currently sleeping after reaching time/charge limit
#define ECVF_AUTH_LOCKED        0x0008 // locked pending authentication
#define ECVF_AMMETER_CAL        0x0010 // ammeter calibration mode
#define ECVF_NOGND_TRIPPED      0x0020 // no ground has tripped at least once
#define ECVF_CHARGING_ON        0x0040 // charging relay is closed
#define ECVF_GFI_TRIPPED        0x0080 // gfi has tripped at least once since boot
#define ECVF_EV_CONNECTED       0x0100 // EV connected - valid only when pilot not N12
#define ECVF_SESSION_ENDED      0x0200 // used for charging session time calc
#define ECVF_EV_CONNECTED_PREV  0x0400 // prev EV connected flag

So $GS is now:

GS - get state
response: $OK evsestate elapsed pilotstate vflags

And $ST is replaced by $AT:

$AT evsestate pilotstate currentcapacity vflags 

And there is a new $AB notification at boot:

Boot Notification
$AB postcode fwrev
 postcode(hex):
   if boot OK then postcode = 00
   if error then postcode
       07 = bad ground
       08 = stuck relay
       09 = GFI test failed
 fwrev(string): firmware revision

It's currently only implemented in my experimental ocpp branch, because it may break existing client code.

[ruimarinho]

@lincomatic did this ever hit an OpenEVSE release? Will this change propagate to MQTT? cc @glynhudson

[lincomatic]

I don't control the OpenEVSE releases. Someone else does the merging. But the changes are now folded into my dev branch. I haven't looked at the syntax of MQTT but if it's just passing through raw RAPI you should have access to it