MQTT2: Doppelpunkte in Topics

Begonnen von dev0, 28 Januar 2019, 08:42:58

Vorheriges Thema - Nächstes Thema

dev0

Topics, die einen Doppelpunkt enthalten scheinen nicht korrekt geparst zu werden. In den MQTT 3.1.1 / 5.0 Specs habe ich nichts gefunden, dass gegen die Verwendung von Doppelpunkten in Topics spricht. Die Doppelpunkte verwende ich im Zusammenhang mit MAC/IPv6 Adressen.
Auch ein Anpassen des readingList Attributs (ich hoffe korrekt gesetzt) hat nicht zum gewünschten Ergebnis geführt.


root@fhem-dev:/$ mosquitto_pub -h 127.0.0.1  -i id1 -t /11:22:33:44:55:66/test1/test2 -m xxx

2019.01.28 08:08:18.536 4: Connection accepted from MQTT2_127.0.0.1_58201
2019.01.28 08:08:18.538 5: CONNECT: (0)(6)MQIsdp(3)(2)(0)<(0)(3)id1
2019.01.28 08:08:18.538 4: MQTT2_127.0.0.1_58201 id1 CONNECT V:3 keepAlive:60
2019.01.28 08:08:18.539 5: PUBLISH: (0)(30)/11:22:33:44:55:66/test1/test2xxx
2019.01.28 08:08:18.539 4: MQTT2_127.0.0.1_58201 id1 PUBLISH /11:22:33:44:55:66/test1/test2:xxx
2019.01.28 08:08:18.539 5: MQTT2: dispatch autocreate:id1:/11:22:33:44:55:66/test1/test2:xxx
2019.01.28 08:08:18.572 4: MQTT2_DEVICE_Parse: MQTT2_id1 /11 => 11
2019.01.28 08:08:18.578 5: DISCONNECT:
2019.01.28 08:08:18.578 4: MQTT2_127.0.0.1_58201 id1 DISCONNECT

list MQTT2_id1
Internals:
   CID        id1
   DEF        id1
   DEVICETOPIC MQTT2_id1
   FUUID      5c4ea1ec-f33f-bbfe-2969-d1b9a12ea4a317b4
   IODev      MQTT2
   NAME       MQTT2_id1
   NR         100
   STATE      ???
   TYPE       MQTT2_DEVICE
   .attraggr:
   .attrminint:
   OLDREADINGS:
   READINGS:
     2019-01-28 08:08:18   11              22:33:44:55:66/test1/test2:xxx
Attributes:
   IODev      MQTT2
   readingList id1:/11:.* 11
   room       MQTT2_DEVICE
   verbose    5



fhem#> attr MQTT2_id1 id1:/11:22:33:44:55:66/test1/test2:.* gtag_test2
root@fhem-dev:/$ mosquitto_pub -h 127.0.0.1  -i id1 -t /11:22:33:44:55:66/test1/test2 -m xxx

2019.01.28 08:11:54.488 4: Connection accepted from MQTT2_127.0.0.1_58302
2019.01.28 08:11:54.490 5: CONNECT: (0)(6)MQIsdp(3)(2)(0)<(0)(3)id1
2019.01.28 08:11:54.491 4: MQTT2_127.0.0.1_58302 id1 CONNECT V:3 keepAlive:60
2019.01.28 08:11:54.491 5: PUBLISH: (0)(30)/11:22:33:44:55:66/test1/test2xxx
2019.01.28 08:11:54.492 4: MQTT2_127.0.0.1_58302 id1 PUBLISH /11:22:33:44:55:66/test1/test2:xxx
2019.01.28 08:11:54.492 5: MQTT2: dispatch autocreate:id1:/11:22:33:44:55:66/test1/test2:xxx
2019.01.28 08:11:54.492 4: MQTT2_DEVICE_Parse: MQTT2_id1 /11 => gtag_test2
2019.01.28 08:11:54.528 5: DISCONNECT:
2019.01.28 08:11:54.528 4: MQTT2_127.0.0.1_58302 id1 DISCONNECT

fhem#> list MQTT2_id1
Internals:
   CID        id1
   DEF        id1
   DEVICETOPIC MQTT2_id1
   FUUID      5c4ea1ec-f33f-bbfe-2969-d1b9a12ea4a317b4
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_MSGCNT 1
   MQTT2_TIME 2019-01-28 08:11:54
   MSGCNT     1
   NAME       MQTT2_id1
   NR         100
   STATE      ???
   TYPE       MQTT2_DEVICE
   .attraggr:
   .attrminint:
   OLDREADINGS:
   READINGS:
     2019-01-28 08:11:54   gtag_test2      22:33:44:55:66/test1/test2:xxx
Attributes:
   IODev      MQTT2
   readingList id1:/11:22:33:44:55:66/test1/test2:.* gtag_test2
   room       MQTT2_DEVICE
   verbose    5



Edit: Nur so ein Gedanke und ohne in den Quellcode geschaut zu haben, vermute ich die Ursache im Separator in Dispatch/Parse. Vielleicht wäre der null character (Unicode U+0000) ein passender Separator, da MQTT Topics/Filter dieses Zeichen nicht verwenden dürfen...

rudolfkoenig

ZitatVielleicht wäre der null character (Unicode U+0000) ein passender Separator

Das war auch mein erster Gedanke, allerdings muesste das koordiniert mit dem MQTT_GENERIC_BIRDGE Maintainer passieren, da dieses Modul auch betroffen ist.
Solange habe ich Doppelpunkte in topics nach Unterstrich gewandelt (MQTT2_CLIENT und MQTT2_SERVER).
Das ist zwar nicht ideal, hat aber meiner Ansicht nach ausser eine leichte Verwirrung beim Benutzer keine Nebeneffekte.

dev0

@rudi: danke für den pragmatischen Fix.
@hexenmeister: Magst Du Dich ggf. mit rudi koordinieren, um das umzustellen, wenn es mehr oder weniger problemlos möglich ist, bevor viele Anwender die _ Schreibweise verwenden? Du hattest diese Thematik in den MQQT(ohne 2) Modulen doch auch schon mal gefixed.

Vielleicht wäre diese Lösung dann auch eine Empfehlung für weitere 2-stufige Modulentwickler?

hexenmeister

#3
MQTT_GENERIC_BRIDGE hat Problem mit den Doppelpunkten weder beim Senden noch beim Empfang in Verbindung mit dem 'alten' MQTT-IO.
Wenn ich mich recht erinnere, verwende ich eigene (etwas veränderte) parse-Methode fürs Zerlegen von Parametern. Könnte der Grund sein. Weiß jetzt nicht mehr aus dem Kopf.

Klar arbeite ich an einer gemeinsamen Lösung gerne mit. Ich habe allerdings bis jetzt nicht verstsanden, wie diese aussehen wird. Wie kann man denn bequem die Null-Zeichen in die Attributen (Steuerungsparameter) eingeben? Oder habe ich ganz falsch verstanden?


Oder geht es lediglich um die Interne DatenÜbergabe?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Herrje, ich brauche wohl dringend Schlaf  :o
Vergisst alles, was ich geschrieben habe. Ja klar weiß ich, worum es geht und warum die alten Module nicht betroffen sind (dort ist die Übergabe ganz anders realisiert).
Null Zeichen ist wohl die beste Lösung, zu wann soll geändert werden?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

dev0

Zitat
Null Zeichen ist wohl die beste Lösung, zu wann soll geändert werden?
Vielen Dank, dass Du auch bereit bist Dein Modul anzupassen. Mit dem Unterstrich könnte man bestemmt auch leben, mit Null ist es aber sauberer und verwirrt womöglich weniger.
Meine zwischenzeitlichen Bedenken, dass es mit Null vielleicht Probleme beim Splitten gibt, haben sich zum Glück nicht bestätigt: "\0" funktioniert ;)

rudolfkoenig

ZitatNull Zeichen ist wohl die beste Lösung, zu wann soll geändert werden?
Bin flexibel, sag bitte Bescheid.

hexenmeister

Naja, ist ja nur das Ersetzen von
my ($cid, $topic, $value) = split(":", $msg, 3);

durch
my ($cid, $topic, $value) = split("\0", $msg, 3);

Von mit aus können wir sofort einchecken.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

Habe den Trenner vom : auf \0 umgestellt, und kurz getestet.

hexenmeister

Habe jetzt auch umgestellt, kurz getestet und eingecheckt :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

dev0

Ich danke Euch beiden!

Jetzt müßte in 00_MQTT2_SERVER nur noch das Ersetzen von Doppelpunkten (Zeile 417) wieder entfernt werden ;)
Danach funktioniert es bei mir wie erwartet.

rudolfkoenig

ZitatJetzt müßte in 00_MQTT2_SERVER nur noch das Ersetzen von Doppelpunkten (Zeile 417) wieder entfernt werden.
Im Reading darf : nicht auftauchen, d.h. man verlagert das Problem nach hinten.Ich koennte Doppelpunkt im 10_MQTT2_DEVICE.pm abfangen, aber bei rawEvents muesste der Empfaenger das pruefen.
Auch in MQTT2_DEVICE ist die Frage, ob die generierten Events : enthalten sollen, und damit nicht gleich den Readings sind.=> Ich bin gegen die Aenderung.

dev0

OK, dann hatte ich das "solange" in:
ZitatSolange habe ich Doppelpunkte in topics nach Unterstrich gewandelt
falsch interpretiert. Dann hätte man sich die Umstellung auf NULL beim Splitten allerdings auch sparen können, wenn ich micht nicht irre.

Wenn keine Zeichen in Topics verwendet werden dürfen, die den FHEM Readingsnamen Konventionen widersprechen, dann sollte man allerdings nicht nur : ersetzen. Auswirkungen in Events mit Doppelpunkten hatte ich bislang allerdings nicht bedacht (rawEvents).
Von mir aus kann es aber gerne so beliben wie es ist, ich weiß mir jetzt zu helfen.

rudolfkoenig

Ich bin inzwischen von meinen eigenen Argumenten nicht mehr ueberzeugt :)

Da eine Aenderung meinerseits auch eine Aenderung bei den Anwender nach sich ziehen wuerde, habe ich die Konvertierung optional gemacht mit dem topicConversion Attribut.
Voreinstellung ist 1, also bleibt alles beim Alten.