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.
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 <[email protected]>
Co-authored-by: Michael Geers <[email protected]>
…to add-schedule-for-planner
|
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.
|
Vielen, vielen Dank für deine Hilfe, da hätte ich lange gesucht! |
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? |
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. |
Passt das so? |
Habt ihr für solche Funktionen eine extra Datei im Backend? |
Sorry, da habe ich deine Nachricht zu schnell gelesen und zu wenig darüber nachgedacht. 🙈 |
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