Hallo, ich habe hier mehrere Geräte gleichen Typs mit einem ESP8266. Diese Geräte befinden sich alle in verschiedenen Haushalten und sollen nun per Internet miteinander kommunizieren können. Ich stelle mir das so vor, dass ich eine Webseite oder einen Weberver erstelle, an dem sich alle Geräte anmelden und diese Webseite oder Webserver koordiniert dann die Kommunikation. Sollte ich hier Blödsinn verzapfen, dann bitte ich um Entschuldigung - ich habe eben kaum Erfahrung mit TCP/IP. Die ESPs sollen also als Clients von einem Internet-Server gesteuert werden. Wie macht man sowas? Wo fange ich an? Gruß Peter
Ich bin absoluter Fan von Socket.IO und verwende das oft in Node.JS Applikationen auf meinen Raspberries. Für ESP gibt's auch was: https://github.com/dtoki/Socket.io-Esp-client Hab das aber noch nicht getestet.
Hallo Mick, danke für Deine Antwort. Aber ich glaube, ich habe mich nicht klar ausgedrückt: Die ESPs als Client zu programmieren ist nicht das Problem. Es geht mir darum, wie ich den Webserver (oder was ich für die Koordination der ESPs sonst brauche) erstelle/programmiere. Was brauche ich dazu? Welche Programmiersprche verwendet man dafür? Was muss ich implementieren? Hab ich noch was vergessen?
Deine Fragestellung ist etwas seltsam. Wie programmierst du deine ESPs? Daraus resultiert dann auch die nötige Implementierung des Servers.
Peter schrieb: > Es geht mir darum, wie ich den Webserver (oder was ich für die > Koordination der ESPs sonst brauche) erstelle/programmiere. z.B. einen Raspberry Pi, auf dem Mosquitto läuft https://mosquitto.org/ https://github.com/mqtt/mqtt.github.io/wiki
Vermutlich ist eine Hürde, daß die verschiedenen Haushalte einen "Client"-Anschluß haben, sprich einen Router, der per NAT Clients auf eine einzige IP-Adresse "multiplext", die eventuell sogar alle 24h eine andere ist. Wenn irgendwo (bei einen Hister) der zugehörende Server steht, mit eigenem DNS-Name oder zumindest fester IP, dann geht das easy. Sonst ...
Ich finde die Frage gar nicht unklar. Ich hatte damals mit PHP einen schnellen Einstieg in die Programmierung von Webservern gefunden. Bei PHP ist die Anbindung an eine SQL Datenbank sehr komfortabel gelöst. Und es ist sehr weit verbreitet, dementsprechend gut dokumentiert. Im Prinzip läuft das so: Jedesmal, wenn deine Clients die URL eines PHP Scriptes aufrufen, wird das Script vom Webserver ausgeführt und dessen Output an den Client gesendet. Während der Ausführung kann das PHP Script Daten aus dem HTTP Request extrahieren und verarbeiten, zum Beispiel in die Datenbank speichern. Demnach empfehle ich Dir, bei irgendeinem Webhoster einen Webspace mit PHP und einer Datenbank anzumieten. So etwas kostet ohne Fremdfinanzierung durch Werbebanner etwa 5 Euro pro Monat. Das ist kaum teurer, als der Stromverbrauch eines kleinen Servers zuhause. Falls du keine entsprechenden Anbieter kennst, schau Dir mal Hosteurope an. Die sind nicht die billigsten, doch ich bin denen seit gefühlt 20 Jahren treu weil sie zuverlässig und unkompliziert sind.
MQTT ist der richtige Weg! Es gibt haufenweise public-MQTT-Broker die man nutzen kann, und über NAT muß man sich dann auch keine Gedanken mehr machen. Das geht übrigens auch mit SSL-Verschlüsselung....sogar mit einem ESP8266.
:
Bearbeitet durch User
> Es gibt haufenweise public-MQTT-Broker die man nutzen kann
Klar, und denen soll ich meine persönlichen Daten und die Gewalt über
mein Haus anvertrauen? Nee, lass mal.
Stefan U. schrieb: >> Es gibt haufenweise public-MQTT-Broker die man nutzen kann > > Klar, und denen soll ich meine persönlichen Daten und die Gewalt über > mein Haus anvertrauen? Nee, lass mal. Wenn du so misstrauisch bist, richte dir doch nen eigenen Broker ein! Nen v-Server mit öffentlicher IP gibts bereits ab <=5€/Monat.
:
Bearbeitet durch User
Ich empfehle ebenfalls MQTT; wie schon oben beschrieben entweder über einen öffentlichen MQTT-Broker, oder - wenn einem das nicht ganz geheuer ist - über einen eigenen vServer, auf dem man einen eigenen MQTT-Broker (also in der Regel mosquitto) installiert. Der Ansatz, dass die ESPs stattdessen über HTTP mit der Aussenwelt bzw. einem Internet-Server kommunizieren (z.B. einem 08/15-Webspace-Angebot mit PHP und Datenbankanbindung) kommt imho spätestens bei Aktoren schnell an seine Grenzen: Bei ESPs, die lediglich als Sensoren fungieren und Daten senden, ist das kein Problem - aber sobald ein ESP als Aktor fungieren und Daten empfangen soll, hat man ein Problem: Dieser ESP müsste dann ständig den Server auf neue Daten pollen, oder irgendwelche anderen Notlösungen verwenden, um das Problem der fehlenden Push-Funktionalität des HTTP-Protokolls auszumerzen. Daher lieber gleich MQTT nehmen; dieses Protokoll ist mittlerweile eh geradezu der de-facto-Standard für die Kommunikation von IoT-Geräten. Diesen Artikel hier: https://www.heise.de/developer/artikel/Kommunikation-ueber-MQTT-3238975.html bietet eine hervorragende kurze Einführung. Die Installation und Einrichtung des für MQTT nötigen MQTT-Brokers ist ein Kinderspiel; auf den meisten Linux-Systemen genügt üblicherweise ein
1 | sudo apt-get install mosquitto |
schon hat man einen MQTT-Broker laufen. Der ist im Auslieferungszustand allerdings noch offen wie Scheunentore; wenn der MQTT-Broker also nicht im heimischen Netzwerk, sondern für jedermann erreichbar im Internet laufen soll, dann sollte man zumindest noch mosquittos Authentifizierungsmechanismus aktivieren, damit sich nicht jedermann mit dem MQTT-Broker verbinden kann.
Beitrag #5194914 wurde vom Autor gelöscht.
Danke für die Antworten! Stefan U. schrieb: > Ich finde die Frage gar nicht unklar. > > Ich hatte damals mit PHP einen schnellen Einstieg in die Programmierung > von Webservern gefunden. Bei PHP ist die Anbindung an eine SQL Datenbank > sehr komfortabel gelöst. Und es ist sehr weit verbreitet, > dementsprechend gut dokumentiert. > > Im Prinzip läuft das so: Jedesmal, wenn deine Clients die URL eines PHP > Scriptes aufrufen, wird das Script vom Webserver ausgeführt und dessen > Output an den Client gesendet. Während der Ausführung kann das PHP > Script Daten aus dem HTTP Request extrahieren und verarbeiten, zum > Beispiel in die Datenbank speichern. > > Demnach empfehle ich Dir, bei irgendeinem Webhoster einen Webspace mit > PHP und einer Datenbank anzumieten. So etwas kostet ohne > Fremdfinanzierung durch Werbebanner etwa 5 Euro pro Monat. Das ist kaum > teurer, als der Stromverbrauch eines kleinen Servers zuhause. > > Falls du keine entsprechenden Anbieter kennst, schau Dir mal Hosteurope > an. Die sind nicht die billigsten, doch ich bin denen seit gefühlt 20 > Jahren treu weil sie zuverlässig und unkompliziert sind. Ich habe vor längerem ein paar Webseiten auf HostEurope mit HTML und PHP erstellt. Deshalb kann ich mir diesen Ansatz recht gut vorstellen: Alle ESPs senden an ein PHP Script, was vom Konzept her wohl nichts Anderem als dem Ausfüllen eines Webseiten-Formulars entspricht. Die Webseite (der Webserver) schreibt dann in eine Datenbank und kann diese Daten dann an alle weiteren ESPs (bei Bedarf) versenden. Chr. M. schrieb: > schau dir mal MQTT an. Wolfgang schrieb: > z.B. einen Raspberry Pi, auf dem Mosquitto läuft > https://mosquitto.org/ > https://github.com/mqtt/mqtt.github.io/wiki Harry L. schrieb: > MQTT ist der richtige Weg! Joachim S. schrieb: > Ich empfehle ebenfalls MQTT; Das mit dem MQTT scheint mir aber die passender Lösung zu sein. Allerdings weiss ich nicht so recht wo ich dann anfangen soll. Wobei ein paar Hinweise habe ich ja von Euch bereits erhalten: - Zuerst muss ich mir einen RaspberryPi besorgen und auf dem den MQTT Broker zum Laufen bringen - das wird schwierig genug! - Dann muss ich noch dafür sorgen, dass der RaspberryPi immer erreichbar ist - Dynamic DNS? Ich werde mir mal die Links ansehen/durchlesen und hoffe, das ich da weiter komme. Wer noch weitere Infos hat: Immer her damit! Danke und Gruß Peter
>> Klar, und denen soll ich meine persönlichen Daten und die Gewalt über >> mein Haus anvertrauen? Nee, lass mal. > Wenn du so misstrauisch bist, richte dir doch nen eigenen Broker ein! > Nen v-Server mit öffentlicher IP gibts bereits ab <=5€/Monat. Ach was! lies mal, was ich ich empfohlen habe! Fast genau das, und ich habe auch 5€ geschrieben.
Peter schrieb: > - Zuerst muss ich mir einen RaspberryPi besorgen und auf dem den MQTT > Broker zum Laufen bringen - das wird schwierig genug! > - Dann muss ich noch dafür sorgen, dass der RaspberryPi immer erreichbar > ist - Dynamic DNS? Einen Raspberry Pi benötigst Du nicht unbedingt. Letztlich benötigst Du für für MQTT bei Deinem Vorhaben halt irgendeinen MQTT-Broker/Server, der von jedem Haushalt, der an Deinem Vorhaben teilhaben soll, erreichbar sein muss. Dafür gibt es mehrere Möglichkeiten: 1. Ihr benutzt einen von Dritten betriebenen MQTT-Broker wie "cloudmqtt.com", der problemlos für jedermann über das Internet erreichbar ist. Vorteil: Keinerlei Einrichtungs- und Administrationsaufwand. Nachteil: Der MQTT-Server ist nicht unter Deiner Kontrolle, und es fühlt sich mglw. komisch an, die Geräte über irgendeinen komischen fremden Cloud-Dienst kommunizieren zu lassen. 2. Du betreibst Deinen eigenen MQTT-Broker, indem Du die MQTT-Broker-Software mosquitto auf einem System/Server installiert, mit dem alle teilnehmenden Haushalte auf irgendeine Weise über das Internet kommunzieren können. Dafür gibt's wieder mehrere Möglichkeiten: 2.1. Du mietest einen virtuellen Internet-Server (vServer) bei einem entsprechenden Anbieter, der über eine öffentliche IP-Adresse problemlos für jedermann über das Internet erreichbar ist. Preislich ab ca. 3 Euro pro Monat möglich. Über das Internet kannst Du Dich auf diesem Server einloggen und beliebige Software installieren etc. 2.2. Du betreibst den Server, auf dem den MQTT-Broker installierst, in Deiner eigenen Wohnung. Theoretisch könntest Du die MQTT-Broker-Software (mosquitto) einfach auf Deinem normalen PC installieren; weil der MQTT-Broker/Server aber 24/7 erreichbar sein soll etc., betreibt man den MQTT-Broker aber üblicherweise auf eigenständiger (und idealerweise energiesparender) Hardware. Dafür bietet sich der günstige Einplatinencomputer Raspberry Pi besonders an, daher ist das in der Praxis die wohl beliebteste Lösung; letztlich kannst Du aber jedes beliebige Computersystem benutzen, auf dem Linux oder Windows läuft. Dieser Server/dieses Netzwerkgerät muss dann wie gesagt für jeden teilnehmenden Haushalt erreichbar sein, dafür gibt's wieder mehrere Möglichkeiten: 2.2.1. Du sorgst dafür, dass zumindest der Standard-MQTT-Port 1883 Deines Servers für jedermann über das Internet erreichbar ist, indem Du den entsprechenden Port per NAT freigibst und einen Service a la DynDNS benutzt, damit man über eine feste Kombination aus IP-Adresse und Port über das Internet auf den MQTT-Broker zugreifen kann. 2.2.2. Du und die anderen teilnehmenden Haushalte richten ein VPN ein. Auf diese Weise kann nicht jeder beliebige Internetnutzer mit Deinem MQTT-Broker/Server kommunzieren. Kurzum: Das eigentliche Problem liegt vermutlich darin, ein beliebiges eigenständiges Linux oder Windows-System zum Laufen zu bekommen, das als Server fungiert und auf das alle teilnehmenden Haushalte zugreifen können. Hast Du das erst einmal erreicht, dann ist der erfolgreiche Betrieb eines MQTT-Brokers im Zweifelsfall nur noch ein
1 | sudo apt-get install mosquitto |
entfernt. Stefan U. schrieb: >>> Klar, und denen soll ich meine persönlichen Daten und die Gewalt über >>> mein Haus anvertrauen? Nee, lass mal. > >> Wenn du so misstrauisch bist, richte dir doch nen eigenen Broker ein! >> Nen v-Server mit öffentlicher IP gibts bereits ab <=5€/Monat. > > Ach was! lies mal, was ich ich empfohlen habe! Fast genau das, und ich > habe auch 5€ geschrieben. Du hast aber doch von einem gewöhnlichen Webspace-Angebot mit PHP und Datenbankanbindung gesprochen. Harry hingegen hat darauf hingewiesen, dass man für den gleichen Preis von unter 5 Euro/Monat bereits einen vollwertigen vServer mieten kann - also ein vollwertiges Linux-System, über das man die volle Kontrolle hat. Damit hat man letztlich nun mal viel mehr Möglichkeiten - man kann beliebige Software installieren, beliebige Programmiersprachen benutzen etc. Und speziell das, wovon Harry gesprochen hat (nämlich: einen MQTT-Broker auf dem gemieteten vServer zu installieren und zu betreiben) ist bei einem reinem Webspace-Angebot nun mal nicht möglich.
:
Bearbeitet durch User
> Harry hingegen hat darauf hingewiesen, dass man für den gleichen Preis...
Hab's nun verstanden. Harry Vorschlag macht Sinn.
Ich möchte noch darauf hinweisen, dass man bei einem gewöhnlichen DSL
Anschluss fürs Wohnzimmer in der Regel keine feste IP Adresse erhält.
Eventuell kann man was mit Dyndns machen, ich hatte allerdings bei
meinem letzen Versuch das Problem, dass mein
Internet-Anschluss-Betreiber anscheinend den Zugriff auf Dyndns gesperrt
hat.
Joachim S. schrieb: > 2.2.2. Du und die anderen teilnehmenden Haushalte richten ein VPN ein. > Auf diese Weise kann nicht jeder beliebige Internetnutzer mit Deinem > MQTT-Broker/Server kommunzieren. 2.2.3. Das Ganze kommuniziert über TOR. Es ist zwar ein Entrynode an jedem Standort notwendig, dafür entfällt allerding der gesamte Kram mit DynDNS etc.
Peter schrieb: > Die ESPs sollen also als Clients von einem Internet-Server gesteuert > werden. Anders rum: Clients steuern den Server. Wenn die zentrale Stelle die ESPs steuert sind also die ESPs deine Server und die zentrale Stelle ist der einzige Client. Was soll dann genau kommuniziert werden? Was soll die Zentrale kontrolieren und steuern?
Der Zentrale Server kann seine Clients steuern, indem er Kommandos in Warteschlangen ablegt, welche die Clients in angemessenen Intervallen abrufen.
Stefan U. schrieb: > Eventuell kann man was mit Dyndns machen, ich hatte allerdings bei > meinem letzen Versuch das Problem, dass mein > Internet-Anschluss-Betreiber anscheinend den Zugriff auf Dyndns gesperrt > hat. Das ist ja voll gruselig. Welcher Provider war denn das?
Unitymedia. Das ist schon über ein Jahr her, seit dem habe ich es gar nicht mehr versucht. Da ich einen virtuellen Webserver miete, ist diese Spielerei für mich ziemlich uninteressant.
Joachim S. schrieb: > Der Ansatz, dass die ESPs stattdessen über HTTP mit der Aussenwelt bzw. > einem Internet-Server kommunizieren (z.B. einem 08/15-Webspace-Angebot > mit PHP und Datenbankanbindung) kommt imho spätestens bei Aktoren > schnell an seine Grenzen: > Bei ESPs, die lediglich als Sensoren fungieren und Daten senden, ist das > kein Problem - aber sobald ein ESP als Aktor fungieren und Daten > empfangen soll, hat man ein Problem: Dieser ESP müsste dann ständig den > Server auf neue Daten pollen, oder irgendwelche anderen Notlösungen > verwenden, um das Problem der fehlenden Push-Funktionalität des > HTTP-Protokolls auszumerzen. ...hat aber den Vorteil, dass man damit durch praktisch jede Firewall kommt und es keine Probleme mit den vielen NATs (eins in der Fritzbox, noch mindestens eins beim Provider...) gibt. Zudem ist bei Hausautomatisierung ja keine Echtzeitfähigkeit gefordert. Da sind Verzögerungen von wenigen Sekunden (Lichtschalter) bis mehreren Minuten (Heizungsthermostat) akzeptabel.
Nicht zwangsläufig denn es gibt ja Websocket. Also die Möglichkeit das Protokoll zu wechseln. Dann kann man alles mögliche über den Webserver übertragen. Das Pooling ist er weniger ein Problem, mit Json kann man auch die Response sehr klein halten.
:
Bearbeitet durch User
Stefan U. schrieb: > Unitymedia. Naja klar, da gibt's ja wohl nicht mal eine öffentliche IP-Adresse, die machen also "carrier-grade NAT". Da wäre es natürlich sinnvoll, dyndns zu sperren, weil es sowieso völlig nutzlos wäre. Allerdings ist es nicht wirklich gesperrt, es kann nur einfach nicht funktionieren. Dein DynDNS-Client kennt die öffentliche IP-Adresse nicht, und selbst wenn er sie ermitteln kann (was relativ leicht ist): Er hat nicht die Kontrolle über das Border-Gateway des Providers (den Inhaber der öffentlichen Adresse) und kann deswegen dort keine Forwards einrichten. Also: Wer vorhat, irgendwas aus seinem LAN öffentlich erreichbar zu machen, der sollte natürlich niemals einen solchen Provider wählen. Minimalanforderung für DynDNS ist eine öffentliche IP-Adresse für das EIGENE Border-Gateway (AKA: Router/Fritzbox/whatever). Fazit: Dein Fehler.
Schreiber schrieb: > Zudem ist bei Hausautomatisierung ja keine Echtzeitfähigkeit gefordert. Das kommt drauf an, was du als "Echtzeitfähigkeit" bezeichnest. Ich lege schon Wert darauf, dass das Licht ziemlich sofort an geht, wenn es das soll. Reaktionszeiten im Mikrosekundenbereich sind da allerdings nicht gefordert.
https://de.wikipedia.org/wiki/Echtzeitsystem Es kommt drauf an was man daraus macht. MQTT ist da das Mittel der Wahl.
Danke für die Erklärung bezüglich Unitymedia. Ich wusst das noch nicht, hatte deswegen gedacht, dass sie Dyndns gesperrt hatten.
Kurze Off topic Ergänzung zu Unitymedia: Bei mir war das Problem, dass ich durch IPv6 keine echte Ipv4 Adresse hatte, sondern eben nur eine über NAT. Nach vielen Problemen bin ich dann zum buissnes Tarif gewechselt, da hast du sogar eine feste IPv4
M.Keller schrieb: > Kurze Off topic Ergänzung zu Unitymedia: Bei mir war das Problem, dass > ich durch IPv6 keine echte Ipv4 Adresse hatte NEIN, nicht "durch IPv6". Das hat damit garnix zu tun. IPv4 und IPv6 können völlig unabhängig voneinander betrieben werden, auch über ein- und denselben Anschluss. > Nach vielen Problemen bin ich dann zum buissnes Tarif > gewechselt, da hast du sogar eine feste IPv4 Genau das ist, was der Provider wollte: dir mehr Kohle abknöpfen. Übrigens: auch in der Business-Variante hast du IPv6. Das allein zeigt, dass du da oben Müll erzählt hast. Die Sache ist einfach: So macht dein Provider aus der Knappheit der IPv4-Adressen und der Tatsache, dass er sich nicht rechtzeitig um einen ausreichend großen IPv4-Adress-Pool gekümmert hat, auch noch Extra-Profit. Und du zahlst das. Selbst schuld...
Ich melde mich nochmals... Wir hatten MQTT für drei Monate auf einigen IoT ESPs im Einsatz. Das Ganze lief leider nicht zuverlässig. Darum hatte ich socket.io vorgeschlagen, da dieses verschiedene Mechanismen gegen Verbindungsproblemen standardmässig bereitstellt.
Mick schrieb: > Wir hatten MQTT für drei Monate auf einigen IoT ESPs im Einsatz. Das > Ganze lief leider nicht zuverlässig. "lief nicht zuverlässig" klärt nichtmal, ob es an der Stromversorgung, an der Programmimplementation oder am Protokoll lag. Was hattest du denn als QoS eingestellt und wie hat sich "lief nicht zuverlässig" bemerkbar gemacht? Welche Firmwareversion der ESP8266(?) hattet ihr ingesetzt? Zu Anfang gab es da noch deutliche Probleme.
c-hater schrieb: > NEIN, nicht "durch IPv6". Das hat damit garnix zu tun. Dann hab ich das halt etwas laienhaft ausgedrückt, sorry so tief stecke ich nicht im Thema. Fakt war aber, das ich damals (2013) einen DualStack-lite Anschluss hatte mit einer öffentlichen IPv6 Adresse und einer IPv4 die von außen nicht erreichbar war. Das Verfahren heißt Carrier Grade NAT, richtig. Jetzt hab ich eine feste IPv4 Adresse. Ich hab zwar nur 50mbit statt 120mbit, dafür den besseren Service + Fritzbox für 29€… ich fühle mich nicht abgezockt :-) Back2topic: es würde mich jetzt schon sehr interessieren wieso ihr mit MQTT Probleme hattet und ein Wechsel des Protokolls geholfen hat, das Protokoll soll ja genau bei eher schlechten Verbindungen trotzdem funktionieren
Oder jeder ESP hat seine eigne Webseite. Und irgendwo hast du noch eine HTML Seite die die ESPs als IFrame lädt ... Oder der ESP hat ein IFrame drin, das in Wirklichkeit auf dem PI liegt Ich hab zum Beispiel der ESP Webseite ein Hintergrundbild verpasst. Aber das Bild kommt vom Apache Server des PI, nicht vom ESP. Funktioniert im lokalen Netzwerk prima.
Jens schrieb: > Ich hab zum Beispiel der ESP Webseite ein Hintergrundbild verpasst. Aber > das Bild kommt vom Apache Server des PI, nicht vom ESP. > Funktioniert im lokalen Netzwerk prima. nach 5 Jahren endlich die Lösung :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.