Closed glynhudson closed 5 years ago
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
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
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.
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.
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.
@lincomatic did this ever hit an OpenEVSE release? Will this change propagate to MQTT? cc @glynhudson
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
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:
https://community.openenergymonitor.org/t/request-for-new-input-to-emoncms-from-openevse/10161/4