Ich wäre auch sehr für! Kann mich oben geschriebenen nur anschließen. Nutze auch fast ausschließlich alles über MQTT…
Ja, danke, ich glaube ich habe es kapiert. Ich sollte also den GPIO-Status, den ich auf dem ESP8266-Gerät sehe per MQTT an einen „Value“-Topic schicken, der für die Visualisierung im IPSymcon Webfrontend verwendet wird. Und einen zweiten „Command“-Topic für die Gegenrichtung, der auf dem ESP8266 den Schaltvorgang auslöst (z. B. beim ESPEasy einfach eine Hilfsvariable füllen und bei Veränderung der Variable dann den Schaltvorgang des dazugehörigen GPIO auslösen). Im Webfrontend stelle ich dann den Value-Topic für die Visualisierung dar. Wenn ich nun ein Gerät schalten möchte, Ändere ich nicht den „Value“-Topic, sondern den „Command“-Topic. Für Bewegungsmelder, Funktaster, Timer usw., die jeweils ein Skript auslösen überhaupt kein Problem. Und beim Aktionsskript für die Variable des „Value“-Topics nehme ich nicht die Standardeinstellung, sondern ändere stattdessen den dazugehörigen Command-Topic. Erst nachdem der Schaltvorgang dann erfolgreich vom ESP8266 bestätigt wurde, ändert sich auch die Anzeige im Webfrontend. Dadurch, dass ich keine Rückkopplung zwischen der Anzeigevariable auf die Commandvariable habe, kann auch keine Endlosschleife entstehen. Super, vielen Dank für die Erklärung!
Dann habe ich nur noch einen kleinen Schönheitsfehler, wenn das Modul mal nicht erreichbar ist, setze ich zwar durch Betätigung des Buttons im Webfrontend den Topic für die Commandvariable, es gibt natürlich keine Rückmeldung, dass geschaltet wurde und in der Visualisierung bleibt (wie gewünscht) der aktuelle Schaltzustand stehen. Wenn dann z. B. nach 10 Minuten das WLAN wieder funktioniert, holt sich das Modul direkt den Topic der Commandvariablen ab und schaltet dann mit 10 Minuten Verzögerung das Gerät ein oder aus. D. h., idealerweise sollte ich den Zustand der Variablen status/LWT noch auswerten und im Zustand „Connected“ den Button bedienbar machen und im Zustand „Connection lost“ die Button-Bedienbarkeit deaktivieren, richtig?
Bei dem Command-Topic sollte das Retain-Flag nicht gesetzt sein, dann kann sich dein Device beim Start auch keinen veralteten Schaltbefehl abholen
Guten Morgen,
ich hatte gestern nach einem Update meines Systems (PiVCCU2 inkl. IPS und Broker auf Tinker Board S) etwas Probleme u.a. auch mit dem mosquitto MQTT Broker. Das lief plötzlich nicht mehr.
Die Chance hatte ich genutzt und ihn deinstalliert. Dann habe ich Dein Script installiert.
Script geladen und war dann erst einmal platt, dass meine Tasmota-Devices so sauber im Objektbaum eingebunden wurden.Coole Sache.Mehr hatte ich ersteinmal noch nicht verändert.
Dann stellte ich aber fest, dass, ich einen Sonoff schalte und alle gehen an und auch wieder aus beim Ausschalten.
Ich glaube, ich muss mit noch einmal intensiver damit auseinandersetzen und vor allem, wie das nun in dem Zusammenspiel mit Kais mqtt-Client und IPS-Tasmota funktionieren soll.
Grins
Ich habe dies genau so auch wie "Boui "…einen anschalten und alle gehen an, genauso beim ausschalten.
Gruß
richimaint
Ich bin ja manchmal kurz davor, mir ein Tasmota-Device zuzulegen, bloß um mal nachvollziehen zu können wo da die Fallstricke sind… aber mir fehlt leider die Zeit im Moment. :o
Damit habe ich auch noch Probleme.
Ich habe noch die angelegten Devices die ich über Kais Tasmota Konfigurator erstellte. Diese haben als übergeordnete Instanz den „IPS_KS_MQTTClient“. Welche Instanz brauchen diese Devices jetzt?
Bin jetzt wieder auf den Mosquitto Broker umgestiegen.
sokkederheld’s Skript braucht KaiS’s Module nicht.
Ich habe das mal nur kurz vor Wochen probiert, auf einen anderen frischen IPS-System (ohne KaiS Module), um zu sehen was geht.
Das Skript legte alles an, und ist somit ein anderer Weg, als KaiS Module für Mosquitto.
Was besser ist, mag ich nicht sagen, aber ich bleibe erst mal bei Mosquitto mit den Tasmota Modulen von Kai.
Gibt es Hinweise, dass da ein Bug in meinem Skript ist?
Ich gehe einfach davon aus, dass es noch nicht ganz klar ist, wie nun die Devices aus IPS heraus angesprochen werden. Wie z.B. Ein-/Ausschalten Licht.
tomgr schreibt, dass man keine der Module von KaiS benötigt. Im Thread lese ich, dass man IPS-Tasmota benötigt.
So richtig blicke ich nicht durch, weil mir auch etwas der Einstieg in die Thematik fehlt.
Das hat auch etwas damit zu tun, dass ich bisher lediglich 3 Stehlampen mit Sonoff ausgestattet habe und die restlichen Devices in der Schublade zum Spielen liegen.
Alles völlig ohne Prio.
Gesendet von iPhone XS mit Tapatalk
tomgr schreibt, dass man keine der Module von KaiS benötigt. Im Thread lese ich, dass man IPS-Tasmota benötigt.
So richtig blicke ich nicht durch, weil mir auch etwas der Einstieg in die Thematik fehlt.
KaiS Module werden für das Skript nicht benötigt, hier wird einfach alles angelegt was über MQTT reinkommt.
Die Tasmota Firmware nutzen wir, um die ESP MQTT fähig zu machen, due kannst aber auch ESPEasy oder XY nehmen, alles was MQTT spricht sollte gehen.
Mit Shelly geht es mit der org. Firmware, da die schon MQTT kann.
Aber mir ist das Skript etwas zu heftig, da finde ich KaiS Module etwas besser zu konfigurieren.
Aber auch an sokkederheld, ich finde es toll gemacht, auch wenn ich es nicht so nutzen werde.
Und mir kommt da gerade noch ne Idee, ich muss mal was versuchen.
Okay. Dann mal ein kurzes Statement von mir zu der Thematik.
Mein Skript versucht eigentlich „nur“, einen MQTT-Server bereit zu stellen und dessen „Inhalte“ in IPS zu verwalten, unabhängig davon welche Geräte mit diesem Server sprechen und welche Struktur die Daten (abgesehen davon dass es halt MQTT ist) haben. Es funktioniert, dafür dass es ein PHP-Skript ist, ganz okay.
Dass ich nun bspw. ankommende JSON-Payloads zu Instanzen aufdrösele ist eigentlich schon mehr als ich je machen wollte und es lässt mein Skript natürlich ein bisschen so aussehen, als sei es als ein Gegenstück zu dieser oder jener MQTT-Client-Firmware gedacht.
Das ist (bislang) aber nicht mein Anliegen und ich glaube auch nicht, dass das Skript besser wird, wenn ich es langsam aber sicher zur eierlegenden Wollmilchsau auszubauen versuche. (Stichwort Feature Creep). Auf Dauer schadet das der Stabilität und Wartbarkeit.
Es sind viele MQTT-Firmwares im Umlauf, die viele Dinge ganz unterschiedlich machen und es wird nicht möglich sein, dass ein MQTT-Server (der ja von der Definition her eigentlich dumm sein soll) mit jeglicher Firmware irgendeine schlaue Beziehung eingeht. Da ist es viel sinnvoller, wenn die „Intelligenz“ von anderen Clients kommt, beispielsweise auch einem Modul in IPS so wie es das ja offenbar schon gibt.
Überlegt euch also, welche Architektur ihr wollt, denn nicht jede ist sinnvoll.
Wollt ihr eine übersichtliche Anzahl Geräte, die MQTT sprechen, mittels eigener Skripte direkt und transparent in IPS integriert bekommen ohne einen extra MQTT-Server aufzusetzen? Benutzt gerne mein Skript.
Wollt ihr viele Geräte per MQTT vernetzen? Soll das auch unabhängig von IPS laufen? Habt ihr IPS-seitig schon einen Weg der Einbindung per MQTT-Clientmodul? Wollt nicht selbst programmieren? Dann wird euch mein Skript vermutlich nicht viel nützen, sondern einfach nur eure CPU belasten. Denn es ist nun mal ein PHP-Skript und kein natives Binary.
Und bitte, in Zukunft überlegt auch wenn ihr Fragen habt, ob sich diese wirklich auf „meinen“ MQTT-Server beziehen, oder ob das eigentlich Fragen zu eurer jeweiligen Firmware sind. Letztere würden dann nämlich nicht hier her gehören.
Danke und viel Erfolg
Danke für die Klarstellung. Dann mache ich hier mal den Weg frei und bin erstmal raus.
Gesendet von iPhone XS mit Tapatalk
Danke sokkederheld.
Wollt ihr eine übersichtliche Anzahl Geräte, die MQTT sprechen, mittels eigener Skripte direkt und transparent in IPS integriert bekommen ohne einen extra MQTT-Server aufzusetzen? Benutzt gerne mein Skript.
Das passt so, aber wenn es viele Geräte sind wird es schon stressig.
Aber trotzdem, hast du da was schönes gebaut, um mal schnell was zu sehen.
Mal sehen. was die Zukunft so bringt, denn bei mir wird immer mehr mit MQTT statt LCN im Haus gemacht, da nicht im ganzen „Bunker“ die Datenader liegt. Und da die Tasmota Module oder auch Shelly mit MQTT bisher einfach gut laufen, kommt da immer mehr rein.
Wir haben jetzt so ca. 35 MQTT Hardware Module im Haus.:eek:
Theoretisch könnte man auch darüber abstimmen lassen, wie das Skript weiter entwickelt werden soll. Oder man macht 'nen Fork, der mehr auf bestimmte Clients eingeht… :rolleyes::rolleyes:
Hallo,
ich benutze ESPEasy, da kann ich leider nur für den gesamten MQTT-Verkehr entscheiden, ob ich das Retain Flag setzen möchte oder nicht. Habe erst noch versucht, das mit Hilfsvariablen im ESPEasy zu lösen, hat aber alles nicht so wirklich gut funktioniert.
Habe es daher anders gelöst - benutze MQTT nun „nur“, um den aktuellen Status der Relais zu visualisieren und statt eines Command-Topics benutze ich einfach ein http-Kommando. Habe hierfür ein kleines Skript geschrieben, welches bei Betätigung im Webfrontend den http-Request absetzt, z. B. so:
file_get_contents(„http://“.$IP_Adresse."/control?cmd=GPIO,".$GPIO.",1");
Somit gibt’s keine Rückkopplung, der Switch im Webfrontend schaltet erst um, wenn das ESPEasy den MQTT-Topic aktualisiert hat und alles klappt prima
Vielen Dank nochmal für das tolle Skript!
Hallo,
da MQTT nun direkt in IP-Symcon integriert werden soll, gehe ich davon aus, dass damit die Notwendigkeit für dieses Skript von mir demnächst wegfällt. Danke allen, die geholfen haben, es war eine sehr interessante und lehrreiche Sache für mich
Vielleicht ist das Thema hier besser aufgehoben.
https://www.symcon.de/forum/threads/40057-Modul-5-1-IPS-Shelly-MQTT-Server?p=398469#post398469
Der Broker hat eigentlich nichts mit meinem Modul zu tun!
Grüße,
Kai
Sorry…ich nutze MQTT Server von Symcon…nicht von sokkederheld.
Also falscher Thread.