SW2: Einfache MQTT-Topics zum setzen des Lademodus etc

[openWB]

Die Doku ist aktuell wenn der PR gemerged ist
https://github.com/openWB/core/pull/2914

[bennysweb]

Ist denn die Doku https://wiki.openwb.de/doku.php?id=open ... :simpleapi noch passend zur aktuellen Alpha?
ich kann mit den dort angegebenen Topics weder den minimal_pv_soc noch den instant_charging_limit_soc setzen, sehe aber auch das entsprechende Topic für minimal_pv_soc nicht im Explorer.

Was ich noch vermisse, was auch in den aktuellen PRs nicht auftaucht, wären:
- SoC-Limit für PV-Laden
- SoC-Limit Ziel-Laden
- am liebsten auch "Zeitplan aktivieren/deaktivieren" und "Uhrzeit setzen" für Zeitplan - verstehe aber, wenn das erst mal zu kompliziert wird.

Ja, das fehlt mir auch noch (zusätzlich noch SoC-Limit für preisbasiertes Laden)... Wäre es möglich, das noch zu implementieren?

[Andi]

Vielen Dank für die ganzen Anpassungen an der simpleAPI! Das wird nun schon ganz gut.

Allerdings gibt es einen Punkt der mir gerade noch die Nutzung sehr schwer macht:

beim Schreiben des Chargemode ist folgende Definition der Lademodi gegeben:
set_chargemode instant, pv, eco, stop, target

Beim Lesen des Chargemode über
openWB/simpleAPI/chargepoint/5/chargemode

kommt aber eine andere Definition zurück:
instant_charging, pv_charging_ eco_charging, stop und scheduled_charging

Das ist mega ungeschickt, da man dann nicht 1:1 einen Status sich merken kann und wiederverwenden kann! Jetzt müsste ich mir eine komplexe Mappinglogik aufsetzen um den Status zu merken und ggf. nach einem temporären Eingriff meiner Automatik wieder zurück auf den letzten "Usermode" zurückzuschreiben... Oder auch der Usecase zu prüfen ob der aktuelle Lademodus dem Sollmodus entspricht funktioniert auch nicht so einfach mit einem Vergleich.

Könntet ihr das bitte vereinheitlichen, so daß es keine unterschiedliche Definition des Lademodus innerhalb der simpleAPI gibt?

[Andi]

noch eine Ergänzung: ich fände die kurzen neuen Definitionen besser, da die alten längeren mit _charging im Zusammenhang mit KNX eh immer Probleme aufgrund der Länge gemacht haben (in einem String KNX Kommunikationsobjekt werden nur die ersten 14 oder 15 Zeichen übertragen...)

[openWB]

Um es zu vereinheitlichen wäre ich nun tatsächlich auf die selben Namen wie lesend gegangen da nochmal eingängiger.

[Gero]

Wenn man in header-files oder sonstwo Konstanten definiert, ist das mit den langen Namen sicherlich aussagekräftiger als nur was kurzes. Aber für den Modus selbst hat man den Wert früher auf ein paar Bit gekürzt. Wenn man heute ein paar Bytes dafür nimmt, wäre das meines Erachtens nach schon OK. Die angehängte Konstante „_charging“ halte ich für wenig hilfreich. Wer mag, kann sich seine Konstante für „pv“ ja gerne „chargemode_pv_charging“ nennen. Das würde ich vermutlich auch so machen. Das Literal selbst ist mit „pv“ eigentlich lang genug.

Aber vielleicht ist das Definieren von Konstanten ja old-school und weil ja Speicherplatz ja egal ist, nimmt man für das Literal halt 20 Bytes.

[Andi]

Hauptsache einheitlich, wie genau ist mir eigentlich egal, solange die ersten 15 Zeichen eindeutig unterscheidbar sind. Ändern muss ich meine ganzen Logiken jetzt eh nochmal, aber dann hoffentlich zum letzten mal.