Beiträge von Dot

... und es ist live jetzt.

Hmm, leider ist das Update von Google abgelehnt worden, da der Review Prozess über das Login Fenster gestolpert ist (welches im ersten Release schon da war). Ich muss einen Demo Account zur Verfügung stellen, was natürlich nicht möglich ist (da dieser auch ein Auto bräuchte). Ich könnte natürlich mein eigenes Auto an diesen demo Account teilen, womit ich Google Zugriff auf mein Auto geben würde.

Ich versuche, dass Google zu erklären, aber es steht ein wenig in den Sternen, ob und wann dies gelingen wird.

V1.2.4 wird bald im Playstore verfügbar sein mit den folgenden Änderungen:

- Absturz (durch bug in geocoding) in Android Versionen 12 unter darunter ist behoben

- Routine zur Handhabung von Abstürzen hinzugefügt, die eine Log Datei ins Download Verzeichnis schreibt

- zeigt jetzt auch den Ladestand der 12V Batterie im Dashboard

Entschuldigt die Abstürze in Android 12 und darunter, dies ist jetzt behoben. Im Falle weiterer Abstürze wird eine Datei ins Download Verzeichnis geschrieben, die ihr mir dann als eMail schicken könnt, um die mögliche Absturzursache zu finden.

Goldbacher ich hoffe, dass die neue Version auf dem Redmi9 Deiner Frau jetzt funktionieren wird!

... auch nicht berücksichtigt ist Verfügbarkeit auf der Infra Seite selbst. Ich habe noch nie so viele Zapfsäulen ausser Betrieb gesehen wie Ladestationen in meinem 1 Jahr eAuto Besitz. Sollte Zapfsäulen ausfallen, gehe ich von weitaus schnelleren Reparaturen aus wie bei Ladesäulen da die klare zuordnung zu einer Tankstelle das vorantreibt. Die oft lange Nichtverfügbarkeit lokaler öffentlicher Ladestationen ist frustrierend (selbst bei Unternehmen wie BP)

Die Beschränkung des Navizugangs ist keine sicherheitsrelevante Entscheidung, sondern eine finanzielle. Gekoppelt mit der Platform in der Hand des gleichen Anbieters kommt die Sache dann eben schnell in die Ecke der Ausnutzung eines Monopols, was die Aktionen der EC in den letzten Jahren zu ändern sucht.

Skullz101 entscheidend ist dein Satz "Man ist ja frei in der Entscheidung," da dies bei zwei quasi Monopolen in der Handy- und Autoplatform eben nur beschränkt der Fall ist (glücklicherweise wurde Google ein wenig früher gezwungen, das ebenso restriktive AA zu öffnen).

ah super. Äpfel mit birnen vergleichen. Ein Vergleich von Zapf/Ladepunkten alleine befasst wenig, da die Verweildauer nicht berücksichtigt wird.

Wenn wir nur die reine Verweldauer sehen, so würden bei 80% Ladehub eAutos wahrscheinlich 5 mal länger an einer Ladestation verweilen (25min vs 5min, grob gerechnet). Aber die weitaus größere Zahl sind AC Lader. How muss man von Zeiten zwischen 30min bis 4 Stunden ausgehen (wieder, grob geschätzt). D.h. ein Ladepunkt der ein eAuto bedient würde zwischen 6 und ca 60 Füllungen von Verbrennern bedienen.

Dazu kommt die Verweildauer durch Parken, obwohl Ladeanbieter das mit Gebühren in den Griff kriegen wollen. Aber dennoch kann man in, z.b. München, an Stadtwerkladern (die mehrheit öffentlicher Lader hier) bis zu 4 Stunden parken. Auch haben die Stadtwerke hier in München die Neuinstallation von öffentlichen Ladern ordentlich versaut durch Fehler im Ausschreibungsverfahren.

Punkt ist: ein Vergleich mit Verbrenner Infrastruktur ist ein wenig komplizierter als Ladepunkte mit Zapfsäulen zu vergleichen. Aber DCS weiss das sicherlich schon...

Verfügbarkeit (geographischer und zeitlicher Natur) ist da fairer, wenn auch komplizierter zu berechnen.

Ich würde auf Apple tippen, da die Nutzung der HUD ein spezielles Interface ist, was Apple wahrscheinlich nicht freigegeben hat.

Bedenke auch, dass in Android Auto keine Navi App ausserhalb Google bis vor zwei Jahren eine AA Zulassung von Google erhielt. Nur Druck von der EU hat Google dazu bewegt, dieses Monopol aufzugeben. Trotzdem beschränkt Google noch immer Navi App in ihren interfaces, was z.B. TomTom weniger interaktiv aussehen lässt als Google Maps. Das sind so die Kriege der Monopolisten.

In den Übersichten der meisten Marken siehst Du nur gesamtdatenverbrauch. Aber Android hat Werte für senden und empfangen (sehe die in einer Lifelogging App die ich mal programmiert habe).

Ich würde ein Ticket mit Smart aufmachen und die Statistiken als Screenshot senden. Da ist wirklich was faul, vor allen Dingen wenn dies so riesig unterschiedlich bei Nutzern.

Ich kann mir nur vorstellen, dass da ein Bug im Laden der graphischen Inhalte (Autoansichten) vorhanden ist, da nur diese Daten groß genug sind, schnell viele Daten zu verbrauchen. Bei mir sind die Hintergrunddaten recht in Ordnung und ein langsamer Verbrauch mit vielen kleinen Daten würde sich auch in der Batterienutzung bemerkbar machen -> daher in kurzer Zeit viele Daten!

Ob da Smart was machen wird, ist fraglich. Aber nur tickets können das anstoßen!

Ja, wird kommen. Die internen Code Änderungen der letzten Updates sind auf Operationen ausgerichtet die von Widgets oder Timern gestartet werden (für zeit basierte Klima).Werde das Widget zuerst testen, dann Timer basierte Klima, dann werteabhängige Klima (e.g. wenn zu heiß und am Laden, kühlen an).

Bin allerdings auf Reisen in den nächsten zwei Wochen, daher etwas sporadisch.

Zitat von RR500

Ich will niemanden hier zu nahe treten.

Ich kann es halt nicht beurteilen wo meine Daten landen. Du schon, wenn Du die App gemacht hast. Solltest bei Smart anfangen, dann wäre die HelloSmart App sicher bald reichhaötiger und besser.

Aber die Daten landen nirgendwo anders als bei Smart selbst. Das ist sicher ein Problem, aber das kommt mit einem Wagen der ein Internet angeschlossenes Objekt ist.

Was die Transparenz angeht, so hast du da mehr mit einem 3rd party Entwickler, der sich persönlich bloßstellt mit Namen und allem. Wenn ich bei Smart arbeitete, wäre ich nur einer hinter einem Markennamen.