HTTP API: getParameters returns wrong values

[twityde]

I integrated Simple EVSE to my SmartHome System. If in unconect the car or stop loading, getParameter returns still the wrong State. After Login to the Simple EVSE UI the values will be correct.

Here are sample Data from my last charge 2 Days a go. Copied five minutes ago: {"type":"parameters","list":[{"vehicleState":3,"evseState":false,"actualCurrent":20,"actualPower":0,"duration":1013998861,"energy":5.28,"mileage":35.2,"meterReading":14.91,"currentP1":0,"currentP2":0,"currentP3":0}]}

After login to the UI: {"type":"parameters","list":[{"vehicleState":1,"evseState":false,"actualCurrent":20,"actualPower":0,"duration":0,"energy":0,"mileage":0,"meterReading":9.63,"currentP1":0,"currentP2":0,"currentP3":0}]}

And the log entry will be also wrong: {"type":"latestlog","list":[{"uid":"","username":"","timestamp":1558286890,"duration":3653892,"energy":4.39,"price":27},{"uid":"","username":"","timestamp":1558290917,"duration":1014021464,"energy":5.28,"price":27}]}

[andig]

in

server.on("/getParameters", HTTP_GET, [](AsyncWebServerRequest * request) {

we have

item["vehicleState"] = evseStatus;

and in

bool ICACHE_FLASH_ATTR queryEVSE() {

there is a lot of updating evseStatus.

However I'm not sure that evseStatus is really updated in every codepath.

[twityde]

In the menatime i checked the log file of my home assistant server. If i deactivate the wallbox by API, the esp returns "S0_EVSE successfully deactivated". For me it looks like queryEVSE(); in deactivateEVSE(true); does not work correctly. Maybe a sleep will help.

Can somebody try to reproduce this bug?

Steps to reproduce:

1. Connect car to SimpleEVSE
2. Activate EVSE by using the HTTP API
3. getParameters by using the HTTP API
4. Deactive EVSE by using the HTTP API
5. Get Parameters by using the HTTP API
6. Login to Web UI
7. Get Parameters by using the HTTP API

[andig]

Might help to post the api results after each step? Also: does it make a difference if you deactivate by api or the car stops charging?

[twityde]

@andig i tried it just now. If the car stops the charging, everything is correct. But it is reproducable everytime i stop via api.

[andig]

Could you share the api results up to where there‘s a difference? Is the root cause the api to stop or the missing ui login? Serms the stop api is the actual problem?

It might make sense to log the actual evse api output- maybe the root cause is in the evse firmware instead of here?

[twityde]

The getParameters returns: {"type":"parameters","list":[{"vehicleState":1,"evseState":false,"actualCurrent":20,"actualPower":0,"duration":0,"energy":0,"mileage":0,"meterReading":0,"currentP1":0,"currentP2":0,"currentP3":0}]} After the car stopped the charging.

Deactivating by API returns "S0_EVSE successfully deactivated".

      else if(strcmp(awp->value().c_str(), "false") == 0){
        if(evseActive){
          if(deactivateEVSE(true)){
            request->send(200, "text/plain", "S0_EVSE successfully deactivated");
          }
          else{
            request->send(200, "text/plain", "E0_could not deactivate EVSE - internal error!");
          }
        }
        else{
          request->send(200, "text/plain", "E3_could not deactivate EVSE - EVSE already deactivated!");
        }
      }

So deactivateEVSE(true) returns true. But in deactivateEVSE the result of queryEVSE() is not used.

I will try to attach a serial monitor and check the output.

[twityde]

Strange. With Putty attached it works like expected:

true
[ ModBus ] Query Modbus before activating EVSE
[ ModBus ] got EVSE data successfully
[ ModBus ] EVSE successfully activated
[ ModBus ] got EVSE data successfully
[ ModBus ] got EVSE data successfully
[ ModBus ] got EVSE data successfully
[ ModBus ] got EVSE data successfully
[ ModBus ] got EVSE data successfully
[ ModBus ] got EVSE data successfully
false
[ ModBus ] EVSE successfully deactivated
[ ModBus ] got EVSE data successfully

Update: I set up an dev enviroment and tried a delay(500) before the queryEVSE. Same bug. As a workarround i added queryEVSE(true) to getParameters:

    //
    //  HTTP API
    //

  //getParameters
  server.on("/getParameters", HTTP_GET, [](AsyncWebServerRequest * request) {
    queryEVSE();
    AsyncResponseStream *response = request->beginResponseStream("application/json");

It works, but i don't like it.

[andig]

It works, but i don't like it.

Its ugly because now the call becomes synchronous.

queryEVSE is always called from the main loop and getParameters will just use the latest value. You could add more logging to see if the query is called from the main loop after you have deactivated. I'd also suggest to add logging of the raw register values in queryEVSE in case the output from the EVSE is different in both cases.

[andig]

Actually, if you look here https://github.com/CurtRod/SimpleEVSE-WiFi/blob/master/SimpleEVSE-WiFi.ino#L1814 it seems if it won't be queries if evseActive=false- might this be the problem?

Update yes, think it is. In here https://github.com/CurtRod/SimpleEVSE-WiFi/blob/master/SimpleEVSE-WiFi.ino#L1803 it is only updated if the web UI is active which is not your case.

Imho EVSE update should be run in any case even if its deactivated?

[twityde]

I will change line 1814 and remove the condition evse Active.

But the question is, why does the queryEVSE in the deactivate function doesn't work?

Could it be that simple evse deactivate asynchronous?

[andig]

I‘m only guessing. Maybe it takes a Moment on the evse side? Then you would have a race condition.

[rtfmjoey]

I'm integrating with Domoticz and am running into the same issue. I noticed that when I have the EVSE web page open somewhere and then use the API everything works ok.

When I don't have the webpage open it takes somehwere from 5 to 60 seconds before anything happens and occasionally nothing happens at all...

/edit:

I removed evseActive == true from https://github.com/CurtRod/SimpleEVSE-WiFi/blob/eedada39687a09c09864bf51c3358a8911132b00/SimpleEVSE-WiFi.ino#L1811 and now the issue seems resolved.

[CurtRod]

with update to 0.2.8 the issue is resolved