matth-x / MicroOcpp

Hi,
I'm pretty new to the world of EV/EVSE and OCPP. As a first step I flashed the MicroOCPP example code to a ESP32. On the other side I used a up-to-date version of evcc (as OCPP server).
This works very well, and MicroOCPP and evcc harmonize perfectly ;-)

But as soon as I start the charging process from evcc, error messages start to appear:

[lp-2 ] ERROR 2024/07/12 11:01:54 charge power: timeout
[site ] DEBUG 2024/07/12 11:01:54 pv power: 4078W
[site ] DEBUG 2024/07/12 11:01:54 grid meter: -3968W
[site ] DEBUG 2024/07/12 11:01:54 site power: -3968W
[lp-2 ] ERROR 2024/07/12 11:01:54 charge rater: charge meter error timeout
[lp-2 ] ERROR 2024/07/12 11:01:54 charge total import: timeout

Is there something missing in the example? Should the MicroOCPP-code send more data?
If so, which functions would need to be implemented to report "charge power", "charge meter" and "charge total"?
Would it make sense to add these to the official example?

PS: In the serial output from MicroOCPP I see this warning coming up permanently:

[MO] info (RemoteStartTransaction.cpp:42): Setting Charging profile via RemoteStartTransaction
[MO] warning (SmartChargingService.cpp:569): unsupported charge rate unit

Could that be related to the problem?

Hi @BorisBrock, thank you for the kind words and the report!

Yes, that could actually be related. EVCC tries to start a transaction and sends a charging schedule for load management. This schedule is based on power values instead of currents, but the minimal ESP example can just process currents. Consequently, MicroOCPP rejects the request to start charging and doesn't send the power measurement and energy register as expected by EVCC.

The simplest workaround would be to change this SmartCharging handler

MicroOcpp/examples/ESP/main.cpp

Line 71 in 8b1f0fd

setSmartChargingCurrentOutput([](float limit) {

into setSmartChargingPowerOutput

Apparently EVCC just supports power-based load management which makes total sense for solar surplus charging.

Hi @matth-x ,
thanks for the quick response. I tried to replace setSmartChargingCurrentOutput with setSmartChargingPowerOutput, but that did not solve the problem. I also tried adding both setSmartChargingCurrentOutput and setSmartChargingPowerOutput handlers, but that also didn't help.

I still get

[MO] info (RemoteStartTransaction.cpp:42): Setting Charging profile via RemoteStartTransaction
[MO] warning (SmartChargingService.cpp:569): unsupported charge rate unit

when evcc tries to start the charging.

EDIT:
I also found setSmartChargingOutput(std::function<void(float,float,int)>. Using this instead of setSmartChargingCurrentOutput and setSmartChargingPowerOutput did the trick. The error message regarding the unsupported charge rate unit is now gone.

Sadly evcc still produces lots of timeout errors (see my initial post). So in that regard, there still seems to be a problem between evcc and MicroOCPP.

Thanks for testing it! Admittedly, it's very common that some manual configuration is needed for new OCPP connections. In the new protocol version 2.0.1, the auto-discovery mechanisms got a lot stronger though.

Can you share the communication logs? You may erase any private data of course like web addresses, IDs, etc.

Sure thing. I'll see what else I can get out of evcc.
Can I also do something on the MicroOCPP-side (e.g. enable more verbose debug outputs)?

Awesome.

Have you set the MO_TRAFFIC_OUT build flag as shown below? Also you can increase the debug verbosity by replacing MO_DL_INFO with MO_DL_DEBUG

MicroOcpp/platformio.ini

Lines 22 to 23 in 8b1f0fd

    
           -D MO_DBG_LEVEL=MO_DL_INFO ; flood the serial monitor with information about the internal state 
        
           -DMO_TRAFFIC_OUT   ; print the OCPP communication to the serial monitor

I've been looking at the evcc and MicroOCPP logs for an hour now :-)
Here's what I found out:

Before I start charging, everything is fine (no timeout errors in evcc)
When I start charging, the timeout errors pop up
After dismissing these errors, the system runs smoothly again (no more errors)

So the errors seem to only occur the moment I start charging with evcc.

In the MicroOCPP output I saw, that these kind of messages only appear once I started charging in evcc:

[MO] Send: [2,"1000018","MeterValues",{"connectorId":1,"transactionId":3,"meterValue":[{"timestamp":"2024-07-14T18:37:53.804Z","sampledValue":[{"value":"0","context":"Sample.Periodic","measurand":"Energy.Active.Import.Register","unit":"Wh"},{"value":"0.00","context":"Sample.Periodic","measurand":"Power.Active.Import","unit":"W"}]}]}]

Could this be an issue? Do these get sent too late by MicroOCPP? Should they be sent all the time (i.e. before evcc starts charging)? Or does evcc expect them too soon after starting to charge?

log_evcc.txt
log_mocpp.txt

It sounds like EVCC expects a MeterValue value message right at the beginning of the transaction while MicroOCPP only sends them after the measurement periods elapsed. I can imagine that setting the measurement interval in MO to a very low value like 5 seconds could be worth a try. The configuration key is MeterValueSampleInterval.

Can you maybe check in the EVCC issue section if this is a known problem? I never got any feedback that having another MeterValue message at the transaction beginning would be needed, however, if it turns out as a common practice, then I can imagine adding this behavior to MO for sure.

Another possible workaround is to keep sending MeterValues while no transaction is running by setting the configuration Cst_MeterValuesInTxOnly to false. This should work for now, but I'm considering deprecating that config in some future release.

	-D MO_DBG_LEVEL=MO_DL_INFO ; flood the serial monitor with information about the internal state
	-DMO_TRAFFIC_OUT ; print the OCPP communication to the serial monitor

Various timeout errors when testing MicroOCPP example with evcc