Kommunikation zwischen Smartphone und Mikrocontroller

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Kommunikation zwischen Smartphone und Mikrocontroller

    Hallo,
    ich bin komplett neu im Bereich der App Entwicklung, was aber nicht bedeutet, dass ich gar keine Ahnung von Programmierung habe. Da die Tage wieder kürzer und die Temperaturen kälter werden, möchte ich mich einem neuen Projekt widmen: Swift programmieren lernen. Diesbezüglich arbeite ich die Tutorials von Paul Hudson durch (Hacking with Swift) und mache auch ganz gute Fortschritte.

    In den vergangenen Jahren habe ich viele kleine Projekte mit dem ESP8266 umgesetzt. Ein Mikrocontroller mit WiFi und einigen GPIOs. Dieser ist im Heimnetz eingebunden und kommuniziert mit einem Raspberry Pi (Homebridge). Der Mikrocontroller lässt sich schließlich über Apples Home App steuern. Die Kommunikation zwischen Raspberry und ESP8266 erfolgt relativ simpel via URLrequest.

    Ich würde gerne etwas ähnliches realisieren, allerdings ohne Raspberry als Server. Die Kommunikation soll ausschließlich zwischen dem ESP8266 und meiner eigenen IOS App erfolgen. Dabei sollte der ESP8266 so energiesparend wie möglich arbeiten, da er zukünftig in eine Batterie angeschlossen wird. Nun mache ich mir Gedanken, wie die Kommunikation zwischen beiden Endgeräten ablaufen könnte.

    Mein erster Gedanke war ebenfalls auf URLrequest zu setzen. Dafür müsste die App aber permanent auf den ESP8266 zugreifen (vermutlich über einen Loop der im Hintergrund läuft um die App nicht zu blockieren) und den Status diverser Sensoren abfragen, um Zustandsänderungen unverzüglich übermittelt zu bekommen. Diese sollen ja nicht nur beim Aufrufen der App aktualisiert werden. Ich denke das wäre alles andere als Energiesparend. In meiner eingebildeten Theorie dachte ich mir, dass das Smartphone bzw. die App auch als HTTP Server fungieren und Zustandsänderungen erfassen könnte. Somit würde nur Traffic entstehen, sobald sich am ESP8266 etwas ändert und dieser den neuen Wert ans Smartphone sendet. Aber ob das so funktioniert, keine Ahnung... War nur eine Idee.

    Theoretisch würde ich auf MQTT setzen. Das habe ich bereits ausprobiert und war in Kombination mit Smartphone und einem Rapsberry Pi als MQTT Broker (mosquitto) erfolgreich. Soweit ich weis gibt es sogar ein MQTT library für den ESP8266 um diesen als Broker laufen zu lassen.. zu einem späteren Entwicklungsstand würde ich den ESP8266 aber durch einen ESP32-S2 (sobald verfügbar) ersetzen, für den es dann wiederum keine Library gibt um ihn als Broker laufen zu lassen. Eine eigenen Library zu schreiben und zu implementieren fällt an dieser Stelle aufgrund mangelnder Fachkenntnisse aus.

    Nur frage ich mich: Was gibt es noch für Möglichkeiten? Wie würdet Ihr die "Echtzeit" - Kommunikation zwischen App und Mikrocontroller realisieren?

    Viele Grüße
  • Sehr guter Einwand, vielen Dank! Darüber habe ich auch bereits nachgedacht und im Rahmen meines Projektes wäre es tatsächlich eine gute Option. Ich bin auf den Mikrocontroller nicht festgelegt. Der ESP8266 besitzt kein Bluetooth Modul (könnte erweitert werden), der von mir angestrebte ESP32-S2 ebenfalls nicht. Wobei ich an dieser Stelle auf den ESP32 oder ESP32-S3 (soll ja auch bald released werden) zurückgreifen würde. Getestet habe ich schon ein wenig mit einem Raspberry Pi Zero W, aber ich glaube dort ist generell die Leistungsaufnahme im Vergleich zum ESP32 höher. Gemessen habe ich es noch nicht.

    Wie bekommst du dann deine IOS App in Echtzeit mit dem ESP synchronisiert? Hast du ein paar Schlagwörter für mich, damit ich ein wenig recherchieren kann? Natürlich kommt die Swift Programmierung erst viel später, ich beschäftige mich ja noch mit Tutorials usw.. Nebenbei arbeite ich allerdings schon ein wenig am ESP und da wäre es bereits jetzt schon ganz gut zu wissen, wie die Kommunikation mit dem Smartphone ablaufen könnte.

    Das MQTT Protokoll läuft soweit ich weis nur IP-basiert und ist (trotz ständig offener TCP-Verbindung) stromsparender als HTTP. Das liegt wohl an kleinen Keep-Alive-Paketen bei MQTT und großen headern bei HTTP. Aber da bin ich kein Experte. Trotzdem fällt MQTT als Protokoll aus, da ich keine (Broker) Library für den ESP32 finden konnte. Ein URLrequest loop in der App, bei dem der ESP permanent abgefragt wird, scheint mir keine gute Lösung zu sein. Wie sieht es mit der Möglichkeit aus, dass der ESP einen URLrequest an das Smartphone sendet, sobald sich eine Zustandsänderung ergeben hat? Das Smartphone wäre zwar immernoch per Wlan mit dem ESP verbunden, eine Abfrage in Bezug auf eine Statusänderung erfolgt dann aber nicht mehr kontinuierlich.

    Dennoch bin ich von der Bluetooth-Idee sehr angetan und würde darauf gerne aufbauen.


    Edit: Habe gerade herausgefunden das es noch MQTT-SN gibt. Das Problem von MQTT ist eine ständig geöffnete Verbindung, was sich mit Bluetooth LE ausschließen würde. Bei MQTT-SN besteht diese Anforderung nicht. Das wäre dann glaube ich auch mit Bluetooth möglich (das "normale" MQTT vielleicht auch schon, keine Ahnung), dennoch mangelt es am Broker für den ESP.
  • Ich habe das schon verstanden und auch bereits erwähnt, dass es für den ESP8266 entsprechende Adapter gibt. Trotzdem muss ja noch eine Kommunikation mit dem Smartphone stattfinden. Das wird doch auch alles über irgendwelche Protokolle laufen und hierbei bin ich noch in der Phase der Ideenfindung.
  • Ich halte das Project für nicht besonders praktikabel. Ein Smartphone als "Datenserver" einzusetzen macht absolut keinen Sinn. Fang doch erstmal damit an eine App zu schreiben, die die Daten die dein Rasp speichert schön darstellt und auswertet.
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Vielen Dank für eure Antworten. Der nRF5 sieht wirklich interessant aus! Ich werde mich dazu heute abend mal ein wenig genauer belesen und vor/nachteile zum ESP32 abwägen, welcher ja auch BLE bietet.

    @Thallius: Ich hoffe das ich mich nicht falsch ausgedrückt habe. Natürlich möchte ich den Mikrocontroller als "Server" einsetzen und mit dem Smartphone die darauf gespeicherten Informationen darstellen (und auch den einen oder anderen Zustand setzen). Ursprünglich via MQTT mit dem Mikrocontroller als Broker. Aber inzwischen gefällt mir die Bluetooth Variante besser, eine Broker Library für den ESP konnte ich auch nirgends finden. Die Idee mit dem Smartphone als "Server", auf den der ESP dann immer Zustandsänderungen sendet.. Naja, war eher ein schuss ins blaue.

    Letztendlich fehlt mir blos noch eine Idee, wie die Kommunikation zwischen Smartphone und Mikrokontroller ablaufen könnte. Ich denke für den Mikrokontroller gibts einige Tutorials um so ein Vorhaben zu realisieren. In Bezug auf Swift stelle ich mich da wohl noch ein bisschen ungeschickt an. Da ist es immer hilfreich zu wissen was man sucht! Als ich damals ein wenig mit dem Raspberry gespielt und Daten via MQTT mit dem Smartphone ausgetauscht habe: Es hat gefühlt ewig gedauert eh ich herausgefunden habe, welche Bibliothek ich in Swift einbinden muss, da mir schlicht der Name fehlte und ich vermutlich die falschen Suchbegriffe verwendet habe..
  • hyxamp schrieb:

    In Bezug auf Swift stelle ich mich da wohl noch ein bisschen ungeschickt an. Da ist es immer hilfreich zu wissen was man sucht!
    Suche mal nach Core Bluetooth. Da finden sich Snippets. Daten verschicken und empfangen ist nicht sehr geradlinig.
    Das erscheint mir als ein guter Einstieg: medium.com/@shu223/core-blueto…s-with-swift-9be8524600b2

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Tolibi () aus folgendem Grund: Formatierung korrigiert

  • hyxamp schrieb:

    Vielen Dank für eure Antworten. Der nRF5 sieht wirklich interessant aus! Ich werde mich dazu heute abend mal ein wenig genauer belesen und vor/nachteile zum ESP32 abwägen, welcher ja auch BLE bietet.

    @Thallius: Ich hoffe das ich mich nicht falsch ausgedrückt habe. Natürlich möchte ich den Mikrocontroller als "Server" einsetzen und mit dem Smartphone die darauf gespeicherten Informationen darstellen (und auch den einen oder anderen Zustand setzen). Ursprünglich via MQTT mit dem Mikrocontroller als Broker. Aber inzwischen gefällt mir die Bluetooth Variante besser, eine Broker Library für den ESP konnte ich auch nirgends finden. Die Idee mit dem Smartphone als "Server", auf den der ESP dann immer Zustandsänderungen sendet.. Naja, war eher ein schuss ins blaue.

    Letztendlich fehlt mir blos noch eine Idee, wie die Kommunikation zwischen Smartphone und Mikrokontroller ablaufen könnte. Ich denke für den Mikrokontroller gibts einige Tutorials um so ein Vorhaben zu realisieren. In Bezug auf Swift stelle ich mich da wohl noch ein bisschen ungeschickt an. Da ist es immer hilfreich zu wissen was man sucht! Als ich damals ein wenig mit dem Raspberry gespielt und Daten via MQTT mit dem Smartphone ausgetauscht habe: Es hat gefühlt ewig gedauert eh ich herausgefunden habe, welche Bibliothek ich in Swift einbinden muss, da mir schlicht der Name fehlte und ich vermutlich die falschen Suchbegriffe verwendet habe..
    Wenn die Daten auf dem Microcontroller liegen, dann sehe ich keine Notwendigkeit diese auf das Handy zu übertragen wenn die App nicht aktiv ist und genutzt wird. Du kannst die Daten in dem Moment aktualisieren wenn die App in den Vordergrund kommt. Ansonsten verbrämst du nur unnötig Datenvolumen und/oder Akku
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Vielen Dank @Tolibi, ich schaue es mir am Wochenende mal genauer an!

    @Thallius: Kurz zum Projekt selber: Wir haben einen Wohnwagen und ewig viele Bedienpanele für Solar, Batterie, Ladebooster, Füllstandsanzeige vom Wassertank usw... Für den Winter habe ich mir vorgenommen, alle anzeigen zu entfernen und durch ein Tablet zu ersetzen. Auf dem Tablet läuft dann eine eigene App. Ich bin mir sicher das es entsprechende Anwendungen bereits gibt (die Hardware von Votronic besitzt eine Bluetooth Schnittstelle und kommt ebenfalls mit eigener App), allerdings möchte ich ja auch etwas dabei lernen (Swift). Der Mirkocontroller läuft die ganze Zeit, unabhängig davon ob wir mit dem Auto unterwegs sind oder nicht. Über Solar bzw. dem Ladebooster sollten die Batterien genügend geladen werden. Wenn wir dann Campen fahren, möchte ich mich mit dem Tablet via Bluetooth zum Mikrocontroller verbinden um beispielsweise mal den Füllstand vom Wassertank anzusehen. Wenn die App läuft, möchte ich generell alle Werte "live" anschauen können. Gerade beim befüllen des Wassertanks macht es ja Sinn.. Oder beim ausrichten des Solarpanels. Wenn das Tablet gesperrt ist, müssen keine Daten ausgetauscht werden.. Allerdings möchte ich mich auch nicht unbedingt jedes Mal mit dem Mikrocontroller neu verbinden müssen. Wobei der letzte Punkt dann Bluetooth LE schon wieder ausschließt, notfalls muss ich mich eben wieder neu verbinden. Das Smartphone soll also zu 90% nur Messwerte darstellen, die vom Mikrocontroller aufgezeichnet wurden. Mit den letzten 10% würde ich gerne irgendetwas steuern können: Licht, Wechselrichter, Wasserpumpe.. Wobei wir dafür ja bereits mechanische Schalter im WoMo haben und die schneller betätigt sind, als wenn erst das Tablet/Smartphone entsperrt werden, App geöffnet und Button betätigt werden muss (jedenfalls aus eigener Erfahrung im Eigenheim). Da wäre eine Sprachsteuerung komfortabler, fällt aber fürs WoMo aus.
  • Also mein erster Gedanke: mache den Controller zu einem WLAN-Access-Point. Und verbinde das Tablet mit diesem privaten WLAN. Dann nimmst Du einfach den Safari auf dem Tablet und auf dem Controller ein paar PHP-Scripts. Da kannst Du dann alles schön anzeigen und Buttons die Funktionen auslösen sind auch sehr einfach zu realisieren. So wie die Konfiguration einer FritzBox. Spart auch Xcode, Swift und Developer-Account.
  • hns schrieb:

    Also mein erster Gedanke: mache den Controller zu einem WLAN-Access-Point.
    Oder einen (kleinen) Schritt weiter: Bei dem Anwendungsfall oben rechne ich eigentlich mit einem LTE-Router / WLAN-Extender im WoMo :) Dann gibt es doch eh schon ein privates WLAN und der Controller könnte alle Daten als Webserver entweder als Seite oder - um das Swift-Lernprojekt zu unterstützen - als REST-API zur Verfügung stellen.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Genauo soetwas habe ich bereits vor einigen Jahren umgesetzt. Mit einem Webserver, PHP und auch ein bisschen Java und schon konnte ich wundervoll irgendwelche Messungen anschauen und Aktionen ausführen. Positiver nebeneffekt: Geht auf IOS und Android. In diesem Fall lief der Webserver auf meinem NAS und die Werte wurden vom Mikrokontroller in eine SQL Datenbank geschrieben (ebenfalls auf dem NAS). So ähnlich hatte ich es auch anfangs vor, daher ist mir Bluetooth gar nicht in den Sinn gekommen. Ist prinzipiell auch eine gute Option, allerdings möchte ich etwas neues lernen.

    Dann war ja immernoch das Thema mit dem Stromverbrauch: ein weiterer Punkt, warum mir Bluetooth doch etwas besser gefällt. Wir stehen recht viel autark. Wenn wir mit Freunden unterwegs sind, kann es schon mal vorkommen, dass wir eine Woche am See sind (ohne das Fahrzeug zu bewegen), die Solarpane im Halbschatten der Bäume liegen und die Batterien kaum geladen werden. Da ist es zum Ende der Woche schon öfter mal recht eng geworden. Ein zusätzlicher Verbraucher, der im Verältniss zum Rest nicht so eine hohe Leistungsaufnahme hat, dafür aber kontinuierlich läuft, muss auch ein wenig durchdacht sein. Natürlich könnte ich wlan immer anschalten, wenn ich ein Blick in meine App werfen möchte.. Das macht es aber auch schon wieder komplizierter.

    Ich werde mir den ESP32 aber mal bestellen und auf Arbeit die Leistungsaufnahme bei verschiedenen Bedingungen (unterschiedliche Sensoren, Wlan an/aus, Bluetooth an/aus, Umgebungstemperatur...) messen. Vielleicht machts am Ende des Tages doch alles keinen großen Unterschied und ich kann nochmal überlegen, was ich genau umsetzen möchte.

    LTE Router ist nicht im WoMo vorhanden, zum Campen brauche ich in der Regel kein Handy. Außer zukünftg, wenn ich mal einen Blick auf die Boardelektrik werfen will ;)