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

sokkederheld · 31. Januar 2018 um 09:59

Changelog:

[ul]
[li]Problem mit „non wellformed“ Meldungen unter PHP 7 sollte behoben sein[/li][li]Fehler behoben, dass das „#“ Skript auf oberster Ebene nicht dazu führte, dass darunter keine Topic-Skripte mehr angelegt werden[/li][li]Uninstall-Funktion eingebaut, zu aktivieren indem am Anfang des Skripts $uninstall auf true gesetzt wird.[/li][/ul]

Achtung, wenn ihr den Uninstall durchführt werden alle Sessions gelöscht. Den Topic-Baum lösche ich nicht, solange Dinge drin stehen, das macht ihr vorsichtshalber selbst wenn ihr euch gaaanz sicher seid

atreutler · 31. Januar 2018 um 20:48

Bei der Behandlung des LWT scheint der Ausschluss durch die Bildung des #-Scripts nicht zu wirken. Dies kann aber von Euch gewollt sein.

Zur Erläuterung habe ich den Screenshot hochgeladen. Die Rot markierten Kategorien und Variablen hatte ich nicht erwartet. Es ist aber verständlich, dass persistente Variablen (z.B. LWT) erscheinen müssen.

Frage: Wie ist der Wertebereich des Parameters „RETAIN“ beim Publishen?
1/0 oder true/false ?

Gruß Andreas

sokkederheld · 1. Februar 2018 um 04:19

Okay, jetzt verstehe ich.

Ja, Kategorien werden immer angelegt, sobald auf darunter liegende Topics gepublisht wird.

Variablen dienen als Speicher bzw. Repräsentation von Retained Messages und werden dementsprechend auch immer angelegt, falls sie nicht existieren.

Nur die Skripte pro Topic sind nicht zwingend. Sofern es irgendwo im Baum darüber oder auf gleicher Ebene ein „#“ Skript gibt, wird dieses beim Erhalt von Messages aufgerufen und kein weiteres Skript für das Topic angelegt.

Beim Publishen aus IPS kannst du RETAIN true oder false setzen. Default, falls du es weglässt, ist false.

sokkederheld · 1. Februar 2018 um 04:54

Ich denke immer mal wieder darüber nach, ob ich irgendwie Variablenprofile unterstützen bzw. berücksichtigen sollte. Mich würden eure Meinungen zum Thema interessieren.

Beispiel: Ich setze aus meiner Topicstruktur heraus einen Link auf eine Statusvariable von einem Temperaturfühler. Dies führt dazu, dass der Wert dieser Variablen fortan unter dem entsprechenden Topic als Retained Message gepublisht wird.

Allerdings wird als Message derzeit immer „nur“ der numerische Wert verbreitet, also bspw. -1.0 oder 5.7 - selbst wenn die Variable ein Profil hat, in dem z.B. der Suffix " °C" definiert ist.

Das könnte ich ändern, so dass er in dem Fall den formatierten Wert publisht.

Aber ich bin mir unsicher, ob man das überhaupt will, oder ob es in der Kommunikation zwischen Geräten nicht eher lästig ist.

Umgekehrt ist es so, dass der Broker beim Empfang einer Retained Message gegenwärtig versucht, automatisch den geeigneten Variablentyp zu „raten“. Das kann klappen, aber es kann auch schief gehen.

Problematisch wird unter anderem, wenn unter einem Topic zuerst eine Retained Message mit einem numerischen Wert empfangen wird und anschließend kommt ein Wert, der nicht numerisch darstellbar ist. Also bspw. zuerst „123“ und später „Hallo“. Dann erzeugt der Broker zunächst die Variable mit dem entsprechenden Namen als Integer. Anschließend muss er jedoch eine Korrektur vornehmen. Momentan äußert sich das so, dass er die bisherige Variable umbenennt und eine neue, mit dem Typ String, erstellt unter dem alten Namen.

Das Verhalten finde ich auch nicht perfekt, aber da es in MQTT keine Datentypen gibt, ist mir nichts anderes eingefallen. Alternative wäre, dass automatisch angelegte Variable immer Strings sind und man andere Typen immer händisch anlegen müsste.

Variablenprofile könnte man theoretisch ebenfalls wieder berücksichtigen beim Empfang, aber da wird es schnell kompliziert. Angenommen, ich empfange „21.3 °C“ als Message - wenn ich dann will, dass da automatisch ein geeignetes Profil heraus gesucht und verwendet wird ist das zwar vom Endergebnis her „schick“, aber alles andere als trivial.

Zumindest wenn einer Variablen manuell ein Profil zugewiesen wurde, könnte ich es so einrichten, dass es einen Effekt hat. Bspw. wenn ein Wert nur entweder „Online“ oder „Offline“ sein kann, wäre zu überlegen ob ich es dem User ermögliche, an dieser Stelle anstelle einer String-Variable z.B. eine Boolean mit entsprechenden Associations im Profil anzulegen (also etwa true = „Online“, false = „Offline“ oder so).

Was meint ihr so…?

sokkederheld · 7. Februar 2018 um 08:25

Okay, ich gehe dann mal davon aus dass die vorgeschlagene Funktionalität verzichtbar ist.

Ich überlge aktuell, ob ich versuchen sollte, ein PHP-Modul aus dem Broker zu bauen. Wäre allerdings noch mal ein bisschen Arbeit. Würde für mich stark davon abhängen, ob Interesse besteht.

Fonzo · 7. Februar 2018 um 09:01

Fände ich sehr praktisch als PHP Modul erleichtert dann nochmals das anlegen und man kann die Kommunikation besser im Debug Fenster verfolgen. Wenn Du zu einem PHP Modul fragen hast kannst Du Dich ja melden.

Boui · 7. Februar 2018 um 09:23

Ich gebe zu, dass ich den Thread gelesen habe und spannend fand.
Zur Zeit habe ich nur 5 Sonoff Basic im Einsatz und habe den von Kai verlinkten Broker auf dem PI3 mitlaufen. Nachdem ich erst meinen Systemekampf auf dem PI3 durchgefochten habe, bin ich geläutert und am liebsten wäre mir alles in IPS. Broker, CCU, …
Gerne per Modul. Wobei der Umstand, dass bei der Menge an Modulen die Chance auf einen Crash beim Update bestimmt schlechter als 50:50 steht, die Freude trübt. Das ist echt ein nerviger Bug.

Also um es kurz zu machen. Ja. Gerne ein Modul.

BTW: So nebenbei bin ich nur 95% glücklich mit der Steuerung über WLAN, da ich in ruhigen NetzPhasen doch eine nervige Latenzzeit von gut einer Sekunde beim Reagieren der Geräte habe.

Gesendet von iPad mit Tapatalk

sokkederheld · 27. Februar 2018 um 17:50

Habe einen Fehler behoben, der dazu führen konnte dass Pakete, die unmittelbar (im selben TCP-Paket) hinter einem PUBLISH-Paket empfangen wurden, verworfen oder als Payload missinterpretiert wurden.

sokkederheld · 1. März 2018 um 04:41

Bezüglich Umstellung auf PHP-Modul:

Ich werde das in näherer Zeit nicht machen. Einerseits fehlt mir die Zeit, andererseits kollidiert das Prinzip dieses Projekts, mit seiner automatischen Anlage und Verwaltung von Objekten in einer Baumstruktur, sowie der Repräsentation von Topic-Namen durch Objektnamen, mit den vorgegebenen Best Practices. Weder „soll“ ein Modul hierarchische Objektbäume erzeugen, noch soll es Namen zur Referenzierung verwenden. Beides sind aber Mittel, die mein Broker absichtlich einsetzt um so zu arbeiten wie er es tut.

Ich werde stattdessen dieses Projekt weiter pflegen und habe es mittlerweile auch im produktiven Einsatz. Heißt, ich erwarte dass ich in absehbarer Zeit es guten Gewissens als „Release“ deklarieren kann.

Was mir persönlich an Features noch hilfreich erscheint und ich daher auf jeden Fall implementieren möchte:

[ul]
[li]Grundsätzliche Möglichkeit, pro Objekt (Skript, Variable) Konfigurationsparameter festzulegen. Entweder bietet sich an, dazu das Info-Feld zu verwenden. Oder man nutzt weitere Variablen an einem separaten Ort (kostet halt wenn man eine kleine Lizenz hat, darum eher nö). Oder man schreibt einfach Zeilen in ein Konfigurationsskript, das dann included wird (ggf. am effizientesten).
[/li][li]Ich möchte vorsehen, dass man die automatische „Datentyp-Eskalation“ pro Variable abschalten kann. Bislang ist es so, dass wenn ich ein Topic als Integer-Variable erstellt habe, und dann publisht ein Client unter dem Topic eine retained Message mit „Hallo“, dann wird die existierende Variable umbenannt und eine neue vom Typ String erstellt. Umgekehrt, wenn da ein String ist und es kommt eine 1, wird diese Zahl trotzdem als String in der existierenden String-Variable gespeichert. Hintergrund für diesen ganzen Zirkus ist, dass ich vermeiden wollte dass irgendwelche automatisch erstellten Variablen mit einem „zu kleinen“ Datentyp die Funktion des Brokers behindern können, weil der beim automatischen Anlegen der Variablen falsch geraten hat was den geeigneten Typ betrifft.
[/li][li]Ich möchte pro Variable festlegbar machen, dass nicht ihr Wert direkt, sondern der per Variablenprofil formatierte Wert publiziert wird.
[/li][/ul]

sokkederheld · 2. März 2018 um 02:42

Da die Frage immer mal wieder auftaucht - so könnt ihr direkt aus IPS heraus eine Nachricht publishen:

$arr = array(
  "TOPIC" => "foo/bar",
  "MESSAGE" => "Hello World!"
);
IPS_RunScriptEx(12345 /* durch die ID des Broker-Skripts bei euch ersetzen! */, $arr);

Noch einfach wird’s wenn ihr eine Retained Message publishen wollt, da diese ja einfach durch eine Variable innerhalb der Topicstruktur repräsentiert wird:

[ul]
[li]Variable ggf. an der entsprechenden Stelle in der Topic-Struktur anlegen
[/li][li]Falls die Variable neu angelegt wurde, das Brokerskript einmal in der Konsole ausführen
[/li][li]die Variable auf den Wert der zu publishenden Message setzen - fertig
[/li][/ul]

mat1987 · 2. März 2018 um 23:29

Hello,

ich blicke leider noch nicht ganz durch und bitte um Hilfe.
Ich habe eine Raspberry3 mit IPS und „MQTT Broker for IP-Symcon 2018 by sokkederheld Version 0.10“ installiert.
weiters habe ich einen Sonoff T1 Taster/Schalter welcher mit folgender Firmware geflasht wurde: „Sonoff-Tasmota 5.12.0 von Theo Arends“

als MQTT Host habe ich die IP des IPS Servers eingetragen. - das passt auch alles soweit (siehe Screenhots)

mein Frage:

wo sehe ich nun den aktuellen Satus des Schalters? - ich sehe dass sich das Datum „Aktualisiert“ beim schalten ändert aber ich vermisse eine Variable „on/off“
wie kann ich den Schalter nun von IPS aus ansteuern? - wie kann ich ein ON, OFF oder TOGGLE senden?

Danke schon mal,
LG, Martin

Fonzo · 3. März 2018 um 00:06

Um den Status des Schalter zu sehen bzw. diesen zu schalten braucht man IPS-Tasmota. Siehe auch Modul Tasmota. Der einzige Unterschied wäre jetzt das statt Mosquitto als MQTT Broker dann eben das Skript von sokkederheld als MQTT Broker verwendet werden würde.

sokkederheld · 3. März 2018 um 02:57

Ich beantworte deine Fragen jetzt mal „nur“ aus der Sicht der Broker-Entwicklers, ohne mich mit Tasmota oder ähnlichem zu befassen. Also eventuell ist das für dich nicht maximal hilfreich, aber ich würde hier gerne beim Thema bleiben und deine Fragen sind ja nicht uninteressant.

Ich auch

Es sieht aus, als ob das Gerät unter dem STATE-Topic zwar etwas publiziert, die Nachricht aber nicht als permanent (retained) markiert ist - das heißt, es gibt in dem Sinne keinen permanenten Status aus, sondern nur eine Nachricht die für den Moment besagt „Einschaltmoment“ bzw. „Ausschaltmoment“.

Darum hat der Broker an der Stelle ein Skript erstellt und keine Variable. (Gegenbeispiel wäre das Last Will Topic auf der gleichen Ebene, das hat vom Gerät das „retained“ Flag spendiert bekommen und erscheint deswegen direkt als Variable.)

Du kannst aber natürlich in dem Skript eine beliebige Aktion auslösen, inklusive dem Setzen einer Variablen:

SetValue(12345 /* hier die ID einer Variablen eintragen */, $_IPS['MESSAGE'] == 'ON' /* Wert anpassen je nachdem wie das Gerät den "Ein"-Zustand bezeichnet */);

Wobei du gucken musst, wo die Variable sinnvollerweise abgelegt wird. Innerhalb der Topic-Struktur gälte die von dir erstellte Variable ja selbst wiederum als eigenes Topic, das dann wiederum an alle Geräten, die ab der Ebene „#“ abonniert haben, gepublisht wird. Also vielleicht besser die Variable außerhalb der Topic-Struktur an einem geeigneten Ort ablegen.

Schöner wäre, wenn das Gerät seinen Status als „retained“ Message ausgäbe, sofern es sich nicht um ein rein momentanes Ereignis, sondern einen Status von Dauer handelt. Eine retained message ist eine persistente Nachricht, die auch nachträglich von anderen Geräten abgerufen werden kann, selbst wenn das setzende Gerät sie nicht aktualisiert.

„Normale“ Nachrichten sind flüchtig und verpuffen sofort, es sei denn man hat sie bereits abonniert. Sie machen eigentlich nur da Sinn, wo es um die Meldung eines Ereignisses geht.

Siehe mein vorheriger Post

mat1987 · 3. März 2018 um 09:38

Danke für die Antwort,…
leider klappt es immer noch nicht,… ich würde gerne „nur“ deinen Broker verwenden und mit die IPS Tasmota „sparen“

die Variable wird einfach nicht gesetzt,…
im Message Fesnster erhalte ich folgende Meldung mit einem Abbruch,… hmmmm…

sokkederheld · 3. März 2018 um 10:06

Das ist die Ausgabe der automatisch vom Broker erzeugten Skripte, solange du sie nicht bearbeitet hast. Du müsstest die o.g. Codezeile in das STATE-Skript schreiben, den vorherigen Inhalt ersetzend.

Aber ich habe gerade noch eine andere Idee, wie ich eine komfortablere Lösung ermöglichen kann. Das käme im nächsten Update und das käme dann, wenn das Baby mich lässt

mat1987 · 3. März 2018 um 10:22

Vielen Dank! hat geklappt!! Ich war etwas verwirrt wegen den scripts,… ich hatte eigentlich Variablen erwartet, aber jetzt verstehe ich warum - danke für die Ausführliche Erklärung.

Das aktive Schalten beschreibst du so:
$arr = array(
„TOPIC“ => „foo/bar“,
„MESSAGE“ => „Hello World!“
);
IPS_RunScriptEx(12345 /* durch die ID des Broker-Skripts bei euch ersetzen! */, $arr);

kannst du mir vielleicht helfen wie das bei mir aussehen müsste?
Danke schon mal dem frisch gebackenen Papa

sokkederheld · 3. März 2018 um 10:57

Den String bei TOPIC ersetzt du durch dein Topic, also bspw. tele/sonoff/STATE. Falls man das Gerät so ansprechen kann, das kommt natürlich auf das Gerät an.

Den String bei Message ersetzt du durch den Wert, der bei dem Gerät für „an“ steht, also bsp. ON. Oder was immer du sonst von dem Gerät willst.

Und statt 12345 sollte da natürlich die ID des Skripts stehen, das „MQTT Broker“ heißt. Müsstest du bei dir in der Konsole gucken.

sokkederheld · 4. März 2018 um 05:01

Changelog:

[ul]
[li]Fehler behoben, dass das Publishen von 0 mit Retain-Flag auf einem Topic als „Retained Message entfernen“ interpretiert wurde
[/li][li]Fehler behoben, dass das Entfernen einer Retained Message durch publishen eines leeren Topics nicht funktionierte
[/li][li]Neues Feature eingebaut: Schattenvariablen (s.u.)
[/li][/ul]

Was ist eine Schattenvariable?

Relativ einfach: Eine Schattenvariable enthält den Inhalt der letzten für das zugehörige Topic publizierten Nachricht. Dabei ist unerheblich, ob das Retain-Flag für die Nachricht gesetzt war - im Gegensatz zu einer „normalen“ Variable in der Topic-Struktur, welche nur mit als „Retain“ markierten Nachrichten befüllt würde, wird der Wert einer Schattenvariable immer gesetzt, sobald auf das Topic publiziert wird!

Was soll das?

Angenommen, ich habe ein Topic, auf das ein Gerät publisht, ohne dass das Retain-Flag gesetzt wäre. Der Broker wird dann dort ein Skript erstellen, um die Messages zu behandeln, denn diese sind ja offiziell nicht zur Speicherung bestimmt. Aber mitunter möchte man in IPS dennoch eine Speicherung vornehmen. Das war bislang nur möglich, indem man im Skript des Topics explizit eine Variable setzt, die auch noch außerhalb der Topic-Ebene liegen sollte, um nicht sinnlos in die Welt publiziert zu werden.

Das geht nun dank der Möglichkeit, Schattenvariablen zu erstellen, deutlich einfacher.

Wie wird eine Schattenvariable erstellt

Eine Schattenvariable wird nicht automatisch erstellt, da sie eine Ausnahme darstellt und nicht zum Betrieb des Brokers erforderlich ist. Sie muss händisch auf der entsprechenden Topic-Ebene angelegt werden. Dabei ist auf den passenden Datentyp zu achten.

Um eine Variable als Schattenvariable zu kennzeichnen, wird ihrem Namen ein Sternchen (*) vorangestellt.

Beispiel

Mein Topic heißt tele/sonoff/STATE. Dann würde ich auf der Kategorieebene unterhalb von sonoff eine Variable namens *STATE erstellen. Diese erhält fortan immer die jeweils letzten auf dem Topic publizierte Nachricht.

Was ist noch zu beachten?

Eine Schattenvariable existiert für MQTT-Clients nicht und ist nur für die Verwendung innerhalb IPS bestimmt. Es kann nicht direkt auf die Schattenvariable publiziert werden und auch das Abonnieren ist nicht möglich, da die dauerhafte Speicherung von Nachrichten ohne Retain-Flag dem MQTT-Standard widerspräche.

sokkederheld · 9. März 2018 um 13:55

[ul]
[li]Konfigurationsskript hinzugefügt. Dieses erscheint automatisch auf der gleichen Ebene wie das Core-Skript
[/li][li]Der Name des Core-Skripts beinhaltet ab sofort automatisch die Versionsnummer.
[/li][li]Möglichkeit, die Verwendung von Variablenprofilen für ausgewählte Topic-Filter zu aktivieren
[/li][li]Möglichkeit, die Datentyp-Eskalation (wenn ein nicht numerischer String auf ein Topic gepostet wird, das als Integer-Variable angelegt ist, wird diese umbenannt und stattdessen eine String-Variable erzeugt) pro Topic-Filter zu deaktivieren
[/li][li]Fehler behoben, dass bei existierender Schattenvariable trotzdem automatisch ein Skript für das Topic angelegt wurde.
[/li][/ul]

sokkederheld · 10. März 2018 um 18:35

Den saloppen ersten Post habe ich mal durch eine halbwegs umfassende Doku ersetzt, denn mir ist aufgefallen dass der Broker mittlerweile ein gewisses Feature Set hat. Falls etwas unklar oder schlecht formuliert sein sollte, weist mich gerne darauf hin und ich versuche es zu verbessern. Ich wollte nur gerne, dass Interessierte als ersten Post etwas strukturiertes vorfinden, in das man sich einlesen kann anstatt den ganzen Thread durchwühlen zu müssen.