Autor Thema: Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER  (Gelesen 8237 mal)

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23821
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #1 am: 15 November 2018, 12:15:23 »
Habs hinzugefuegt.

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #2 am: 15 November 2018, 12:32:06 »
Danke  :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #3 am: 15 November 2018, 22:34:25 »
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
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #4 am: 15 November 2018, 22:57:25 »
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

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #5 am: 15 November 2018, 23:03:48 »
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

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #6 am: 16 November 2018, 00:04:16 »
(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

Offline Billy

  • Hero Member
  • *****
  • Beiträge: 1176
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #7 am: 16 November 2018, 09:40:27 »
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*

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #8 am: 16 November 2018, 09:48:13 »
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23821
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #9 am: 16 November 2018, 09:59:29 »
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.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23821
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #10 am: 16 November 2018, 10:04:29 »
Zitat
Gibt 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

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #11 am: 16 November 2018, 10:28:06 »
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23821
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #12 am: 16 November 2018, 10:31:15 »
Zitat
Beim Setzen einer neuen Subscription-Liste wird also ein Reconnect gemacht?
Ja.

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #13 am: 20 November 2018, 23:27:27 »
- 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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23821
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #14 am: 21 November 2018, 08:24:56 »
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.

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #15 am: 21 November 2018, 08:39:06 »
Alles klar, danke, passe ich heute abends an :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Offline HomeAlone

  • Full Member
  • ***
  • Beiträge: 255
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #16 am: 21 November 2018, 17:24:18 »
Habe in diesem Thread meine Ergebnisse beim Testen des MQTT2_CLIENTS geposted. Denke auch nicht, dass es mit der Bridge zu tun hat, die hier besprochenen (dis-)connects treten aber auch bei mir auf und ich habe auch entsprechende logs vom Mosquitto mit angehangen.
Vielleicht hilft es ja bei der Fehlersuche.

Offline HomeAlone

  • Full Member
  • ***
  • Beiträge: 255
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #17 am: 25 November 2018, 10:56:44 »
Update: Seit den Änderungen von Rudi im MQTT2_CLIENT Modul von heute Nacht kommen bei mir keine disconnects mehr vor. Habe allerdings zu Testzwecken den Mosquitto lokal auf dem selben System laufen wie fhem. Bisher klappt es mit MQTT_GENERIC_BRIDGE einwandfreil.
Werde noch berichten, ob und wie es auf einem remote Mosquitto läuft.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14026
  • "Developer"?!? Meistens doch eher "User"
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #18 am: 20 Dezember 2018, 12:10:38 »
Hinweis:

Die commandref wäre noch zu ergänzen, z.B. so:
Zeile 2558
  <br/>One fo the device types could serve as IODev: <a href="#MQTT">MQTT</a>, <a href="#MQTT2_CLIENT">MQTT2_CLIENT</a> or <a href="#MQTT2_SERVER">MQTT2_SERVER</a>.

Zeile 2946
    <br/>Es wird eines der folgenden Geraete als IODev benoetigt: <a href="#MQTT">MQTT</a>, <a href="#MQTT2_CLIENT">MQTT2_CLIENT</a> oder <a href="#MQTT2_SERVER">MQTT2_SERVER</a>..
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #19 am: 27 Dezember 2018, 19:03:43 »
Danke! Habe in die Commandref übernommen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Offline pc1246

  • Hero Member
  • *****
  • Beiträge: 2998
  • Kein support per PN oder eMail
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #20 am: 09 Januar 2019, 10:47:46 »
Moin zusammen
Ich habe folgendes Problem:
2019.01.08 17:09:59 1: reload: Error:Modul 00_MQTT deactivated:
 Attempt to reload Net/MQTT/Message.pm aborted.
Compilation failed in require at ./FHEM/00_MQTT.pm line 80.
BEGIN failed--compilation aborted at ./FHEM/00_MQTT.pm line 80.

2019.01.08 17:09:59 0: Attempt to reload Net/MQTT/Message.pm aborted.
Compilation failed in require at ./FHEM/00_MQTT.pm line 80.
BEGIN failed--compilation aborted at ./FHEM/00_MQTT.pm line 80.

2019.01.08 17:09:59 1: reload: Error:Modul 10_MQTT_GENERIC_BRIDGE deactivated:
 Can't continue after import errors at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 366.
BEGIN failed--compilation aborted at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 403.

2019.01.08 17:09:59 0: Can't continue after import errors at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 366.
BEGIN failed--compilation aborted at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 403.
Ich meine das schon mal gelesen zu haben, finde das aber in der Masse der threads nicht wieder. FHEM ist aktuell, auf diesem System!
Muss ich erst ein device vom Typ MQTT anlegen?
Danke und Gruss
Christoph
RasPi2
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; add-on board mit 6 IT-Steckdosen;3 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; KS300; ESA2000; HUE

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14026
  • "Developer"?!? Meistens doch eher "User"
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #21 am: 09 Januar 2019, 10:55:10 »
Moin Christoph,
bin nicht ganz sicher, aber vermutlich benötigst du die Perl-Module, die für MQTT (alt) erforderlich sind, weil die Gen-Bridge im Hintergrund Funktionen aus MQTT aufruft - was nur geht, wenn die dafür erforderlichen Module geladen werden können.

MQTT mußt du aber nicht definieren.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline pc1246

  • Hero Member
  • *****
  • Beiträge: 2998
  • Kein support per PN oder eMail
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #22 am: 09 Januar 2019, 11:21:39 »
Moin Beta
Danke fuer den Hinweis! Ich habe es nach meinem Post nochmal probiert, und eine weitere Meldung im log gefunden, die mich auf die richtige Spur gefuehrt hat!
sudo apt-get install libmodule-pluggable-perlDa MQTT2 mosquitto nicht installiert, fehlt diese lib. Also flugs nachinstalliert, und schon geht es. Evtl. ein kleiner Hinweis in einer der vielen wiki Eintraege!?
Gruss Christoph
RasPi2
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; add-on board mit 6 IT-Steckdosen;3 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; KS300; ESA2000; HUE

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14026
  • "Developer"?!? Meistens doch eher "User"
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #23 am: 09 Januar 2019, 11:28:59 »
Moin Beta
Danke fuer den Hinweis! Ich habe es nach meinem Post nochmal probiert, und eine weitere Meldung im log gefunden, die mich auf die richtige Spur gefuehrt hat!
sudo apt-get install libmodule-pluggable-perlDa MQTT2 mosquitto nicht installiert, fehlt diese lib. Also flugs nachinstalliert, und schon geht es. Evtl. ein kleiner Hinweis in einer der vielen wiki Eintraege!?
Gruss Christoph
Hab's mal hier eingefügt: https://wiki.fhem.de/wiki/MQTT#MQTT_GENERIC_BRIDGE

Bist du sicher, dass das eine Modul ausreichend ist? Kommt mir wenig vor... (Ich hatte mal mosquitto auf dem Server laufen und daher die betreffenden Perl-libs alle drauf, aber vermutlich nicht deinstalliert, obwohl debianisiert).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline pc1246

  • Hero Member
  • *****
  • Beiträge: 2998
  • Kein support per PN oder eMail
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #24 am: 09 Januar 2019, 11:36:34 »
Hallo Beta
Ja, das sieht gut aus! Generic bridge wurde angelegt, und scheint auch zu funktionieren!
Publisht momentan noch nicht, aber das ausgewaehlte device wird gezaehlt!
Gruss Christoph
RasPi2
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; add-on board mit 6 IT-Steckdosen;3 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; KS300; ESA2000; HUE

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14026
  • "Developer"?!? Meistens doch eher "User"
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #25 am: 09 Januar 2019, 11:56:16 »
Für's publish ist m.E. dann das MQTT2-IO zuständig.

Da Funktionen aus NET::MQTT erst für MQTT_DEVICE benötigt werden, nicht für MQTT, sollte das eine Modul ausreichen.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #26 am: 10 Januar 2019, 07:39:19 »
Ja, leider eine 'durchgereichte' Abhängigkeit. Bridge verwendet 00_MQTT, dort werden Bibliotheken aus FHEM/lib/net/mqtt geladen und die wollen die Pluggable-Lib. :/ Ich weiß noch nicht so recht, wie ich das am besten auflöse.  ???

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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23821
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #27 am: 10 Januar 2019, 08:06:34 »
Theoretisch: pruefen, ob die Daten uber MQTT versendet/empfangen werden sollen, und wenn ja, das Modul per eval require laden.
Ob das auch praktisch eine sinnvolle Loesung ist, ist eine andere Sache.

Offline LudgerR

  • Jr. Member
  • **
  • Beiträge: 62
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #28 am: 11 Januar 2019, 14:42:41 »
Zur Info

laut Commandreference  MQTT_GENERIC_BRIDGE

Zitat
IODev
Dieses Attribut ist obligatorisch und muss den Namen einer funktionierenden MQTT-Modulinstanz enthalten. Modul MQTT2_SERVER wird nicht unterstuetzt.
IODev

wird MQTT2_SERVER  nicht unterstuetzt.

War etwas irritierend. Ich dachte schon ich hätte trotz update nicht den letzten Release Stand.

Glücklicherweise  steht anfangs

Zitat
Es wird eines der folgenden Geraete als IODev benoetigt: MQTT, MQTT2_CLIENT oder MQTT2_SERVER.



Fhem on FB7390 and PI 3+ , 2xCUNO(IR+1-Wire), 13xFHT, Buderus GB-112, EM1000 WZ/GZ, FS20,AMAD,SONOS

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14026
  • "Developer"?!? Meistens doch eher "User"
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #29 am: 11 Januar 2019, 14:50:01 »
@LudgerL:
Danke für's Nachfragen/Melden.
Bitte UNBEDINGT autocreate abschalten, wenn du derzeit ein MQTT2-IO mit der Generic Bridge verwenden willst!

@hexenmeister:
Da stehen nach meinem Lektürestand von neulich noch ein paar Einschränkungen usw. in der cref drin, die man überarbeiten sollte. Vielleicht komme ich am WE dazu, dann bekommst du wieder Vorschläge?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #30 am: 11 Januar 2019, 15:00:24 »
@LudgerR: Danke, werde korrigieren.

@Beta-User, das wäre sehr hilfreich, danke! Ich vergesse immer wieder nach Änderungen das cr anzupassen  >:(
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Offline LudgerR

  • Jr. Member
  • **
  • Beiträge: 62
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #31 am: 11 Januar 2019, 15:34:47 »
@Beta-User
Danke für den Hinweis bzgl. autocreate. 
---------

Die Warnung hatte ich bereits vorher gelesen und trotzdem "autocreate" im MQTT2 server aktiviert.
Bisher ohne Konsequenzen.

Ich habe eine Verständnisfrage.

Warum taucht der prefix mqtt  nicht im  log der Generic-Bridge?

defmod mqttGeneric MQTT_GENERIC_BRIDGE  mqtt  TYPE=FBDECT
attr mqttGeneric IODev MQTT2_FHEM_Server
attr mqttGeneric room MQTT2_DEVICE,SYSTEM
attr mqttGeneric verbose 5

setstate mqttGeneric 2019-01-11 15:14:08 device-count 1
setstate mqttGeneric 2019-01-10 23:17:50 incoming-count 0
setstate mqttGeneric 2019-01-11 15:14:45 outgoing-count 2467
setstate mqttGeneric 2019-01-11 15:14:45 transmission-state outgoing publish sent
setstate mqttGeneric 2019-01-10 23:17:50 updated-reading-count 0
setstate mqttGeneric 2019-01-10 23:17:50 updated-set-count 0



2019.01.11 15:14:45 3: FBDECT set FBDECT_fb1AHAHTTP_08761_0074086 on
2019.01.11 15:14:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: FBDECT_fb1AHAHTTP_08761_0074086/state => on (qos: 0, retain: 0)
2019.01.11 15:14:45 5: FBAHAHTTP_Write reply for fb1AHAHTTP: 1

Ich habe eigentlich nach publish: etwas wie mqtt/FBDECT_   erwartet.
 
Fhem on FB7390 and PI 3+ , 2xCUNO(IR+1-Wire), 13xFHT, Buderus GB-112, EM1000 WZ/GZ, FS20,AMAD,SONOS

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14026
  • "Developer"?!? Meistens doch eher "User"
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #32 am: 11 Januar 2019, 15:42:27 »
Bisher ohne Konsequenzen.
Soweit ich das verstanden habe, wirkt sich das dann aus, wenn du eingehende Nachrichten hast: Dann "schnappt" sich autocreate/das MQTT2-DEVICE die Nachricht und die Generic-Bridge bekommt nichts mehr davon mit. Für publish ist es egal...

Der prefix wirkt sich auf die Frage aus, wie das Attribut im jeweiligen Device heißt:
Zitat
The first parameter is a prefix for the control attributes on which the devices to be monitored (see above) are configured. Default value is 'mqtt'. If this is e.g. redefined as 'hugo', the control attributes are named hugoPublish etc.
Ich habe da mqttBridge spezifiziert, ist evtl. einleuchtender wie "hugo".

Du suchst vermutlich eher sowas wie "globalPublish"?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4640
    • tech_LogBuch
Antw:Erweiterung MQTT_GENERIC_BRIDGE für MQTT2_CLIENT und -_SERVER
« Antwort #33 am: 12 Januar 2019, 16:37:04 »
Soweit ich das verstanden habe, wirkt sich das dann aus, wenn du eingehende Nachrichten hast: Dann "schnappt" sich autocreate/das MQTT2-DEVICE die Nachricht und die Generic-Bridge bekommt nichts mehr davon mit. Für publish ist es egal...
Ja und auch nur dann, wess es sich um gleiche Topic handelt.

Der prefix wirkt sich auf die Frage aus, wie das Attribut im jeweiligen Device heißt:Ich habe da mqttBridge spezifiziert, ist evtl. einleuchtender wie "hugo".
;D ;D ;D

Du suchst vermutlich eher sowas wie "globalPublish"?
Das ist dan eben an der Bridge selbst zu setzen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy