RCT: add battery control

[andig]

Depends on mlnoga/rct#18

[andig]

@Maschga could you give this PR a try? I'm not sure I'm calling the right functions for hold/normal. Would be great if you could test this with an actual device.

[Maschga]

Normal looks good. 👍

Why do you use SOCTargetConstant for Hold?
According to do-gooder it should be SOCTargetExternal. Is SOCTargetConstant better? What is the effect?
Source:

evcc/meter/rct.go

Line 202 in dc00b24

return m.conn.Write(rct.PowerMngSocStrategy, []byte{rct.SOCTargetConstant})

[andig]

What is the effect?

I wouldn't know. It sounded as if the RCT would then hold the soc constant. However, that's also not what we want. Hold should prevent discharge, but still allow charge. Not sure how to best do this. I guess SOCTargetExternal with given Soc would still have the same problem.

[Maschga]

Is it evcc possible to calculate how much surplus is available in addition to charging the e-car and how many kw could still charge the battery? Then this could be added using power_mng.battery_power_extern.

[andig]

much surplus is available in addition to charging the e-car and how many kw could still charge the battery? Then this could be added using power_mng.battery_power_extern.

Why? Battery does that itself?!

[Maschga]

I have set power_mng.soc_strategy to Constant. This results in the target Soc of the battery being set to 50%. RCT then wanted to discharge the battery, which is currently full.

[andig]

So: what to use for hold (but still charge surplus)? You'll need to tell me- I can't test this...

[TobiasHuber1980]

Keine Ahnung, aber vielleicht hilft es euch ja...

External battery control is possible when the SoC target selection is set to "Extern":

Parameter: 0xF168B748 // power_mng.soc_strategy | t_enum (uint8_t) | SoC target selection

The following six values are possible:

0 – SoC target = SoC

1 – Const

2 – Extern

3 – Average Battery voltage

4 – Intern (default)

5 – Timetable

The power_mng.battery_power_extern parameter allows external control of the desired battery power:

0xBD008E29 // power_mng.battery_power_extern | t_float | Battery target power [W] (positive = discharge)

[Maschga]

You could set power_mng.soc_min to the current SOC value of the battery. This will prevent the battery from discharging, but the battery can still charge if there is excess power available.

[andig]

Welches Datenformat braucht da der Parameter? 1 Byte? Float32?

[Maschga]

Laut rctclient ist das ein float.
So sieht der Code im PR aus:

// SetSocMin sets the minimum SOC target (power_mng.soc_min) with the given value
func (c *Connection) SetSocMin(min float32) error {
	if min < 0.00 || min > 1.00 {
		return fmt.Errorf("invalid SOC min value: %.2f, valid range is 0.00 to 1.00", min)
	}

	// Round to 2 decimal places
	min = float32(math.Round(float64(min)*100) / 100)

	data := make([]byte, 4)
	binary.BigEndian.PutUint32(data, math.Float32bits(min))

	if err := c.Write(PowerMngSocMin, data); err != nil {
		return fmt.Errorf("failed to set SOC min: %w", err)
	}

	return nil
}

[Maschga]

Das Runden der Zahl kannst du weglassen. Das ändere ich noch im PR.

[andig]

Du kannst nochmal probieren. Wenn das nicht funzt gerne nach Bedarf anpassen.

[Maschga]

Kannst du für minsoc einen Default von 7% (also 0.07) und für maxsoc einen Default von 97% (also 0.97) angeben?

[andig]

Das kannst du im Template ändern.

[andig]

Braucht man für charge überhaupt external? Sonst könnte man da auch einfach nur den minsoc setzen und müsste gar nicht mit dem Modus rumfrickeln...

[Maschga]

@andig Kannst du mir für diesen PR Schreibzugriff geben? Würde gerne eine Implementierung committen.

[Maschga]

Hab's mit einem separaten PR gelöst.

[Maschga]

Super, das muss dann nur noch endgültig getestet werden.

[andig]

Kannst du das testen?

[andig]

Argh. Warum brauchts diese ganzen Werte? Ich möchte die nicht setzen falls es nicht absolut notwendig ist. Ich würde das gerne rückgängig machen, es sei denn es gäbe einen zwingenden Grund dafür.

[Maschga]

Um RCT zum Laden aus dem Netz zu bekommen, muss man ein bisschen herumexperimentieren. Das ist leider kein Feature von RCT.
Ich kann noch eine andere Möglichkeit ausprobieren, vielleicht muss man mit der nicht so viele Werte setzen. Aber ich glaube, dass für das Laden immer mindestens zwei oder drei Werte gesetzt werden müssen.

[Maschga]

Wird NewRCT() alle 30s im Intervall aufgerufen oder nur, wenn sich der Wert von api.BatteryMode ändert?

[andig]

NewRCT wird nur beim Start von evcc aufgerufen.

[Maschga]

Ach, Entschuldigung, ich meinte die Funktion batteryMode.

[andig]

Die wird wie die meisten Funktionen in evcc nur aufgerufen wenn es Änderungen gibt.

[Maschga]

Ist es möglich, dass von BatteryCharge direkt auf BatteryHold gesprungen wird oder gibt es Fälle, die nicht eintreten können?

[andig]

Alle Kombinationen sind möglich, z.b. wenn sich die Preise ändern oder ein Ladevorgang startet.

[Maschga]

Das ist die beste Lösung, die ich finden konnte.
Es sollte funktionieren, ich konnte es bisher nur mit der RCT App am Gerät testen, aber noch nicht mit evcc selbst.
Die Aufrufe sind aber die gleichen.

[Maschga]

@andig Soll es noch mit evcc getestet werden? Ich habe keinen dynamischen Tarif.

[Maschga]

Soll ich noch einen PR erstellen, um den Lint-Test zu fixen?

[andig]

Fixed. You can avoid this using VScode with Go plugin.

[Maschga]

@andig Mir fällt noch eines auf: Die RCT-Batterie macht periodisch Kalibrierungen. Wenn die Batterie gerade in diesem Modus ist (sei es Kalibrierung oder Balancing), dann wäre es super, wenn evcc auf BatteryNormal geht, ansonsten wird die Kalibrierung gestört.
Das lässt sich damit abfragen:
0x71765BD8 INT32 INT32 battery.status Battery status

Hier werden die zwei wichtigen Werte erklärt.

Ich kann gerne im mlnoga-PR die Werte zum Lesen hinzufügen, aber ich weiß nicht, wo die Logik in evcc am Besten hinpasst. Kannst du mir da helfen?

[andig]

Leider nein- das passt nicht in die Logik. Man könnte allenfalls den Start von Charge/Hold mit Fehlermeldung verhindern.

[Maschga]

Dass die Batterie die Kalibrierung ungestört machen kann, wäre sehr wichtig.
Dann auch gerne die Implementierung mit Fehlermeldungen.

[Maschga]

Dann gibt es wahrscheinlich auch keine Logik, um zum Beispiel 1 Minute bevor die Kalibrierung startet in den BatteryNormal Modus zu wechseln?

[Maschga]

Und meine letzter Gedanke: Vielleicht sollte im Fall, dass der Inselmodus eingetreten ist, die Batterie auch nur im Modus BatteryNormal bleiben. Sorry für die ganzen Spezialfälle.

[Maschga]

Kann ich dafür einen PR machen?

[andig]

Für "Modus nicht starten" gerne. Einen Hintergrundprozess der Modi wieder beendet würde ich nicht sehen oder wäre zumindest nicht RCT-spezifisch. Dafür fehlt mir noch der echte Bedarf.