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
Die technisch korrekte übersetzung wäre meins wissens "recurrent". ;) |
| }); | ||
| test("should format single days and ranges", () => { | ||
| expect(fmt.getShortenedWeekdaysLabel([0, 1, 3, 5, 6])).eq("Mo-Di, Do, Sa-So"); | ||
| expect(fmt.getShortenedWeekdaysLabel([0, 2, 3, 5, 6])).eq("Mo, Mi-Do, Sa-So"); |
There was a problem hiding this comment.
| expect(fmt.getShortenedWeekdaysLabel([0, 2, 3, 5, 6])).eq("Mo, Mi-Do, Sa-So"); | |
| expect(fmt.getShortenedWeekdaysLabel([0, 2, 3, 5, 6])).eq("Mo, Mi, Do, Sa, So"); |
Ich würd vorschlagen den Trennstrich nur zu nutzen wenn es eine durchgehende Spanne von 3+ Wochentagen gibt. In allen anderen Fällen sollten wir einfach Wochentage auflisten auch wenn das ggf. mal länger ist.
| }); | ||
| test("should format ranges", () => { | ||
| expect(fmt.getShortenedWeekdaysLabel([0, 1])).eq("Mo-Di"); | ||
| expect(fmt.getShortenedWeekdaysLabel([0, 1, 2, 3, 4, 5, 6])).eq("Mo-So"); |
There was a problem hiding this comment.
Typografisch korrekt sind hier Leerzeichen und ein En Dash (–). Bei der Preisspanne in den Ladepunkt- oder Batterieeinstellungen haben wir das auch so gemacht.
Klingt wie eine Kleinigkeit, aber wir haben Nutzer (mich nicht ganz ausgenommen), denen diese Details sehr wichtig sind 😄
https://github.com/evcc-io/evcc/blob/master/assets/js/components/SmartCostLimit.vue#L286
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