Add schedule for planner #16091
Add schedule for planner #16091
Conversation
|
Was wäre denn hier die Idee fürs API? |
|
Wording: Ich würd hier nicht |
|
Oder einfach Wochenplaner? |
|
Wie soll ich es jetzt machen? 😅 |
|
Lass uns bei |
| }, | ||
| methods: { | ||
| fetchRepetitivePlans: async function () { | ||
| let response = await api.get(`/loadpoints/${this.id}/plan/repetitive`); |
There was a problem hiding this comment.
Die Komponente sollte sich nicht selbst die Daten holen. Das Muster was wir standardmäßig verwenden ist, dass wir Schreiboperationen via REST machen die aktualisierten Daten aber über Websockets gepusht werden. Die landen dann im globalen State. Da dieses Feature nur für Fahrzeuge mit SoC verfügbar sein wird sollten wir den Ladeplan auch direkt am Fahrzeug pushen. Siehe hier:
Damit ist er dann auch gleich über MQTT verfügbar und wir lösen das Problem Datensync zwischen Geräten. Also mehrere offene Browserfenster.
Aktuell veröffentlichen wir den "einmaligen Plan" auch noch nicht am Fahrzeug. Das müssen wir aber in diesem Zuge mit machen. Momentan kommen die aktuellen Plandaten die für die Statusanzeige in der UI und für das Ladeplanformular verwendet werden vom Ladepunkt. Mit der Einführung von mehreren Plänen würde ich am Ladepunkt nur noch die Daten des "als nächstes anstehenden Plans" veröffentlichen. Dass kann ein einmaliger sein, aber auch eine Ladung, die aufgrund einer Wiederholungsregel ansteht. Bislang mussten wir das nicht trennen. Jetzt ist das aber erforderlich.
There was a problem hiding this comment.
Beim Vehicle werden zwei Arrays mitgegeben: plans und repeatingPlans.
Beim Loadpoint werden die effectivePlanSoc und effectivePlanTime-Felder mitgeschickt.
Passt das so?
assets/js/mixins/formatter.js
Outdated
| @@ -285,5 +296,35 @@ export default { | |||
| // TODO: handle fahrenheit | |||
| return this.fmtNumber(value, 1, "celsius"); | |||
| }, | |||
| getShortenedWeekdaysLabel: function (weekdays) { | |||
There was a problem hiding this comment.
Hier wären Unittests sicher gut.
There was a problem hiding this comment.
Co-authored-by: Michael Geers <michael@geers.tv>
Co-authored-by: Michael Geers <michael@geers.tv>
…to add-schedule-for-planner
|
@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. |
| // SetRepeatingPlans stores every repeating plan | ||
| SetRepeatingPlans([]api.RepeatingPlanStruct) error | ||
| // GetRepeatingPlansAsNormalPlans returns every repeating plan with a timestamp-key to sort | ||
| GetRepeatingPlansWithTimestamps(onlyActivePlans bool) []api.PlanStruct |
There was a problem hiding this comment.
Ich würde für diesen Daten-Zwischenstand keine neue öffentliche API am Fahrzeug machen. Das wird ja "nur" für die Berechnung des nächsten Zeitslots verwendet. Ich würd die Berechnung in der Methode verschieben, die rausfindet was die nächsten zu beachtenden Zeitpunkte sind. Also eher nen Aufruf, der in der Schleife bei vehiclePlanSoc() läuft.
There was a problem hiding this comment.
Du würdest also die Methode entfernen und den Code dieser Methode in die Methode vehiclePlanSoc verschieben?
| @@ -43,6 +43,13 @@ type API interface { | |||
| // SetPlanSoc sets the charge plan time and soc | |||
| SetPlanSoc(time.Time, int) error | |||
|
|
|||
| // GetRepeatingPlans returns every repeating plan | |||
| GetRepeatingPlans(onlyActivePlans bool) []api.RepeatingPlanStruct | |||
There was a problem hiding this comment.
Den onlyActivePlans Filter könnten wir auch rauslassen und erst in der Listenbearbeitung wo das für uns relevant ist prüfen. Ist aktuell ja nur die eine Stelle, wenn ich das richtig sehe.
|
@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. |
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 |
|
Hi @naltatis and @Maschga , Thank you for your work on this! 🚀 |
|
Aktuell werden die Wiederholenden Pläne in jedem Publish Zyklus im UI wieder überschrieben/zurückgesetzt. publish.overwrite.webmMeine 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
|
| getShortenedWeekdaysLabel: function (selectedWeekdays) { | ||
| if (0 === selectedWeekdays.length) { | ||
| return this.$t("main.chargingPlan.noWeekdaysSelected"); | ||
| } |
There was a problem hiding this comment.
Der Fall und die entsprechenden Translations können aktuell nicht vorkommen.
Aber: Wir könnten überlegen, ob wir es doch erlauben "keinen Tag" auszuwählen. So 100% glücklich bin ich mit der "Letzte Option kann nicht abgewählt werden" Entscheidung nicht mehr. Gerade, dass der Eintrag dann ausgegraut wird ist zwar konsequent, aber auch komisch.
Vielleicht erlauben wir doch die leere Wochentagsliste. Der Anzeigetext (noWeekdaysSelected) könnte dann etwas Kurzes wie - oder keine Auswahl sein. In der Go-Logik würden Einträge mit leerer Wochentagsliste dann einfach übersprungen. Also keine zusätzliche Fehlerkommunikation an den Nutzer. Das nichts passiert, wenn er keinen Tag auswählt dürfte ohnehin erwartungskonform sein.
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.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.bug.mp4
Vielen Dank für das tolle Projekt!
~ Maschga