Wlan Anbindung

  • 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: …

    Beim Smart läuft das so wie ich das sehe über Secure MQTT. Das ist das kein Problem mit Push und Pull. Falls jemand sich weiter informieren möchte, sollte hier die Stichpunkte Ecarx, HiveMQ mal nachschauen … Wird sonst zu technisch hier :P


    https://www.hivemq.com/static/case-studies/hivemq-case-study-ecarx.pdf


    Der nur lesende Zugriff bei „aktivem“ Fahrzeug soll nur verhindern, dass es eindeutige Zustände gibt. Die Person im Fahrzeug hat hierbei immer Vorrang. Evtl. geht es hier auch um Sicherheit, dass niemand von außen das Fahrzeug steuern kann, solange es „aktiv“ ist. Zum Beispiel beim Fahren.

    Fahrzeughistorie:

    Golf VI Limousine 1.2 TSI - 86 PS / 160 NM - Deep Black Perleffekt

    Audi A3 8V Limousine 40 TFSI Quattro - 190 PS / 320 NM - Daytonagrau Perleffekt

    Smart #1 Pulse - 428 PS / 584 NM - Quantum Blue Metallic

    2 Mal editiert, zuletzt von hydralein ()

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

    #3 BRABUS | Laser Red Metallic + Eclipse Black | Continental AllSeasonContact 2

    iOS und CarPlay-Nutzer, Wenigfahrer, Smarthome-Enthusiast