Beiträge von Kanecaine

Zitat von wahlg

Schon mal darüber nachgedacht mit dem Nachbar auf eine gewisse Zeit den Stellplatz zu wechseln.

Hm, das verstehe ich nicht. Was soll das bringen? Er hat den Stellplatz rechts, direkt an der Wand neben der Wallbox. Würde er links vom „Durchgang“ stehen, könnte er rückwärts einparken, aber dann wäre das Kabel doch erst recht im Weg, weil man dann mit den Fahrrädern drüber müsste. Steht das Auto rechts an der Wand, vorwärts eingeparkt, dann geht das Kabel unterhalb des Stoßfängers zur Heidelberg. Das wäre in der Situation doch noch der beste Kompromiss.

Was wir noch nicht geklärt haben: wem gehören die Fahrräder? Da sie auf dem eigenen Stellplatz zu stehen scheinen, wird es sich wohl auch um die eigenen Fahrräder handeln. Dem entsprechend hätte man es ja selbst in der Hand, entsprechend vorsichtig zu sein oder das Auto vorher abzustecken / nicht anzustecken. Da das wohl zu naheliegend wäre, glaube ich fast, dass es nicht die eigenen Fahrräder sind. aAber was haben die dann auf „deinem“ Stellplatz zu suchen? Scheint mir kein offizieller Fahrrad-Abstellplatz zu sein in der Ecke, wenn man damit zwischen den Autos durch muss. Dann sollten diejenigen vielleicht ihre Räder künftig woanders hinstellen - nur so ein Gedanke.

Zitat von Andimp3

"App-Baukasten"

Exakt, schließlich bietet Smart die App ja auch für Android an. Man will dann natürlich so viel Code wie möglich nur einmal schreiben. Und dafür gibts dann solche Frameworks oder Baukästen, plattformübergreifende Bibliotheken für Standard-Funktionen und das bläht die Software dann natürlich auf. Wie sehr, darüber war ich auch überrascht, als ich die Hello # App gesehen habe, die nativ und ausschließlich für iOS entwickelt wurde.

Zum Vergleich: ich hab früher mal .NET Programme geschrieben. Damit die lauffähig sind, braucht es das .NET Framework. Wenn man sich nicht sicher sein kann, dass das auf dem Zielrechner in der benötigten Version vorhanden ist, musste man die benötigten Programmbibliotheken dem Programm mit beifügen. Da waren dann tausende Zeilen Code enthalten, die niemals ausgeführt werden.

Und da sieht man mal, dass selbst das Ausgeben von Fehler- oder Hinweismeldungen bei der Softwareentwicklung nicht trivial ist. Schnell neigt man als Entwickler dazu, es auf die unmittelbare Stelle zu beziehen, an der die Meldung im Code ausgegeben wird. Doch der Fehler kann in einer Objekt-Hierarchie auch von viel weiter „unten“ kommen. Das ist selbst für (den/die) Entwickler nicht immer sofort erkennbar, sodass sich die wahre Ursache erst beim Debuggen des Codes findet.

Generell sollte man als Entwickler versuchen auf Annahmen zu verzichten und sich bei solchen Ausgaben auf das beziehen, was bekannt ist. Auch wenn es im ersten Moment wenig „kundenfreundlich“ wirkt, eine ungenaue oder gar unzutreffende Fehlermeldung finde ich schlimmer als eine unverständliche. Man kann ja durchaus auch einen Fehlercode mit beifügen und im Handbuch darauf näher eingehen.

Statt „Langsames Laden“ hätte ich mir in dem Fall gewünscht, dass „Ladevorgang wurde (mehrfach) unterbrochen“ ausgegeben wird. Auch wenn bei AC keine Kommunikation mit der Wallbox stattfindet, kann das Auto doch erkennen, ob die Ladeleistung während des Ladens auffällig schwankte oder gar unterbrochen wurde. Darauf sollte sich die Fehlermeldung bestenfalls beziehen statt Annahmen über ein fehlerhaftes Kabel zu machen. Es spricht ja nichts dagegen zu sagen „Der Ladevorgang wurde unterbrochen. Bitte Stromzufuhr und Kabel prüfen“. Aber wie eingangs geschrieben: für uns hier im Forum ist das einfach gesagt, für einen Entwickler unter Umständen aber gar nicht so einfach erkennbar / umgesetzt.

Wow, danke hydralein das beantwortet meine Fragen und ich habe wieder was gelernt. MQTT ist mir im Smarthome-Bereich schon mehrfach begegnet, aber bislang sah ich keinen Grund mich damit mal näher zu beschäftigen.

Für alle die es interessiert, sich aber nicht durch die Dokumentation wühlen wollen oder denen das alles zu kompliziert ist, versuche ich mich mal an einer kurzen und einfach verständlichen Zusammenfassung:

Im Prinzip war mein Gedanke mit dem Ausruf des Autos „hier ist meine Adresse, darüber kannst du mich erreichen“ gar nicht so falsch. Allerdings sprechen wir hier nicht von einer klassischen Client-Server-Kommunikation bei der eine Verbindung hergestellt, eine Anfrage gesendet, diese beantwortet und damit die Verbindung wieder beendet wird. Eine solche Kommunikation ist „stateless“. Das heißt, jede Anfrage ist neu und kennt keine der vorherigen Anfragen - in etwa so wie Siri, die sich auch nicht mehr erinnern kann, worüber wir vorher gerade noch gesprochen haben.

Bei MQTT werden die Teilnehmer, die miteinander sprechen, nicht in Clients und Server unterteilt, sondern in Clients und Broker. Wichtiger Unterschied: jeder Client kann sowohl Anfragen senden, als auch beantworten, wenn er sich dafür zuständig fühlt. Und der Broker ist „nur“ dafür da, um zwischen den Clients zu vermitteln. Diese sprechen also niemals direkt miteinander. Natürlich macht der Broker noch bisschen mehr, z.B. die Authentifizierung, sodass auch nur Clients miteinander sprechen, die das auch dürfen.

Genau das brauchen wir in unserem Fall ja: das Auto ist nach klassischer Denkweise sowohl Client als auch Server, stellt also Anfragen genauso wie es Anfragen beantwortet. MQTT bricht das auf und erlaubt allen Clients beides.

Jetzt nochmal kurz zu meiner ursprünglichen Frage: wie finden sich die Clients und der Broker? Antwort: die Clients melden sich am Broker an. Daher muss nur der Broker im öffentlichen Netz erreichbar sein. Das Auto stellt eine Verbindung her und diese bleibt anschließend für weitere Kommunikation offen. Wird die Verbindung unterbrochen, kann sie später wieder hergestellt und an die vorige Sitzung angeknüpft werden. Ich nehme an, dass dies bspw. dann erfolgt, wenn das Auto über WLAN eine Verbindung ins Internet herstellt. Dann dürfte dies die „primäre“ Internetverbindung sein. Das Auto meldet sich danach einfach wieder beim Broker und die Kommunikation wird fortgesetzt. Der Verbindungsaufbau geht also immer vom Auto aus und dem Broker ist es egal, ob das Auto per 4G oder WLAN ins Internet gekommen ist. Genauso ist es ja auch bei der App auf dem Handy. Das Handy kann in einem WLAN sein oder im Mobilfunknetz und meldet sich genauso beim Broker an. Damit ist auch die Frage beantwortet, ob eine lokale Kommunikation möglich ist: ist sie nicht, da alles immer über den Broker abgewickelt wird, und die Teilnehmer niemals direkt miteinander sprechen.

Steht das Auto in einer Tiefgarage ohne 4G-Empfang wäre eine Verbindung ins Internet (zum Broker) per WLAN problemlos möglich. Leider deaktiviert Smart das WLAN- Modul im Tiefschlaf, sodass in Folge solange keine Kommunikation mit dem Auto mehr möglich ist, bis es sich wieder am Broker anmeldet. Grund dafür dürfte der Energieverbrauch der erforderlichen Komponenten sein. Wenn das der einzige Grund ist, ließe sich das zukünftig sicher per Software-Update ändern: eine Option das WLAN dauerhaft aktiv zu lassen wenn der SoC > x% ist.

Beides ist richtig.

▷ LED Kennzeichenbeleuchtung erlaubt oder nicht / legal - verboten?

Nur das Leuchtmittel zu ersetzen ist i.d.R. nicht legal, da die Beleuchtungseinheit eine Bauartgenehmigung hat die auch das Leuchtmittel umfasst. Für die Frontscheinwerfer war das lange Zeit das Hauptproblem für eine legale Umrüstung, denn wer tauscht schon den ganzen Scheinwerfer inkl. ggf. weiterer Modifikationen an Kabelstrang und Ansteuerung? Anders kann hier aber nicht dasselbe Abstrahlverhalten gewährleistet werden. Da der Markt aber da ist, hat es sich scheinbar gelohnt dass es entsprechende Retrofit-Sets gibt bei denen der Hersteller (Osram) fahrzeugspezifische Tests (Einzelabnahmen) durchführt. Die Sets sind daher auch nur für die genannten Modelle zulässig. Es lässt sich also nicht pauschal sagen, dass es gar nicht geht / nicht zulässig wäre.

Zunächst müsste jemand schauen, ob die Kennzeichenbeleuchtung vom #3 auch im #1 verbaut werden kann. Wenn dieses Bauteil eine E-Nummer hat, dann würde ich sagen, dass ein legaler Austausch möglich ist. Wenn es keine hat, müsste man irgendwie an die Bauartgenehmigung herankommen und schauen, was da aufgeführt ist. Steht dort nur der #3 drin, dann wäre es im #1 tatsächlich nicht zulässig.

Oder am einfachsten, wie von Schmarti empfohlen: eine CoolBlue Halogen, die einer LED optisch schon sehr nahe kommt. Damit wäre man auf der sicheren Seite.

Ich denke auch, man muss hier zwischen „lesend“ und „schreibend“ unterscheiden. Bei lesendem Zugriff aufs Auto wird es so sein, wie zuvor beschrieben: das Auto hat eine Änderung (Status, Sensorwert) und überträgt dies in die Cloud. Push-Prinzip. Dort landet es in einer Datenbank und die kann man wiederum per App abfragen.

Bei „schreibend“ wäre das aber unsinnig. Dann müsste das Auto ja im Pull-Prinzip zyklisch nachfragen, ob es etwas gibt, was umzusetzen wäre, bspw. die Sitzheizung einzuschalten. Deshalb denke ich, dass es hier anders funktionieren wird. Doch ein Push vom Smart-Server ans Auto ist gar nicht so trivial: je nachdem ob es per Mobilfunk oder WLAN verbunden ist, hat es abweichende IP-Adressen und die sind in beiden fällen nicht statisch. Das Mobilfunknetz ist noch dazu ein Shared Medium, die Teilnehmer haben i.d.R. keine öffentliche IPv4-Adresse. Wie kann der Smart-Server also das Auto in dem Fall erreichen und mitteilen, dass es die Sitzheizung aktivieren soll? Lösungen dafür gibt es freilich (sonst würde es ja nicht funktionieren). Allerdings wüsste ich gern mehr darüber. Denkbar wäre, dass das Auto seine IP-Adresse(n) an den Smart-Server übermittelt: „guck mal, so kannst du mich erreichen“. Oder es kommt IPv6 zum Einsatz, aber das würde hier jetzt zu weit führen. Nur so viel: dann hätte das Auto eine permanent erreichbare Adresse.

Bei meinem vorigem Auto war es so, dass „Steuerbefehle“ vom Server per SMS ans Auto gesendet worden sind. Da stellen sich all die Fragen der Netzwerktechnik nicht. Ist aber auch nicht das gelbe vom Ei: es fehlt der Rückkanal. Der Server kann nur bestätigen, dass es die Nachricht ans Auto übermittelt hat, ob der Befehl dann auch umgesetzt wurde, war nie sicher.

Das hat hydralein kürzlich erst genauer untersucht und hier beschrieben:

Beitrag

RE: Kein Netzwerksignal

Moin zusammen,
ich habe mir mal den Datenverkehr vom Smart angeschaut (Smart mit WLAN verbunden und am Router einen Mitschnitt gestartet) und folgendes herausgefunden:

- Datenverkehr ist komplett verschlüsselt. Habe keinen unverschlüsselten Datenverkehr gefunden. Läuft alles über MQTT over TLS, TLS 1.2. etc.
- Crash Logs werden mit Sentry.io und Android Bugly verarbeitet.
- Update der Sprachdateien läuft über die CDN von Microsoft Azure.
- Navigation Traffic Informationen kommen über HERE.
-…

hydralein

3. Mai 2024

Fazit: da das Fahrzeug mit der Smart-API in der Cloud kommuniziert, muss die App auch Zugriff auf die Cloud haben. Eine rein lokale Kommunikation zwischen Auto und App ist ganz sicher nicht zusätzlich vorgesehen bzw. möglich. Insofern wäre es egal, ob beide im selben WLAN sind. Entscheidend ist, dass beide Zugriff auf das Internet haben müssen. Ob das Internet per Mobilfunk oder über WLAN per DSL oder Glasfaser bereitgestellt wird, ist unerheblich.

Zitat von kkucky

Es kann Probleme geben, das Leuchtmittel auf Funktion vom Auto überwacht wird. Irgendwie muss das Auto ja merken wenn die Birne kaputt geht und es dann anzeigen.

Stimmt, das kann ein Problem sein da eine Glühbirne einen anderen Widerstand hat, als eine LED. Teilweise gab es dann Sets bei denen nicht nur die Birne getauscht wurde, sondern der ganze Lampeneinsatz mit Streuscheibe und da war dann ein zusätzlicher Widerstand verbaut, der dem Steuergerät eine funktionierende Glühbirne vorgaukelte. Aber keine Ahnung wie das heutzutage, speziell beim #, ist.

Danke, mal eine angenehm unaufgeregte Vorstellung des #3 mit kaum Kritik. Mir hat’s gefallen - sowohl das Video als auch das Auto

Soweit mir bekannt, ist der Wechsel von Glühbirne zu LED zulassungstechnisch kein Problem, solange das Leuchtmittel selbst für diese Verwendung zugelassen ist. Das kann eine allgemein gültige Betriebserlaubnis sein oder eine die auf bestimmte Fahrzeuge beschränkt ist. Früher gabs auf den Leuchtmitteln mal spezielle E-Prüfziffer, die bspw. einem Leuchtmittel die Verwendung als z.B. zulässiges Blinklicht oder Standlicht bescheinigt haben. Und selbst für die Hauptscheinwerfer gibt es diverse offizielle Umrüst-Kits von Halogen auf LED von z.B. Philips und/oder Osram, die entsprechend ihrer ABE zulässig sind laut StVZo.

Ergo: wenn eine LED entsprechend als Kennzeichen-Beleuchtung zulässig ist, darf diese auch verwendet werden. Die Verwendung einer #3-Leuchte im #1 ist daher naheliegend (insofern passend), aber genauso gut ginge auch jedes andere zugelassene Leuchtmittel. Gab es hier im Forum nicht schon welche, die im #1 zugelassene LED verbaut hatten? Mir war so.

edit: das mit den E-Nummern ist auch heute noch so, hier alles Wissenswerte zum Thema:

LED Kennzeichenbeleuchtung nachrüsten – Wissenswertes & Anleitung zum selber machen

Die Kennzeichenbeleuchtung der meisten Autos wurde in der Vergangenheit mit Glühbirnen ausgeführt. Die LED ist jedoch das neuere Leuchtmittel und hat viele…

www.autoteile-markt.de