SW2: Einfache MQTT-Topics zum setzen des Lademodus etc

[BJ Axel]

Das mit den einfachen einstellen der Lademodi per MQTT scheint ja wohl bei vielen ein riesen Thema zu sein deshalb kann man diesen Wunsch nur unterstützen und Nachdruck geben...

Und dazu bitte stabile Topics und nicht regelmäßige, fundamentale Änderungen.

[openWB]

Gerne mal die gewünschten Funktionen hier sammeln.
Auch was z.B. in Rahmen einer Benutzerverwaltung bzw Rechteverwaltung interessant wäre zu unterscheiden.

Geht es wirklich nur um den Lademodus?

[Hefer]

Gerne mal die gewünschten Funktionen hier sammeln.
Auch was z.B. in Rahmen einer Benutzerverwaltung bzw Rechteverwaltung interessant wäre zu unterscheiden.

Geht es wirklich nur um den Lademodus?

Aus meiner Sicht ja. Das würde mir erstmal reichen

[Gero]

Geht es wirklich nur um den Lademodus?

Ich würde an der Stelle noch den minimalen Dauerstrom mitnehmen. Da kann ich mir auch noch vorstellen, dass den im Zuge eigener Ladesteuerung einige setzen können wollen. Andererseits hat sich hier noch keiner mit dem Wunsch gemeldet. Wahrscheinlich machen die alle dann Sofortladen statt den Mindeststrom hochzusetzten. Oder es gibt mittlerweile nur noch ganz eenig Installationen ohne Speicher, so dass der die Aufgabe des Sammelbeckens übernimmt.

Alles andere im Ladeprofil erscheint mir eher zu statisch (Phasenamzahl, Einspeisegrenze, Priorität), zu komplex wie Zeit- oder Zielladen‘oder einfach selbst realisierbar. (Strommenge)

[Requiem]

+1 für die Topics, auch meine HA-Automation ist durch 2.1.8 zerschossen worden. Und das war mir Abstand die komfortabelste Art, den Lademodus zu ändern.

[openWB]

Message verstanden.

Was spricht denn dagegen die Topics in der Automation anzupassen?

Ich kann nachvollziehen das ein extra Topic nur mit dem Lademodus es einfacher macht (das nehme ich auch mit )
damit aber erstmal alles so wie vorher funktioniert, wie gehabt Topic auslesen, Lademodus auslesen / anpassen, Json zurück senden.

Exemplarisch für ein Ladepunkt 2:
Topic Lesen von: openWB/chargepoint/2/set/charge_template

Hier dann das gewünschte anpassen, z.B.

Code: Alles auswählen

"chargemode": {"selected": "pv_charging"

(oder eben instant_charging, usw...)

und das Json retained senden an: openWB/set/chargepoint/2/set/charge_template

[juli_august]

Hallo zusammen,

auch bei mir hat es leider die Automation zerschossen.

Ich hatte bisher mehrere Funktionen realisiert, die nun nicht mehr wie gewohnt laufen:

• Umschalten des Lademodus (PV / Sofort / Zeit / Stop etc.)
  Zusätzlich konnte ich im Sofortladen-Modus noch einstellen, ob ein Limit aktiv ist (keines / SoC / Energiemenge) und – falls gesetzt – direkt den gewünschten Wert (z. B. 85 % SoC oder 15 kWh Energie).
  Der große Vorteil war, dass meine bessere Hälfte ausschließlich in openHAB unterwegs sein musste – ohne zusätzlich in der openWB-Oberfläche etwas verstellen zu müssen.

• SoC-Schätzung ohne VW-Konnektivität (und ohne 99 €-Gebühr)
  Ich habe eine Logik gebaut, die erkennt, wenn das Fahrzeug die angebotene Ladeleistung nicht mehr zu über 90 % nutzt. Daraus schließe ich, dass der SoC bereits > 85 % liegt. In dem Fall sende ich automatisch ein STOP an die openWB – funktioniert im Alltag hervorragend.

Da openWB nun nur noch vollständige JSON-Topics akzeptiert, ist die bisherige Lösung über einzelne Items in openHAB leider nicht mehr praktikabel.
Ich müsste künftig den kompletten JSON-Inhalt erst auslesen, gezielt manipulieren und dann vollständig zurücksenden. Das ist technisch machbar, aber im Vergleich zu früher ein deutlicher Mehraufwand – gerade aus openHAB-Sicht.

Vielleicht gibt es ja mittelfristig wieder eine einfachere Möglichkeit, nur Teilparameter zu schreiben – das wäre wirklich hilfreich.

Viele Grüße
Julian

[Gero]

auch bei mir hat es leider die Automation zerschossen.

Nein, hat es nicht. Das was Du früher aus deiner Automation heraus verändert hast, wird weiterhin verändert, das ist nämlich das Ladeprofil. Eine Änderung am Ladeprofi bewirkt nun - also mit 2.18 nicht mehr eine Änderung des Lademodus am Ladepunkt.

Dafür gibt es ein neues Topic. Bitte nimm dieses statt des Ladeprofils. Wie es heißt, steht oben. Inhaltlich ist es immer noch ein Ladeprofil.

[Andi]

Message verstanden.

Was spricht denn dagegen die Topics in der Automation anzupassen?

Mehrere Dinge:
- man muss erstmal das richtige Topic finden in das man schreiben muss. Wer kommt drauf das man in ein topic chargetemplate tiefer reinsehen muss wenn es vorher auch ein eigenes topic für den Lademodus gab? Eine saubere MQTT Doku fehlt leider seit anbeginn und wäre genau jetzt bei solch essentiellen Umstellungen eigentlich mehr wie nice to have aus meiner Sicht.
- man muss dann ein sehr verschachteltes JSON verarbeiten und erstmal die Struktur verstehen. Das geht mit gängigen Automation Tools nicht ohne weitere JSON Kenntnisse und weitere zu erstellende Logik(en) und ist für einen reinen Hausautomatisierung Endandwender ohne SW Kenntnis schon eine extreme zusätzliche Hürde!
- dann muss man wieder ein komplettes geändertes JSON zusammenbauen und auf das richtige topic senden

Für mich war das kein riesen Ding, aber auch ich habe ehrlicherweise mehrfach bei der Umsetzung geflucht daß man das so verschlimmbessern und aus meiner persönlichen Sicht auch intransparent machen musste!

Daher kann ich die Reaktionen hier gut verstehen...

[Andi]

und es ist auch zum Auslesen und weiterverarbeiten deutlich komplizierter geworden da man für jeden Einzelwert um ihn in seine Anwendung zu bekommen nun mit komplexen JSON Strukturen arbeiten muss. Früher konnte man einfach den payload direkt weiter verarbeiten, jetzt muss man ihn sich erstmal mühsam aus einem JSON extrahieren.