Guten Morgen!
Nachdem ich mich am Wochenende ja schonmal zu Thema geäußert hatte, um
mir Euren Rat zu holen, habe ich mich weitergebildet und mich mit dem
Schichtenmodell zur Datenkommunikation in Computernetzwerken
beschäftigt. Ich habe danach festgelegt, dass ich die Kommunikation
zwischen meinem PC und meiner Lampensteuerung über TCP/IP ohne
Zuhilfename eines Webservers (der über den HTML Code eine WebSite
generieren würde) realisieren werde. dazu werde ich im ESP8266 einen TCP
- Server und im PC einen TCP Client realisieren. Für den TCP Server gibt
es ausreichend Beispiele im Netz, den TCP Client werde ich über Visual
Basic realisieren. Damit kann ich zwar nicht von jedem Mobilen Endgerät
auf die Lampen zugreifen, aber das war eh nie das Ziel! Vorteil, ich
brauch nicht HTML sprechen lernen.
Kommentare erwünscht!
Schönen Tag!
MQTT habe ich mir angeguckt! Und es ist leider nicht mein Freund
geworden!
Ich habe verstanden, dass MQTT zweierlei ist, einmal ein Protokoll für
Hausautomation, zum anderen ein Broker, welcher die Daten zur
Lampensteuerung verwaltet! Ich habe nicht erkennen können, wie ich mit
Hilfe des Brokers eine Oberfläche generiere, die meiner Lampensteuerung
zuträglich wäre. Zudem habe ich nicht auf Anhieb verstanden, was da wo
programmiert werden muss. Daher bleibe ich bei meinem schön erfundenen
Protokoll, welches bisher über UART lief, und sende die Daten nun über
WLAN.
Hallo,
ArduStemmi schrieb:> MQTT habe ich mir angeguckt! Und es ist leider nicht mein Freund> geworden!
Schade. MQTT nimmt einem etliches an Protokollaufwand ab.
Quality of Service (Betätigung, daß eine Message den Client erreicht
hat) ist möglich.
Retained Message sind möglich (Deine Lampe mit Empfänger ist nicht
erreichbar oder zeitweise komplett aus), dann schikct der Broker bei
Neuanmeldung automatisch den letzten Zustand. Das Licht geht also wieder
an, wenn es vorher an war und nicht erst, wenn Du von Hand einen neuen
Einschaltbefehl schickst.
Last Will: Deine Lamle teilt dem Broker beim Anmleden mit, wie lang der
KeepAlive sein soll und was der Broker machen soll, wenn sich die Lampe
nicht mehr meldet. Beispielsweise eine Message an Deine Verwaltung,
Lampe xx ist nicht erreichbar.
Das passiert zusammen mit Retained auch dann, wenn Deine
Verwaltungssoftware sich Stunden später beim Broker anmeldet.
Sowas alles selber einzubauen macht ziemlichen Aufwand.
>> Ich habe verstanden, dass MQTT zweierlei ist, einmal ein Protokoll für> Hausautomation, zum anderen ein Broker, welcher die Daten zur> Lampensteuerung verwaltet! Ich habe nicht erkennen können, wie ich mit> Hilfe des Brokers eine Oberfläche generiere, die meiner Lampensteuerung> zuträglich wäre.
Der Broker ist ein reiner Verwalter.
Deine Oberfläche zur Bedienung muß also ein MQTT-Client sein. Der
schikct dann z.B. Lampe/Wohnzimmer/Decke Ein zum Broker.
Der Broker schaut nach, wer alles Lampe/Wohnzimmer/Decke abboniert hat
und schickt es an diese Clients.
MQTT-Clients gibt es nahezu für jedes Betriebssystem, Anbindungen an
existierende Hausautomatisierungs-Software (FHEM, OpenHAB usw.) auch.
Gruß aus Berlin
Michael
ArduStemmi schrieb:> Ich habe verstanden, dass MQTT zweierlei ist, einmal ein Protokoll für> Hausautomation, zum anderen ein Broker, welcher die Daten zur> Lampensteuerung verwaltet!
Weder das eine noch das Andere würde ich 100%ig unterschreiben. Bspw.
ist MQTT keineswegs ein Protokoll speziell für die Hausautomation,
sondern es eignet sich einfach nur (unter Anderem) gut für
Hausautomation.
Du kannst Dir MQTT bzw. einen MQTT-Broker eher als ein ganz allgemeines
"Internet-Forum" wie dieses hier vorstellen, wo man beliebige "Threads"
erstellen kann, in die man beliebige Nachrichten hineinschreiben kann.
Diese Threads können "beobachtet"/"abonniert"/"subscribed" werden (oder
wie auch immer man das nennen will), d.h., man kann dafür sorgen, dass
man automatisch informiert wird, wenn neue Nachrichten in einem
bestimmten Thread gepostet werden, für den man sich interessiert.
Ist jetzt eine stark vereinfachte Erklärung, hilft aber, eine erste
grobe Vorstellung davon zu erhalten, was MQTT eigentlich macht. Wer es
besser verstehen will, dem kann ich z.B. diese kurze Einführung auf
heise empfehlen:
https://www.heise.de/developer/artikel/MQTT-Protokoll-fuer-das-Internet-der-Dinge-2168152.html> Ich habe nicht erkennen können, wie ich mit> Hilfe des Brokers eine Oberfläche generiere
Gar nicht, denn MQTT ist ein minimalistisches Protokoll lediglich zum
Austausch von Nachrichten, und hat mit Benutzeroberflächen daher erst
einmal genauso wenig zu tun wie z.B. TCP. Stattdessen machst Du eine
Benutzeroberfläche z.B. in HTML, und wenn Du dann auf einen bestimmten
Button klickst, dann wird "unter der Haube" per Javascript eine
Nachricht an einen MQTT-Broker geschickt.
> Daher bleibe ich bei meinem schön erfundenen> Protokoll, welches bisher über UART lief, und sende die Daten nun über> WLAN.
MQTT zu verwenden wäre zwar in meinen Augen eindeutig der sinnvollste
Weg - aber Du müsstest Dich da natürlich erst kurz einarbeiten. Genau
wie in HTML, wenn Du zusätzlich eine Benutzeroberfläche haben willst,
die in jedem Webbrowser läuft.
Stattdessen hast Du Dich jetzt halt für eine letztlich suboptimale
Lösung entschieden, die aber natürlich den Vorteil hast, dass Du Dich
nicht erst einarbeiten musst.
Ich kenne den Artikel von Heise! Der erläutert das dahinter stehende
System sehr gut! Mir fehlt leider ein Hinweis auf einen Workflow und die
dazu benötigten Ressourcen und Kompetenzen! Dein Hinweis, die Oberfläche
mittels HTML zu gestalten deutet ja darauf hin, dass ich irgendeine
Netzwerk Instanz benötige, die die Website aufnimmt! Und dann noch Java,
im Untergrund!
Und wo läuft denn der Broker, wenn mein Computer aus ist? Auf dem NAs?
Ich glaube nicht! Damit fallen 30 % aller Vorteile weg!
Eine wichtige Info noch! Die Computerverbindung zur Lampensteuerung
dient nur, um Standardwerte für Beleuchtungsszenarien zu hinterlegen!
Für die Auswahl, welches Szenario gerade aktiv wird, dient das
Bedienelement, welches bisher über UART angesprochen wurde!
Ardustemmi schrieb:
warum schreist du denn so?
Der MQTT Broker kann auf irgendeinem Gerät im Netz laufen, das kann auch
ein NAS oder eine FritzBox sein wenn sich auf diesen Geräten zusätzliche
Pakete installieren lassen. Sinnvoller ist aber eher einen Kleinrecher
wie Raspberry Pi dafür nehmen. Steht auch auf meiner Roadmap, RaspPi mit
MQTT, NodeJS und JavaScript.
Mein MQTT Broker lief zusammen mit openHAB jahrelang auf einem Synology
NAS, beide sind jetzt aber völlig problemlos auf einen Raspi2 umgezogen.
Holger
HTML ist allerdings auch nicht schwer - wenn man sich auf die Grundlagen
beschränkt. Dein Webserver muss nicht zwingend eine Webseite erzeugen.
Er könnte auch einfach mit einzeiligen Rückmeldungen im Klartext
antworten.
Du kannst dann wahlweise mit einem Basic Programm, oder einer Smartphone
App oder einem Javascript (eingebettet in einer statischen HTML Datei,
die evtl. irgendwo anders liegt) oder einem Shell Script oder einer
Batch Datei oder ... ansteuern. Es ist sehr einfach von
unterschiedlichen Clients aus nutzbar, wenn der Embedded-Server erst
steht.
In Band 2 beschreibe das HTTP Protokoll und in Band 3 eine konkrete
Anwendung mit ESP8266:
http://stefanfrings.de/mikrocontroller_buch/index.html
