Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER

Begonnen von hexenmeister, 15 November 2018, 12:00:57

Vorheriges Thema - Nächstes Thema

hexenmeister

Hallo allerseits,
wie schon hier im FOrum angekündigt, habe ich mit der Erweiterung der GenericBridge angefangen, damit diese auch in Verbindung mit den neuen MQTT2.* Modulen verwendet werden kann.
Eine erste Alpha-Version, die über MQTT2-IO etwas empfangen kann, habe ich bereits, sie ist jedoch noch nicht soweit, sie zum Test vorzustellen. Ich denke in den nächsten Tagen wäre es soweit.

Damit das funktioniert musste ich die Module MQTT2_CLIENT und MQTT2_SERVER bei mir modifizieren ({Clients} und {MatchList}).


$hash->{Clients} = ":MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:";
$hash->{MatchList}= { "1:MQTT2_DEVICE"  => "^.*", "2:MQTT_GENERIC_BRIDGE" => "^.*" },


@rudolfkoenig
Kannst Du bitte die GenericBridge in Deine Module entsprechend mitaufnehmen? Thx :)

Grüße

Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig


hexenmeister

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

So, Empfang (subscribe) über MQTT2 (CLIENT und Server) scheint jetzt zu funktionieren. Muss natürlich noch gründlich getestet werden. Werde heute noch einchecken. 8)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Gibt es eigentlich eine saubere Methode zu prüfen, ob MQTT2_CLIENT connected ist und ggf. eine (dis)connect als Event mitzubekommen? Auf 'state' zu prüfen erscheint mir irgendwie etwas unsicher... Kann doch per stateFormat 'verdreht' werden.

Was passiert, wenn Nachrichten gesendet werden, wenn die Verbinung unterbrochen wurde? Werden sie zwischengespeichert und beim Neuverbinden gesendet oder gehen sie verloren?

Hintergrund der Fragen: alte MQTT IO erlaubte entsprechende CallBacks für on(dis)connect. GenericBridge hat für solche Fälle einen eigenen Buffer für (beim Reconnect) zu versendende Nachrichten. Sogar mit einer Möglichkeit zu definieren, ob zum gleihen Topic alle oder nur erste ode rletzte Nachricht versendet wird.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Fragen über Fragen...

Wenn ich es richtig sehe, Retain-Flag wird durch Anhängen von ':r' an das Topic gesetzt. Wie definiere ich QOS (zur Übergabe über IOWrite und bei Subscriptions)?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

(Test)Version mit MQTT2-Unterstützung (senden und empfangen) eingeckecht.
Unklar noch, wie QOS übergeben werden kann und wie die Liste der von dem IO-Modul abonierten Topics aus der Bridge beeinflusst werden kann. Es war, meine ich, ein Vorschlag mit IOWrite($hash, "subscribe", <liste>)?

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Billy

Habe folgenden Effekt, BUG?

Beim Starten von MQTT2_CLIENT auf einer 2ten Instanz folgende Meldung im Log der 1. Instanz
2018.11.16 09:32:52 1: 192.168.148.17:1883 disconnected, waiting to reappear (mqtt2client)
2018.11.16 09:32:52 1: 192.168.148.17:1883 reappeared (mqtt2client)
2018.11.16 09:32:53 1: 192.168.148.17:1883 disconnected, waiting to reappear (mqtt2client)
2018.11.16 09:32:53 1: 192.168.148.17:1883 reappeared (mqtt2client)
2018.11.16 09:32:54 1: 192.168.148.17:1883 disconnected, waiting to reappear (mqtt2client)
2018.11.16 09:32:54 1: 192.168.148.17:1883 reappeared (mqtt2client)
2018.11.16 09:32:54 1: 192.168.148.17:1883 disconnected, waiting to reappear (mqtt2client)
2018.11.16 09:32:54 1: 192.168.148.17:1883 reappeared (mqtt2client)
.......


Im  Log der 2. Instanz

2018.11.16 09:32:53.398 1: 192.168.148.17:1883 disconnected, waiting to reappear (mqtt2client)
2018.11.16 09:32:53.431 1: 192.168.148.17:1883 reappeared (mqtt2client)
2018.11.16 09:32:53.751 1: 192.168.148.17:1883 disconnected, waiting to reappear (mqtt2client)
2018.11.16 09:32:53.770 1: 192.168.148.17:1883 reappeared (mqtt2client)
2018.11.16 09:32:54.231 1: 192.168.148.17:1883 disconnected, waiting to reappear (mqtt2client)
2018.11.16 09:32:54.251 1: 192.168.148.17:1883 reappeared (mqtt2client)
2018.11.16 09:32:54.693 1: 192.168.148.17:1883 disconnected, waiting to reappear (mqtt2client)
2018.11.16 09:32:54.713 1: 192.168.148.17:1883 reappeared (mqtt2client)
2018.11.16 09:32:55.150 1: 192.168.148.17:1883 disconnected, waiting to reappear (mqtt2client)
2018.11.16 09:32:55.171 1: 192.168.148.17:1883 reappeared (mqtt2client)
.....


FHEM auf neuestem Stand.
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

hexenmeister

Vermutlich haben beide Instanzen dieselbe Clientids. Das mögen mqtt Server nicht. Versuche manuell unterschiedliche zu vergeben.
In jedem Fall hat das kaum was mit der bridge zu tun.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

Ich habe:
- m2d/m2c/m2s: Datensenden umgestellt auf IOWrite($hash, "publish", "topic message");
- m2c: WriterFn fuer IOWrite($hash, "subscribe", "space separated list of topics") implementiert. Das wird _nur_ dann angewendet, falls "attr MQTT2_CLIENT subscriptions setByTheProgram" gesetzt ist. Letzteres ist notwendig, da sonst bei einem Mischbetrieb mit MQTT2_DEVICE diese keine Daten mehr kriegen.
- m2c: vor dem Verbindungsabbau wird ein DISCONNECT gesendet
- m2s: nach einem DISCONNECT wird kein lwt gesendet
- onConnect nach msgAfterConnect umbenannt und ein msgBeforeDisconnect implementiert

Sonst: QOS kann man per publish nicht spezifizieren: ich meine, QOS:1 ist bei einer Uebertragung per TCP/IP ueberfluessig, und ich sehe fuer QOS:2 noch nicht den Anwendungsfall, bzw. dass es sich lohnt, die Energie zu investieren.

rudolfkoenig

ZitatGibt es eigentlich eine saubere Methode zu prüfen, ob MQTT2_CLIENT connected ist und ggf. eine (dis)connect als Event mitzubekommen?
fhem> info timer
2018-11-16 10:03:32 MQTT2_CLIENT mc CONNECTED
2018-11-16 10:03:35 MQTT2_CLIENT mc DISCONNECTED

hexenmeister

Das klingt gut, vielen Dank!
Werde mein Modul entsprechend anpassen.

Beim Setzen einer neuen Subscription-Liste wird also ein Reconnect gemacht?

QOS 1 und 2 sind für mich verschmerzbar.  :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

ZitatBeim Setzen einer neuen Subscription-Liste wird also ein Reconnect gemacht?
Ja.

hexenmeister

Zitat von: rudolfkoenig am 16 November 2018, 09:59:29
- m2c: WriterFn fuer IOWrite($hash, "subscribe", "space separated list of topics") implementiert. Das wird _nur_ dann angewendet, falls "attr MQTT2_CLIENT subscriptions setByTheProgram" gesetzt ist.

Wenn ich deine Programmlogik richtig verstanden habe, ist da noch ein Fehler drin.
Im Falle "setByTheProgram" wird die Liste aus $hash->{".subscribe"} genommen...

    if($s eq "setByTheProgram") {
      $s = ($hash->{".subscribe"} ? $hash->{".subscribe"} : "#");
    }

... aber beim IOWrite("subscribe"...) wird in $hash->{".subscribtion"} geschrieben.

  } elsif($function eq "subscribe") {
    $hash->{".subscribtion"} = $topicMsg;
    MQTT2_CLIENT_Disco($hash);


Mags Du bei Gelegenheit nachsehen?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

Danke fuer den Hinweis, du hast natuerlich Recht.
Habe jetzt alles mit subscr.* auf subscriptions geaendert, d.h. du musst leider den Aufruf auch anpassen.