Es wird im Auto morgen früh kalt sein!

Dasselbe bei mir heute auch :unamused:

Ich glaube wie gesagt nicht, das es zwischen den Timern und der Zeitumstellung eine bewusste Logik gibt. Waere dem so… das haette auch der Praktikant in der SW-Abteilung hinbekommen…

Vielmehr wird es so sein, dass die Architektur nicht sauber ist. Dadurch gab und gibt es unvorhersehbare Seiteneffekte und der Kreis schliesst sich dort, wo einfach keine sinnvolle Change Impact Analyse (CAI) auf Anforderungsebene moeglich ist! Und eine CIA werden die auf jeden SW-Change Request (CR) nach Prozess in diesem Status machen muessen…

Edit: Das macht echt Angst - denn warum sollte das auf der Ebene von ASIL-Funktionalitaeten besser laufen :flushed:

Erklärungsversuch: Soweit wir wissen, werden die Daten zwischen App & Polestar per cloud synchronisiert. Das lässt weiter vermuten, dass die Zeiten in einer Datenbank gespeichert sind. Üblicherweise nutzt man in internationalen Apps UTC Zeiten. Normalzeit in Deutschland ist UTC+1 und Sommerzeit dann eben UTC+2
Eigentlich muss in der Software nichts gemacht werden; die Konvertierung von UTC in lokale Zeit und umgekehrt lässt man das Framework erledigen. Wenn man allerdings glaubt man müsse die Zeiten in der Software nochmal „manuell“ anpassen kommt oft Müll dabei raus :wink:

Wenn im jetzigen Status der SW der Praktikant noch beigeht und ueberlegt, an welcher Stelle er anpassen muss - dann laeuft da aber einiges schief!

Wie Du schon schreibst - das Framework muss stehen und die SW-Architektur wird nicht mehr angefasst.

Edit: Aber logischer Erklaerungsversuch!

Nun denn, man weiß um den Fehler und will ihn asap fixen.
Ja klar, und der Mond hat schon drei Ecken und die Sonne geht im Westen auf.

1 „Gefällt mir“

grins

Ist doch klar… Zum 29. Okt. 2023 sind sowieso alle Stability Improvements und Bugfixes geplant durch und unsere SW ist fehlerfrei - natuerlich inkl. der Zeitumstellung…

Die haben die Antwort vom letzten Jahr wiedergefunden. Kann man sogar in diesem Forum finden :see_no_evil:

3 „Gefällt mir“

Ganz so trivial ist es dann vielleicht doch nicht. Der Wagen kann auch Zeitzonen wechseln. Wenn ich den Timer in DE auf 07:00 Uhr morgens stelle, möchte ich ihn UK sehr wahrscheinlich auch auf 07:00 Uhr stehen haben. Vielleicht ist das eher der Fehler: Sie haben überhaupt Zeitzonen im Design und sollten einfach die relative Zeit unabhängig von SZ/WZ und Zeitzone speichern…

Es sieht eher so aus, dass sie utc speichern und dann vom Server umrechnen lassen (wohl dummerweise auch „Fixzeiten“ wie eben Tageszeittimer…). Da alles über Cloudserver läuft, kann es vlt sein, dass bei einem die Zeit mehr oder weniger Stunden vorgestellt wurde als bei dem anderen, je nachdem, in welcher Zeitzone der jeweilige Cloudserver steht. Das ist keine Entschuldigung für PS, lediglich eine Vermutung, wo da das Problem liegt. Tatsächlich macht es keinen Sinn, einen absolut einzustellenden Zeitwert in einem (relativen) Zeitformat abzuspeichern, halt einfach nicht nachgedacht beim Verknüpfen in der db seitens PS… Eigentlich sollte PS auch alles daran setzen, dass die Daten ihrer zB deutschen Kunden auch nur auf deutschen Cloudservern gespeichert werden. So machen es jedenfalls andere verantwortungsvolle Firmen in der IT-Welt. Ich möchte nicht sagen, dass PS es nicht so macht, aber das Beispiel mit den unterschiedlichen Zeitverschiebungen bei Kunden aus einer Zeitzone lässt zumindest daran zweifeln.

/edit: Bei mir war der Timer nach Update nie weg, hat auch zuverlässig funktioniert, aber nach der Zeitumstellung auch um eine Stunde nach hinten verstellt. Es hat auch 3 Anläufe gebraucht, den Timer wieder auf die korrekte Zeit umzustellen.

Wenn sie die Zeiten einfach fix und nicht als Timestamp abspeichern, dann wäre ja alles in Ordnung. Und dann ist der Serverstandort eigentlich egal (wenn man andere Rahmenbedingungen des Datenschutzes außen vor lässt, aber diese Diskussion ist OT)

Ganz so einfach ist es leider doch nicht.
Das gewünschte Ereignis wird schließlich zentral vom Server getriggert. Der Server läuft sinnvollerweise auf UTC. Es muss also immer die gewünschte Auslösezeit (absolut) und die Zeitzone in der sich das Auto zur Auslösezeit befindet bekannt sein.
Alternativ könnte auch das Ganze lokal am Auto laufen. Dann wird es aber schwierig es über „Hey Google“ zu managen. Bei einer entsprechenden Anfrage müsste der Server erst die Zeiten vom Auto holen bzw. senden - das würde dann jedwede vernünftige Responsetime sprengen.

Aber egal, das bisschen delta-Zeit rechnen ist wahrlich kein Hexenwerk und äußert blamabel für die Polestar-Entwickler, dass sie das nach mehr als 2 Jahren immer noch nicht im Griff haben (wie so Vieles andere auch nicht…)

Das tatsächliche Auslösen wird doch wohl lokal sein. Ich lege ja auch nicht meinen Wecker in die Cloud.
Und die Response Time ist weniger offensichtlich als die Umstellung der Stromstärke während des Ladens. Und das funktioniert ja (wenn auch etwas verzögert).

1 „Gefällt mir“

So ein bisschen ist das alles aber auch lustig. Es sterben ja keine Menschen wegen so eines Timers. Ich bin schon mein ganzes Leben lang early adopter und bin bei vielen Gegenständen Kummer am Anfang gewöhnt. Ich hatte auch das erste in Deutschland verfügbare Android Handy schon von der ersten Woche an als es das überhaupt gab. Ihr glaubt gar nicht, was da alles verrücktes passiert ist, heute hinterfragt das keiner mehr. Wir sind alle so ein wenig die Citroen DS Fahrer des 21. Jahrhunderts und wer besonders sein will, der muss manchmal die Gabe haben, einfach ruhig bleiben zu können. Ich könnte mir trotz der ganzen Vorfälle - auch wenn die natürlich manchmal ungeil sind - nicht vorstellen, zurzeit ein anderes Auto zu fahren. Vor allem nicht so ein eAuto, das aussieht wie ein gestrandeter Wal aus einem Unternehmen mit einem kompletten Honk als Chef, wenn Ihr wisst wen und was ich meine. Ich bin zufrieden und auf jeden Fall dürfen die Verrücktheiten auf Dauer durchaus weniger werden, aber ich muss mich heute noch jeden Tag zurückhalten, nicht laut zu lachen, tanzen und singen (und die letzten beiden kann ich echt schlecht), wenn ich zu meinem Auto gehe. Sorry spamme hier gerade das Topic zu… Bin jetzt ruhig!

2 „Gefällt mir“

Da wäre ich mir gar nicht so sicher - das Auto ist ggf. im Tiefschlaf!

Wenn du deinen Wecker über den GoogleHome-Assi stellst liegt er 100% i n der Cloud!

Hast du schonmal den US-Zugang aktiviert und den PS2 über Google Home angesprochen? Nein, solltest du mal probieren.
Dann mal Türstatus (auf/zu) Auto verändern (NICHT über die App, mit Schlüssel) und über GoogleHome abfragen - bis dann die richtige Antwort, der veränderte Status, gemeldet wird vergehen schon mal leicht 2h, zuvor ist es immer der Status vor der Änderung.
Es wird also der Serverwert benutzt.

Warum? Darüber dürfen wir spekulieren - und deshalb bin jetzt auch wieder raus.

Ich habe ja außer dem Polestar kein Android. Ich hehe aber davon aus, dass mein Android Phone den Wecker auch lokal einrichtet und ich dann in den Flugmodus gehen kann. Siri macht es so.

1 „Gefällt mir“

Ja, habe ich gemacht. Ist doof. Zumal ich zu sehr nuschle und er Polestar immer mit Polster, Poster oder Pupser versteht. Die Fragen sind alle „hart“ vorgegeben. Solche Skills haben wir vor sechs Jahren schon dem Google Assistant beigebracht und ist einem Technologieunternehmen nicht würdig.

Machen Android Telefone genau so. Da wird einfach die Uhr App gesteuert.

Was die Timer angeht: da die ja auch in Tiefgaragen starten sollten, hoffe ich doch auch Mal, dass die lokal starten. Da kann sicher jemand der sein Auto da parkt was zu sagen, einige haben ja offensichtlich in ihrer Tiefgarage kein Netz, wenn da auch keine Timer funktionieren, wäre das schon recht doof.

1 „Gefällt mir“

Naja, wahrscheinlich wird der PS2 hin und wieder aufwachen und Mal ein paar Daten an den Server schicken. Scheinbar wohl so alle 2h. Und scheinbar kann App/Server den PS2 auch nur bis zu nem gewissen Grad aufwecken (nämlich um die dort möglichen Dinge zu erledigen), das CD bleibt dabei ja scheinbar aus (sonst hätten wir ja vll auch mal Aufzeichnungen im CSV, während des „Schlafens“).