schenlap

Same problem here with debian, could anyone solve the issue yet? optirun -vv ./X-Plane-x86_64 --verbose --force_run ``` [53949.703938] [DEBUG]Reading file: /etc/bumblebee/bumblebee.conf [53949.704239] [DEBUG]optirun version 3.2.1 starting... [53949.704248] [DEBUG]Active configuration: [53949.704251]...

Ja, das hast du richtig verstanden. > Der letzte müsste sich an der Zielzeit bemessen, nicht daran ob er der letzte des Plans ist? beides ist möglich. Es geht aber...

ich würde das Cheap komplett rauswerfen, spricht etwas dagegen? Ich sehe darin keinen Nutzen mehr.

>Bekommen wir Beides unter einen Hut? aktuell geht beides. Dann müssen die von dir genannten Änderungen noch umgesetzt werden. (cheap aus konfig übernehmen, cheap in site verschieben). Auch da würde...

Jetzt produzieren alle Tests ein fail. Es wird nie eingeschaltet. Bei den aktuellen Strompreise wäre das vielleicht sogar sinnvoll :-) . Auf den ersten Blick sind es nur Umbenennungen aber...

Das wäre eine mögliche Lösung. Es wird zuvor auf t.clockNow gesetzt, da die Zeit noch nicht weitergeschritten ist, wird Before nicht erfüllt. Ev. muss man es auch anders lösen. ```...

Mit `if !slot.Start.After(t.clock.Now())` bekomme ich keinen Fail. Mit dieser Änderung bekommst du ``` planner_test.go:111: fixed tariff case 1: expected true, got false planner_test.go:111: fixed tariff case 1: expected true, got...

Ich glaube ich habe noch eine große Unschönheit gefunden: Ist kein Tarif konfiguriert, dann wird mit Zielzeit über timer.go geladen. Konfiguriert man einen fixed-Tarif, z.B wegen der Ersparnisanzeige, dann wird...

Typ prüfen ist auch nicht schön. planner sollte timer.go eigentlich komplett ersetzen. Wobei das jetzt nicht so ist (nämlich dann wenn der SoC zum Zielzeitpunkt noch nicht erreicht wird, übernimmt...

Als Referenz, zoned tariffs: https://github.com/evcc-io/evcc/pull/5583 schedule könnte dann so aussehen: ``` tariffs: planner: - days: Mo-Fr targettime: 7:00 - days: Sa targettime: 9:00 ``` oder sollte es am loadpoint liegen?