Release v3.5.0-RC2 - Can not start due to Comms Error

[Xnygra]

Describe the bug Charging do not start, Display says "EV meter Comms Error", which make sense since the EV meter (Eastron 3P) is switched of when not charging, but comes alive when charging starts. This seems to prevent charging to start. There is a breaking change due to the address of the EV meter, but its correct in my case. All works again when roll back to RC1

Upload your config {"version":"v3.5.0-RC2","mode":"OFF","mode_id":0,"car_connected":true,"wifi":{"status":"WL_CONNECTED","ssid":"Useme","rssi":-73,"bssid":"E4:5E:1B:FB:86:5A"},"evse":{"temp":28,"temp_max":65,"connected":true,"access":false,"mode":0,"loadbl":0,"pwm":1024,"solar_stop_timer":0,"state":"Charging Stopped","state_id":9,"error":"EV Meter Comm Error","error_id":4,"rfid":"Not Installed"},"settings":{"charge_current":0,"override_current":0,"current_min":6,"current_max":16,"current_main":22,"current_max_circuit":22,"current_max_sum_mains":600,"solar_max_import":11,"solar_start_current":5,"solar_stop_time":10,"enable_C2":"Not present","modem":"Not present","mains_meter":"API","starttime":1712175060,"stoptime":0,"repeat":0},"mqtt":{"host":"192.168.86.36","port":1883,"topic_prefix":"SmartEVSE-49475","username":"mqtt","password_set":true,"status":"Connected"},"home_battery":{"current":0,"last_update":0},"ev_meter":{"description":"Eastron3P","address":101,"import_active_power":0,"total_kwh":0,"charged_kwh":0,"currents":{"TOTAL":0,"L1":0,"L2":0,"L3":0},"import_active_energy":0,"export_active_energy":0},"mains_meter":{"import_active_energy":0,"export_active_energy":0},"phase_currents":{"TOTAL":249,"L1":79,"L2":82,"L3":88,"last_data_update":1712168038,"original_data":{"TOTAL":249,"L1":79,"L2":82,"L3":88}},"backlight":{"timer":120,"status":"ON"}}

[fluppie]

You put the kWh meter after the contactor? I think most/almost all people have differential switch => xx Amp breaker => kWh meter => contactor 1 or maybe 1&2 and then the ev type 2 plug? Any specific reason you cut off the kWh meter?

[Xnygra]

Yes, the EV meter is after the contactor. The EV meter was added after the initial installation, and due to physical limitation it was added after the contactor, in another cabinet where the Type 2 cable is terminated. It have been working flawless in that manner up till now, but yes, it should really be before the contactor, so I have a weekend project of rewiring and reorganising the setup. So maybe not a bug, it just my poor setup that have worked up till now. Thank you for pointing that out, should have thought about it myself.

[TommyboyNL]

I've got a similar issue, charging stops almost immediately after starting due to a communication error. However, I do not turn off the EV meter with the relay so it is always on. Communication with my EV meter does work (partly), because I can see the current on all three phases jump to 15,x A for a second. There are no other MODBUS devices attached. I am not using a termination resistor on either end. This issue is both during normal charging and smart charging. It worked with RC1, but not with RC2. A roll-back solved my issue. EV meter: Eastron SDM630-Modbus V2, purchased from SanderVunderink.

[dingo35]

Ok guys thanks for your bug report, this should fix it: cf35328e.zip

[Xnygra]

Thank you, I´ll try it this evening, will update you on the results.

[TommyboyNL]

Ok guys thanks for your bug report, this should fix it: cf35328e.zip

Unfortunately I am still getting a communications error, even when not charging. I forgot to mention that I also use the API to push my DSMR5 smart meter readings to the EVSE. I'll try disabling that and see if it changes something.

[dingo35]

Check your meter settings! Because we added some kWh meters your config might be off; see release notes!

[TommyboyNL]

I checked those meter settings yesterday and checked them again after installing cf35328e, they were correct. After disabling the mains meter I no longer got communications errors, so I think the problem is with the API calls. I am using the following YAML in my ESPhome config:

interval:
  - interval: 5sec
    then:
      - http_request.post:
          url: !lambda |-
              std::string url;
              float l1 = id(returnedl1).state > 0 ? - id(currentl1).state : id(currentl1).state;
              float l2 = id(returnedl2).state > 0 ? - id(currentl2).state : id(currentl2).state;
              float l3 = id(returnedl3).state > 0 ? - id(currentl3).state : id(currentl3).state;
              url.append("http://192.168.10.12/currents?L1=");
              url.append(to_string(l1*10));
              url.append("&L2=");
              url.append(to_string(l2*10));
              url.append("&L3=");
              url.append(to_string(l3*10));
              return url.c_str();

My car battery is basically full, so I do not have a lot of time to debug this at the moment.

[dingo35]

You can test without charging; does feeding the SmartEVSE with curl work?

curl -X POST "http://ip-addr/currents?L1=100&L2=200&L3=300"

...feeds your SmartEVSE with 10A,20A and 30A respectively on L1-L3. If you resend that info within 11 seconds you should not get a timeout.... If this works, the problem lies with your HA not feeding the SmartEVSE. If this doesn't work, the problem lies in our firmware...

[Xnygra]

I think a found why its not working for me, and its not related to the EV meter. The time on the LCD says the GMT time, but the Web GUI show the correct time, GMT+2. So when i push NORMA/SOLAR/SMART, nothing happens, and on the LCD it says starting 21.00 (when i pushed to start) and LCD clock says time:19.00. So this trigger the timer with an offset of two hours.

Where does the SmartEvse fetch its time from? can I manually change that?

Maybe a should start a new issue so this one not going OT from TommyBoys problem?

[dingo35]

No keep it at this issue, the symptoms are the same....

The webui gets its time from ntp from SmartEVSE, but gets its timezone from the OS/browser. The SmartEVSE gets its Timezone info from the Wifi Setup Portal; if you re-setup your wifi you will see the automatically detected timezone, that is then stored in NVS memory.

We had to upgrade the ESPAsyn_wifimanager from 1.14.1 to 1.15.1 because the author took 1.14.1 offline; that might cause the problem...

[devdems]

@dingo35 do you think that this fix that you did https://github.com/dingo35/SmartEVSE-3.5/commit/5707a8f5f0237050ef20e5641e9123581a6082c6 would resolve also this issue?

[dingo35]

If @Xnygra s report is accurate, it is not solved by the ntp change; his problem was that the timezone was inaccurate, your problem was that the time was inaccurate.

The starting/stopping is directly related to that: you were both delayed charging without noticing it, although it is clearly stated on the LCD screen AND the upper part of the webserver...

[Xnygra]

I did another try with the RC2 version, and restarted my router (Google nest wifi, if that matter) but still wrong time zone. And yes, it is stated delayed charging on the webserver, i just hadn't noticed that earlier, Start Time two hours ahead from that i pressed "Smart"

[dingo35]

@Xnygra: READ: If you don't resetup your wifi, your timezone will not change.

You can also try this alpha 3.5.1 test version that has a totally different webserver, wifimanager and timezone detection: 26eae13983e.zip

By the way, no spiffs.bin to flash there, we are getting rid of that...

[Xnygra]

@Xnygra: READ: If you don't resetup your wifi, your timezone will not change. Got it, didn't read your comment well enough.

The alpha 3.5.1 seems to work, got the correct time in display. Thank you.