Beiträge von Dot

... 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.

Das steht Dir frei. Ich kann Dir versichern dass ich keinerlei Interesse an deinen Fahrzeugdaten habe. Ehrlich gesagt ist das Risiko auf meiner Seite, meine Arbeit anderen zur Verfügung zu stellen, inklusive denen die vermuten ich würde deren Daten missbrauchen. Besser BTT...

Die Android Smore# app zeigt auch die 12v Spannung (nicht den Ladestand in Prozent, da ich es nicht interessant fand).

Wird im Dashboard Tab angezeigt

Die Funktion der eigentlichen "Erkennung" ist oder sollte nur ein Input in das sein, was im HUD angezeigt oder anderswo verwendet wird. Wenn kein Schild vorhanden, aber die notwendige Geschwindigkeit sich ändert, dann muss das erkannt werden, basta. Da über Erkennugsraten der optischen Hilfe zu streiten ist wirklich an der Sache vorbeizureden. Die optische Erkennung wird natürlich super funktionieren wenn alles explizit signalisiert ist mit runden Geschwindigkeitszeichen - ist es aber nicht.

Solange die Gesamtfunktion, bestehend aus optischer Erkennung aber auch Ranziehen (oder nicht) von Kartenmaterial, über eine nennenswerte Zeit nicht das richtige anzeigt, sind die Auswirkungen auf Bimmeln, ACC etc schon deutlich spürbar (oder machen für mich angepasste ACC nicht brauchbar).

Da auf "bei einigen scheint es nicht so gut zu funktionieren " hinzuweisen ignoriert das eben zu häufig am eigentlichen Problem vorbeigeredet wird (z.b. durch Fokus auf Erkennungsraten wie in einem separaten Post dargelegt)