Add Peblar

[PieVo]

Hey EVCC team,

Here is a charger implementation for the Peblar chargers (https://peblar.com/products/ev-charging). Developer info on the modbus API is located at developer.peblar.com.

I've been using this implementation for a while and tested it for the 1p3p switchover to work. This switchover won't work on all variants due to relay configurations (and 1 phase connected systems ofc).

I've checked the doc build to run fine and cleaned out some lint errors. Can you review this code?

[PieVo]

Hmm, something bad happens to the currents, I'm getting a lot of these:

"Garage: charger logic error: current mismatch (got 15.1A measured, expected 12.2A)"

Need to find out if it is related to the recent changes.

[andig]

There is a 1A difference between set current and max phase current observed:

		// use measured phase currents as fallback if charger does not provide max current or does not currently relay from vehicle (TWC3)
		if !isCg || errors.Is(err, api.ErrNotAvailable) {
			// validate if current too high by more than 1A (https://github.com/evcc-io/evcc/issues/14731)
			if current := lp.GetMaxPhaseCurrent(); current > lp.chargeCurrent+1.0 {
				if shouldBeConsistent {
					lp.log.WARN.Printf("charger logic error: current mismatch (got %.3gA measured, expected %.3gA)", current, lp.chargeCurrent)
				}
				lp.chargeCurrent = current
				lp.bus.Publish(evChargeCurrent, lp.chargeCurrent)
			}
		}

[PieVo]

Hmm, something bad happens to the currents, I'm getting a lot of these:

"Garage: charger logic error: current mismatch (got 15.1A measured, expected 12.2A)"

Need to find out if it is related to the recent changes.

I've seen this happen on 2 different vehicles, it is not vehicle related..

• I assume the new current is set the end of the loop (pv charge current: x = y + z)
• The vehicle has plenty of time to set this new current (in my case 20s)
• The loadpoint charge currents used in lp.GetMaxPhaseCurrent are gathered in the start of the next loop.

Still need to dig into this further where this mismatch is coming from. Right now I can only say it happens on "changing" conditions such as cloud-sun-cloud.

[andig]

I've seen this happen on 2 different vehicles, it is not vehicle related..

Mhhm. And the version before the brushing did not show this?

[PieVo]

current-mismatch_debug.txt

I've seen this happen on 2 different vehicles, it is not vehicle related..

Mhhm. And the version before the brushing did not show this? I don't remember seeing this on my initial fork of about 2 months ago but the check seems added afterwards. I'll place some low level debug to see if this comes from the charger API.

Update: The charger input/current response of the EV seems ok to me. The charge logic seems to expect a value from 2 loops before...

[andig]

Did you find out whats wrong?

[PieVo]

Did you find out whats wrong?

Not really.. I'm trying to see what happens in the "charger logic error". For that, I added logging to the setCurrent & getPhaseValues functions. Here is what I get during a charger logic error:

In loop "n-1" the current is set to 15631mA via modbus to the charger. That current is applied in at most 5 seconds by the EV. (This EV always draws 0.8A less than the advertised limit).

In loop "n" the current is read back and is according to (my) expectation (14.9A). However the expectation from the charger logic error is another value, namely, a value mentioned as "max charge current" mentioned in loop n-1, being 13.4A.

At the end of loop "n" this "max charge current" of 13427mA is eventually set towards the charger.

My conclusion would be that the expectation of the charger logic error is actually 1 iteration too soon. What do you think?

[andig]

Didn‘t check the code yet, but why does the actual setCurrent only happen with one cycle delay? It is using the wrong value imho.

[PieVo]

Hi @andig, I've been testing this branch for the past weeks and have not seen more warnings regarding the current sanity check. Is there anything you would like to see changed? Otherwise this could be merged.