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?
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.
> 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.
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.
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/wikiHarry 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.
> 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?
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.
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.
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 :-)
