Patch für mehrere Probleme mit Topics und Payload

[hexenmeister]

Moin!

Ich habe jetzt mehrere hier im MQTT-Unterforum genannten Probleme gesammelt angegangen.
Zwar habe ich schon fast identische Versionen zum testen im "Topic mit Leerzeichen oder Doppelpunkt funktioniert nicht"-Thread angeboten, mache hier dennoch noch ein mal, da es mehr Themen betroffen sind, als nur Leerzeichen/Doppelpunkte.

Also, hier ist die Fix-Liste:

- Problem mit dem $-Zeichen in Topics
- Problem mit dem Leerzeichen in Topics (solche Topics müssen mit Anführungzeichen geschützt werden)
- Problem mit dem :-Zeichen in Topics
- Problem mit dem JSON-String als Payload
- Problem mit GUI-Zusatzparametern in publishSet (z.B. level:slider,0,1,100)
- Beim Wiederaufbau von verlorenen (bzw. manuell getrennten) Verbindungen wird jetzt ggf. gesetzte QOS-Flags für jeden Topic wieder korrekt neu gesetzt.
- Client-Hooks für client_start und client_stop

Betroffen sind zwei Dateien (00_MQTT, 10_MQTT_DEVICE), s. Anhang.

Bei mir (und paar anderen Benutzern) scheint alles korrekt zu funktionieren, dennoch sind natürlich weitere Tester immer willkommen.

Ansonsten könnten meines Erachtens die Änderungen in die RePo aufgenommen werden.

@eisler: Stephan, wie wäre es für dich bequemmer: Modul-Dateien im Ganzem, oder als Patches? Falls zweite, reicht dann ein Gesamtpatch (pro Datei natürlich), oder soll ich die Änderungen (soweit geht) voneinander trennen und Einzelpatches liefern?

Grüße
Alexander

[Beta-User]

Moin!

Gute Sache, würde vermutlich u.a. die meisten der hier erörterten Probleme lösen, um die Sidoh-Milight-Bridge voll nutzen zu können.

Hab's mir kurz angesehen, und irgendwie kann ich die Unterschiede zu den im SVN enthaltenen Module nicht recht erkennen. Sicher, dass hier die gepatchten Versionen gepostet sind?

Danke jedenfalls für die Initiative,

Beta-User

[eisler]

@hexenmeister Modul-Dateien im Ganzem, oder als Patches passt beides. Gesamtpatch pro Datei ist ok.

Grüße
Stephan

[hexenmeister]

Hab's mir kurz angesehen, und irgendwie kann ich die Unterschiede zu den im SVN enthaltenen Module nicht recht erkennen. Sicher, dass hier die gepatchten Versionen gepostet sind?

Ähm... Habe nochmals angesehen, ja, doch, sind die gepatchte Versionen. Schau mal bitte noch mal nach. Ich hänge zwischendurch mal auch Patches an.

[hexenmeister]

Und die Patch-Dateien...

[Beta-User]

Ähm... Habe nochmals angesehen, ja, doch, sind die gepatchte Versionen. Schau mal bitte noch mal nach. Ich hänge zwischendurch mal auch Patches an.

Sorry, das paßt...

Zu diesem Teil

Problem mit dem JSON-String als Payload

eine Frage:
Bedeutet das, dass man empfangssseitig nicht mehr unbedingt den Weg über expandJSON (oder was selbergestricktes) gehen muß?
Wie sieht es auf der Sendeseite aus?

EDIT: (Werde erst mal testen, was jetzt eigentlich Stand der Dinge ist, vielleicht klappt ja bereits mehr von alleine, als ich im Moment annehme... Melde mich dann ggf. wieder.).

Gruß, Beta-User

[hexenmeister]

Nein, das ermöglicht Versand von json-representation im payload. Das ging früher nicht.

[Beta-User]

Danke für die Klarstellung, das hilft jedenfalls deutlich weiter.

In Bezug auf die Milight-Bridge: Wie muß man das anwenden/einstellen, dass json verwendet werden soll bzw. welche Parameter da rein sollen? Oder läuft das automatisch?

[hexenmeister]

Nein, wir haben uns immer noch nicht verstanden. Json-string muss man immer noch selbst zusammenstellen. Nur früher gingen keine Werte in geschweiften Klammern.
Beim Thema direkte json Unterstützung bin ich mir weiterhin nicht sicher, dass das eine gute Idee wäre, das in Modul einzubauen. Dafür gibt es doch schon expand json Modul.

[Beta-User]

Dann wäre also die Frage: wie stellt man den JSON-String sendeseitig zusammen?
Ein Beispiel würde mir sehr weiterhelfen. Bei den Milights müßte was rauskommen wie {"$command":"$value"}, also {"hue":"123""}, {"command":"white_mode"} oder {"brightness":"255"}

Was expanJSON angeht: Ist schon klar, dass es das gibt, und dass es vermutlich auch wg. der rekursiven Funktionsweise besser ist, das separat zu lassen. Muß ich mich halt erst mal eindenken, aber das wird schon werden...

[hexenmeister]

Derzeit gibt es keinerlei json-Unterstützung in dem Modul. D.h. man muss schon selbst diesen irgendwie zusammensetzen und an das 'set'-Befehl übergeben.
Es wäre denkbar, eine Möglichkeit einzubauen, dass dabei eine vorher definierte Expression ausgeführt wird, die das dann zusammensetzen könnte, das wäre aber ein anderes Vorhaben, was mit dem hier nichts zu tun hätte.

[Beta-User]

OK, Danke für die Info.


Evtl. hat lufi da in dem bereits verlinkten thread schon gute Vorarbeit geleistet. Vielleicht könnt ihr euch das mal ansehen, das wäre nett.


Mobiler, kurzer Gruß,


Beta-User

[hexenmeister]

So ein String, wie dort beschrieben, kann jetzt gesendet werden (das war genau das Problem, der String wurde fälscherweise als Expression 'erkannt' und verschlückt).
Wg. dem automatischen Zusammenbau habe ich, denk' ich, das Problem noch nicht verstanden. Soll beim 'set blup' irgendwas wie '{"value":"blup"}' gesendet werden?

[Beta-User]

Hmm, das Problem mit dem Versenden war mir bisher nicht aufgefallen - das hat mit lufi's Version und auch meinen diversen Versuchen ohne Probleme geklappt.

Dann also ein Anlauf dazu, das darzustellen, wie das bei den Milights nach meinem evtl. noch unvollständigen Verständnis ist:
- Alles, was an Befehlen an den Hub gesendet wird, geht über denselben update-Topic raus, die eigentliche Info, auf welches Detail sich eine Änderung/ein Befehl bezieht, steckt also in dem JSON.
- Die Event-Map sieht z.B. so aus: /status ON:on/ /status OFF:off/
- wird jetzt ein "on" verursacht, geht an das update-topic (Text aus mosquitto_sub, dort jeweils ohne die '') ein '{"status":"ON"}', entsprechend bei Nutzung des "brightness:colorpicker,BRI,0,1,255" z.B. ein '{"brightness":"123"}'.
- Die Umsetzung erfolgt innerhalb des modifizierten Moduls schlicht, indem die bereits vorhandenen Variablen genutzt werden ($command und $value).

Die entscheidende Änderung im Code ist das hier (in der "sub set()", meine Version, ich kann nicht sagen, ob das Nebenwirkungen auf Devices hat, die das nicht brauchen...):

Code Auswählen Erweitern

if(defined($hash->{'.sendJson'}) and $hash->{'.sendJson'} ne 0) {
$value =~ s/^\s+|\s+$//g;
$msgid = send_publish($hash->{IODev}, topic => $hash->{publishSets}->{$command}->{topic}, message => "{\"$command\":$value}", qos => $hash->{qos}, retain => $retain);
} else {
$msgid = send_publish($hash->{IODev}, topic => $hash->{publishSets}->{$command}->{topic}, message => $value, qos => $qos, retain => $retain);
...
Die restlichen Änderungen sind nur dazu da, das Attribut definieren zu können.

Das Vorgehen an sich, Änderungen so umzuformen, erscheint mir auch einigermaßen generisch, so dass das eigentlich auch auf andere Devices passen könnte, die JSON-Infos auf update-Topics erwarten (nur dann macht das Senden von JSON ja Sinn).

Hoffe, das jetzt halbwegs verständlich erläutert zu haben, wie gesagt, ich bin erst dabei mich überhaupt in das ganze Thema MQTT einzudenken.

Gruß, Beta-User

EDIT: Sende-Code angepaßt, Erläuterung folgt

[Beta-User]

EDIT:
Vorab: Macht das Sinn, das hier zu diskutieren, oder sollte das in einen separaten Thread?
Und ansonsten: Ist das Thema mit den Milights so spezielle, dass es tatsächlich besser wäre, dafür ein eigenes Client-Modul zu basteln?

Ansonsten noch eine Ergänzung zum Vorhergehenden:

Der Sendecode wie bereits dargestellt funtioniert zwar:

müßte was rauskommen wie {"$command":"$value"}, also {"hue":"123""}, {"command":"white_mode"} oder {"brightness":"255"}

Besser wäre aber scheinbar:
{"$command":$value}, also {"hue":123}, {"command":white_mode} oder {"brightness":255}
Hab's oben bereits angepasst. Damit scheint die Bridge genauso klar zu kommen, aber ein update aller Daten in state erfolgt teilweise nur dann, wenn keine "" um $value gesendet werden. Negative Auswirkungen scheint das nicht zu haben, ist aber auch nicht intensiv getestet.

Noch etwas Traffic, damit erkennbar wird, wie FHEM und die Bridge miteinander sprechen:

Code Auswählen Erweitern

Client mosqsub/XXXX received PUBLISH (d0, q0, r0, m0, 'milight/0x63C2/rgbw/4', ... (22 bytes))
{"command":night_mode}
Client mosqsub/XXXX received PUBLISH (d0, q0, r0, m0, 'milight/updates/0x63C2/rgbw/4', ... (15 bytes))
{"state":"OFF"}
Client mosqsub/XXXX received PUBLISH (d0, q0, r0, m0, 'milight/updates/0x63C2/rgbw/4', ... (37 bytes))
{"state":"ON","command":"night_mode"}
Client mosqsub/XXXX received PUBLISH (d0, q0, r0, m0, 'milight/states/0x63C2/rgbw/4'' ... (93 bytes))
{"state":"ON","status":"ON","level":72,"bulb_mode":"night","color":{"r":255,"g":255,"b":255}}

Evtl. könnte man das so machen, dass man die Zeichenkette mit der Anweisung, wie das im Ergebnis zusammengebaut werden soll, direkt in dem Attribut sendJson hinterlegen kann (hier also: {\"$command\":$value}).
Dann könnte das im Ergebnis evtl. so aussehen (wenn das direkt und ohne Zwischenschritte geht, sonst müßte man ggf. erst das Attribut auslesen und den Sendestring vorab in eine Variable packen):

Code Auswählen Erweitern

$msgid = send_publish($hash->{IODev}, topic => $hash->{publishSets}->{$command}->{topic}, message => $hash->{'.sendJson'}, qos => $hash->{qos}, retain => $retain);
Kann's ja bei Gelegenheit mal testen...