Hallo Sascha,
würde mich auch interessieren wie das aussieht.
Kannst Du bitte mehr Details (z.B. Bilder) posten?
Würde mich auch interessieren…
Gesendet von iPhone mit Tapatalk
Hallo Gemeinde,
hier mal ein Bild einer nackten Platine.
Ein Bild einer bestückten reiche ich nach 
Die Platine hat jetzt bis zu 32 + internen Ports ( so um die 10 ), also um die 42 Ports.
Ein Platinendesign für 64 habe ich jetzt nicht, aber das ist natürlich alles machbar
Liebe Grüße von der ESP8266 Front
(Ich ärgere mich schon langsam, wie viel „Homematic“ Geld hier verschwunden ist :(. Wäre ich doch schon
viel früher auf die Idee gekommen!)
Liebe Grüße
Sascha
EDIT: Doch noch geschafft Also Hier ein Bild einer „fast“ fertigen Platine. (Ein paar Kondensatoren, Widerstand Arrays und fast alle Jumper fehlen noch, möge der Briefträger den Rest morgen bringen :))
Richtig gut gemachte Experimentierplatine für den ESP.
Gruß Helmut
Zu diesen Endlosschleifen: Das passiert, wenn ihr ein und denselben Wert sowohl zum Ansteuern des Gerätes, als auch für dessen Rückmeldung verwendet (also in diesem Falle das selbe Topic). Das kann übrigens auch ganz unabhängig von dem MQTT-Skript, z.B. in IPS direkt passieren, wenn ihr dort eine Variable benutzt, die bei Änderung ihres Werts sowohl ein Gerät ansteuert, als auch den Status des Gerätes rückmeldet.
Das ist der Grund, warum man nicht einfach bspw. Die STATE-Variable eines Homematic-Schaltaktors direkt setzen kann, sondern einen speziellen Schaltbefehl verwenden muss. Die Variable ist streng genommen nur die Rückmeldung und hat mit der Ansteuerung aus IPS nichts zu tun!
Bei MQTT-Aktoren wird dies meist gelöst über zwei getrennte Topics, bspw. Eines das auf „value“ endet und eines auf „command“ o.ä. Alle Implementierungen, bei denen hingegen das Topic für Ansteuerung und Rückmeldung gleichzeitig benutzt wird, etwa eine 1 als Message des selben Topics sowohl bedeuten kann „ist an“ als auch „ soll bitte an schalten“ werden Gefahr laufen, zu solchen Endlosschleifen zu führen, wenn das Timing salopp gesagt ungünstig ist. Also muss das anders umgesetzt werden.
Hoffe, das war verständlich.
Die Server Socket von IPS ist meiner Erfahrung nach leider auf Dauer nicht stabil wenn Verbindungen dauernd neu aufgebaut werden. Am besten konfiguriert man seine Clients so, dass sie die Verbindung möglichst halten.
Da die Message nicht mit gesetztem Retain-Flag kommt, wird standardmäßig keine Variable angelegt. Das Handling „per Variable“ ist standard bei Messages mit Retain-Flag, weil diese „bis auf weiteres“ gültig bleiben, während eine Message ohne Retain-Flag nur für den Augenblick gültig ist und daher defaultmäßig per Skript behandelt wird.
Du kannst das Setzen einer Variablen erzwingen, indem du eine Schatten-Variable (siehe ersten Post in diesem Thread) mit dem entsprechenden Namen an der entsprechenden Stelle von Hand erstellst. Der andere Weg wäre, das Device dazu zu bringen, die Message mit Retain-Flag zu senden, was aber ggf. nicht möglich und auch nicht sinnvoll ist.
Das empfinde ich überhaupt nicht als Abwertung
Ich fände eine „native“ Integration dieses soliden Protokolls auch viel schöner, aber das wurde damals von vielen als Bastelkram abgetan (während Spielereien wie Alexa und Philips Hue in dieser Community zum Teil sehr ernst genommen werden).
Bei vielen Usern endet DIY halt eher mit Klick auf den Kaufbutton (bzw. der hellhörigen Bestellwanze am Küchentisch). Und das schöne ist ja auch, dass Home Automation mittlerweile so mainstream geworden ist, dass man sich seine Automation tatsächlich zusammenkaufen kann, ohne zu löten. Die Bereitschaft, irgendwelche China-Hardware mit alternativer Firmware zu flashen, haben eher wenige und außerdem kommen hier und dort auch einige nicht unberechtigte Bedenken wegen der Gerätesicherheit hinzu (ich meine vor allem was die Verarbeitung, Brandschutz, elektrische Sicherheit betrifft).
Solange „die Industrie“ (also die, welche ihre China-Hardware mit Äpfeln und anderen Logos geschmückt teuer verkaufen, als auch die, welche gute alte Dinosaurier-Tech Made in Germany anbieten mit hardcoded Passwortzugang zum Heizkessel) das MQTT-Protokoll nicht mitmachen, ist das kein Umsatzbringer. Als reinen DIY-Crowdpleaser werden die Symcons das vermutlich nicht einbauen. Und schlimmer noch, es gab ja damals bei der Diskussion sogar User die richtig gegen MQTT agitiert haben nach dem Motto „viele wichtiger ist meine proprietäre Rasenmähroboter-Schnittstelle!!“.
Nun denn, genug gerantet, ich würde mich wie gesagt selber total freuen wenn sich da was ergäbe mit MQTT nativ, aber ich glaube leider nicht daran. 
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