MQTT Broker in IP-Symcon (Beta..!)

Und schon sind die Fehlermeldungen weg.:smiley:

Wenn ich per Mosquitto eine Nachricht an den Broker versende, erhalte ich folgende Fehlermeldung

Nachricht:
mosquitto_pub -h 192.168.21.31 -t test/bulb -m 1

Fehlermeldung

Hi vielen Dank für deine Klasse Arbeit, funzt auf anhieb !

Aber ich verstehe nicht so ganz deinen Ansatz das du die Topics alle in IPS abbilden willst ?

Wenn ich das auf meine MQTT Umgebung anwendende wird das ganz schön viel…

Ich habe es so gelöst, das alles was über MQTT reinkommt an ein Script geschickt wird, und das Script macht dann alles…

Aber das ist ja Geschmacksache, finde deinen Ansatz auf jeden Fall interessant !

Ich würde mir wünschen das die Wahl hat, ob IPS der Brocker ist oder ein anderer Brocker im Einsatz ist…

Und in IPS kann man einfach Topics abonnieren und einstellen was per welchem PayLoad passieren soll…

Senden kann man noch nicht mit deinem Brocker ?

Mach weiter so, das wird bestimmt super…

Habe was gefunden, damit kann mit direkt nur mit PHP MQTT Nachrichten senden:

GitHub - bluerhinos/phpMQTT: a simple php class to connect/publish/subscribe to a MQTT broker

Funktioniert super !

Wichtig:

In der phpMQTT.php den Eintrag „namespace Bluerhinos;“ änder in „#namespace Bluerhinos;“ !!!

Das könnte auch was für uns sein:

Danke für den Hinweis, werde ich im nächsten Update beheben!

Das war halt eher ein „mal gucken ob ich es so hinbekomme“ Projekt, als eines das ich unbedingt selbst benötige. Ich habe es über zwei Wochen während der kurzen Pausen zwischen „Fläschchen geben“ und „wickeln“ geschrieben um in meiner Elternzeit nicht völlig aus dem Trott zu kommen als Entwickler :wink:

Ich fand es reizvoll, der Tatsache Rechnung zu tragen, dass IPS und MQTT vom Einsatzzweck her gewisse Schnittmengen haben und wollte diese ausloten.

Was ich tun könnte, um deinen Anforderungen vielleicht im nächsten Update etwas entgegen zu kommen, ist folgendes (sag bitte mal was dazu ob es sich für dich sinnvoll anhört): Wenn man irgendwo im Topic-Baum ein Skript mit dem Wildcard-Namen „#“ anlegt, wird ab dieser Ebene dieses Skript genutzt und bei Empfang von Messages aufgerufen, anstatt dass überall unterhalb weitere Kategorien und Skripte angelegt werden.

Wobei ich glaube, für Retained Messages ginge das so nicht, denn die sollen ja tatsächlich dauerhaft gespeichert sein im System. Für diese müsste ich weiterhin an entsprechender Stelle jeweils eine Variable anlegen.

Respekt, das du das nebenbei machst !

Hi hm beides wäre gut… ich habe z.b. bei jedem MQTT Device ein Status und ein Remote Topic, da muss ich schon unterscheiden von welchem eine Nachricht gekommen ist…

Retained Messages sind für mich noch schwarze Magie :wink: ich weis noch keinen Sinnvollen Anwendungsfall und bis jetzt, als ich mal aus versehen Nachrichten mit Retain versendet hatte, sehr unschöne Effekte aufkamen, weil das nirgendwo abgefangen wurde…

Danke :slight_smile:
Macht ja auch Laune, soweit. Jedenfalls wenn so konstruktives Feedback kommt :wink:

Du meinst du hast Topics auf gleicher Hierarchieebene, die aber verschieden behandelt werden sollen?

Eventuell wäre dann ein anderer Ansatz hilfreich:

[ul]
[li]Möglichkeit, eine Liste von Topicfiltern anzulegen, die nicht in der IPS-Struktur angelegt werden sollen
[/li][li]Statt kategorieweise „Wildcard-Skripte“ zu erlauben (was auch vom Verarbeitungsaufwand je Message recht aufwändig ist) eher ein globales Handlerskript, das einfach parallel zu allen anderen Vorgängen immer aufgerufen wird wenn jedwede Message empfangen wird?
[/li][li]
[/li][/ul]

Eine Retained Message ist am ehesten das, was eine Variable in IPS ist - ein Wert, den der Broker permanent unter einem bestimmten Topic abspeichert und an alle Abonnenten ausliefert. Eine Message ohne Retained-Flag ist hingegen eine eher flüchtige Angelegenheit. Sie zerstört sich sozusagen selbst, sobald sie an alle Abonnenten (unter Berücksichtigung des jeweiligen Abo-QOS-Levels) ausgeliefert wurde. Darum werden „nicht retained“ Messages auch in meinem Broker standardmäßig als Skripte angelegt, welche dann mit der entsprechenden Message aufgerufen werden.

Du kannst übrigens ein „Sammelskript“ bereits jetzt hinfrickeln indem du an den entsprechenden Stellen unter dem jeweiligen Topicnamen einen Link zu einem dafür bestimmten Skript ablegst. Müsstest du allerdings für jedes Topic einzeln machen und darauf achten, dass dort nicht bereits ein Skript mit dem gleichen Namen liegt.

Hm ich weis, was eine Retained Message ist und wie sie funktioniert, aber deine Erklärung ist super ! Viel besser was ich sonst so gelesen habe…

Aber für mich habe ich bis jetzt für Retained Messages keinen Anwendungsfall gefunden…

Ich ich glaube wir sind da auf dem falschen weg… ich stelle mir das so vor :

Der Brocker empfängt alles und in der MQTT Device Instance stellt man folgendes ein:

Name:
Sub Topic:/lol/remote/
Pup Topic:/lol/status/
Sub PayLoad:
Pub PayLoad:

In der Instance wird dann nach den eingestellten SUB und Payloads das gewünschte umgesetzt…

So in Richtung HM mit den SN, oder wie bei Modbus mit den Adressen…

Das ist auch ein interessanter Ansatz. Allerdings passt es nicht so recht zu dem was ich versuche; eher zu einem MQTT-Client als zu einem Broker (der ja von seiner Funktion her irgendwo die gesamt Topicstruktur vorhalten muss).

Im Gegensatz zu HM, wo es diese Seriennummern gibt, existiert bei MQTT auch eine Hierarchie, was IPS mit seinen Unterkategorien recht ähnlich ist. Darum bilde ich es so ab.

Retained Messages sind eigentlich eine super Sache für viele Dinge, z.B. wenn ich einen Temperaturfühler habe der nur sporadisch alle 15 Minuten einen Wert misst - so steht der (jeweils letzte) Wert auch zwischen zwei Messintervallen zuverlässig zur Verfügung.

Im Grunde würde ich sogar alles, was nicht „Meldungscharakter“ hat, sondern statische Daten sind, über retained Messages lösen.

Klar, es geht, solange alle Geräte up sind, grundsätzlich auch ohne - solange der Tempfühler funktioniert, kommt die nächste Messung ja in <= 15 Minuten, und solange das verarbeitende Gerät damit klar kommt bspw nach einem Reboot auch mal eine Weile „keine Ahnung“ zu haben was die Außentemperatur ist, kein Problem. Aber imo aufwändiger am Client und fehleranfälliger insgesamt.

Ich finde es mit dem Retained-Flag für statische Daten wenigsten eleganter. In IPS ist eine Statusvariable ja auch statisch, wenn mein Gerät mal nicht erreichbar ist.

Das nächste Update kommt voraussichtlich Anfang der Woche. Darin werde ich den Fehler mit MQTT 3.1.0-Clients beheben sowie eine Unterstützung für Wildcard-Handlerskripte eingebaut haben.

Ok TOP ! Aber vergiss nicht, das du dich auch um dein Baby kümmern musst, das ist wichtiger als IPS :wink:

Das hat auch ein lauteres Organ als IPS, trotz Multiroom-Audio… :smiley:

Changelog:

[ul]
[li]Clients mit MQTT-Protokollversion 3.1.0 sollten nun funktionieren[/li][li]Möglichkeit, auf beliebiger Topic-Ebene ein Skript (oder Link auf ein Skript) namens „#“ zu erstellen, welches dann jedwede Messages ab dieser Ebene und darunter verarbeitet. Es werden, wenn im „Pfad“ des jeweiligen Topics so ein Skript existiert, keine Einzel-Handlerskripte pro Topic mehr erzeugt. Wenn jedoch ein Skript mit dem Namen eines Topics existiert, wird dieses dennoch (auch) aufgerufen, sobald darauf gepublisht wird.[/li][li]unerhebliche kleine Bugfixes[/li][/ul]

Sollten…aber tun es nicht. Weiterhin gleiche Fehlermeldung.
Habe vorsichtshalber alles nochmal gelöscht. Fehler bleibt auch in der 0.4

Da hatte ich geschlampt. Nun aber in der 0.5…

Funktioniert nun. Vielen Dank. Dann teste ich mal … :slight_smile:

Wann werden die Subscribe Sessions eigentlich wieder gelöscht? Nur nach einem Unsubscribe oder auch nach einem bestimmten Timeout?

Nächste Frage :slight_smile:
Habe ich die Möglichkeit eine Callbackmethode in jedem Topicscript aufzurufen. Hintergrund: Ich möchte alle Daten von jedem Topic loggen. Da du aber automatisiert ein Script eingebaut hast, habe ich nur die Möglichkeit dies zu tun, wenn auch automatisiert von mir ein Stück Source ausgeführt und das bei jedem Topic was neu erstellt wird.
Ich möchte erkennen wann welche Nachricht mit welchem Payload versendet wurde.

Zeilen 680-685…


    $sessions = array();
    $session_var_ids = IPS_GetChildrenIDs($sessions_cat_id);
    foreach($session_var_ids as $var_id) {
        $conn_id = ident_to_conn_id(IPS_GetObject($var_id)['ObjectIdent']);
        if($conn_id != '') {
            $client_id = IPS_GetName($var_id);