Yet another EmonEVSE pv divert problem

glyn.hudson · 5 May 2022 16:17

Hi Bill,

Sorry to hear you’re having issues, could you let me know the WiFi firmware version and OpenEVSE controller FW version you’re running, and I’ll investigate. Thanks for posting detailed screenshots, that’s very useful.

What make and model of EV are you charging?

It would be very helpful if you could post the RAPI output (OpenEVSE serial console) when the PV divert is misbehaving, e.g

It should look something like this

$GP^33
$OK 297 281 -2560^2B
$SV 229940^05
$OK^20
$SV 229970^06
$OK^20
$OK^20
$SV 229430^0F
$OK^20
$SV 229390^02
$OK^20
$SV 228090^00
$OK^20
$OK^20
$SV 230860^0E
$OK^20
$GS^30
$OK fe 3546 01 0200^24
$GP^33
$OK 297 281 -2560^2B
$SV 229850^05
$OK^20
$SV 229680^06
$OK^20

It looks like there is an issue with pilot signal not correctly communicating the current value to the EV or the EV not responding correctly. There seems to be subtle differences between EVs, particularly with how some EVs don’t correctly follow the protocol when it comes to sleeping and pausing a charge.

billt · 5 May 2022 18:28

Hello.

The WiFi firmware is 4.1.2 and the OpenEVSE firmware is 8.2.0.T2.

Openevse3

The car is a Hyundai Ioniq Electric 38kWh, 2021.

The RAPI output will have to wait, but I will get it at the next opportunity.

That was the sort of thought that I had.

greentangerine · 6 May 2022 07:20

Having looked at the code, I think my specific issue is that I need to set the divert_PV_ratio higher to account for the positive export. I’ve changed it from 1.1 to 1.3 to see what happens.

billt · 7 May 2022 09:19

Just started charging and here’s a sample of the RAPI output, when itshould have been charging at about 20A.

$OK 30140 222010^15
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222010^15
$GU^36
$OK 6732240 16584^28
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222010^15
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222010^15
$GU^36
$OK 6744221 16584^2E
$FP 0 0 Charging��30.14A^44
$OK^20
$FP 0 1 Energy��1.9kWh^43
$OK^20
$GG^24
$OK 30140 222010^15
$SV 222000^03
$OK^20
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222000^14
$GU^36
$OK 6758270 16584^27
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222000^14
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222000^14
$GU^36
$OK 6772312 16584^2A
$FP 0 0 Charging��30.14A^44
$OK^20
$FP 0 1 Lifetime��17kWh^8C
$OK^20
$GG^24
$OK 30140 222000^14
$FP 0 0 Charging��30.14A^44
$OK^20
$SV 222020^01
$OK^20
$GG^24
$OK 30140 222020^16
$GU^36
$OK 6784353 16584^26
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222020^16
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222020^16
$GU^36
$OK 6798395 16584^21
$FP 0 0 Charging��30.14A^44
$OK^20
$FP 0 1 EVSE�Temp��20.6C^9D
$OK^20
$GG^24
$OK 30140 222020^16
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222020^16
$GU^36
$OK 6812571 16584^20
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222020^16
$SV 222560^00
$OK^20
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222560^17
$GU^36
$OK 6824621 16584^23
$FP 0 0 Charging��30.14A^44
$OK^20
$FP 0 1 Energy��1.9kWh^43
$OK^20
$GG^24
$OK 30140 222560^17
$FP 0 0 Charging��30.14A^44
$OK^20
$GS^30
$OK 03 1055 03 0540^20
$GG^24
$OK 30140 222560^17
$GP^33
$OK -2560 207 -2560^35
$GU^36
$OK 6840722 16584^23
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222560^17
$FP 0 0 Charging��30.14A^44
$OK^20
$SV 222470^00
$OK^20
$GG^24
$OK 30140 222470^17
$GU^36
$OK 6852787 16584^2F
$FP 0 0 Charging��30.14A^44
$OK^20
$FP 0 1 Lifetime��17kWh^8C
$OK^20
$GG^24
$OK 30140 222470^17
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222470^17
$GU^36
$OK 6866864 16584^2A
$FP 0 0 Charging��30.14A^44
$OK^20
$GG^24
$OK 30140 222470^17
$FP 0 0 Charging��30.14A^44
$OK^20
$OK 30140 222470^17
$GU^36
$OK 6878930 16584^25
$OK^20
$OK^20
$GG^24
$OK 30140 221990^17
$GG^24
$OK 29920 221990^11
$OK^20
$OK^20
$GG^24
$OK 30140 222360^11
$GU^36
$OK 7079843 16584^28

FChan · 8 May 2022 08:25

Quote @billt , I can see your point since you have the EMONEVSE. I have the OpenEVSE.

What is the difference? I have an Open ESVE but I don’t use an EMON setup to deliver the power readings to it or use the Open ESVE software to drive the current up and down. Have my own software for that. It works well although just occasionally I also get funny things happen for reasons unknown.

Anyone tried an Open ESVE with a Peugeot e2008? Thinking of buying one. I can easily believe that different manufacturers interpret the international standards differently causing problems for the ESVE makers.

Also thinking of adding a type 2 socket onto it as the existing Leaf uses Type 1. Would need some relays to switch between the 2 sockets depending on which car is connected. Anyone tried that?

billt · 8 May 2022 08:58

Electrically I believe that EmonEVSE and OpenEVSE are the same. EmonEVSE is assembled and comes in a different enclosure with a socket built in. The OpenEVSE doesn’t have a connector supplied and needs to be assembled.

pdhoogh · 8 May 2022 20:20

Indeed that is what I meant. EmonEVSE is delivered as a ready made product. So you should expect guarantees on it working as advertised. You cannot expect this with a kit.

I have an OpenEVSE with a Peugeot e-208. The e-2008 is essentially the same car with a taller and longer body. And I have issues.

When using Solar PV divert with +I/-E, so excess solar goes to car i.o. grid, the OpenEVSE will stop the charge if no excess current is available or, to be more precise, import is required to keep charging the car. That’s good. After one minute of no charge, the e-208 goes to sleep. When excess solar is available again, OpenEVSE wants to resume charging. But the car does not respond. Charge is dead.

The official answer from the emon guys is “the car is not J1772 compliant, talk to Peugeot”.

Of course that is not helping. It does not change the fact that Solar PV divert does not work for the e-208. And Peugeot is not going to say “Hey, you’re right! Here is a software update to fix this!” They are much more likely to say, French as they are, “We don’t care about American standards, go bake yourself an egg!”

In the mean time I found a few things that do make the car accept a charge again once it went to sleep.

Cycle the door locks with the keyfob. Not very practical and far from “automatic”. It wakes up the car and makes it look at what is going on at the charge port. So: a good piece of data, but not a solution.
Reset the OpenEVSE, using the button on the “Hardware” panel in the OpenEVSE tab of the web gui. Now that is interesting!! So the car is not dead asleep beyond waking without poking it with the keyfob!! Seemingly, resetting the OpenEVSE does something that wakes the car !! What that is precisely I do not know. But it provides a way out that could be used. To hell with J1772 compliance. Who is being incompatible now? That depends on the viewpoint, it seems !!
Wake the e-208 over the cell network. I have been using the “flobz psa car controller” running in docker on my Synology NAS. You can issue http commands to it that will make it request Stellantis servers to wake up the car. And when you do, SUCCESS!! It wakes up and starts charging again.

OK, so 2 and 3 are promising. But they don’t work in the end.

2 does not because OpenEVSE EU does not live up to its documented promise you can issue RAPI commands using MQTT. I tried it, it does not work, I asked the emon guys what I’m doing wrong, maybe I am, but no ersponse so far. So I cannot help you.

3 does not work because Stellantis are French. “We noticed you are using cell services way too much, so we’ll cut you off and won’t tell you we did.” So now my iPhone “MyPeugeot” app is no longer working either.

I will persevere until I have a working solution. But not getting too much help so far.

OK, that being said, please do not use this data to make a decision about buying this car. The e-208 - and the e-2008 is even better in some respects - is a fantastic car. We love it. You cannot get anything better for the money, I believe. Of course it has to fit your requirements and we bought the e-208 for city dwelling and short trips. It is not as good for long haul. But apart from that, given today’s technical capabilities, I find Peugeot nailed every mark that counts. There are better cars, much more expensive though.

greentangerine · 9 May 2022 07:43

Not sure you can blame OpenEVSE for your car’s non-compliance.

I have the same problem with my MG5, only that it goes to sleep after six hours so PV divert generally works. The solution is to open the car and close it again. If I’m charging overnight, I unlock/lock the car before turning in to ensure it will charge. However my wife’s Zoe works perfectly and never fails to charge no matter how long it has been connected.

I did find that changing the ‘Pause Status’ setting under the advance settings solved the problem with the MG5 but that caused issues with the Zoe so reverted back to the default setting and live with the MG5’s quirks.

FChan · 9 May 2022 11:39

Have you considered adding a small 12V relay into the EVSE to cut the pilot/PWM signals for a few seconds? Would this reset the car and wake it up as its looks to the car like a new connection? However the car may notice that the plug has not been removed and reinserted as it is reading resistor inside the plug all the time, is it not? And/or could cycle the 12V to the PCB to reset the EVSE as you say that works to get it going again. You could fairly easily test it by just temporarily cutting the wires with a switch. You’d need some way to trigger the relay such as:

Cycle the relay on a fixed cycle every say 30 mins to reset the charging.
Or implement logic that did “IF current or voltage delivered to car = 0 cycle the relay. WAIT 30 minutes before doing it again (to stop it constantly short cycling when EVSE is off).”

So would need a small PCB to contain the logic for this.

My setup does not use MQTT, I just use my own microcontroller to issue the right RAPI commands via Wi-Fi to turn it on and change the current. Is there thus some chance I wouldn’t experience your problem with a Peugeot EV?

I don’t see why this is so. The kit which I used is just the guts of the ready made product. It all just plugs in and screws together. No skill needed. If it had to be soldered I’d agree with you. The only downside is that the version control of PCBs and firmware may not be quite so rigid in a bunch of bits not tested together at the factory. Also as you say the documentation is poor so it is not entirely easy the work out how to connect the bits together. Although easier for the full kit, I just bought a few parts of a kit.

Plea here , please would the powers that be here put all the right docs in one place? Many of the links just send you off to stuff about emon or other things not strictly connected with the Open EVSE or you find yourself googling for answers and looking at the USA product accidentally. Also the many updates to the PCBs and firmware confuse one. For instance it took me a long time to work out how to connect my own contactor. Different PCB versions have different connections and there are both 12V and 230V coil outputs on some PCBs. But the connection diagram may just show a relay coil. What voltage of coil?

I am talking about the Open ESVE side. No experience of the emon monitoring side.

FChan · 9 May 2022 15:30

May not be to blame but the realities of life mean that all EVSE manufacturers should be as flexible as possible to accommodate the car manufacturers’ slight deviations from the standard. E.g. it should be extremely easy to get the Open ESVE’s processor to (optionally?) reboot itself every say 30 mins to hopefully solve the Peugeot problem.

There is another similar kit product to the Open ESVE that comes with all sorts of things in its manual like “Only works with Leaf, XX and YY. Not tested on others.” or “Won’t work on a Tesla.” This may be due to their failure to comply with J1772 on some of their products or it may be the car’s non-conformance. I believe that J1772 is not that rigorously written so it’s possible to vary from another’s interpretation and both claim to be within the spec.

pdhoogh · 9 May 2022 15:56

@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…

greentangerine · 10 May 2022 07:45

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).

The pilot states and duty cycle are explained here - Basics of SAE J1772 : Support

FChan · 10 May 2022 09:28

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!

pdhoogh · 10 May 2022 09:29

@greentangerine : Thanks for the confirmation!

The info on /state topic can be found in the developers guide:

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”.

greentangerine · 10 May 2022 09:58

The states are defined in J1772EvseController.h.

// 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.

pdhoogh · 13 May 2022 08:10

@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!

billt · 13 May 2022 13:25

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.

FChan · 18 May 2022 09:40

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?

billt · 18 May 2022 10:14

Might give you a clue.

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.

I know nothing about Peugeot vehicles.

FChan · 3 June 2022 11:28

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.