Ok
Dann ist da wohl noch ein Fehler.
Habe gerade mal nachgeschaut
Fehlermeldung: kann Verzeichnis nicht löschen da es nicht leer ist
Zeile 681
Hallo ich habe jetzt gerade nochmal probiert das Skript zu installieren. Folgende Fehlermeldungen bekomme ich dabei… 
Gruß Maik
Wenn der Client unsubscribed, oder wenn du die Subscription-Vairable (unterhalb der Sessions-Kategorie under dort liegenden Session-Variable) löschst. Von allein weggehen tun Subscriptions nicht; es wäre wohl auch eher hinderlich als nützlich, oder?
Du kannst seit der letzten Version an beliebiger Stelle in der Topicstruktur ein Skript (oder einen Link, der auf ein Skript verlinkt) anlegen mit dem Namen „#“ (ohne Anführungszeichen). Dieses Skript wird dann für jedwede Message ab dieser Ebene im Topic-Baum aufgerufen und es werden fortan ab dieser Ebene auch keine weiteren Skripte automatisch mehr erstellt (können aber weiterhin genutzt bzw. manuell erstellt werden).
Theoretisch kannst du auch direkt unter dem Topics-Root so ein Skript anlegen, dann werden gar keine topicspezifischen Handlerskripte erstellt.
Diesen Fehler kann ich leider nicht nachstellen, bzw. ich verstehe auch nicht ganz an welcher Stelle er auftreten sollte, da ich keine Löschungen im Dateisystem durchführe.
Da waren noch Daten von der alten Installation gespeichert. Ich mache im nächsten Update mal die Setuproutine robuster, so dass sie damit umgehen kann.
Changelog 0.6:
[ul]
[li]Setuproutine sollte gelöschte Objekte erkennen und neu erstellen können
[/li][li]kosmetische Bugfixes
[/li][/ul]
Morgen,
so nun mal die Fehlermeldung ganz genau.
Diesen hatte ich auch schon in Zeile 681 oder 682, in der Foreach Schleife.
Bzgl. .des Löschens ist das nicht praktikabel. Wir arbeiten auch in der Firma mit MQTT und in der Praxis werden durch die Clients sehr oft kein Unsubscribe durchgeführt. Gerade wenn man mit dem Programm „Mosquitto“ arbeitet, sammeln sich dort schnell mehrere hunderte Sessions an.
Das mit den Scripts in den Topics ist zwar klasse, aber eigentlich nicht die Aufgabe eines Brokers. Ich glaube du wolltest damit den Topicfilter abbilden. Normalerweiser muss der Client (also in dem Fall wieder Symcon selber) dafür selber einen Subscribe durchführen.
Okay, so herum wird ein Schuh daraus (du hattest vorhin geschrieben, das Löschen von Dateien sei fehlgeschlagen).
Und jetzt verstehe ich glaube ich auch dein Problem mit dem Unsubscriben - du verwendest clean sessions und bei denen sollten die Subscriptions in der Tat nicht den Disconnect überleben. Wenn ein Keep Alive gesetzt ist (setzt der Client) und die Verbindung geht verloren, dann muss so eine Session natürlich expiren, samt ihrer Subscriptions.
Der Bug ist, dass das Löschen der abgelaufenen Session nicht richtig gemacht wird bzw. nicht funktioniert solange Subscriptions da sind. Das werde ich im nächsten Update beheben.
Vielen Dank fürs Melden!
Changelog 0.7:
Sessions mit Clean-Flag werden jetzt korrekt gelöscht, wenn die Session auf Keep-Alive-Timeout läuft oder sauber beendet wird. Dies klappte vorher nicht, sobald die Session mindestens eine Subscription hatte.
Darauf bin ich vorhin nicht eingegangen, daher jetzt nochmal.
Also im Prinzip hast du Recht; solange man, wie eigentlich vorgesehen zwischen Broker und Client strikt unterscheidet ist es nicht Aufgabe des Brokers, irgendwelchen schlauen Dinge mit den Messages anzustellen, außer sie zu verbreiten, zwischenzuspeichern usw. usf.
IPS ist aber ja ein Spezialfall, eine Art unheiliger Broker-Client-Hybrid. Einerseits soll der Broker natürlich einfach Broker sein können, aber in der Regel wollen wir aus IPS heraus ja doch irgendwas mit den Daten anstellen - sonst würde man doch ohnehin lieber einen der regulären, bestens bewährten Broker verwenden.
Mein Ansatz für meinen Broker war, IPS „MQTT sprechen“ zu lassen und zwar als Broker und nicht als Client, weil es ja eine gewisse Überschneidung gibt zwischen der verwaltenden Funktion des Brokers und der von IPS. Ob man das sinnvoll findet oder gar sauber steht auf einem anderen Blatt, aber gewissen Reiz hat es ja.
Du kannst wie gesagt die automatische Anlage von Topic-Handlerskripten verhindern, indem du auf der Ebene ab der du es abstellen willst (also theoretisch auch ab dem Root) das „#“-Wildcard-Skript anlegst (oder einen mit „#“ benannten Link, der auf das Skript verweist, mit dem du die Messages behandeln willst). Es gibt da eine Reihe Einträge in dem $_IPS-Array des aufgerufenen Skripts, über welche du alles was mit der jeweiligen Message zu tun hat, heraus bekommst.
Mit den Client-Subscriptions haben diese Kategorien und Skripte allerdings sowieso nichts zu tun, die sind nur „für IPS“ da! Client-Subscriptions funktionieren davon unabhängig und werden intern vom Broker behandelt (zu erkennen ist eine Subscription an der entsprechenden Variable unterhalb der Session-Variable).
Ich mache dann mal weiter ;.)
Wenn ich eine Client ID beim Subscribe mitgebe, erhalte ich einen Fehler
Edit: Nachdem ich alles gelöscht habe und wieder neu installiert habe, tritt der Fehler nicht mehr auf. Bis auf den A non well formed numeric… Fehler. Dies liegt aber wohl an PHP 7 / Symcon 5 womit ich teste.
Okay, also… was sind deiner Ansicht nach dann die verbleibenden Bugs aus deinem Beispiel, die ich untersuchen sollte?
Danke jedenfalls fürs Testen 
Was du davon beheben möchtest, sei dir selber überlassen.
Okay, also die meisten der Fehler hängen zusammen mit einer gespeicherten Konfiguration, deren Objekte gelöscht wurden. Das lässt sich beheben, indem man das Setup erneut ausführt (Skript in Konsole starten).
Ich werde da mal die Fehlermeldungen sprechender gestalten.
Changelog:
[ul]
[li]Fehler behoben, der dazu führte dass bei jeder manuellen Ausführung des Skripts ein neues Timer-Ereignis angelegt wurde. Falls das bei euch auftritt, die überzähligen Timer-Ereignisse bitte löschen und das Skript einmal ausführen, um nur mehr die beiden benötigten Timer-Ereignisse anzulegen![/li][li]hilfreichere Meldung wird angezeigt, falls Objekt-IDs in der Konfigurationsdatei gespeichert sind, aber diese Objekte nicht (mehr) existieren. Bitte nach dem Löschen von Objekten rund um den MQTT-Broker immer einmal das Skript ausführen, um die Integrität zu gewährleisten! Wenn in der Konfigurationsdatei Objekt-IDs eingetragen sind zu Objekten die es nicht mehr gibt, kann der Broker nicht funktionieren[/li][li]genauere Debugausgabe um dem Problem „non wellformed numeric value“ auf die Schliche zu kommen, falls er bei euch auftritt[/li][/ul]
Generelle Anmerkung:
Die Konfiguration wird folgendermaßen abgespeichert: Wenn das Skript in der Konsole ausgeführt wird, stellt das Skript sicher, dass alle benötigten Objekte existieren und speichert deren IDs in einer Include-Datei. Deren Name wird automatisch anhand der Skript-ID generiert. Das bedeutet, wenn ihr das Skript „überspeichert“ und alle dazu gehörenden Objekte löscht, existiert immer noch die alte Konfigurationsdatei mit den alten Objekt-IDs. Ihr müsst dann auf jeden Fall das Skript einmal zur Einrichtung ausführen, damit die Objekte wieder existieren und die IDs korrekt abgespeichert sind!
Nur mal eine Frage am Rande wenn man das einmal anschauen und ausprobieren will, was ist dann zu beachten? Als Produktivsystem würde ich gerne noch Mosquitto laufen haben so lange das hier noch nicht ausreichend getestet wurde. Kann mann zwei MQTT Broker in einem Netzwerk laufen haben also einer Produktiv und einer zum Testen oder kommen die sich in die Quere? Wie ist denn eine MQTT Testumgebung aufzusetzen ohne das man da das momentan laufende Produktivsystem beeinflusst?
Zunächst einmal: Mittlerweile würde ich davon ausgehen, dass das Skript hinreichend „sicher“ ist, um auch auf einem produktiv eingesetzten IPS mal probeweise genutzt werden zu können. Zu beachten ist höchstens, dass
[ul]
[li]auf dem selben Gerät noch kein MQTT-Broker laufen darf, denn sonst kommen die sich von den Ports her in der Tat in die Quere
[/li][li]die Lizenz sollte es erlauben, dass einige Variablen angelegt werden (je eine pro Session + eine pro Subscription + eine pro Topic mit „Retained Message“
[/li][/ul]
Ein MQTT-Broker im selben Netzwerk (nicht auf der selben Maschine) ist grundsätzlich kein Problem, da man beim Client ja festlegt, mit welchen Broker er sich verbinden soll. Man kann jedoch normalerweise nicht ein- und denselben Client mit zwei Brokern gleichzeitig verbinden. Da müsste man also einen Client nehmen, der nicht essentiell ist, um erste Tests durchzuführen. Was genau da geht hängt sehr von der jeweiligen Konfiguration ab.
So, hier noch mal ein Beispiel für den „a non well …“ Fehler.
Denke daran, dass hat was mit den Datentypen von PHP 7 zu tun. In PHP 5.x siehst du den nicht.
Im Moment sieht PHP 7 wohl noch darüber weg, soll aber später nicht mehr akzeptiert werden.
Ich hatte dies bei der Umstellung auf die 5er IPS Version bei einigen Scripten.
Teilweise musste ist die Datentypen explizit umwandeln.
z.B. $OldValue=floatval($OldValue);
In PHP 5.x konnte ich noch direkt auf die Variable $Oldvalue zugreifen und so tun als wenn es eine float Variable wäre. In PHP7 bringt das die o.g. Warnung bzw einen Error.
Hallo,
danke für die gute Arbeit.
Ich bin erst heute zu V0.8 eingestiegen. Funktioniert auf Anhieb ohne Probleme.
Auch wenn ich etwas sehr skeptisch war, einen Broker per php ins IPS zu bringen. Die Vor- und Nachteile lassen sich aber für mich noch nicht eindeutig abwägen.
Bei einen Realisierung als reinen Client müsste und würde mosquitto die Retain-Funktion behandeln.
In der kurzen Zeit - eine klasse Leistung.
Bei der Behandlung des LWT scheint der Ausschluss durch die Bildung des #-Scripts nicht zu wirken. Dies kann aber von Euch gewollt sein.
Durch die Implementierung als Broker hatte ich eine hohe Systemlast erwartet. Es zeigte sich aber auf meinem Pi keine nennenswerte dadurch verursachte Last.
Meine Testumgebung:
- RPI3 mit Symcon
- 3xSonoff’s mit Tasmota-FW
Es wäre natürlich schön, wenn man nicht nur empfangen, sondern auch publishen könnte.
Weitere kleine Idee:
- eine Variable „debug“, mit der die log-Funktion der unbehandelten Skripte unterdrückt werden kann.
Wie geht eine „Deinstallation“ ?
- MQTT-Zweig im IPS löschen
- I/O-Instanz löschen
fertig?
Viele Grüße und viel Erfolg
Andreas
Gern!
Das freut mich sehr.
Ich verstehe den Satz leider nicht so ganz, aber ich habe das Gefühl ich sollte 
Das wird stark davon abhängen, wie viel MQTT-Traffic rein kommt. Wenn du viele Clients hast und diese dauernd etwas publishen, wirst du schnell eine höhere Last haben!
Insgesamt wird das so immer weniger performant sein als ein reiner MQTT-Broker, der nativ auf der Maschine läuft. Es hängt von der Umgebung ab, ob es akzeptabel ist oder nicht mehr.
Das ist nicht viel, das sollte also auch problemlos gehen.
Kann man - durch Aufrufen des Skripts mit IPS_RunScriptEx();
Übergib folgende Einträge im Array:
[ul]
[li]MESSAGE
[/li][li]TOPIC
[/li][li]RETAIN
[/li][/ul]
(wobei du eine retained message auch schreiben kannst indem du die zugehörige Variable setzt)
Es sollten eigentlich keine topicspezifischen Skripte mehr angelegt werden, sofern ein „#“ Skript auf der Ebene (oder darüber) existiert. Wobei bereits existierende Skripte weiterhin aufgerufen werden (du kannst sie aber löschen).
Ist ein guter Punkt, dazu werde ich mal was einbauen um es zu vereinfachen. Bislang nur manuell:
[ul]
[li]im scripts Ordner die Datei 12345_config.php löschen (Zahl durch Skript-ID ersetzen)
[/li][li]Skript löschen
[/li][li]Topic-Root-Kategorie löschen
[/li][li]Sessions-Kategorie löschen
[/li][li]RegVar löschen
[/li][li]Server Socket löschen
[/li][/ul]
Danke für deine Anmerkungen.