Hallo Mit Elektronik habe vom Arduino schon ein paar Erfahrungen. Jetzt habe ich aber des ESP8266 entdeckt. Damit lässt sich ja so einigen anstellen. Vor allem die Möglichkeit, über WLAN Befehle zu senden ist für mich jetzt von Interesse. Aber welche Möglichkeiten gibt es den "Dingern" Befehle zu senden? Damit könnte ich dann jeden einzelnen ESP eine Lampe anschalten lassen. Schön wäre es auch, wenn ich im Vorfeld eine Liste machen könnte, um ein bestimmtes Blinkmuster zu erzeugen. M.
Es gibt ein haufen Möglichkeiten. Die Dinger können z.B einen Webserver laufen lassen. Da kannst per Webbrowser Lampen an und aus schalten.
Aber dann muss ich mich ja immer bei demjenigen Server anmelden, dessen Lampe ich schalten möchte.
Die übliche und wohl sinnvollste Methode, so etwas bei den ESPs zu machen, ist das leichtgewichtige IoT-Protokoll MQTT. Da brauchst Du irgendeinen MQTT-Server/Broker, z.B. mosquitto ( http://mosquitto.org/ ) Bei diesem Protokoll dreht sich alles um sogenannte "Topics". In Deinem Beispiel könntest Du dann z.B. eine Topic "/lampe/wohnzimmer/set_state" haben, an die Du die Message "on" schickst, um sie einzuschalten. Oder über die Topic "/lampe/wohnzimmer/blinkmuster/", an die Du dann als Message das irgendwie kodierte Blinkmuster sendest. Da mehrere ESPs auf die gleiche Topic subscriben können, kann man mit einem einzigen Befehl auch ganz einfach mehrere ESPs steuern.
Martin (M.) schrieb: > Aber dann muss ich mich ja immer bei demjenigen Server anmelden, > dessen Lampe ich schalten möchte. Und wo liegt das Problem? Ich mach das so: Jeder ESP hat seine eigene "Home Page", da zeigt er seinen Status. Alle anderen Seiten auf diesem Server sind eigentlich Kommandos wie "up" bzw "down" bei Rollläden oder "on" bzw "off" bei anderen Funktionen. Die Funktion kann ich auslösen, indem ich auf eine Schaltfläche in der Homepage klicke oder indem ich die entsprechende Page direkt aufrufe. Ich kann also einen Bookmark auf "Rolladen1.mein_netz.net/up" anlegen und der Rolladen geht bei Aufruf dieses Bookmarks hoch. Aber eigentlich soll es ja automatisiert laufen. Dazu habe ich Scripte, die zeitgesteuert ablaufen. Da wird dann an passender Stelle ein Programm wie wget gestartet. wget "Rolladen1.mein_netz.net/up" öffnet so den Rolladen1. Ein HTTP Request ist aber auch in jeder beliebigen Sprache leicht realisiert. Es geht schon mit HTML. Wenn man eine Übersicht über viele ESPs haben will, kann man sich einen Webserver einrichten, der die Links zu den einzelnen Funktionen auf einer Page zusammenfasst. Man kann aber auch, wie oben gesagt, MQTT verwenden und sich einen MQTT Broker einrichten. Ich überlege gerade, ob meine ESPs nicht beides machen sollten. HTML mehr für den "menschlichen" Zugriff über jedes Gerät mit einem Browser (PC, Pad, Phone), MQTT für den "automatischen" Ablauf. MfG Klaus
Klaus schrieb: > Man kann aber auch, wie oben gesagt, MQTT verwenden und sich einen MQTT > Broker einrichten. Ich überlege gerade, ob meine ESPs nicht beides > machen sollten. HTML mehr für den "menschlichen" Zugriff über jedes > Gerät mit einem Browser (PC, Pad, Phone), MQTT für den "automatischen" > Ablauf. Also dass die ESPs sich einerseits über einen MQTT-Broker steuern lassen, andererseits aber auch jeder einzelne ESP zusätzlich seinen eigenen Mini-http-Server betreibt? Die Idee, die Geräte sowohl über MQTT als auch über den Webbrowser steuern zu können, finde ich klasse - aber ich persönlich würde das dann eher so lösen, dass nicht jeder ESP seinen eigenen Webserver betreibt. Sondern auf dem Server, auf dem der zentrale MQTT-Broker läuft, halt auch noch ein http-Server installiert ist, der als eine Art http-MQTT-Bridge fungiert und zentral für jeden ESP zusätzlich eine http-Schnittstelle bereitstellt, und ohne dass sich die einzelnen ESPs darum überhaupt kümmern müssen. Statt der URL "Rolladen1.mein_netz.net/up" würde man dann das Hochfahren des Rolladens dann durch Aufruf z.B. der URL iotserver.mein_netz.net/Rolladen1/up" anstossen...
Hallo, es führen viele Wege nach Rom... Meine ESP-Sensoren und Aktoren sind MQTT-Client, Broker ist Mosquitto auf einem RasPi. Da läuft auch FHEM drauf, so ist die Automatisierung usw. damit machbar. Auf einigen läuft zusätzlich ein Webserver, damit gibt es eine Konfig-Seite, wo ich bequem selten zu ändernde Parameter einstellen kann und auch die Funktion des Aktors auslösen kann. Sozusagen Hintertür, falls der Rest mal nicht läuft. Einige gehen in den AP-Mode, wenn sie nicht ins lokale WLAN kommen, so daß ich noch vom Notebook o.ä. rankomme. Generell sind alle OTA-Update fähig, damit muß ich die Dinger nicht zum Rechner schaffen, wenn mir mal wieder eine neue Idee kommt. Im Moment denke ich über einen zentralen Update-Server für die ESP nach, mit httpUpdate kann das ein Webserver miterledigen und kann dann automatisch alle identischen Geräte updaten. Das geht prinzipiell auch per Internet, falls ein paar der ESPs z.B. auf einem Wochenedgrundstück o.ä. sind. Fa ja gerade die IoT-Botnetz-Sache durch die Medien geht: ich sehe bisher noch wenig Risiko mit den ESPs, die Möglickeiten, eine modifizierte Firmware raufzubekommen, die Bot spielt und andererseits die Originalfunktion ohne Nebenwirkungen erledigt, sind schon wegen der begrenzten Resourcen recht schwierug zu handhaben. Gruß aus Berlin Michael
Joachim S. schrieb: > aber ich persönlich würde das dann > eher so lösen, dass nicht jeder ESP seinen eigenen Webserver betreibt. > Sondern auf dem Server, auf dem der zentrale MQTT-Broker läuft, halt > auch noch ein http-Server installiert ist, der als eine Art > http-MQTT-Bridge fungiert und zentral für jeden ESP zusätzlich eine > http-Schnittstelle bereitstellt, und ohne dass sich die einzelnen ESPs > darum überhaupt kümmern müssen. Der Webserver aus den ESPs hat den Vorteil, daß man den auch ansprechen kann, wenn der zentrale Server down ist. MfG Klaus
Klaus schrieb: > Der Webserver aus den ESPs hat den Vorteil, daß man den auch ansprechen > kann, wenn der zentrale Server down ist. Das stimmt natürlich. Zumindest als Fallback-Lösung für den Fall, dass die Verbindung zum MQTT-Broker aus irgendeinem Grund nicht hergestellt werden kann oder abbricht, könnte das in gewissen Situation sinnvoll sein.
Guten Abend und vielen Dank für die vielen Antworten Was MQTT ist musste ich mir erst einmal anlesen. Wirklich wissen tue ich es aber immer noch nicht. Aber die Sache mit den Webseiten ist natürlich die Lösung. Die ESPs werden ja alle eine eigene (statische) IP haben. So kann durch das Anklicken eines Links, das Licht an oder ausschalten. Für meine "Lichtorgel" brauche ich dann ja nur noch ein Programm, welches bestimmte Links nacheinander "klickt". Aber das erst später... Füe den ersten Versuch benötige ich also nur einen Laptop mit dem ich dann die einzelnen ESPs aufrufen kann, einen Router, der das WLAN bereitstellt und eben ein paar ESPs. Wie wäre es denn, wenn man auf den Router verzichtet? Kann ein Laptop auch ein WLAN bereit stellen? Und wenn die Reichweite zu klein ist, kann auch von ESP -> ESP gefunkt werden?
Martin (M.) schrieb: > Wie wäre es denn, wenn man auf den Router verzichtet? > Kann ein Laptop auch ein WLAN bereit stellen? Problemlos... Sogar die ESP könnnen "Access Point" spielen. Tipp: Schau mal bei "ESP8266 Mesh" rein... http://www.espressif.com/sites/default/files/30a-esp8266_mesh_user_guide_en.pdf Vielleicht, ist es ja das, was du möchtest.
Danke für den Tipp mit Mesh. Das scheint mir aber für meinen Wissensstand zu hoch zu sein. Ich mach erstmal in einem WLAN vom Router :-)
Ich habe hier auf einem raspberry den home assistant laufen. Das ding kann lampen per mqtt steuern, und alles auf einer ziemlich frei konfigurierbaren website anzeigen. Wenn's unbedingt blinken muss, kann man da nen skript bauen und in der weboberfläche aktivieren.. Vorteil: Alle lampen sind identisch, ip etc sind egal. Einfach mit ihrer mac im mqtt adressieren, dann kann das selbe image auf allen lampen sein..
Du erwähntest eine Lichtorgel. Wenn du den gleichen Befehl an mehrere ESP8266 senden möchtest gibt es entweder Broadcast Messages oder Multicast Messages. Bei Broadcast schickst du die Nachricht einfach an die x.x.x.255 IP und alle Netzteilnehmer empfangen die Nachricht auf dem entsprechenden Port. Der Nachteil ist, das Broadcast Messages dein Netz schnell überlasten. Also keine Dauerlösung aber für ne Party sollte es gehen. Bei Multicast Messages kannst du Netzteilnehmer zu Gruppen zusaqmmenschliessen. Jeder in der Gruppe bekommt zu der IP soweit ich weiss noch eine Multicast IP. Also eine Multicast IP pro Gruppe. Der Addressraum ist 224. irgentwas glaube ich . Wie man merkt habe ich mich nicht ausführlich mit Multicast beschäftigt. Die ESP8266 können maximal 4 TCP/UDP Verbindungen gleichzeitig behandeln. D.h max. 4 Clients können auf die Dinger zugreifen. Der ESP8266 kann zwar auch Access Point spielen. Kann aber nur max 4 Clients haben und der ESp8266 hat auch keine Routing bzw Switching Finktionen. 4 Clients können sich zwar mit dem Access Point des ESp8266 verbinden, aber nicht miteinader kommunizieren. Sondern nur vom Client zum Acces Point und vice versa.
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.