@FChan: Thanks for your suggestions !! I also agree with your point that EVSE manufacturers would get better press if they were less rigidly attached to J1772.
Maybe it is just me, but if I can avoid extra wires and relays I will. I have been a global process control specialist in the largest publicly owned petrochemical company in the world for over 30 years, if there is one thing I’ve learnt it is to avoid points of failure as much as possible.
So I was rather leaning toward a software fix. I can write python code to use MQTT and read the OpenEVSE/state. While in divert mode, when the state = 2 it means the EVSE wants to charge but the car won’t take it, while the car is connected. If there is not enough current, state = 254 (found that nowhere in documentation by the way) and when the car is charging, state = 3. When the EV is not connected, state also reads 254. So state = 2 is a good indication we may need to reset. And resetting could be achieved using a RAPI command the python code sends over HTTP. I had hoped to use MQTT as advertised in the developers manual, but that did not seem to work.
Now we need to make sure we’re not resetting like crazy. There is no need. Like if there is enough current available, but the car has enough charge, there is no need to reset. For that I need the Stellantis servers again and these have not worked for me for three days now. The OpenEVSE is not reading the car’s SOC through the cable, I read somewhere because the pilot it makes is “analog”, whatever that means… but you can see that this is the case by the simple fact OpenEVSE has a “vehicle” tab to set up MQTT for reading SOC.
So still a few issues to hammer out… in a first version of the code I could reset the OpenEVSE every time the state = 2 for say 10 minutes. But that is a bit rough handed…
The maximum charge delivered to the car is requested by the car itself via the pilot signal - the EVSE of course can be configured to deliver less.
So state=2 is an indication that the EVSE can deliver but the car isn’t requesting anything, either because it is full or I guess uncommunicative.
My OpenEVSE has a timed charge for four hours from 00:30 to 04:30 to coincide with Octopus Go.
My wife’s Zoe was charging earlier today and shown in state=3 from 00:30 to 03:16, state=2 from 03:16 to 04:30 and then state=254 onwards (state is one of the many values sent by the unit over MQTT to my emonPi every 30s).
I guess you are a software man. I am more hardware leaning. I can write simple software but have not tried yet to do anything with the Open ESVE. Where exactly are you placing this Python code you are planning? Presumably not by altering the firmware of the Open ESVE PCB. Is it in the Raspberry Pi in the emons side?
But I’d say, as a former safety engineer, don’t forget that software fails too!
It does not say what 254 means, but we (think we) know. Maybe it is the controller’s default to say “I don’t know”. It probably is. It is Hex FE (not FF). And divert mode is not adding any values to the /state enumeration it seems. So when divert mode sees no power, it stops the EVSE charging and the /state says “sh** I have no idea what is going on”.
// EVSE states for m_EvseState
#define EVSE_STATE_UNKNOWN 0x00
#define EVSE_STATE_A 0x01 // vehicle state A 12V - not connected
#define EVSE_STATE_B 0x02 // vehicle state B 9V - connected, ready
#define EVSE_STATE_C 0x03 // vehicle state C 6V - charging
#define EVSE_STATE_D 0x04 // vehicle state D 3V - vent required
#define EVSE_FAULT_STATE_BEGIN EVSE_STATE_D
#define EVSE_STATE_DIODE_CHK_FAILED 0x05 // diode check failed
#define EVSE_STATE_GFCI_FAULT 0x06 // GFCI fault
#define EVSE_STATE_NO_GROUND 0x07 //bad ground
#define EVSE_STATE_STUCK_RELAY 0x08 //stuck relay
#define EVSE_STATE_GFI_TEST_FAILED 0x09 // GFI self-test failure
#define EVSE_STATE_OVER_TEMPERATURE 0x0A // over temperature error shutdown
#define EVSE_STATE_OVER_CURRENT 0x0B // over current error shutdown
//reserved #define EVSE_STATE_PILOT_ERROR 0x0C // pilot self test error
//reserved #define EVSE_STATE_TEMP_SENSOR_FAULT 0x0D // temp sensor dead
#define EVSE_STATE_RELAY_CLOSURE_FAULT 0x0E
#define EVSE_FAULT_STATE_END EVSE_STATE_RELAY_CLOSURE_FAULT
#define EVSE_STATE_SLEEPING 0xfe // waiting for timer
#define EVSE_STATE_DISABLED 0xff // disabled
When my timer finishes at 00:40, the state changes to 254 regardless of whether the car is connected or not; it normally would be and the state continues at 254 when the car is later disconnected.
@greentangerine Thanks for the pointer!! That helped!! @FChan , I’ll come back to you in a second, I missed your last post, did not see e-mail notification for some reason…
Ah! It seems we need to wait a bit and some issues might get resolved. I just learnt from Glyn Hudson that we need a firmware update beyond WiFi 4.1.2. It was somewhere else on Github. Jee… we need even more tools to consolidate the info on the net… I missed this one, sorry for leading you chaps on… So I can hold the tinkering with waking the car’s charger. There is hope the “Pause Disable” will work with the e-208.
There is another inaccurate statement of mine I need to correct. Rapi via Wifi MQTT does work. Not as I expected. For resetting the OpenEVSE, I had the python code publish “$FR” to the topic “OpenEVSE/rapi/in”. That seemed logical to me. But when I published blank “” to the topic “OpenEVSE/rapi/in/$FR” the EVSE did reset. It may be good to clarify that in the developers manual.
Subscribing to “OpenEVSE/rapi/out” did not work either. You need to subscribe to “OpenEVSE/rapi/out/#”. That follows the same logic as above. Aaarrrrggghhh!!! OK, problem on its way of being resolved.
@FChan, of course you are right about software also failing. While working as a process control specialist the punchline in my professional e-mail signature was: “Failure is not an option. It comes packaged with the software.”
@FChan , you’re a safety engineer! Some of my dearest colleagues were (are) safety engineers! Great people. Well… I am both a hardware and a software guy. And I found software “easier” to tinker with than hardware. A hardware change introduces a hard change and if the issue really is a software issue, a software fix should be used. That fix is easily removed when the base challenge gets resolved. Even better if the fix is a self contained little package you can simply disable and remove once the base issue gets resolved. That way you do not need to touch the hardware at all, which is always better for reliability. And… mechanical relays are notoriously problematic, a thing of the stone age to be avoided if at all possible. We once had to use interposing relays in the output circuitry of a Triconex Tricon(R) … of course the loop’s SIL rating went out the window…
My custom python code is developed and has been test running in PyCharm on my laptop. The Mosquitto MQTT broker is running on my Docker capable Synology NAS, a DS220+. Once my custom code is sufficiently debugged, I package it in a Docker image and run it in a Docker container on the NAS. I would never tinker with the OpenEVSE itself, it is not my place to do so. I’m not in the project. I’m in mine
Ah, another punchline about software is the definition of mature software: when the next software patch introduces an equal amount of problems it resolves!
Well, it looks as if my issue has been fixed.
Glyn Hudson sent me a link to V4.1.3 of the firmware and the system seems to be working as it should now.
I have got lost here. Bill, when you say it’s fixed with this firmware update is that only for your issue or does it fix the problem with Peugeot cars too?
This fix may not address any of the other issues that people have, and it’s probably still got bugs. (I notice than after charging has stopped due to inadequate PV, it restarts charging at 30A and doesn’t necessarily reduce in a timely manner.)
However, my needs are simple and it now does what I want it to do.
Bill, sorry to fill your post with Peugeot matters. Maybe this should be posted somewhere else.
Philippe, I have some good news and some bad news, mainly good. I bought the Peugeot e2008 this week and find that it does not lead to the bad behaviour noted here. I.e. when the sun goes in and the charge stops it does not stayed paused for ever. It restores when the sun returns.
Elsewhere I have read that some cars have a maybe 10 cycle limit on this so possibly it won’t do it after that number of cycles. Not got it there yet. Today is day 1 of its charging from the Open EVSE.
I did not write my controlling software, a friend did, so I don’t fully understand its functionality. And I don’t understand the Emons MQTT software. But what I think may be the difference between the official OpenEVSE setup and mine is this.
Official:
When sun goes in/house consumption goes up too much, after a few minutes to check it not just a very temporary blip, set Pilot to 0 amps.
When sun comes in/house consumption goes down, after a few minutes to check it not just a very temporary blip, set Pilot to 6 amps. Restart charge adjustment process
Mine:
When sun goes in/house consumption goes up too much, after a few minutes to check it not just a very temporary blip, set Pilot to 6 amps using a rapi command (am not using MQTT). And send a rapi Pause command.
When sun comes in/house consumption goes down, after a few minutes to check it not just a very temporary blip, remove the Pause command. Leave Pilot at 6 A and restart charge adjustment process.
If true it’s the issuing of a 0 amps command that the Peugeot can’t cope with.
The slight annoyance is that when you walk near the car with the key it thinks you are wanting to disconnect the lead so stops the charge and restarts when you walk away, or 30 secs later. Thus wear and tear of car and charge point relays. You can’t check the SOC on dashboard without instigating this pause and I think that would be true of non-proximity keys too. E.g. say you are at public charge point and wander off to grab a coffee. When you return to sit in car to drink the coffee it will stop the charge for 30 secs. Maybe there is a setting in the car somewhere to stop this behaviour.
