Raw data reporting different phase currents

[deqw]

Just started charging 3 phase at 13A. Lost WiFI when charging started. Restored WiFi by disabling and enabling again. The SmartEVSE is reporting in the display: CHARGING 13.0A. The Eastron reports: L1 12.20A, L2 12.02A, L3 12.15A. Looking good.

The raw data reports: {"version":"SERKRI-1.4.1","mode":"NORMAL","mode_id":1,"car_connected":true,"evse":{"temp":36,"temp_max":65,"connected":true,"access":true,"mode":0,"solar_stop_timer":0,"state":"Charging","state_id":2,"error":"None","error_id":0,"rfid":"Not Installed"},"settings":{"charge_current":130,"override_current":0,"current_min":6,"current_max":13,"current_main":25,"solar_max_import":0,"solar_start_current":4,"solar_stop_time":10,"3phases_enabled":true,"mains_meter":"Eastron"},"home_battery":{"current":0,"last_update":0},"ev_meter":{"description":"Eastron","address":102,"import_active_energy":0,"total_kwh":718,"charged_kwh":0},"mains_meter":{"import_active_energy":1794.8,"export_active_energy":0},"phase_currents":{"TOTAL":20,"L1":7,"L2":7,"L3":6,"last_data_update":1661794952,"original_data":{"TOTAL":20,"L1":7,"L2":7,"L3":6}},"backlight":{"timer":120,"status":"ON"}}

[deqw]

And now just a few minutes after the previous post WiFi died again, while charging continues. Anyone having the same behaviour?

[k-janssens]

No, has been stable here, also after the latest update. Did you loose Wifi after the charging started or was it just coincidence?

[deqw]

Maybe a coincidence, don’t know. Other devices on the same AP had no problem. The SmartEVSE WiFi recovered itself after ten minutes. Going to charge again now, let’s see what happens.

[deqw]

And how about the phase details not reporting the Eastron data? Just started 3 phase charging again with about 12A per phase but raw data is like L1 0.8A, L2 1.0A, L3 0.6A. Mode is Normal.

[k-janssens]

I'm using the sensorbox myself so not much experience with those eastrons.

I remember something about adding an additional eastron config to the code. Was it you who needed this?

At the moment I only see these two: {"Eastron", ENDIANESS_HBF_HWF, 4, MB_DATATYPE_FLOAT32, 0x0, 0, 0x6, 0, 0x34, 0, 0x48 , 0,0x4A , 0}, // Eastron SDM630 (V / A / W / kWh) max read count 80

{"InvEastrn", ENDIANESS_HBF_HWF, 4, MB_DATATYPE_FLOAT32, 0x0, 0, 0x6, 0, 0x34, 0, 0x48 , 0,0x4A , 0}, // Since Eastron SDM series are bidirectional, sometimes they are connected upsidedown, so positive current becomes negative etc.; Eastron SDM630 (V / A / W / kWh) max read count 80

[k-janssens]

Btw, I've added some wifi info in the endpoint in the new 1.4.2 version. It returns things like the RSSI, it's not much data but it could be useful if you keep having wifi issues.

[deqw]

I remember something about adding an additional eastron config to the code. Was it you who needed this?

No that was not for me.

Will update to 1.4.2 romorrow. Thanks.

[k-janssens]

Any updates on this issue?

[deqw]

I've gone back to 1.4.1 and done only charging in Smart mode to prevent possible damage.

[k-janssens]

And 1.4.1 is working normal? Why do you think the 1.4.2 would cause any damage? The only difference between .1 and .2 is 10 lines of code to add some additional data to the API response.

[deqw]

I really can't tell you. I've switched to Smart 1 phase charging due to the incorrect current reporting when doing 3 phase. Point with this experiments is that the car is charging 1 minute then stopping, change settings, try again, stopping again etc. Can't be good so I stopped with that.

[dingo35]

Perhaps you could compare the readouts on the Eastron device itself to the raw data?

[deqw]

Hi @dingo35, I did, see my 1st post in this topic.

[k-janssens]

Yes, if charging is erratic I understand you stopped using it. I'm just trying to make sense what is wrong. If you said you moved back to 1.3.8, I can understand something went wrong as there has been a lot of changes. But between 1.4.1 and 1.4.2 the change cannot explain this behaviour.

[dingo35]

@deqw ok I misread your post.

Do the readouts of the raw data update every 5-10 seconds? The only thing I can think of is that an unstable wifi connection would prevent the raw data from being actual...

End of November I can test 1.4.2 with actual Eastron devices....

[deqw]

I should have gone back to 1.3.8, but did not try anymore as explained before. Reverting to Smart charging was enough for me to do my thing. Actually, I even considered the granny charger for the time being. I don't want to do any development and, unlike you guys, I'm just an end user for this. But be glad to help where I can.

What I'll do: I will go back to 1.3.8 before the next charge and use Normal mode and compare again the Eastron with the raw data. (I expect no difference and think that I just didn't notice it before, we will see).

[deqw]

Do the readouts of the raw data update every 5-10 seconds? The only thing I can think of is that an unstable wifi connection would prevent the raw data from being actual...

The data updates every 4 to 6 seconds. Also refreshed the page myself then.

[deqw]

{"version":"SERKRI-1.3.8","mode":"SMART","mode_id":3,"car_connected":"false","evse":{"temp":31,"temp_max":65,"connected":"false","access":true,"mode":1,"charge_timer":0,"solar_stop_timer":0,"state":"Ready to Charge","state_id":0,"error":"None","error_id":0,"rfid":"Not Installed"},"settings":{"charge_current":0,"override_current":0,"current_min":6,"current_max":13,"current_main":25,"solar_max_import":0,"solar_start_current":4,"solar_stop_time":10,"3phases_enabled":true,"mains_meter":"Eastron"},"home_battery":{"current":0,"last_update":0},"ev_meter":{"description":"Eastron","address":102,"power":0,"total_kwh":827902,"charged_kwh":0},"phase_currents":{"TOTAL":60,"L1":8,"L2":15,"L3":37,"last_data_update":1662985885,"original_data":{"TOTAL":60,"L1":8,"L2":15,"L3":37}},"backlight":{"timer":0,"status":"OFF"}}

Question: where are these reported phase_currents and original_data read from? Mains meter / EVSE meter?

[dingo35]

When you are using EV meters you are supposed to use Smart or Solar mode. In Normal mode these meters should be ignored.

Not sure what data is presented in Raw Data when in Normal mode; I would suggest not delivering L1-L3 data to the endpoints, but I can remember vaguely that the sensorbox is supposed to work in Normal mode...

[deqw]

Thanks for your clarification @dingo35. Leaving me confused behind now ;o). I'm at the point to believe this SmartEVSE is nog for my use case.

[deqw]

note aside: With 1.3.8 the communication errors are back immediately.

[deqw]

Gone back to 1.4.1 due to (stream of) communication errors.

[deqw]

When you are using EV meters you are supposed to use Smart or Solar mode. In Normal mode these meters should be ignored.

Not sure what data is presented in Raw Data when in Normal mode; I would suggest not delivering L1-L3 data to the endpoints, but I can remember vaguely that the sensorbox is supposed to work in Normal mode...

Updated to 1.4.3 now. To be sure about the @dingo35 quote above: What is the purpose then of using the meters when doing 3-phase charging? When using Smart mode only 1-phase charging is available.

[dingo35]

I'm running in Smart mode with three phase charging with Eastron meters for months; when I'm back to my SmartEVSE location I will try to reproduce your problem, but that will be end of November...

[deqw]

Thanks @dingo35 for taking time! I like to refer to a previous post here https://github.com/serkri/SmartEVSE-3/issues/18#issue-1214287269

@deqw : "if(Mode == MODE_NORMAL && enable3f) CONTACTOR2_ON;

Can you explain why this MODE_NORMAL is necessary?"

@k-janssens : "As far as I can see, the original code does not support 3 fase solar/smart modes. E.g. In solar mode and EVSE sees -6A is going to the grid, it'll say the car can load at 6A, but if it charges with 3fases it will load 6A x 3f which is 18

So to avoid any issues this is currently limited for manual mode only as the logic will most likely start flipping on/off otherwise"

(changed the URL and added quotes)

[dingo35]

@dewq, when I look at your raw data, I see that you have two Eastrons connected, one at your MainsMeter and one as EVMeter.

The "Phase currents" reported are the ones from the MainsMeter, NOT from the EVMeter. So that explains why your phase current readouts differ from your charge current, and differ from your EVMeter.

EDIT: The if(Mode == MODE_NORMAL && enable3f) CONTACTOR2_ON;

code is only important if you want to be able to SWITCH from 1phase charging to 3phase charging and back; you need a second contactor for that. Most people just have one contactor installed, and in that configuration you can do a session of 1phase charging or a session of 3phase charging, but you cannot switch between 1phase/3phase within a session. I'm pretty sure this has nothing to do with your issue.

[deqw]

Don't know @dingo35, but then the MainsMeter reports less current than the EVMeter reports putting into the car? It is some time that I looked into this and havent used the SmartEVSE for some time now (don't drive that much and last time used a public charger to top up).

About Smart mode and CONTACTOR2_ON: I do have a second contactor installed. My point is: when in Smart mode 3 phase charging is impossible, which is exactly what that if-statement prevents when not using Normal mode.

Thanks for picking up again after your absence!

[dingo35]

The problem was that the software, in its original development, didn't expect MainsMeter to be connected in Normal mode; so the MainsMeter data was never read.

Now one could argue it doesn't make much sense to run in Normal Mode if you have a MainsMeter connected, but since the config possibility is there, everything should work as expected.

Fixed this with commit f897f94adf7846e10eb73a3488889a43f3feb1b0, @deqw could you test the newest Master?

[deqw]

That's it, I think. But to do a 3phase charge I was forced to Normal mode. I thought the whole idea of these two meters was that the SmartEVSE current could be limited based on the current(s) reported by the MainsMeter when using Smart mode. Is that now the case in your latest change? It would be nice if, when meters are available, that their currents are reported in the raw data output too. Anyway, can you provide me with a binary to test?

[dingo35]

firmware.bin.gz

Ok now I understand why you went back to Normal Mode. I suspect that the enable3f is restricted to Normal Mode because the author of that piece of code was unsure of the consequences for the other modes....

[deqw]

The answer is already in the @k-janssens quote in my last 23 September post above.

Thanks for the binary. Will test and report back.

[deqw]

@dingo35 I have uploaded your binary but have nothing to charge at the moment. Will let you know later. Do I understand correctly that the 3-Phase charging limit, only when in Normal mode, remains in place?

[dingo35]

I am consulting with the author of that piece of code on this topic...

[deqw]

Top!

[dingo35]

@dewq and others: In branch enablec2 you will find a new version; the parameter "enable3f" has been changed to "Enable Contactor 2"; please read the README.md in the upper SmartEVSE-3 directory. You can help by testing this experimental version! You MUST reflash spiffs.bin after flashing the new firmware.

firmware.bin.gz spiffs.bin.gz

[deqw]

@dingo35 Thanks again for your effort. I downloaded both bins, but on uploading the spiffs.bin I get a FAIL returned. The new firmware uploads fine. I had the same problem with the latest original Stegen firmware; reported this there but never got any reaction on that issue (that was reported later by someone else).

[dingo35]

Is your wifi connection steady?

Just try it a few times, a fail usually doesn't mean the file is corrupt, but that the connection was disturbed. Im sure you didn't forget to gunzip the spiffs.bin.gz ... The md5sum should be: ec8de0f4e23244751bbe66218c015bed spiffs.bin

[deqw]

In mean time, phase currents reporting fine now:

version":"18:00:26 @Nov 24 2022","mode":"NORMAL","mode_id"

"phase_currents":{"TOTAL":389,"L1":130,"L2":132,"L3":127,"last_data_update":258824,"original_data":{"TOTAL":389,"L1":130,"L2":132,"L3":127}}

[deqw]

My connection is as steady as can be. Signal 100% (-47 dBm). Tried already ten times to upload spiffs.bin, reboot, other firmware etc.

I am 3-phase charging the car now with version":"18:00:26 @nov 24 2022", need it fully loaded tomorrow.

[dingo35]

Just reflashed that spiffs.bin without any problem.

Perhaps you can ping to your smartevse while flashing, so you can see what happens?

Is your SmartEVSE perhaps overloaded by Homeassistant or EM_API use?

[deqw]

OK, found the problem: the name of the file needs to be exact "spiffs.bin", not like "spiffs2.bin", "spiffs3.bin", etc, which naming results from unpacking consecutive versions in the same download directory. What is that constraint for? Anyway it is uploaded now.

[dingo35]

Well RTFM. The upload screen says very clearly that you can upload firmware.bin or spiffs.bin.

The software determines to which addresses it is going to upload determined by the name. So uploading "i_don_t_read_the_screens_very_well.bin" would obviously result in a fail.

[deqw]

i) Then why does let the upload screen let me choose from any filename I like? Put the constraint there and don't bother me with useless feedback like just a text FAIL.

ii) Then why is uploading firmware_xyz.bin-2 no problem at all?

Your latest firmware works fine.

But overthink your latest reaction to me some time when you are cooled down again. I'm out.