Open BorisBrock opened 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
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
I've been looking at the evcc and MicroOCPP logs for an hour now :-) Here's what I found out:
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?
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.
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:
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:
Could that be related to the problem?