Stuck at Preparing state after hard reset from ESP32 during the transaction phase with OCPP server.

[yourcomrade]

Hi @matth-x , I am currently using the MicroOCPP v1.2.0 with OCPP v1.6's functionalities. I notice that the charging station, which uses esp32 as main controller get stuck at the Preparation state after the RFID tag present. This happens if the esp32 suddenly has a reset during the Charging state and has a transaction still continuing with the OCPP server.
This is tested with Steve OCPP server.
Step to reproduce:

1. Charging station is in the Charging state and has an ongoing transaction with the OCPP sever.
2. Suddenly, a hard reset happens (This can be achieve by pressing reset button)
3. The charging station go back to available mode, and stuck at the preparing mode even after the present of RFID to enable charging.

In some situation, the esp32 has timeout or booting notification because the Steve server refuses to respone it. I think this happen because the Steve server doesn't know that the charging station has just reseting and still think that there is still a charging session going. So I have to manually stop the transaction in Steve, remove and re-add the charging station's id, and then reset the esp32 to make everything normal again. Is there a way to notify the OCPP sever that the charging station had resest so it can stop the transaction?

[razvanphp]

I think this is an implementation detail, in our case, on reboot, transaction id is retrieved from LittleFS and everything continues to work. You could tap into setOnSendConf("BootNotification", .... and check if you have a transaction and issue a manual endTransaction().

Not sure if there is a standard OCPP configuration value for it, but I guess it should be, as it can happen that energy goes down, one client leaves and next one who comes will charge for free (using the previous customer's account).

See #298