Hallo zusammen, ich baue gerade meine Haussteuerung und will die Parameter zu Einstellungen von PC zu µC via MQTT und ESP8266 übertragen. Soweit funktioniert das auch wunderbar (Webseite/PHP/MQTT). ABER: Es gibt einige Parameter, die eigentlich vom µC ausgelesen und dann auf der Webseite angezeigt und verändert werden sollen. Per Definition ist das seitens MQTT so nicht gedacht (ist ja schließlich keine klassische Datenbank). Hat jemand eine Idee, wie ich das umsetzten kann, also Werte bei Bedarf vom MQTT Broker zurücklesen, um diese anschließende z.B. von der Webseite zu verändern? Danke vorab! Tom
Tom schrieb: > Hat jemand eine Idee, wie ich das umsetzten kann, also Werte bei Bedarf > vom MQTT Broker zurücklesen, um diese anschließende z.B. von der > Webseite zu verändern? Der Broker vermittelt nur und soetwas wie "auslesen" gibt es bei MQTT nicht. Du brauchst einen MQTT-Client, der die Werte zum Broker schickt und der reicht sie dann an die Subscriber weiter.
Hi , mir ist bewusst, dass ich die Daten nicht klassisch zurücklesen kann und per Default mein Problem sich so nicht lösen lässt. Ich denke aber, dass so manch einer einen ähnlichen Ansatz hat und für das gleiche Problem eine Lösung - wie auch immer diese aussieht. Diese würde mich letztlich interessieren :-) Das einzige was mir momentan einfällt, ist einen SQL Server zu nutzen, auf dem die Parameter gespeichert werden (parallel zum publish Prozess) und von dort bei Bedarf rückgelesen werden. Oder alternativ: statt SQL in ein txt-File auf dem Webserver/php-Server?!
Bei AWS IoT gibt es dafür Shadow Devices, die dem Status speichern. Gefüttert werden sie mit MQTT oder Rest Updates. Also irgendwo brauchst Du ein digitales Abbild, das gepflegt wird und jede Änderung irgendwo wird per MQTT verteilt und dort festgehalten.
Nachtrag: Liest sich danach als wolltest Du den ESP zum Server / Steuerzentrale machen, das ist keine gute Idee. Der ist nicht dafür geeignet eine DB von Shadow Devices / Zuständen mitzuführen, er ist nur als Client geeignet. Für so eine Management Konsole, die Stati über alles zu managen solltest Du einen „richtigen“ Server nehmen, zB einen Raspberry Pi oder einen richtigen PC.
Conny G. schrieb: > Nachtrag: > Liest sich danach als wolltest Du den ESP zum Server / Steuerzentrale > machen, Mir ist ehrlich gesagt nicht ganz klar was er machen möchte. Wir haben drei Spieler >> PC ... µC ... ESP8266 Wer davon soll MQTT-Client, wer -Broker (Server) sein, und spielt ein Gateway (Shadow, Proxy, ...) mit? Ebenso ist mir nicht klar wer PUBLISHed, nur der Client/die Clients, nur der Server? Denn technisch können beide publishen. Damit ist prinzipiell eine Abfrage von Parametern möglich, wenn auch asynchron: Client SUBSCRIBEd zu Server-Anfragen Server PUBLISHed eine Anfrage Client beantwortet Anfrage mit einem PUBLISH der gewünschten Werte Statt Daten auf Anfrage zu liefern kann der Client natürlich auch selbstständig Daten PUBLISHen wann immer es ihm gefällt.
Versteh das Problem auch nicht ganz... Eventuell wirds anhand eines konkreteren Beispiels klarer, fiktives Heizungsthermostat auf ESP-Basis: Ein Topic: wohnzimmer/heizung/soll für den Soll-Wert (Retained) und ein Topic wohnzimmer/heizung/ist für den Ist-Wert. Ob ich den Soll-Wert nun per App, oder per Webseite, per selbstgebautem Wand-Modul, per FHEM/OpenHAB-Uhrzeitregel oder sonstwie verstelle ist doch egal, MQTT speichert ihn. Wenn sich der MQTT-Server resettet: Kein Problem, er holt den letzten Stand aus seiner persistence-Datei. Wenn sich der Thermostat-ESP resettet: Kein Problem, der MQTT-Server liefert ihm sofort seinen Soll-Wert. Wenn sich das Bedien-Modul resettet, Webseite neu geladen wird, App geöffnet wird: auch kein Problem, MQTT kennt schließlich den zuletzt eingestellten Soll-Wert. Ich wüsste nicht, an welcher Stelle man da sinnvoll eine PHP(-Textfile)-Datenbank o.Ä. mit einbauen könnte, außer zu Visualisierungs-Zwecken (rrdtool &co)
Hallo zusammen, also was ich momentan mache: - Webseite bei einem Hoster - MQTT läuft bei einem CloudMQTT - kein RasPi o.ä. eingebunden - der µC kontrolliert Haus und kommuniziert mit ESP - ESP ist auf die MQTT Messages abonniert; werden Daten empfangen, leitet dieser sie nur weiter (kein Webserver) - Rolladen können direkt angesteuert werden (setzte Wert in MQTT), geht gut - für Rolladenprogramme sollen Zeiten eingestellt werden. Hier kommt meine Problem in's Spiel: * die Zeiten werden eingestellt und dann published * bevor ich was eingebe, wäre es gut, die aktuellen Settings zu sehen Hoffe, das hilft beim Verständnis @ mqtt-sn: Ich weiß jetzt nicht genau, was "retained messages" macht, muß ich mal nachlesen [https://www.hivemq.com/blog/mqtt-essentials-part-8-retained-messages] Scheint fast zu machen was ich brauche?!?
Timo R. schrieb: > - für Rolladenprogramme sollen Zeiten eingestellt werden. Hier kommt > meine Problem in's Spiel: > * die Zeiten werden eingestellt und dann published > * bevor ich was eingebe, wäre es gut, die aktuellen Settings zu sehen Da gibt's jetzt zwei Möglichkeiten. a) Jedesmal vom UI einen Request für die Parameter schicken und auf die Antwort warten b) Irgendwo die Settings speichern, z.B. in einem Shadow Device, das die UI im Zugriff hat. Das Shadow Device gibt Dir jederzeit den Gesamtstatus eines Geräts, ohne dass Du mit dem Gerät direkt sprechen müsstest.
Conny G. schrieb: > a) Jedesmal vom UI einen Request für die Parameter schicken und auf die > Antwort warten Ja, aber genau das bietet MQTT von Haus aus nicht (war nicht dafür gedacht) - oder liege ich da falsch?
Timo R. schrieb: > Conny G. schrieb: > >> a) Jedesmal vom UI einen Request für die Parameter schicken und auf die >> Antwort warten > > Ja, aber genau das bietet MQTT von Haus aus nicht (war nicht dafür > gedacht) - oder liege ich da falsch? Kann man sicher so machen, aber es ist schon vom Architekturansatz her ungünstig. Man würde über eine Strecke, die für asynchrone Kommunikation konzipiert ist quasi-synchron kommunizieren. Und das viel häufiger als man es über eine MQTT Strecke machen will. Müsste man immer alle Parameter von allen Geräten ad hoc abfragen, würden sich riesige Datenübertragungsmengen ergeben, da sieht man schon das das nicht im Sinne des Konzepts ist.
Timo R. schrieb: > Ja, aber genau das bietet MQTT von Haus aus nicht (war nicht dafür > gedacht) - oder liege ich da falsch? Doch, genau das kann MQTT. Es muss aber beim Senden des Werts mitgeteilt werden, dass es sich um einen "aufhebenswerten Wert" handelt, nicht beim Abonieren des Topics.
kein Problem du abonnierst das Thema und der Broker sendet dir die letzte gespeicherte Messages. Du musst also mit deiner Anfrage das Thema abonnieren -> der Broker sendet die letzten Werte und wieder abbestellen. So kommst du an die Werte. Das mit den Schatten funktioniert nur im AWS und da braucht man bloß per GET sich den Schatten holen. Was im übrigen extra kosten verursacht.
:
Bearbeitet durch User
Marco H. schrieb: > kein Problem du abonnierst das Thema und der Broker sendet dir die > letzte gespeicherte Messages. Du musst also mit deiner Anfrage das Thema > abonnieren -> der Broker sendet die letzten Werte und wieder > abbestellen. So kommst du an die Werte. Kann man machen, ist aber Lösungstyp "Hack". > Das mit den Schatten funktioniert nur im AWS und da braucht man bloß per > GET sich den Schatten holen. Was im übrigen extra kosten verursacht. Das war als Lösungskonzept gemeint, nicht als konkrete Lösung, das im AWS zu machen. Aber die Shadows ist wie es gemeinhin gemacht wird, auch bei Apple Homekit oder bei Homematic.
Habe nun die "retained messages" Option in einem anderen Projekt ausprobiert und scheint mir bei meinem Problem zu helfen, sprich darauf kann ich bauen (hoffentlich!) Danke allen!
Timo R. schrieb: > Conny G. schrieb: > >> a) Jedesmal vom UI einen Request für die Parameter schicken und auf die >> Antwort warten > > Ja, aber genau das bietet MQTT von Haus aus nicht (war nicht dafür > gedacht) - oder liege ich da falsch? Ließt du auch die Antworten die du bekommst? Jack schrieb: > Client SUBSCRIBEd zu Server-Anfragen > Server PUBLISHed eine Anfrage > Client beantwortet Anfrage mit einem PUBLISH der gewünschten Werte
Er hat offenbar nicht verstanden das man mit zwei themen arbeiten kann. Abonniert wird die diejenige wo das Device erfolgreich den Status zurückmeldet. Per Publish auf dem Thema das des Device abonniert hat. Du kannst per HTTP request nicht auf auf die Antwort warten. Den Status mußt du per Javascript und GET immer wieder abfragen. Natürlich das in ein json verpacken. Dynamische Webinhalte nennt man so etwas. Warum ? weil der Status sich ja auch vom einen anderen Client ändern könnte. Per Ajax fragt du alle 1sec den Status des Themas ab. Da deine Gateway das Thema ja abonniert hat wird er eine Änderung auch mitbekommen. Alternativ kann man das auch so Lösen wie im AWS mit dem Schatten. So das dein Client auch mitbekommt wenn zwar ein Status gesetzt wurde aber das Gerät nicht diesen zurückgemeldet hat. Das Rücklesen des eigenen Themas bringt nicht sehr viel um zu wissen ob das Gerät den Status auch erhalten hat.
:
Bearbeitet durch User
Marco H. schrieb: > Per Ajax fragt du alle 1sec den Status des Themas ab. ... also primitivstes Polling mit sinnloser Verschwendung von Kanalkapazität
Wie will ein HTTP Client sonst eine status Änderungen feststellen? In dem der User die Seite neu lädt? Mit Header ist die Trafic auch gering da ich ja sagte in json verpacken. Nicht die Seite neu laden. Er kann auch per Websocket das Protokoll wechseln. MQTT über den Browser fahren. www.hivemq.com/demos/websocket-client Schau bis zu dem Punkt in dem der Client äußert das Protokoll zu wechseln ist das ein Webserver. Ob man das nun als Front-End oder als Back-End einsetzt ist relativ Wurst. Per Javascript wird die Seite dann dynamisch verändert wenn eine Abonnierte Message empfangen wird. Probiere es aus das funktioniert auch mit einen lokalen Broker :). Der Webserver stellt nur die Ressourcen zu verfügung und der Browser führt das Javascript dann aus.
:
Bearbeitet durch User
Fortschritt? schrieb: > Marco H. schrieb: >> Per Ajax fragt du alle 1sec den Status des Themas ab. > > ... also primitivstes Polling mit sinnloser Verschwendung von > Kanalkapazität Man kann aus allem ein Drama machen. Er will Werte interaktiv über eine Webseite verändern. Da kann man beim Laden der Webseite schon mal über den Broker ein PUBLISH zum Client auslösen um asynchron (die Webseite muss dann kurz warten) vom Client per PUBLISH über den Broker die aktuellen Werte zurück zu bekommen.
Hallo Tom, viel Gdönse und hin oder her... Viel Programmieren und Gedanken.... MQTT Auf ESP ok Befehle an den ESP Status immer zurück publish'en Dann nimm NodeRed zum steuern, da ist dann alles drinnen mit Datenbank usw. https://nodered.org/ Wenn du es noch schöner haben willst IObroker ... Der hat dann auch noch viele Adapter(Software-Adapter) zu vielen anderen Systemen ... www.http://iobroker.org/ Da kannst du dein Haus als Hintergrund-Bild reinlegen und deine Steuerelemete dazu erzeugen.... Mein Haus habe ich mit SweetHome3D nachgezeichnet http://www.sweethome3d.com/de/ Node Red und IOBroker setzen auf Node.JS auf Funktioniert sogar auf Windows... Besser ist aber Linux. Alles in die Cloud .. damit auch schön alle zuhören und mitschauen können .... ne nicht bei mir ... Kleiner Linux PC der zugleich Datenserver zuhause ist fertig .... VPN Tunnel wenn ich von Unterwegs was machen will. Etwas sicherheit sollte schon sein Gruß Thomas
Mit iobroker habe ich am Anfang experimentiert und der MQTT Teil war grauenhaft. Es kam einige mal Müll zurück der zu anderen Modulen gehörte.
:
Bearbeitet durch User
Marco H. schrieb: > Mit iobroker habe ich am Anfang experimentiert und der MQTT Teil war > grauenhaft. Es kam einige mal Müll zurück der zu anderen Modulen > gehörte. Genau deshalb benutze ich mosquitto ausserhalb vom IO brocker... Node Red (stammt von IBM) für die Logischen Sachen.... Gruß Thomas
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.