RCT: add battery control #18178
RCT: add battery control #18178
Conversation
|
@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. |
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. |
|
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 |
Why? Battery does that itself?! |
|
I have set |
|
So: what to use for hold (but still charge surplus)? You'll need to tell me- I can't test this... |
|
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) |
|
You could set |
|
Welches Datenformat braucht da der Parameter? 1 Byte? Float32? |
|
Laut rctclient ist das ein float. // 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
} |
|
Das Runden der Zahl kannst du weglassen. Das ändere ich noch im PR. |
|
Du kannst nochmal probieren. Wenn das nicht funzt gerne nach Bedarf anpassen. |
|
Kannst du für |
|
Das kannst du im Template ändern. |
|
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... |
|
|
|
Hab's mit einem separaten PR gelöst. |
* Update dependency * fix BatteryCharge * add defaults * add comment
* Update dependency * fix BatteryCharge * add defaults * add comment * change battery mode logic
|
Das ist die beste Lösung, die ich finden konnte. |
|
@andig Soll es noch mit evcc getestet werden? Ich habe keinen dynamischen Tarif. |
|
Soll ich noch einen PR erstellen, um den Lint-Test zu fixen? |
|
Fixed. You can avoid this using VScode with Go plugin. |
|
@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. 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? |
|
Leider nein- das passt nicht in die Logik. Man könnte allenfalls den Start von Charge/Hold mit Fehlermeldung verhindern. |
|
Dass die Batterie die Kalibrierung ungestört machen kann, wäre sehr wichtig. |
|
Dann gibt es wahrscheinlich auch keine Logik, um zum Beispiel 1 Minute bevor die Kalibrierung startet in den BatteryNormal Modus zu wechseln? |
|
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. |
|
Kann ich dafür einen PR machen? |
|
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. |
|
Habe den PR eingereicht, siehe #18417. Ich habe den Code lokal kompiliert und ausgeführt. Funktioniert bei mir ohne Probleme, zumindest was Jetzt bleibt uns nur noch übrig, auf mlnoga/rct#20 zu warten. |
|
Du kannst alles mit testen. |
|
Habe es ausgeführt: Ich interpretiere das mal als erfolgreich. Bin ich damit richtig? |
|
Wie sieht hier das weitere Vorgehen aus? |
|
Magst du den Konflikt auflösen? Es wäre super wenn wir mlnoga noch mit rein bekämen. |
|
Den Konflikt schaue ich mir an. 👍 |
Wie hast du das gelöst? Ich habe den RCT in HA integriert. Dort wird auch "Battery Status" gelogt. Allerdings steht das die ganze Zeit auf Normal und ändert sich im Monat nur für ein paar Sekunden auf was anderes. Das verwirrt mich etwas weil diese Kalibrierung mit Akku ganz aufladen und dann entladen dauert halt länger als nur ein paar Sekunden. Wie ist das bei dir? Also ich kenn die technische Doku aber hast du mal beobachtet was der RCT tatsächlich tut wenn er die Batterie kalibiert? Es gibt auch noch ein weiteres Feld "Next Calibration" oder so. Da steht bei mir aber seit Ewigkeiten schon dasselbe Datum drin... Interessant ist ob der RCT sich überhaupt übersteuern/stören lässt wenn er grad kalibriert... |
|
Wie der Status der Batterie beim Kalibrieren ist, konnte ich noch nicht selber herausfinden, weil meine Batterie noch nicht kalibriert hat. Das mit dem Übersteuern will ich persönlich nicht ausprobieren, wobei mich das Verhalten dabei schon interessieren würde. |
|
Ja berichte mal was dein RCT macht. Bei mir ändert sich der Wert nur für ein paar Sekunden... |
Depends on mlnoga/rct#18, mlnoga/rct#20