Seite 5 von 8
					
				Re: Zielladen, temporär vs. persistent, Backend vs. frontend
				Verfasst: Mo Okt 27, 2025 7:12 am
				von ChristophR
				P.S.: Da es hier viel um die GUI geht, bindet Ihr electron mit ein, damit er sich frühzeitig Gedanken um Colors machen kann?
			 
			
					
				Re: Zielladen, temporär vs. persistent, Backend vs. frontend
				Verfasst: Mo Okt 27, 2025 7:29 am
				von openWB
				Ich habe koala immer im Blick. 
@electron 
Deine Meinung mag ich hier auch gerne hören.
			 
			
					
				Re: Zielladen, temporär vs. persistent, Backend vs. frontend
				Verfasst: Mo Okt 27, 2025 10:39 am
				von Gero
				...um die Entscheidung des Speicherorts zwischen persistent und temporär, also Backend vs Frontend oder Konfiguration und Ladepunkt vielleicht ein wenig in Frage zu stellen, möchte ich nochmal den Vorschlag hervorholen, die Ladepläne (also Zeit- und Zielladen) ins Fahrzeug statt ins Ladeprofil zu verlegen. Denn das Fahrzeug gibt's nur einmal und da stellt sich die Frage halt nicht wo man speichern soll und was man tun muss um die jeweilig andere Kopie des Plans aktuell oder halt auch nicht zu halten.
Ein Ladeprofil bekäme dann mehr Bedeutung eines Profils, was man für mehrere Autos verwenden kann und weniger die Menge an unterschiedlichen Ladeeinstellungen. Die Zeitpläne sind meiner Meinung nach eh so individuell, dass sie vermutlich nie eine so rechte Existenzberechtigung in einem Ladeprofil im Sinne von nutzbar für mehrere Autos bekommen hat. Im heimischen Carport oder Garage ist das ja jetzt schon so, dass da Auto = Ladeprofil ist. Wo wäre denn im Ladepark der Usecase, Ladepläne für eine Menge unterschiedlicher, aber ähnlicher Autos haben zu wollen? Den paar Poolfahrzeugen kann man ja einen identlischen, aber individuellen ladeplan zuweisen, genauso wie die Privatanwender es mit einem fahrzezgindividuellen Ladeprofil tun.
			 
			
					
				Re: Rückmeldungen 2.1.8 Release Patch 2
				Verfasst: Mo Okt 27, 2025 10:44 am
				von KLez
				Gero hat geschrieben: So Okt 26, 2025 10:11 am
Da wäre das Herauslösen der Zeit- und Zielladepläne aus dem Ladeprofil heraus vielleicht auch eine Option.
 
Wir hatten das ja in einem MQTT Thread kurz angekratzt, aber wie ich schon seit Jahren sage sind die völlig nutzlosen Ladeprofile das Problem. Die braucht einfach kein Mensch und ziehen einen riesigen Rattenschwanz weiterer Probleme nach sich. Sehr viele Diskussionen in diesem Forum drehen sich nur darum die Symptome daraus zu bekämpfen, nicht die Ursache.
Klar kann man die Zeit- / Zielpläne aus dem Ladeprofil entfernen, aber was bleibt dann noch übrig? Ich sags nochmal: Führt eine Diskussion darüber die Ladeprofile komplett abzuschaffen. Das würde zig Probleme auf einmal lösen und diese ganzen 0815-Krücken-Implementierungen unnötig machen.
Alle Einstellungen die aktuell im Ladeprofil enthalten sind, können neu sortiert entweder dem Ladepunkt oder einem Fahrzeug zugeordnet werden. Das zusätzliche Abstraktions-Layer in Form der Ladeprofile ist in meinen Augen so sinnlos wie ein Kropf. Es gibt einfach keinen sinnvollen Use-Case dafür und falls sich doch einer finden lässt, macht der höchstens 1% aller Fälle aus.
 
			
					
				Re: Zielladen, temporär vs. persistent, Backend vs. frontend
				Verfasst: Mo Okt 27, 2025 10:47 am
				von aiole
				Danke Gero!
Ich bin ehrlich - darüber habe ich auch schon nachgedacht. Sofern es das Problem des Überschreibens laufender Ladungen löst, finde ich den Ansatz echt überlegenswert.
@Klez
Ganz nutzlos sehe ich die Lade-Profile (noch) nicht - gerade bei großen Ladeparks.
Ladepunkt-bezogene Voreinstellungen halte ich für einen gravierenden  Rückschritt oder meinst du nur die Zuordnung von "Fahrzeug -> Ladepunkt" ?
Direktes Zuordnen der Ladepläne zum Fahrzeug + Fahrzeug-Profil + Lade-Profil könnte schon funktionieren, aber weniger ist in der praktischen Nutzung sicher mehr.
Bsp. Ladepark mit 30 EV:
3 unterschiedliche Ladeprofile erlauben dort z.B. 3x 10 Fahrzeug-Gruppen mit unterschiedlichen Ladevorgaben (Sofort, PV, Eco). Man will da nicht jedes EV anfassen.
nochmal weitergedacht:
Zuordnen der Ladepläne inkl. die ehemaligen Lade-Profil-Einstellungen direkt ins Fahrzeug + nur noch Fahrzeug-Profil und statt Lade-Profil eine Gruppierungsmöglichkeit, die unterschiedliche Lade-Modi erlauben würde, könnte für Ladeparks auch funktionieren.
			 
			
					
				Re: Zielladen, temporär vs. persistent, Backend vs. frontend
				Verfasst: Mo Okt 27, 2025 12:34 pm
				von Thomas aus W
				Aus meiner Sicht wäre eine "Verselbstständigung" der Ladepläne auch der richtige Weg.
Darüber hätte man zu einen die Möglichkeit, Ladepläne unkompliziert anzulegen und andererseits existierende nach Bedarf wiederzuverwenden. 
Ein Ladeplan sollte die Zeitangabe(n) enthalten, und ob mit PV und/oder Preisbeachtung geladen werden soll.
Zu nutzende Phasen und ähnliches bleiben im Lade-Profil des Fahrzeugs im passenden Lademodus-Abschnitt.
Die Pläne selbst hätten  die Eigenschaft "aktiv" nicht mehr, sondern wären immer aktiv, sobald (und so lange) sie einem konkreten Fahrzeug zugeordnet sind. Bei der Zuordnung könnte man entscheiden, ob der Plan nach dem nächsten Abstecken des Fahrzeugs zugeordnet bleiben soll oder nicht. Der Plan würde am Ladepunkt aktiv, wenn das Fahrzeug dem Ladepunkt zugeordnet wird oder bereits zugeordnet ist.
Es müsste für Fahrzeugpools noch die Möglichkeit geben, einen Plan mehreren  Fahrzeugen zuzuordnen, bzw. von diesen zu entfernen. Dabei ist ggf. zu entscheiden, ob die Zuordnung auch für gerade angesteckte Fahrzeug angewendet wird oder erst nach deren Abstecken.
Ich persönlich würde Änderungen an Plänen generell nicht zu lassen. Wenn sich was ändern soll muss halt ein neuer Plan angelegt und anschließend zugeordnet werden. Bei Zielladeplänen ohne Wiederholung die eine neue Zielzeit bekommen könnte man das Neuanlegen und Zuordnen zum aktuellen Fahrzeug implizit machen.
bye
TW
			 
			
					
				Re: Zielladen, temporär vs. persistent, Backend vs. frontend
				Verfasst: Mo Okt 27, 2025 2:22 pm
				von Gero
				Thomas aus W hat geschrieben: Mo Okt 27, 2025 12:34 pm
Aus meiner Sicht wäre eine "Verselbstständigung" der Ladepläne auch der richtige Weg.
 
Gut, man kann ja auch analog zu Ladeprofilen auch Ladepläne machen und diese dann dem Fahrzeug zuordnen. Aber wenn man die dann editierbar macht, läuft man wieder in das Problem mit Front- und Backend.
Ich persönlich würde Änderungen an Plänen generell nicht zu lassen. Wenn sich was ändern soll muss halt ein neuer Plan angelegt und anschließend zugeordnet werden. Bei Zielladeplänen ohne Wiederholung die eine neue Zielzeit bekommen könnte man das Neuanlegen und Zuordnen zum aktuellen Fahrzeug implizit machen.
Hmmm, Ob das konsensfähig ist? Ich drehe gerne mal an meinem Zeitladeplan den start ein bissl nach vorne oder hinten.
 
			
					
				Re: Zielladen, temporär vs. persistent, Backend vs. frontend
				Verfasst: Mo Okt 27, 2025 3:09 pm
				von Thomas aus W
				Gero hat geschrieben: Mo Okt 27, 2025 2:22 pm
Ich drehe gerne mal an meinem Zeitladeplan den start ein bissl nach vorne oder hinten.
 
Wäre die Frage, warum Du das machst.
Ggf. benötigt ein anderer Plan-Typ weniger Feintuning...?
Alternativ hast Du in kurzer Zeit genug Pläne angelegt, dass alle Kombinationen von Start und Ende abgedeckt sind... ;o)
bye
TW
 
			
					
				Re: Zielladen, temporär vs. persistent, Backend vs. frontend
				Verfasst: Mo Okt 27, 2025 4:03 pm
				von aiole
				Also minimales Editieren hat schon Charme  

 .
 
			
					
				Re: Zielladen, temporär vs. persistent, Backend vs. frontend
				Verfasst: Mo Okt 27, 2025 4:47 pm
				von ChristophR
				Thomas aus W hat geschrieben: Mo Okt 27, 2025 3:09 pm
Gero hat geschrieben: Mo Okt 27, 2025 2:22 pm
Ich drehe gerne mal an meinem Zeitladeplan den start ein bissl nach vorne oder hinten.
 
Wäre die Frage, warum Du das machst.
Ggf. benötigt ein anderer Plan-Typ weniger Feintuning...?
Alternativ hast Du in kurzer Zeit genug Pläne angelegt, dass alle Kombinationen von Start und Ende abgedeckt sind... ;o)
bye
TW
 
Wenn ich dann 826 Zielpläne habe, weiß ich doch gar nicht mehr, ob ich den gewünschten schon habe.
Eigentlich ging es hier doch um die kurzfristige Änderung?
Wenn alles auf den Kopf gestellt werden soll, ist das doch bestimmt nix mehr für die 2.1.9.