matth-x / MicroOcpp

OCPP 1.6 client for microcontrollers
MIT License
330 stars 139 forks source link

Various timeout errors when testing MicroOCPP example with evcc #335

Open BorisBrock opened 1 month ago

BorisBrock commented 1 month ago

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

Screenshot from 2024-07-12 11-01-28

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?

matth-x commented 1 month ago

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

https://github.com/matth-x/MicroOcpp/blob/8b1f0fdbae8785c49453f0b2d54a1a8db2fbe3ed/examples/ESP/main.cpp#L71

into setSmartChargingPowerOutput

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

BorisBrock commented 1 month ago

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.

matth-x commented 1 month ago

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.

BorisBrock commented 1 month ago

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

matth-x commented 1 month ago

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

https://github.com/matth-x/MicroOcpp/blob/8b1f0fdbae8785c49453f0b2d54a1a8db2fbe3ed/platformio.ini#L22-L23

BorisBrock commented 1 month ago

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

  1. Before I start charging, everything is fine (no timeout errors in evcc)
  2. When I start charging, the timeout errors pop up
  3. 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

matth-x commented 1 month ago

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.