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
Habs hinzugefuegt.
Danke :)
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)
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.
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)?
(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>)?
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.
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.
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.
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
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. :)
ZitatBeim Setzen einer neuen Subscription-Liste wird also ein Reconnect gemacht?
Ja.
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?
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.
Alles klar, danke, passe ich heute abends an :)
Habe in diesem Thread (http://"https://forum.fhem.de/index.php/topic,92946.msg861749.html#msg861749") 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.
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.
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>..
Danke! Habe in die Commandref übernommen.
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
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.
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-perl
Da 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
Zitat von: pc1246 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-perl
Da 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).
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
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.
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. ???
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.
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.
@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?
@LudgerR: Danke, werde korrigieren.
@Beta-User, das wäre sehr hilfreich, danke! Ich vergesse immer wieder nach Änderungen das cr anzupassen >:(
@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.
Zitat von: LudgerR am 11 Januar 2019, 15:34:47
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:
ZitatThe 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"?
Zitat von: Beta-User am 11 Januar 2019, 15:42:27
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.
Zitat von: Beta-User am 11 Januar 2019, 15:42:27
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
Zitat von: Beta-User am 11 Januar 2019, 15:42:27
Du suchst vermutlich eher sowas wie "globalPublish"?
Das ist dan eben an der Bridge selbst zu setzen.