evcc
evcc copied to clipboard
evcc-io
Add schedule for planner
Fix #5492
Hi,
dieser Draft soll den Support für das Planen für Wochentage hinzufügen.
Dafür fehlt noch folgendes: Ich kenne mich im evcc-System nicht so gut aus. Wenn etwas fehlt, dann bitte mir mitteilen.
- [ ] Backend-Implementierung
- [ ] Tests schreiben
- [x] Bug fixen:
Uncaught (in promise) Maximum recursive updates exceeded in component <ChargingPlanRepetitiveSettingsEntries>. This means you have a reactive effect that is mutating its own dependencies and thus recursively triggering itself. Possible sources include component template, render function, updated hook or watcher source function.. Auslöser ist diese Zeile. - [ ] (Wie) in Preview Pläne visuell anzeigen?
- [x] Bug fixen: Siehe Video. Das Dropdown-Menu aktualisiert nur die Daten des dazugehörigen Select-Menus, wenn auf die Checkbox geklickt wird.
https://github.com/user-attachments/assets/09ad426c-773b-49da-995b-7ed6e9981fd3
- [ ] Weiteres bitte mitteilen
Vielen Dank für das tolle Projekt! ~ Maschga
Wording: Ich würd hier nicht repetetive verwenden. Da steckt von der Bedeutung was "ermüdendes", "monotones" drin. Lass uns repeating nehmen. Sowohl Richtung User als auch im Code.
Lass uns bei
repeatingbleiben.
Die technisch korrekte übersetzung wäre meins wissens "recurrent". ;)
Hi @Maschga, ich hab die Ursache für das Recusionsthema gefunden und gefixt. Das liegt daran, dann in dem Updateprozess immer wieder ein neues Array für die Wochentage erstellt wird. Die MultiSelect Komponente hat bislang nicht den Inhalt, sondern die Objektidentität geprüft. Daher kam es zu schleifen.
Das Thema mit den Wechselwirkungen (Dropdown 1 Änderungen beeinflussen Dropdown 2 Änderungen) hab ich auch gelöst. Die Multiselect-Komponente arbeitet jetzt auch sauber mit Form-IDs.
Layout: Hier sollten die Aktionen am Ende der Zeile auf großen Screens immer untereinander und links ausgerichtet stehen.
Hi @Maschga, ich hab die Ursache für das Recusionsthema gefunden und gefixt. Das liegt daran, dann in dem Updateprozess immer wieder ein neues Array für die Wochentage erstellt wird. Die MultiSelect Komponente hat bislang nicht den Inhalt, sondern die Objektidentität geprüft. Daher kam es zu schleifen.
Das Thema mit den Wechselwirkungen (Dropdown 1 Änderungen beeinflussen Dropdown 2 Änderungen) hab ich auch gelöst. Die Multiselect-Komponente arbeitet jetzt auch sauber mit Form-IDs.
Vielen, vielen Dank für deine Hilfe, da hätte ich lange gesucht!
[ ] Backend-Implementierung [ ] Preview Pläne visuell anzeigen
Bzw. der Preview, aber auch der eigentlichen Regelung und der Status-Anzeige am Ladepunkt sollten wir so verfahren, dass wir immer den "nächsten Plan" ermitteln. Eine Vorschau mit mehreren Plänen würde ich im ersten Schritt noch nicht machen. Auch das Thema "überschneidende oder eng aufeinanderfolgende Pläne" (Bsp: Mo. 8 Uhr 20%, Mo. 8:01 Uhr 100%) können wir erst einmal ignorieren.
Konkret würde das im Backend eigentlich "nur" bedeuten, dass überall da, wo aktuell der "statische Plan" verwendet wird eine Funktion aufgerufen werden muss, die sich den statischen und die wiederholenden Pläne anschaut und die Daten des Nächstgelegenen wieder zurückgibt. In der UI könnten wir den Titel "Plan Vorschau" in "Nächster Plan" oder "Vorschau nächster Plan" umbenennen.
Haben wir nicht bereits Zugriff auf den wiederholenden Plan und auf den statischen? Liese sich der nächstfrühere Plan nicht im Frontend berechnen?
Liese sich der nächstfrühere Plan nicht im Frontend berechnen?
Ja die werden beide gepublisht. Aber wichtig ist ja vor allem, dass der Planner im Backend das Richtige mit den Plänen anstellt. Da muss die Logik ja ohnehin hin. Slots ausrechnen und Ladung starten macht ja nicht die UI.
Layout: Hier sollten die Aktionen am Ende der Zeile auf großen Screens immer untereinander und links ausgerichtet stehen.
Passt das so?
Konkret würde das im Backend eigentlich "nur" bedeuten, dass überall da, wo aktuell der "statische Plan" verwendet wird eine Funktion aufgerufen werden muss.
Habt ihr für solche Funktionen eine extra Datei im Backend?
Ja die werden beide gepublisht. Aber wichtig ist ja vor allem, dass der Planner im Backend das Richtige mit den Plänen anstellt. Da muss die Logik ja ohnehin hin. Slots ausrechnen und Ladung starten macht ja nicht die UI.
Sorry, da habe ich deine Nachricht zu schnell gelesen und zu wenig darüber nachgedacht. 🙈
@naltatis Was hältst du davon bei der Vorschau den Titel immer bei "Plan Vorschau" zu lassen und den Übersetzungs-String "currentPlan" ("Aktiver Plan") zu entfernen?
Und es stellt sich die Frage, ob man in der Vorschau nur noch den nächsten aktiven Plan anzeigen sollte. Das würde im Frontend einiges vereinfachen und vielleicht auch dem Benutzer bei ganz vielen Plänen helfen, sich besser zurechtzufinden, welcher Plan als nächstes dran ist.
Man könnte auch bei den oberen Einstellungen (über der Vorschau) die Ränder der Dropdownmenus des nächsten Plans orange färben, damit der Benutzer besser den nächsten aktiven Plan erkennt.
@Maschga bzgl. Vorschau und Kennzeichnung: Ja, aktuell wird das Diagramm immer angezeigt, auch wenn kein Ladeplan aktiv ist. Dann auf Basis der Werte des "Einmalplans". In diesem Fall steht da "Plan Vorschau". Ist der Plan aktiv ändert sich der Titel in "Aktiver Plan". Mit dieser Änderung müsste das mindestens "Nächster Aktiver Plan" heißen wenn es mehrere gibt.
Bzg. Kennzeichnung würde ich eher Richtung "Badge" Denken. Hinter dem Aktivierungshäkchen ist Platz den wir nutzen können. Hat den Vorteil, dass wir dann Text nutzen können. Das machts gerade für neue Nutzer einfacher zu verstehen als farbliche Umrandungen. Ggf. können wir auch Icon mit Tooltip nehmen. Ich hab hier mal ein schneller Mock.
Das ist noch nicht hübsch. Aber da kann ich mir noch mal GEdanken machen.
Der Vorschlag mit dem Badge wird meiner Meinung nach platztechnisch schwierig, wenn man sich die Bilder hier anschaut.
Der Vorschlag mit dem Badge wird meiner Meinung nach platztechnisch schwierig, wenn man sich die Bilder hier anschaut.
Außerdem ist die Frage, ob man nicht zwei Badges braucht, einmal für den nächsten aktiven Plan und dann noch ein Badge für den nächsten Plan, der im Preview angezeigt wird (der kann ja aktiv oder auch inaktiv sein). Ansonsten besteht die Gefahr, dass der Benutzer meint, dass der Plan mit dem nächster-Badge im Preview angezeigt wird, obwohl das gar nicht stimmt.
Hi @naltatis and @Maschga , nothing helpful to contribute here from my side except that I like the UX of the current draft and believe this will turn out to be a valuable addition to EVCC, especially considering the rising prevalence of dynamic electricity pricing.
Thank you for your work on this! 🚀
Aktuell werden die Wiederholenden Pläne in jedem Publish Zyklus im UI wieder überschrieben/zurückgesetzt.
Meine Vermuting ist, dass hier der entsprechende Watcher noch auf Deep-Compare umgestellt werden muss.
Hier noch mal ein kompakterer Vorschlag für die Markierung des nächsten Plans. Gibt es nur einen (also keine wiederholenden) würde ich die Markierung komplett weg lassen (wie heute). Der "Stern" Funktioniert auch ohne Beschreibung, wenn wir ihn in der Überschrift bei der Visualisierung wiederholen - Fussnoten-Style.
Vorschau
Nächster Plan
Aktiver Plan
Wenn das kommt wäre es der Hammer, dann wäre Frauchen zufrieden😅
Ich hatte vorher unsere 2 Easee Wallboxen und 3 E-Autos (eines davon leider manuell ohne Übertragung der SoC) in der Tibber App integriert, aber wir mussten jedesmal in der App einstellen welches Auto an welcher Wallbox gerade dran hängt. Das funktioniert mit evcc durch die automatische Erkennung perfekt, bis auf der eine den habe ich als offline angelegt und als Standardfahrzeug auf Wallbox 1 hinterlegt, weil der sowiso nur hier geladen wird, evcc Läuft bei uns auf unseren Home Assistanten.
Aber was Tibber besser kann, ist das wir für alle Fahrzeuge seperat einen Wochenladeplan bzw. eine Abfahrtszeit pro Wochentag hinterlegen konnten. Bei evcc muss man dies jedesmal neu einstellen und für den einen Ladevorgang aktivieren. Was meine Frau nicht macht oder vergisst und sich dann aber beschwert wenn die Kiste nicht geladen wurde🤣
Wie ist das ein deinen Beispiel, wo es einen Plan nur für Montag 12:00 Uhr Abfahrt mit Ladeziel 40% und einen für Mo-So auch mit Abfahrtszeit 12:00 Uhr aber 80% Ladeziel gibt. Welcher Plan wird dann für Montag genommen, der erste? Die Idee ist gut, dann könte man ja zwei Pläne für einen Tag hinterlegen oder?
Gibt es schon einen Zeitplan bis wann es verfügbar wäre?
Aktuell werden die Wiederholenden Pläne in jedem Publish Zyklus im UI wieder überschrieben/zurückgesetzt. Meine Vermuting ist, dass hier der entsprechende Watcher noch auf Deep-Compare umgestellt werden muss.
Sollte jetzt gefixt sein.
Wie ist das ein deinen Beispiel, wo es einen Plan nur für Montag 12:00 Uhr Abfahrt mit Ladeziel 40% und einen für Mo-So auch mit Abfahrtszeit 12:00 Uhr aber 80% Ladeziel gibt. Welcher Plan wird dann für Montag genommen, der erste? Die Idee ist gut, dann könte man ja zwei Pläne für einen Tag hinterlegen oder?
Wenn nur ein Plan von beiden aktiv ist, wird nur dieser genommen. Wenn beide aktiv sind, ist das dem Zufall überlassen. Ist das deine Frage?
Wenn nur ein Plan von beiden aktiv ist, wird nur dieser genommen. Wenn beide aktiv sind, ist das dem Zufall überlassen. Ist das deine Frage?
Jupp, dann wäre es wahrscheinlich besser wenn man dies gar nicht so anlegen könnte. Vielleicht so wie bei Tibber, dass man für jeden Wochentag einen Abfahrtzeit eingeben muss und nicht zusätzlich einen Plan ertellen kann von Mo-So.