FHEM Forum

FHEM - Hausautomations-Systeme => MQTT => Thema gestartet von: rudolfkoenig am 07 November 2018, 21:12:15

Titel: MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 07 November 2018, 21:12:15
Auf Wunsch und auf Vorrat.

#1: Es steht ab morgen ab 8 per update zur Verfuegung
#2: Modul aus SVN holen reicht nicht, da fhem.pl, DevIo.pm und MQTT2*.pm auch leicht angepasst wurden
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 07 November 2018, 21:20:53
Grundsätzlich funktioniert und spricht auch mit meinem Mosquitto.
Habe leider in den nächsten tagen sehr wenig Zeit, werde aber nach und nach testen und  die GenericBridge kompatibel machen.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 07 November 2018, 21:57:00
Hat es einen bestimmten Grund, dass QOS 2 nicht implementiert ist? Wäre das aufwendig? Ist es geplant, dies irgendwan nachzuholen?
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 07 November 2018, 22:10:10
Hab gleich eine kleine Wunschliste:
  set connect
  set disconnect

autoreconnect bei Verbindungsabbruch / MQTTServer-Restart
(Leider wird die Verbindung nicht wieder aufgenommen und eine manuelle Möglichkeit gibt es auch nicht.)
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 08 November 2018, 10:00:27
Hallo zusammen. Ich möchte das Modul auch gerne testen, habe aber ein Problem bei der Implementierung:

Zunächst habe ich das Client-Device definieren (Verweis auf den lokal laufenden Mosquitto, zu Testzwecken aktuell noch ohne user/pw/tls):
define mosquitto MQTT2_CLIENT localhost:1883
Das klappt, getestet mit 
set mosquitto publish fhem/testnachrichtwas auch verschickt wird.

Jetzt habe ich für meinen EnOcean Fenstergriff ein MQTT2_DEVICE erstellt und die setList definiert:
define wz_Fenstergriff_rechts_MQTT MQTT2_DEVICE
attr wz_Fenstergriff_rechts_MQTT
setList
  closed fhem/Wohnzimmer/Fenster_rechts/state closed\
  open fhem/Wohnzimmer/Fenster_rechts/state open\
  tilted fhem/Wohnzimmer/Fenster_rechts/state tilted\
  open_from_tilted fhem/Wohnzimmer/Fenster_rechts/state open_from_tilted

Hier scheine ich aber noch einen Fehler zu machen, denn bei den entsprechenden Aktionen wird keine Nachricht via MQTT versendet.
Da scheint der Wurm drin zu sein - zumindest wird keine Nachricht versendet, wenn ich den Fenstergriff betätige.

Im Log erscheint nichts zum MQTT2_CLIENT oder MQTT2_DEVICE, was mir bei der Behebung helfen würde. Eine Perl-warning, die aber eher für Rudi interessant sein dürfte:
2018.11.08 09:20:01 1: PERL WARNING: Use of uninitialized value $a[0] in string eq at ./FHEM/00_MQTT2_CLIENT.pm line 208.
Im Eventlog erscheinen die Events zum Fenstergriff:
2018-11-08 09:48:35 EnOcean wz_Fenstergriff_rechts open
2018-11-08 09:48:41 EnOcean wz_Fenstergriff_rechts closed
Jedoch keine zum MQTT2_DEVICE. Auch bei verbose level 5 kommt nichts.

Da der Zustand des Fenstergriffs im Reading state definiert wird, habe ich auch
setList
  state:closed fhem/Wohnzimmer/Fenster_rechts/state closed\
  state:open fhem/Wohnzimmer/Fenster_rechts/state open\
  state:tilted fhem/Wohnzimmer/Fenster_rechts/state tilted\
  state:open_from_tilted fhem/Wohnzimmer/Fenster_rechts/state open_from_tilted
probiert, mit demselben - gar keinem ;) - Ergebniss.

 Jemand eine Idee, was ich falsch mache?

Viele Grüße
Sascha
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Beta-User am 08 November 2018, 10:09:57
Hast du auch im device mosquitto als io hinterlegt?
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 08 November 2018, 10:16:25
Hast du auch im device mosquitto als io hinterlegt?
Ja, habe ich (genauergesagt wude es automatisch angelegt ;) )
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Beta-User am 08 November 2018, 10:26:01
Du setzt den state ;) .

Da könnte $event oder Teile helfen.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Billy am 08 November 2018, 10:56:04
Habe mal mit dem Test auf meinem Testsystem begonnen.
1. Anlegen mit
define mqtt2client MQTT2_CLIENT 192.168.148.17:1883
attr mqtt2client autocreate 1
attr mqtt2client disable 0
attr mqtt2client room MQTT2
hat geklappt!
Einen SonoffBasic anlegen mit
define mqtt2_Sonoff8 MQTT2_DEVICE
attr mqtt2_Sonoff8 IODev mqtt2client
attr mqtt2_Sonoff8 devicetopic Sonoff/cmnd/sonoff_8
attr mqtt2_Sonoff8 disable 0
attr mqtt2_Sonoff8 room MQTT2
attr mqtt2_Sonoff8 setList on Sonoff/cmnd/sonoff_8/POWER1 ON\
off Sonoff/cmnd/sonoff_8/POWER1 OFF
hat geklappt! und lässt sich schalten! :)

Bug?
Im Event monitor kommt ständig Meldung
Global global UNDEFINED MQTT2_mqtt2client MQTT2_DEVICE mqtt2client
Und im Log
PERL WARNING: Deep recursion on subroutine "main::MQTT2_CLIENT_Read" at /data/fhem//FHEM/00_MQTT2_CLIENT.pm line 312.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 08 November 2018, 11:27:16
Zitat
Hat es einen bestimmten Grund, dass QOS 2 nicht implementiert ist? Wäre das aufwendig? Ist es geplant, dies irgendwan nachzuholen?
Ja, Ja, haengt vom Bedarf ab.
Zitat
Leider wird die Verbindung nicht wieder aufgenommen
Ich arbeite daran.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 08 November 2018, 13:18:09
Zitat
Leider wird die Verbindung nicht wieder aufgenommen
Ist jetzt gefixt.

Zitat
PERL WARNING: Deep recursion on subroutine
Das habe ich evtl. auch gefixt, bin aber unsicher.
Falls es nochmal auftritt, hier ein "attr mqtt2client verbose 5" hier anhaengen.

Zitat
Global global UNDEFINED MQTT2_mqtt2client MQTT2_DEVICE mqtt2client
Falls man das autocreate Attribut in MQTT2_CLIENT setzt, dann sollte auch eine autocreate FHEM-Instanz definiert sein, damit die Geraete angelegt werden. Diese Meldung kommt, falls irgendein topic in der Summe der MQTT2_DEVICES nicht behandelt wurde. Alternativ verzichtet man auf autocreate.

Zitat
PERL WARNING: Use of uninitialized value $a[0]
Das muss ein set gewesen sein, aber eigentlich wird ein paar Zeilen vorher genau das geprueft.
Wuerde mich freuen, wenn du es mit der aktuellen Version (SVN oder morgen ab 8 per update) verifizieren koenntest, und falls es auftritt, mir genau beschreibst, wie ich es reproduzieren kann.

Zitat
Im Log erscheint nichts zum MQTT2_CLIENT oder MQTT2_DEVICE, was mir bei der Behebung helfen würde.
Ich habe eine Log-Meldung auf verbose 5 beim verschicken (aka PUBLISH) hinzugefuegt, und auch die anderen Meldungen etwas umformuliert.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 08 November 2018, 13:26:57
Du setzt den state ;) .

Da könnte $event oder Teile helfen.
Oh Mann, ich Depp. Ich muss dem MQTT2_DEVICE ja noch mitteilen, wenn sich etwas am Fenstergriff geändert hat.  :-[

D.h. ein DoIF für das eigentliche Device (wz_Fenstergriff_rechts) definieren, innerhalb dieses DoIFs den State des Device wz_Fenstergriff_rechts_MQTT füttern und dann noch mal schauen, ob es nicht doch klappt, korrekt?

Teste ich doch mal :)
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 08 November 2018, 13:58:25
Oh Mann, ich Depp. Ich muss dem MQTT2_DEVICE ja noch mitteilen, wenn sich etwas am Fenstergriff geändert hat.  :-[

D.h. ein DoIF für das eigentliche Device (wz_Fenstergriff_rechts) definieren, innerhalb dieses DoIFs den State des Device wz_Fenstergriff_rechts_MQTT füttern und dann noch mal schauen, ob es nicht doch klappt, korrekt?

Teste ich doch mal :)

Und siehe da, kaum macht man alles richtig, schon klappts! ;)

Folgendes DOIF wirkt Wunder:

define di_wz_Fenstergriff_Change DOIF \
([wz_Fenstergriff_rechts:state] eq "open") (set wz_Fenstergriff_rechts_MQTT open) DOELSEIF \
([wz_Fenstergriff_rechts:state] eq "closed") (set wz_Fenstergriff_rechts_MQTT closed) DOELSEIF \
([wz_Fenstergriff_rechts:state] eq "tilted") (set wz_Fenstergriff_rechts_MQTT tilted) DOELSEIF \
([wz_Fenstergriff_rechts:state] eq "open_from_tilted") (set wz_Fenstergriff_rechts_MQTT open_from_tilted) DOELSE \
(set wz_Fenstergriff_rechts_MQTT notdefined)

Dann klappt es mit der normalen Definition für das Attribut setList:
attr wz_Fenstergriff_rechts_MQTT set List\
  closed fhem/Wohnzimmer/Fenster_rechts/state closed\
  open fhem/Wohnzimmer/Fenster_rechts/state open\
  tilted fhem/Wohnzimmer/Fenster_rechts/state tilted\
  open_from_tilted fhem/Wohnzimmer/Fenster_rechts/state open_from_tilted\
  notdefined fhem/Wohnzimmer/Fenster_rechts/state notdefined\

Was ich leider nicht gefunden habe: Kann man das DoIf auch vereinfachen? Im Endeffekt möchte ich ja den state 1:1 wieder übergeben. Also irgendwas in der Art:
define di_wz_Fenstergriff_Change DOIF \
([wz_Fenstergriff_rechts:state] <has_changed>) (set wz_Fenstergriff_rechts_MQTT <value of wz_Fenstergriff_rechts:state>)
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Beta-User am 08 November 2018, 14:02:40
@HomeAlone
Dein ganzes setup wirkt für mich komisch. Du hast einen Sensor. Der erzeugt per autocreate ein mqtt2_device. Damit verbinde ich gedanklich einen entfernten Sensor, der auf einer anderen fhem-installation lebt und dann per (generic) bridge übermittelt wird.
Jetzt liest es sich so, als solle ein Sensorwert versendet werden. Dafür sind die mqtt2-Module noch nicht optimiert. Heute löst man sowas noch besser mit der generic_bridge; will man nicht mosquitto nutzen sondern mqtt2_Server, muss man diesen mit 00_MQTT.pm anbinden (noch...).
Ich würde daher diesen Weg empfehlen, dürfte für die Zukunft leichter zu warten sein...
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 08 November 2018, 14:20:01
Oder anders: Mit MQTT2 gibt es noch kein einfaches Verfahren, um ein MQTT2_DEVICE mit einem anderen FHEM-Geraet zu synchronisieren. Fuer MQTT (ohne 2) kann man MQTT_GENERIC_BRIDGE verwenden, hoffentlich demnaechst auch fuer MQTT2.

Das DOIF kann man vmtl auch so vereinfachen:
define di_wz_Fenstergriff_Change notify wz_Fenstergriff_rechts:state.* set wz_Fenstergriff_rechts_MQTT $EVTPART1
attr di_wz_Fenstergriff_Change addStateEvent
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 08 November 2018, 14:42:50
Bei der GenericBrigde bin ich dran. Kann leider noch nicht sagen, wann ich soweit bin. Es dürfte nicht so viel sein, die Module (mqtt und mqtt2) sind jedoch grundverschieden und ich habe gerade leider zu viele Baustellen außerhalb der IT.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 08 November 2018, 14:49:40
Ich habe Bedenken bzgl. MQTT2_CLIENT und Performance in Systemen, wo viele Messages durch die Gegend schwirren. Per default abonniert MQTT2_CLIENT alle topics. Das führt zu unnötigen Last im Netz und in der Software. Das alte mqtt Modul erweitert (und reduziert) die subscription Liste dynamisch bei Bedarf. Es wäre schön, auch für mqtt2 so etwas zu haben. Ich habe gesehen, dass man die Liste selbst vorgegeben kann. Dies ist jedoch eine fehleranfällige und unkomfortable Lösung. Klar, dass autosubscribtion so nicht funktionieren kann. Diese ist jedoch für Systeme mit guter Messagelast eh kein sinnvoll gangbarer Weg.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 08 November 2018, 14:51:53
Zitat
Das alte mqtt Modul erweitert (und reduziert) die subscription Liste dynamisch bei Bedarf. Es wäre schön, auch für mqtt2 so etwas zu haben.
Kannst du mir skizzieren, wie sowas gemacht wird?
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 08 November 2018, 14:56:06
Versuche heute Abend ausführlich zu beschreiben.
Bin gerade noch unterwegs.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Billy am 08 November 2018, 15:04:46
Zitat
Zitat
PERL WARNING: Deep recursion on subroutine
Das habe ich evtl. auch gefixt, bin aber unsicher.
Falls es nochmal auftritt, hier ein "attr mqtt2client verbose 5" hier anhaengen.

Ist mit der neuen Version gefixt! Tritt bei mir zumindest nicht mehr auf.

Zitat
Zitat
Global global UNDEFINED MQTT2_mqtt2client MQTT2_DEVICE mqtt2client
Falls man das autocreate Attribut in MQTT2_CLIENT setzt, dann sollte auch eine autocreate FHEM-Instanz definiert sein, damit die Geraete angelegt werden. Diese Meldung kommt, falls irgendein topic in der Summe der MQTT2_DEVICES nicht behandelt wurde. Alternativ verzichtet man auf autocreate.
Mit autocreate aus erledigt!

Also meine Test als user zeigen, dass man mit mqtt2client arbeiten kann.
Umsteigen werde ich erst wenn die GenericBrigde für mqtt2client läuft. ;)

Zitat
Oder anders: Mit MQTT2 gibt es noch kein einfaches Verfahren, um ein MQTT2_DEVICE mit einem anderen FHEM-Geraet zu synchronisieren. Fuer MQTT (ohne 2) kann man MQTT_GENERIC_BRIDGE verwenden, hoffentlich demnaechst auch fuer MQTT2.

Ich gebe die Hoffnung nicht auf, dass es in FHEM für MQTT mal eine durchgängige Lösung gibt wobei das Thema Funktionalität Bridge für mich
ein wesentliches Kriterium bleibt!

Gruß Billy
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 08 November 2018, 15:08:19
Zitat
das Thema Funktionalität Bridge für mich ein wesentliches Kriterium bleibt!
Kannst du mir sagen warum? Ich kann z.Zt. nur Sonderfaelle vorstellen.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 08 November 2018, 15:22:31
@HomeAlone
Dein ganzes setup wirkt für mich komisch[...]

Wollte gerade meine Antwort losschicken, da gibt es schon sechs neue Beiträge hier... die meine Antwort kürzer machen. :)

was ich final möchte, ist sichere (verschlüsselte) MQTT-Kommunikation.  Das schien mir mit den MQTT2-Modulen möglich, mit den MQTT-Modulen nicht. Daher der Ansatz wie oben von mir gegangen.
Die generic Bridge habe ich bereits getestet - sie ist super bequem und elegant zu konfigurieren - da die Devices "magisch" um MQTT-Fähigkeit erweitert werden, aber (bis zu einem der 6 Zwischenpostings von @hexenmeister ging ich davon aus, dass hier keine sichere Anbindung geplant ist.

Kurz: Der Komfort der Generic Bridge gepaart mit sicherer Kommunikation wäre das, was ich mir wünsche.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Billy am 08 November 2018, 15:25:11
Kannst du mir sagen warum? Ich kann z.Zt. nur Sonderfaelle vorstellen.

Die Bridge (Generic-Bridge) macht es mir einfacher zwischen den Instanzen Informationen auszutauschen. :)

Die ersten 3 Beiträge aus diesem Link
https://forum.fhem.de/index.php/topic,92888.0.html (https://forum.fhem.de/index.php/topic,92888.0.html)
sagen eigentlich alles. Wenn das Sonderfälle sind auch ok.

Wenn die Funktionalitäten einer Bridge wie von Martin angedacht als "core feature" für FHEM einfliesst wäre mir das auch egal.
Wichtig es ist userfreundlich!



Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 08 November 2018, 15:34:33
"core feature" wäre imho dem "separation of concerns" Prinzip zuwider.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 08 November 2018, 15:37:23
Das DOIF kann man vmtl auch so vereinfachen:
define di_wz_Fenstergriff_Change notify wz_Fenstergriff_rechts:state.* set wz_Fenstergriff_rechts_MQTT $EVTPART1
attr di_wz_Fenstergriff_Change addStateEvent

Perfekt - funktioniert! Vielen Dank!  :)
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 08 November 2018, 18:53:22
Kannst du mir sagen warum? Ich kann z.Zt. nur Sonderfaelle vorstellen.
Für mich ist das sogar einer der Hauptanwendungsfälle :D
Ich verbinden mehrere FHEM-Instanzen mit der GenericBridge über MQTT miteinander.
Einige FHEM-Instanzes sind eine Art "Hardware-Treiber", die physische Geräte MQTT-fähig machen. Als UI kann dann eine andere FHEM-Instanz oder ein beliebiger MQTT-Client (NodeRed, MQTTDash etc.) dienen.

Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 08 November 2018, 19:08:35
Kannst du mir skizzieren, wie sowas gemacht wird?

Der Ablauf ist ungefähr so:
- am Anfang ist nichts aboniert.
- MQTT-Modul bekommt mit, wenn Client-Devices angelegt oder gelöscht werden (z.B. MQTT_BRIDGE, MQTT_DEVICE, MQTT_GENERIC_BRIDGE) und wenn darin Topic-Relevante Attribute definiert oder gelöscht werden.
- Es wird nach jeder solchen Änderung eine Schnittmenge der alten und neuen Subscriptions gebildet. Für neue Subscription wird eine Subscribe-Message und für überflüssige (gelöschte) eine Unsubscribe-Message gesendet. Falls grade keine Verbindung besteht, wird lediglich die Liste gepflegt.
- Die jeweils aktuelle Liste wird ggf. bei jedem Connect / Disconnect entsprechend abgearbeitet.

Bei den MQTT_.*-Modulen melden sich die Client-Module selbst bei dem IODev, wenn sich Subscriptions ändern. Es kann natürlich auch über Event-Mechanismus die Anlage/Löschung von Geräten und Attributen überwacht werden. So macht auh die GenericBridge mit den fremden aber von ihr überwachten Geräten.

Ich hoffe, das war halbwegs verständlich. Wenn nicht, versuche ich gern alle weiteren Fragen zu beantworten.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 08 November 2018, 19:21:13
Die Verbindung wird sofort wieder aufgenommen, wenn das Netzwerk wieder steht bzw. MQTT-Server verfügbar wird.
Top!
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 08 November 2018, 23:26:41
Auto-Subscription ist mAn nur fuer sehr "ausgefallene" Konfigurationen sinnvoll.
Ich kann es implementieren, wird aber nicht die Voreinstellung sein.

Es kann nur mit Einschraenkungen funktionieren, da ich die Regexps der MQTT2_DEVICE readingList nicht immer zu den MQTT-Subscription-Matcher-Syntax konvertieren kann. Und ich haette gerne eine Beschreibung, wie ich aus den MQTT_GENERIC_BRIDGE Attributen die Liste der benoetigten Subscriptions ableiten kann.
Sag Bescheid, wenn MQTT_GENERIC_BRIDGE MQTT2_DEVICE unterstuetzt, vorher waere es sinnlos was zu implementieren.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 08 November 2018, 23:35:52
Bei den asugefallenen Konfigurationen bin ich mir nicht so sicher. MQTT nimmt immr größeren Raum in IoT. Es werden immer mehr Nachrichten versendet. Derzeit ist das für die allermeisten Nutzer sicher kein Problem, kann aber mal werden.

Welche Fälle bei den Matcher sind problematisch?

Zitat
haette gerne eine Beschreibung, wie ich aus den MQTT_GENERIC_BRIDGE Attributen die Liste der benoetigten Subscriptions ableiten kann.
Derzeit meldet sich MQTT_GENERIC_BRIDGE beim MQTT über ein sub call bei jeder Ändeurng. Hat aber auch intern im Hash eine Struktur, wie z.B.:
subscription helper array: $VAR1 = [
          '/ha/dg/wz/rollo/west1/state',
          '/ha/dg/wz/fenster/west2/+',
          '/ha/dg/wz/rollo/ost/position',
          '/ha/dg/wz/rollo/ost1/position',
          '/ha/dg/wz/rollo/west2/position',
          '/ha/dg/wz/fenster/ost1/+',
          '/ha/dg/wz/rollo/all/state',
          '/ha/dg/wz/rollo/west2/state',
          '/ha/dg/wz/rollo/west1/position',
          '/ha/og/bz/rollo/all/position',
          '/ha/dg/wz/rollo/ost2/position',
          '/ha/dg/wz/fenster/west1/+',
          '/ha/og/bz/rollo/all/state',
          '/ha/dg/wz/rollo/all/position',
          '/ha/dg/wz/rollo/west/position',
          '/ha/dg/wz/rollo/ost2/state',
          '/ha/dg/wz/rollo/ost/state',
          '/ha/dg/wz/fenster/ost2/+',
          '/ha/dg/wz/rollo/west/state',
          '/ha/dg/wz/rollo/ost1/state'
        ];

Da ich eh extra was für MQTT2 einbauen muss, kann ich mich gerne danach richten, wie du es an dieser Stelle für besser hälst.

Zitat
wenn MQTT_GENERIC_BRIDGE MQTT2_DEVICE unterstuetzt, vorher waere es sinnlos was zu implementieren
Sicher, ich melde mich, wenn ich soweit bin :)

Edit:
MQTT2_DEVICE muss MQTT_GENERIC_BRIDGE eigentlich nicht unterstützen, sondern nur IOs wie MQTT2_SERVER und MQTT2_CLIENT
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 09 November 2018, 00:00:48
Dass es zunehmend mehr Geraete MQTT verwenden, ist mir klar, aber dass die Mehrheit MQTT fuer ein ausgefallenes Routing verwenden will, das glaube ich nicht.

Zitat
Welche Fälle bei den Matcher sind problematisch?
Mit einer Definition wie
attr sonoff readingList tele/sonoff/S.* { json2nameValue($EVENT) } haette ich so meine Schwierigkeiten.
readingList in MQTT2_DEVICE ist eine Liste von "regexp mapping" Paare, wobei der Regexp topic:message matchen muss.

Zitat
Derzeit meldet sich MQTT_GENERIC_BRIDGE beim MQTT über ein sub call bei jeder Ändeurng.
Das ist unpassend.
Ich wuerde IOWrite($hash, "subscribe", "space separated list of subscriptions") vorziehen, das waere "portabel".
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 09 November 2018, 11:56:17
Für mich ist das sogar einer der Hauptanwendungsfälle :D
Ich verbinden mehrere FHEM-Instanzen mit der GenericBridge über MQTT miteinander.
Einige FHEM-Instanzes sind eine Art "Hardware-Treiber", die physische Geräte MQTT-fähig machen. Als UI kann dann eine andere FHEM-Instanz oder ein beliebiger MQTT-Client (NodeRed, MQTTDash etc.) dienen.

Das Bridging ist bei Verwendung von MQTT nicht auf fhem-Instanzen beschränkt. Ich nutzte MQTT zum Bridging zwischen fhem (nativ installiert) und Anbindung von anderen "Hardware-Treibern" die als Containern-Images realisiert sind - z.B. zigbee2mqtt und Node Red. Im Endeffekt kommt es auf dasselbe heraus, wie bei Hexenmeister: Was drunter läuft, ist egal - die Kommunikation geschieht aber standardisiert via MQTT.

Was zum Glück fehlt wäre von der Funktion her die "MQTT2_GENERIC_BRIDGE", mit der Flexibilität der MQTT_GENERIC_BRIDGE und der Möglichkeit, einen externen MQTT-Broker sicher (Authentifizierung und Verschlüsselung) einzubinden.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 09 November 2018, 12:17:28
Meine Idee ist, das Modul so zu erweitern, dass beides in einem unterstützt wird. Eine zusätzliche MQTT2_GENERIC_BRIDGE würde nur mehr Pflege bedeuten.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 09 November 2018, 12:19:52
Benutzername/Passwort sollte mit MQTT2_CLIENT funktionieren.
SSL (aka TLS) auch, habe ich aber nie getestet.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 09 November 2018, 12:57:57
Mit einer Definition wie

attr sonoff readingList tele/sonoff/S.* { json2nameValue($EVENT) }

haette ich so meine Schwierigkeiten.
readingList in MQTT2_DEVICE ist eine Liste von "regexp mapping" Paare, wobei der Regexp topic:message matchen muss.
Das sehe ich ein. Die Definition ist nicht nach MQTT-Regteln abbildbar. Dort gehen Platzhaltern nur für ganze SubTopics, nicht für Teile davon, die mit 'S' anfangen ;D GENERIC_BRIDGE und auch (glaube ich) MQTT erlauben auch nur das, was MQTT-Protokoll auch her gibt. Daher sehe ich kein Problem dabei, dies auch so zu begrenzen.

Zitat
Ich wuerde IOWrite($hash, "subscribe", "space separated list of subscriptions") vorziehen, das waere "portabel".
Ok, passt. Dann aber wahrscheinlich auch analog für 'unsubscribe'.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 09 November 2018, 13:17:46
Zitat
Ok, passt. Dann aber wahrscheinlich auch analog für 'unsubscribe'.
Einfachheithalber wuerde ich nur subscribe haben wollen, und ich wuerde bei jeder Aenderung die Verbindung zu mosquitto neu aufmachen. Spricht was dagegen / hast du vor die subscriptions oft zu aendern?
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 09 November 2018, 13:27:50
Einfachheithalber wuerde ich nur subscribe haben wollen, und ich wuerde bei jeder Aenderung die Verbindung zu mosquitto neu aufmachen. Spricht was dagegen / hast du vor die subscriptions oft zu aendern?
Jain. Streng genommen können in der Zwischenzeit ankommende Nachrichten verloren gehen.
Im normalen Betrieb ändern sich die Subscription eigentlich nicht von alleine. Nur, beim Start (während die Geräte initialisiert werden) und wenn der Benutzer die entsprechenden subscribe-Attribute ändert.
Beim Start wartet GenericBridge eh darauf, dass FHEM 'initialized' meldet, bleibt also nur die Änderung durch de Benutzer. Nicht die reine Lehre, sollte jedoch nicht das Problem sein. Man sollte nur darauf auchten, die Verbindung korrekt zu schliessen, sonst fliegen LWTs. ;D
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 09 November 2018, 13:31:48
Noch ein kleiner Wunsch:
MQTT-Modul erlaubt nicht nur LWT zu definieren, sondern auch beim Connect / Disconnect topics abzusetzen. Damit kann man gut den Status per MQTT nachverfolgen:
- gestartet und verbunden
- disconnected / sauber beendet
- abgestürzt.

So ein OnConnect/OnDisconnect Message sind natürlich auch mit Notify möglich, wären aber in Modul IMHO ganz an der rechten Stelle :)
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 09 November 2018, 13:43:09
Zitat
Nicht die reine Lehre, sollte jedoch nicht das Problem sein.
Dann werden wir nur mit subscription starten, und wenn es zu Problemen fuehrt, weitersehen.

Zitat
beim Connect / Disconnect topics abzusetzen.
Das Disconnect topic haette ich gerne im Detail erklaert bekommen. Ich dachte das nennt sich LWT.

Zitat
So ein OnConnect/OnDisconnect Message sind natürlich auch mit Notify möglich
Dann wollen wir ja das auch dabei belassen, und das Modul schoen einfach halten :)
Ich bin immer noch der Ansicht, dass sowas nur in Spezialfaellen notwendig ist, und solche Benutzer werden ein notify dazubauen koennen.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 09 November 2018, 13:47:44
Dann werden wir nur mit subscription starten, und wenn es zu Problemen fuehrt, weitersehen.
OK.

Zitat
Das Disconnect topic haette ich gerne im Detail erklaert bekommen. Ich dachte das nennt sich LWT.
LWT wird dann von Server los gelassen, wenn der Client sich ohne abzumelden verabschiedet. Normal Abmelden lösst kein LWT, bin mir da recht sicher.
EDIT: ein schnelles Googeln: http://www.steves-internet-guide.com/mqtt-last-will-example/

Zitat
Dann wollen wir ja das auch dabei belassen, und das Modul schoen einfach halten :)
Ich bin immer noch der Ansicht, dass sowas nur in Spezialfaellen notwendig ist, und solche Benutzer werden ein notify dazubauen koennen.
Kann damit gut leben, habe nur erwähnt, weil das 'alte' Modull das kann.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 09 November 2018, 14:00:52
Ähm... Vielleicht doch nicht so einfach mit dem notify. Für eine disconnected message muss ich nicht nur den event mitbekommen, sondern auch noch vor dem eigentlichen disconnect die Nachricht versenden können... 😐
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Billy am 09 November 2018, 17:31:28
Bug?
habe einen Sonoff POW mit MQTT2_DEVICE eingebunden.
Das Ergebnis war positiv, insbesondere hat mich die implementierte Json Auflösung mit { json2nameValue($EVENT) }
begeistert.
---------------
Problem!
Ich hatte dann bemerkt, dass inzwischen eine neue  MQTT2_DEVICE und MQTT2_CLIENT Version
verfügbar war --> nach update werden die Readings nicht mehr aktualisiert!
List:
Internals:
   CID        DVES_92312B
   DEF        DVES_92312B
   DEVICETOPIC MQTT2_DVES_92312B
   IODev      mqtt2client
   NAME       MQTT2_DVES_92312B
   NR         144
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-11-09 16:34:58   ENERGY_Current  0.000
     2018-11-09 16:34:58   ENERGY_Factor   0.00
     2018-11-09 16:34:58   ENERGY_Period   0
     2018-11-09 16:34:58   ENERGY_Power    0
     2018-11-09 16:34:58   ENERGY_Today    0.009
     2018-11-09 16:34:58   ENERGY_Total    0.034
     2018-11-09 16:34:58   ENERGY_Voltage  0
     2018-11-09 16:34:58   ENERGY_Yesterday 0.003
     2018-11-09 16:29:08   POWER           OFF
     2018-11-09 16:34:58   Time            2018-11-09T16:34:58
     2018-11-09 17:04:25   state           off
Attributes:
   IODev      mqtt2client
   devStateIcon devStateIcon on:black_Steckdose.on off:black_Steckdose.off
   readingList DVES_C22239:stat/sonoff_pw2/POWER:.* POWER
DVES_C22239:tele/sonoff_pw2/SENSOR:.* { json2nameValue($EVENT) }
   room       MQTT2
   setList    on cmnd/sonoff_pw2/POWER on
off cmnd/sonoff_pw2/POWER off
   stateFormat state
   webCmd     on:off

Update LOG
Update
   2018.11.09 16:33:00 1: UPD FHEM/00_MQTT2_CLIENT.pm
   2018.11.09 16:34:24 1: update finished,
Man sieht, dass nach dem update die Aktualisierung der Readings stopt.
Schalten on off geht noch.

Billy

Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Billy am 09 November 2018, 17:37:55
Lösung?

Wenn ich aus der Definition readingslist
readingList DVES_C22239:stat/sonoff_pw2/POWER:.* POWER
DVES_C22239:tele/sonoff_pw2/SENSOR:.* { json2nameValue($EVENT) }

DVES_C22239: rausnehme, geht es wieder! ;)

readingList stat/sonoff_pw2/POWER:.* POWER
tele/sonoff_pw2/SENSOR:.* { json2nameValue($EVENT) }

Ist das so gewollt?

List sieht jetzt so aus!

Internals:
   CID        DVES_92312B
   DEF        DVES_92312B
   DEVICETOPIC MQTT2_DVES_92312B
   IODev      mqtt2client
   LASTInputDev mqtt2client
   MSGCNT     20
   NAME       MQTT2_DVES_92312B
   NR         144
   STATE      OFF
   TYPE       MQTT2_DEVICE
   mqtt2client_MSGCNT 20
   mqtt2client_TIME 2018-11-09 17:40:17
   READINGS:
     2018-11-09 17:39:16   ENERGY_Current  0.000
     2018-11-09 17:39:16   ENERGY_Factor   0.00
     2018-11-09 17:35:35   ENERGY_Period   0
     2018-11-09 17:39:16   ENERGY_Power    0
     2018-11-09 17:39:16   ENERGY_Today    0.015
     2018-11-09 17:39:16   ENERGY_Total    0.040
     2018-11-09 17:39:16   ENERGY_Voltage  0
     2018-11-09 17:39:16   ENERGY_Yesterday 0.003
     2018-11-09 17:40:17   POWER           OFF
     2018-11-09 17:39:16   Time            2018-11-09T17:39:15
     2018-11-09 17:40:14   state           on
Attributes:
   IODev      mqtt2client
   devStateIcon devStateIcon ON:black_Steckdose.on OFF:black_Steckdose.off
   readingList stat/sonoff_pw2/POWER:.* POWER
tele/sonoff_pw2/SENSOR:.* { json2nameValue($EVENT) }
   room       MQTT2
   setList    on cmnd/sonoff_pw2/POWER on
off cmnd/sonoff_pw2/POWER off
   stateFormat POWER
   webCmd     on:off

Passt!
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 09 November 2018, 21:19:46
Zitat
Wenn ich aus der Definition readingslist...DVES_C22239: rausnehme, geht es wieder!
Danke fuer den Hinweis, das habe ich wohl uebersehen.
Habs gefixt: fuer Geraete, die ueber bridgeRegexp erzeugt werden, wird readingList ab sofort ohne das kuenstliche clientId angelegt.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 10 November 2018, 17:23:30
Benutzername/Passwort sollte mit MQTT2_CLIENT funktionieren.

Ja, funktioniert. Aber ich würde mir wünschen, dass es sinnvolle Meldungen im Logfile gäbe, wenn eine Verbindung wegen fehlender oder falscher user/password Daten nicht aufgebaut werden kann.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 10 November 2018, 18:50:24
Zitat
Aber ich würde mir wünschen, dass es sinnvolle Meldungen im Logfile gäbe, wenn eine Verbindung wegen fehlender oder falscher user/password Daten nicht aufgebaut werden kann.
Das war eigentlich meine Absicht, die Implementierung war aber kaputt.
Jetzt werden die "offiziellen" MQTT CONNACK Meldungen ausgegeben, mein mosquitto liefert aber auch beim falschen Passwort "bad id", obwohl ein "bad user name or password" existiert.
MQTT2_SERVER ist noch grober, und terminiert die Verbindung.

Zitat
Normal Abmelden lösst kein LWT, bin mir da recht sicher.
Mag sein, aber MQTT_CLIENT sendet kein DISCONNECT, insofern wird LWT immer ausgegeben.
Wenn jemand mit sagt, warum DISCONNECT sinnvoll ist, kann ich es gerne einbauen :)
Da mein Vorschlag mit der notify nur beim reconnect, nicht aber beim FHEM-Start funktioniert, habe ich onConnect spendiert.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 10 November 2018, 22:49:23
Korrektes disconnect ist mir deshalb wichtig, damit ich für alle meine Instanzen immer einen korrekten Status per MQTT verfügbar habe. Also online, herunter gefahren (sauber disconnected) und abnormal beendet (lwt).
Und leider brauche ich für die "normal beendet" einen onDisconnect, da mit notify sich das nicht realisieren lässt. Oder habe ich etwas übersehen?
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 11 November 2018, 17:12:37
Benutzername/Passwort sollte mit MQTT2_CLIENT funktionieren.
SSL (aka TLS) auch, habe ich aber nie getestet.

SSL habe ich heute getestet, das funktioniert tatsächlich. Für mich der einzige Grund, vielleicht tatsächlich von MQTT auf MQTT2 umzusteigen und die bestehenden Konfigurationen entsprechend anzupassen, wenn ich mal Zeit dafür habe.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 11 November 2018, 22:23:25
Das war eigentlich meine Absicht, die Implementierung war aber kaputt.
Jetzt werden die "offiziellen" MQTT CONNACK Meldungen ausgegeben, mein mosquitto liefert aber auch beim falschen Passwort "bad id", obwohl ein "bad user name or password" existiert.

mein mosquitto liefert korrekt:

2018.11.11 22:18:55 1: mqtt2_local: Connection refused, bad user name or password
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 11 November 2018, 23:33:00
Die Sache mit der automatisch aus dem deviceName ermittelten clientId, wenn diese nicht per Attribut gesetzt ist, sollte man dringend nochmal überdenken. Wenn zwei oder mehr FHEM Installationen ohne gesetzte clientId (zufällig oder beabsichtigt) den gleichen Namen für das MQTT2_CLIENT device verwenden, passieren ganz komische Dinge. Hier wäre vielleicht die Verwendung einer UUID (oder zumindest eines Teils davon) in der clientId sinnvoller und eindeutiger.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 12 November 2018, 09:42:31
Zitat
mein mosquitto liefert aber auch beim falschen Passwort "bad id"
Hat sich rausgestellt, dass ich eine alte mosquitto Version hatte, dem auch SSL unbekannt war.
Mit einer aktuelleren mosquitto funktioniert SSL auch bei mir, und bei falschen Benutzername oder Passwort liefert es "Connection refused, not authorized"

Zitat
Wenn zwei oder mehr FHEM Installationen ohne gesetzte clientId (zufällig oder beabsichtigt) den gleichen Namen für das MQTT2_CLIENT device verwenden, passieren ganz komische Dinge.
Kannst du das bitte konkretisieren?
Sowohl den Setup, wie auch die komischen Dinge.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 12 November 2018, 11:22:35
Mit einer aktuelleren mosquitto funktioniert SSL auch bei mir, und bei falschen Benutzername oder Passwort liefert es "Connection refused, not authorized"

Die Meldung "not authorized" bekomme ich nur, wenn ich gar keine Benutzerdaten definiert habe.
Die Meldung "bad user name or password" kommt bei mir, wenn die übergebenen credentials falsch sind.

Kannst du das bitte konkretisieren?
Sowohl den Setup, wie auch die komischen Dinge.

MQTT Broker = mosquitto auf einem externen Server im Internet
FHEM_1 = define mqtt2 MQTT2_CLIENT <host>:<port>
FHEM_2 = define mqtt2 MQTT2_CLIENT <host>:<port>

Dann melden sich beide FHEM Installationen mit der gleichen clientId an und schießen sich gegenseitig die Verbindung ab.



Im Moment versuche ich aber, die Ursache hierfür rauszufinden:

2018.11.12 11:14:34 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:14:35 1: host:8883 reappeared (mqtt2)
2018.11.12 11:15:44 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:15:44 1: host:8883 reappeared (mqtt2)
2018.11.12 11:15:46 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:15:46 1: host:8883 reappeared (mqtt2)
2018.11.12 11:16:55 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:16:55 1: host:8883 reappeared (mqtt2)
2018.11.12 11:18:05 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:18:05 1: host:8883 reappeared (mqtt2)
2018.11.12 11:19:20 1: host:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:19:20 1: host:8883 reappeared (mqtt2)

Das hatte ich gestern schonmal, ist dann aber wie von Zauberhand verschwunden. Aber seit heute Nacht wird mein Logfile damit geflutet.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 12 November 2018, 11:30:14
Wenn beide FHEM Instanzen hinter den gleichen IP (aus Sicht der mosquitto Server) stecken, dann habe ich eine Theorie: mosquitto vermutet ein Tasmota, der eine zweite Verbindung zum gleichen MQTT Server oeffnet. MQTT2_SERVER hat fuer solche Faelle (gleicher clientId vom gleichen IP) auch eine Ausnahme. Was spricht gegen die Umbenennung des MQTT2_CLIENTs?
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 12 November 2018, 11:39:38
Die beiden FHEM Installationen befinden sich nicht im gleichen Netzwerk bzw. hinter der gleichen IP, denn dann bräuchte ich keinen externen Broker.

Gegen die Umbenennung spricht die Tatsache, dass ich etwas über 40 FHEM Installationen habe, die in der technischen Grundkonfiguration immer identisch sind. D.h. die FHEMWEB Instanz heißt überall "web", und die MQTT2_CLIENT Instanz heißt eben immer "mqtt2". Das reduziert den Verwaltungsaufwand erheblich.

Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 12 November 2018, 11:45:27
Wie komme ich der Ursache für den Socket error auf die Spur?

1542018430: New client connected from <meineIp> as mqtt2 (c1, k30, u'udo').
1542018460: Socket error on client mqtt2, disconnecting.
1542018461: New connection from <meineIp> on port 8883.
1542018461: New client connected from <meineIp> as mqtt2 (c1, k30, u'udo').
1542018531: Socket error on client mqtt2, disconnecting.
1542018531: New connection from <meineIp> on port 8883.
1542018531: New client connected from <meineIp> as mqtt2 (c1, k30, u'udo').
1542018602: Socket error on client mqtt2, disconnecting.
1542018602: New connection from <meineIp> on port 8883.
1542018602: New client connected from <meineIp> as mqtt2 (c1, k30, u'udo').
1542018672: Socket error on client mqtt2, disconnecting.
1542018672: New connection from <meineIp> on port 8883.
1542018672: New client connected from <meineIp> as mqtt2 (c1, k30, u'udo').
1542018742: Socket error on client mqtt2, disconnecting.
1542018742: New connection from <meineIp> on port 8883.

2018.11.12 11:32:45 5: mqtt2: keepalive 30
2018.11.12 11:32:45 5: mqtt2: received PINGRESP
2018.11.12 11:33:15 5: mqtt2: keepalive 30
2018.11.12 11:33:15 5: mqtt2: received PINGRESP
2018.11.12 11:33:25 1: <host>:8883 disconnected, waiting to reappear (mqtt2)
2018.11.12 11:33:25 5: HttpUtils url=https:/<host>:8883/
2018.11.12 11:33:25 1: <host>:8883 reappeared (mqtt2)
2018.11.12 11:33:25 5: mqtt2: received CONNACK (0)(0)
2018.11.12 11:33:25 5: mqtt2: received SUBACK (0)(9)(0)
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 12 November 2018, 12:19:50
Die Verbindungsprobleme mit dem socket error treten scheinbar nur bei SSL auf.
Und interessanterweise nur in einer der beiden momentan umgestellten FHEM Installationen, die ansonsten gleich konfiguriert sind.

define mqtt2 MQTT2_CLIENT <host>:8883
attr mqtt2 SSL 1
attr mqtt2 clientId fhemHome
attr mqtt2 username udo

Ausserdem bin ich davon ausgegangen, dass die clientId (fhemHome) für die Verbindung zum mosquitto verwendet wird und nicht der FHEM-eigene deviceName (mqtt2)
Als nächstes werde ich testen, was passiert, wenn ich die devices in den beiden Installationen tatsächlich verschieden benenne - was mir aber nicht gefallen würde.

Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 12 November 2018, 12:25:29
Zitat
Ausserdem bin ich davon ausgegangen, dass die clientId (fhemHome) für die Verbindung zum mosquitto verwendet wird und nicht der FHEM-eigene deviceName (mqtt2)
Jetzt wo Du es sagst :)
Es wird $hash->{clientId} verwendet, was aus dem Attribut clientId (oder NAME, falls nicht gesetzt) abgeleitet wird, indem man alles ausser 0-9A-Za-z entfernt.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 12 November 2018, 12:34:52
Das Attribut clientId ist gesetzt auf "fhemHome" und der Wert steht auch in $hash->{clientId} korrekt drin.

Internals:
   BUF       
   DEF        <host>:8883
   DeviceName <host>:8883
   FD         9
   NAME       mqtt2_Home
   NR         222
   PARTIAL   
   SSL        1
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   fhemHome
   lastMsgTime 1542022425.73912
   nextOpenDelay 5
   Helper:
     DBLOG:
       state:
         fhemDbLog:
           TIME       1542022395.72668
           VALUE      CONNECTED
   READINGS:
     2018-11-12 12:33:15   state           opened
Attributes:
   SSL        1
   clientId   fhemHome
   group      00 System
   icon       mqtt
   room       99 System
   username   udo

Am Name der devices liegt die Ursache für die Verbindungsprobleme offenbar nicht alleine. Die reconnects treten auch mit unterschiedlichen Namen immer noch auf, allerdings seltener als vorher: immer im Abstand von ca. 70 Sekunden.

Ausserdem ist mir aufgefallen, dass MQTT2_CLIENT offenbar keine RenameFn() besitzt ;)


Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 12 November 2018, 14:53:23
Es wird $hash->{clientId} verwendet, was aus dem Attribut clientId (oder NAME, falls nicht gesetzt) abgeleitet wird, indem man alles ausser 0-9A-Za-z entfernt.

Hm... bist Du sicher? An welcher Stelle erfährt DevIo_OpenDev() denn, dass es mit $hash->{clientId} anstatt $hash->{NAME} arbeiten soll?

Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 14 November 2018, 10:12:01
Etwas praeziser:
- DevIo_OpenDev oeffnet nur die TCP-Verbindung, sie interessiert sich nicht um clientId.
- nach dem die Verbindung offen ist, wird $hash->{clientId} gesendet.
- clientId wird in define initialisiert, und in AttrFn modifiziert
- die Verbindung wird neu aufgebaut, wenn FHEM gestartet ist (und damit alle Attribute bekannt sind), oder wenn man ein "relevantes" Attribut (SSL, clientId, etc) gesetzt hat.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 14 November 2018, 11:46:39
Aber der mosquitto kennt einen Client trotzdem nur unter $hash->{NAME} und nicht mit der clientId.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 14 November 2018, 11:59:47
Schick mir bitte deine Definition.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 14 November 2018, 12:09:48
search result for device: mqtt2_Home in version: 0
--------------------------------------------------------------------------------
define mqtt2_Home MQTT2_CLIENT <host>:8883
attr mqtt2_Home SSL 1
attr mqtt2_Home clientId fhemHome
attr mqtt2_Home username udo

Auf dem mosquitto ist der client als "mqtt2_Home" bekannt.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 16 November 2018, 11:04:44
Mit dieser Konfiguration, und einen entsprechend praeparierten mosquitto.conf/password_file erhalte ich in der mosquitto Konsole:
1542362593: New client connected from 127.0.0.1 as fhemHome (c1, k30, u'udo').
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 16 November 2018, 18:04:50
tja, ob Du es glaubst oder nicht, heute erfolgen die connects bei mir auch mit der clientId.
Aber warum das Verhalten jetzt anders ist als vor zwei Tagen? Keine Ahnung.



Aber ein ungelöstes Problem besteht immer noch. Die von mir weiter oben beschriebenen Disconnects / Reconnects bei Verwendung von SSL. Schalte ich SSL ab, bleibt alles ruhig im Logfile.

Hast Du dazu eine Idee? Oder einen Hinweis, wie man der Ursache auf die Spur kommen kann?

Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 16 November 2018, 19:18:58
Weiss nicht, ob folgende sich als Idee, oder "Stochern im Dunkeln" qualifizieren:
- testweise den mosquitto ganz anderswo (Deutschland? :) ) installieren.
- statt mosquitto MQTT2_SERVER ausprobieren.
- ich habe mal die Abstaende beim Abbruch gerechnet: 31 70 71 70. Laut Spec sollte ein Server bei 1.5-fachen des keepalive-Timeouts die Verbindung zuklappen, aber 31/70 passt nicht zu dem default 30Sekunden, hat also vmtl nicht mit dem keepalive zu tun. Ich wuerde trotzdem einen Versuch mit keepalive = 5 und eins mit keepalive = 60 starten. Das meine ich nicht als Loesung (wg. Kosten), sondern als Ursachensuche.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: DasQ am 17 November 2018, 15:12:00
Danke fuer den Hinweis, das habe ich wohl uebersehen.
Habs gefixt: fuer Geraete, die ueber bridgeRegexp erzeugt werden, wird readingList ab sofort ohne das kuenstliche clientId angelegt.

weiß jetzt nicht in wie weit das auf mein Problem zutrifft, aber bei mir wird jedesmal aufs neue mein 3D-Drucker neu erzeugt. mit so einer einzigartigen ID

sinniger weise hab ich eben alle devices gelöscht die nach jedem reboot von meim drucker angelegt werden. und jetzt druckt der erstmal ...
aber ich hab noch ein paar log schnipsel da.
*******edit********
reboot von fhem und schwups da ist es wieder  ;D

defmod MQTT2_4F3E5we6bNeD4ApOmMmhM9 MQTT2_DEVICE 4F3E5we6bNeD4ApOmMmhM9
attr MQTT2_4F3E5we6bNeD4ApOmMmhM9 IODev MQTT2_Broker
attr MQTT2_4F3E5we6bNeD4ApOmMmhM9 readingList 4F3E5we6bNeD4ApOmMmhM9:octopi/temperature/bed:.* { json2nameValue($EVENT) }\
4F3E5we6bNeD4ApOmMmhM9:octopi/event/ZChange:.* { json2nameValue($EVENT) }\
4F3E5we6bNeD4ApOmMmhM9:octopi/event/CaptureStart:.* { json2nameValue($EVENT) }\
4F3E5we6bNeD4ApOmMmhM9:octopi/event/CaptureDone:.* { json2nameValue($EVENT) }
attr MQTT2_4F3E5we6bNeD4ApOmMmhM9 room MQTT2_DEVICE

setstate MQTT2_4F3E5we6bNeD4ApOmMmhM9 2018-11-17 15:20:58 _event CaptureDone
setstate MQTT2_4F3E5we6bNeD4ApOmMmhM9 2018-11-17 15:20:58 _timestamp 1542464458
setstate MQTT2_4F3E5we6bNeD4ApOmMmhM9 2018-11-17 15:20:37 actual 63.27
setstate MQTT2_4F3E5we6bNeD4ApOmMmhM9 2018-11-17 15:20:58 file /home/pi/.octoprint/timelapse/tmp/CFFFP_nose_for_glasses_20181117143246-56.jpg
setstate MQTT2_4F3E5we6bNeD4ApOmMmhM9 2018-11-17 15:20:58 new 11.2
setstate MQTT2_4F3E5we6bNeD4ApOmMmhM9 2018-11-17 15:20:58 old 11.0
setstate MQTT2_4F3E5we6bNeD4ApOmMmhM9 2018-11-17 15:20:37 target 65.0


2018-11-01_16:37:28 MQTT2_3bmkejUfjPlt69yRscQEJQ mqtt: connected
2018-11-01_16:38:11 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086691
2018-11-01_16:38:11 MQTT2_3bmkejUfjPlt69yRscQEJQ remoteAddress: 192.168.1.57
2018-11-01_16:38:11 MQTT2_3bmkejUfjPlt69yRscQEJQ _event: ClientOpened
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086694
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ _event: Connecting
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ state_id: DETECT_SERIAL
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ _event: PrinterStateChanged
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ state_string: Detecting serial port
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086694
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ state_id: OPEN_SERIAL
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086694
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ _event: PrinterStateChanged
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ state_string: Opening serial port
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ state_string: Detecting baudrate
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ _event: PrinterStateChanged
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086694
2018-11-01_16:38:14 MQTT2_3bmkejUfjPlt69yRscQEJQ state_id: DETECT_BAUDRATE
2018-11-01_16:38:27 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086707
2018-11-01_16:38:27 MQTT2_3bmkejUfjPlt69yRscQEJQ state_string: Operational
2018-11-01_16:38:27 MQTT2_3bmkejUfjPlt69yRscQEJQ _event: PrinterStateChanged
2018-11-01_16:38:27 MQTT2_3bmkejUfjPlt69yRscQEJQ state_id: OPERATIONAL
2018-11-01_16:38:28 MQTT2_3bmkejUfjPlt69yRscQEJQ _event: Connected
2018-11-01_16:38:28 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086708
2018-11-01_16:38:28 MQTT2_3bmkejUfjPlt69yRscQEJQ port: AUTO
2018-11-01_16:38:28 MQTT2_3bmkejUfjPlt69yRscQEJQ baudrate: 0
2018-11-01_16:38:30 MQTT2_3bmkejUfjPlt69yRscQEJQ data_SOURCE_CODE_URL: https://github.com/MarlinFirmware/Marlin
2018-11-01_16:38:30 MQTT2_3bmkejUfjPlt69yRscQEJQ data_UUID: cede2a2f-41a2-4748-9b12-c55c62f367ff
2018-11-01_16:38:30 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086710
2018-11-01_16:38:30 MQTT2_3bmkejUfjPlt69yRscQEJQ data_MACHINE_TYPE: 3D Drucker
2018-11-01_16:38:30 MQTT2_3bmkejUfjPlt69yRscQEJQ name: Marlin 1.1.8 (Github)
2018-11-01_16:38:30 MQTT2_3bmkejUfjPlt69yRscQEJQ data_PROTOCOL_VERSION: 1.0
2018-11-01_16:38:30 MQTT2_3bmkejUfjPlt69yRscQEJQ _event: FirmwareData
2018-11-01_16:38:30 MQTT2_3bmkejUfjPlt69yRscQEJQ data_EXTRUDER_COUNT: 1
2018-11-01_16:38:30 MQTT2_3bmkejUfjPlt69yRscQEJQ data_FIRMWARE_NAME: Marlin 1.1.8 (Github)
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ data_EXTRUDER_COUNT: 1
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ name: Marlin 1.1.8 (Github)
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ _event: FirmwareData
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ data_PROTOCOL_VERSION: 1.0
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ data_MACHINE_TYPE: 3D Drucker
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ data_FIRMWARE_NAME: Marlin 1.1.8 (Github)
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086719
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ data_UUID: cede2a2f-41a2-4748-9b12-c55c62f367ff
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ data_SOURCE_CODE_URL: https://github.com/MarlinFirmware/Marlin
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ actual: 21.0
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ target: 0.0
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086719
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086719
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ target: 0.0
2018-11-01_16:38:39 MQTT2_3bmkejUfjPlt69yRscQEJQ actual: 21.0
2018-11-01_16:39:52 MQTT2_3bmkejUfjPlt69yRscQEJQ type_1: machinecode
2018-11-01_16:39:52 MQTT2_3bmkejUfjPlt69yRscQEJQ type_2: gcode
2018-11-01_16:39:52 MQTT2_3bmkejUfjPlt69yRscQEJQ _timestamp: 1541086792
2018-11-01_16:39:52 MQTT2_3bmkejUfjPlt69yRscQEJQ path: CFFFP_Esp32_Door_18650_sockel.gcode
2018-11-01_16:39:52 MQTT2_3bmkejUfjPlt69yRscQEJQ _event: FileAdded
2018-11-01_16:39:52 MQTT2_3bmkejUfjPlt69yRscQEJQ name: CFFFP_Esp32_Door_18650_sockel.gcode

2018-11-17_12:47:55 MQTT2_4F3E5we6bNeD4ApOmMmhM9 mqtt: connected
2018-11-17_12:48:49 MQTT2_4F3E5we6bNeD4ApOmMmhM9 remoteAddress: 192.168.1.57
2018-11-17_12:48:49 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _timestamp: 1542455329
2018-11-17_12:48:49 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _event: ClientOpened
2018-11-17_12:49:33 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _event: SettingsUpdated
2018-11-17_12:49:33 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _timestamp: 1542455373
2018-11-17_12:49:33 MQTT2_4F3E5we6bNeD4ApOmMmhM9 config_hash: d0068e3d9054504bc8dd4640101f6e44
2018-11-17_12:49:33 MQTT2_4F3E5we6bNeD4ApOmMmhM9 effective_hash: 4e02b64dd1aff4233d0ba663114cece0
2018-11-17_12:49:42 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _event: SettingsUpdated
2018-11-17_12:49:42 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _timestamp: 1542455382
2018-11-17_12:49:42 MQTT2_4F3E5we6bNeD4ApOmMmhM9 config_hash: d0068e3d9054504bc8dd4640101f6e44
2018-11-17_12:49:42 MQTT2_4F3E5we6bNeD4ApOmMmhM9 effective_hash: 4e02b64dd1aff4233d0ba663114cece0
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _event: Connecting
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _timestamp: 1542455451
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 state_id: OFFLINE
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _event: PrinterStateChanged
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _timestamp: 1542455452
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 state_string: Offline
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _timestamp: 1542455452
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 state_string: Opening serial port
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 state_id: OPEN_SERIAL
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _event: PrinterStateChanged
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 state_id: DETECT_BAUDRATE
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _event: PrinterStateChanged
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _timestamp: 1542455452
2018-11-17_12:50:52 MQTT2_4F3E5we6bNeD4ApOmMmhM9 state_string: Detecting baudrate
2018-11-17_12:50:53 MQTT2_4F3E5we6bNeD4ApOmMmhM9 state_string: Operational
2018-11-17_12:50:53 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _timestamp: 1542455453
2018-11-17_12:50:53 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _event: PrinterStateChanged
2018-11-17_12:50:53 MQTT2_4F3E5we6bNeD4ApOmMmhM9 state_id: OPERATIONAL
2018-11-17_12:50:53 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _timestamp: 1542455453
2018-11-17_12:50:53 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _event: Connected
2018-11-17_12:50:53 MQTT2_4F3E5we6bNeD4ApOmMmhM9 baudrate: 0
2018-11-17_12:50:53 MQTT2_4F3E5we6bNeD4ApOmMmhM9 port: AUTO
2018-11-17_12:50:56 MQTT2_4F3E5we6bNeD4ApOmMmhM9 data_PROTOCOL_VERSION: 1.0
2018-11-17_12:50:56 MQTT2_4F3E5we6bNeD4ApOmMmhM9 data_FIRMWARE_NAME: Marlin 1.1.8 (Github)
2018-11-17_12:50:56 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _event: FirmwareData
2018-11-17_12:50:56 MQTT2_4F3E5we6bNeD4ApOmMmhM9 data_EXTRUDER_COUNT: 1
2018-11-17_12:50:56 MQTT2_4F3E5we6bNeD4ApOmMmhM9 data_MACHINE_TYPE: 3D Drucker
2018-11-17_12:50:56 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _timestamp: 1542455456
2018-11-17_12:50:56 MQTT2_4F3E5we6bNeD4ApOmMmhM9 data_UUID: cede2a2f-41a2-4748-9b12-c55c62f367ff
2018-11-17_12:50:56 MQTT2_4F3E5we6bNeD4ApOmMmhM9 data_SOURCE_CODE_URL: https://github.com/MarlinFirmware/Marlin
2018-11-17_12:50:56 MQTT2_4F3E5we6bNeD4ApOmMmhM9 name: Marlin 1.1.8 (Github)
2018-11-17_12:50:59 MQTT2_4F3E5we6bNeD4ApOmMmhM9 type_1: machinecode
2018-11-17_12:50:59 MQTT2_4F3E5we6bNeD4ApOmMmhM9 _timestamp: 1542455459

Den Drucker hab ich noch als "normales" (mosquitto ehemals) mqtt device konfiguriert und das läuft auch soweit.

defmod AnetA8 OctoPrint 192.168.1.150 80 60
attr AnetA8 apikey 8D54170EsupergeheimE853F4FB94A
attr AnetA8 event-min-interval 600
attr AnetA8 group 3Dprinter
attr AnetA8 icon it_printer
attr AnetA8 room Wohnzimmer

setstate AnetA8 Printing
setstate AnetA8 2018-11-17 14:32:31 job_estimatedPrintTime 7795.67129583261
setstate AnetA8 2018-11-17 14:32:31 job_filament_tool0_length 4063.347
setstate AnetA8 2018-11-17 14:32:31 job_filament_tool0_volume 0
setstate AnetA8 2018-11-17 15:07:32 job_file_date 1542461566
setstate AnetA8 2018-11-17 15:07:32 job_file_display CFFFP_nose_for_glasses.gcode
setstate AnetA8 2018-11-17 15:07:32 job_file_name CFFFP_nose_for_glasses.gcode
setstate AnetA8 2018-11-17 15:07:32 job_file_origin local
setstate AnetA8 2018-11-17 15:07:32 job_file_path CFFFP_nose_for_glasses.gcode
setstate AnetA8 2018-11-17 15:07:32 job_file_size 5475858
setstate AnetA8 2018-11-17 15:07:32 job_user _api
setstate AnetA8 2018-11-17 12:50:31 online true
setstate AnetA8 2018-11-17 15:07:32 progress_completion 6.65974172449322
setstate AnetA8 2018-11-17 15:07:32 progress_filepos 364678
setstate AnetA8 2018-11-17 15:07:32 progress_printTime 2085
setstate AnetA8 2018-11-17 15:07:32 progress_printTimeLeft 28783
setstate AnetA8 2018-11-17 15:07:32 progress_printTimeLeftOrigin estimate
setstate AnetA8 2018-11-17 15:07:32 state Printing
setstate AnetA8 2018-11-17 15:07:32 temperature_bed_actual 62.47
setstate AnetA8 2018-11-17 15:07:32 temperature_bed_offset 0
setstate AnetA8 2018-11-17 15:07:32 temperature_bed_target 65
setstate AnetA8 2018-11-17 15:07:32 temperature_tool0_actual 205
setstate AnetA8 2018-11-17 15:07:32 temperature_tool0_offset 0
setstate AnetA8 2018-11-17 15:07:32 temperature_tool0_target 205


Internals:
   DEF        192.168.1.150 80 60
   INTERVAL   60
   NAME       AnetA8
   NR         293
   STATE      Printing
   TYPE       OctoPrint
   READINGS:
     2018-11-17 14:32:31   job_estimatedPrintTime 7795.67129583261
     2018-11-17 14:32:31   job_filament_tool0_length 4063.347
     2018-11-17 14:32:31   job_filament_tool0_volume 0
     2018-11-17 15:11:32   job_file_date   1542461566
     2018-11-17 15:11:32   job_file_display CFFFP_nose_for_glasses.gcode
     2018-11-17 15:11:32   job_file_name   CFFFP_nose_for_glasses.gcode
     2018-11-17 15:11:32   job_file_origin local
     2018-11-17 15:11:32   job_file_path   CFFFP_nose_for_glasses.gcode
     2018-11-17 15:11:32   job_file_size   5475858
     2018-11-17 15:11:32   job_user        _api
     2018-11-17 12:50:31   online          true
     2018-11-17 15:11:32   progress_completion 7.74211091668192
     2018-11-17 15:11:32   progress_filepos 423947
     2018-11-17 15:11:32   progress_printTime 2325
     2018-11-17 15:11:32   progress_printTimeLeft 27045
     2018-11-17 15:11:32   progress_printTimeLeftOrigin estimate
     2018-11-17 15:11:32   state           Printing
     2018-11-17 15:11:32   temperature_bed_actual 66.33
     2018-11-17 15:11:32   temperature_bed_offset 0
     2018-11-17 15:11:32   temperature_bed_target 65
     2018-11-17 15:11:32   temperature_tool0_actual 204.96
     2018-11-17 15:11:32   temperature_tool0_offset 0
     2018-11-17 15:11:32   temperature_tool0_target 205
   helper:
     ADDRESS    192.168.1.150
     PORT       80
     RUNNING_REQUEST 0
     CMD_QUEUE:
Attributes:
   apikey     8D54170Esupergeheim853F4FB94A
   event-min-interval 600
   group      3Dprinter
   icon       it_printer
   room       Wohnzimmer
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 17 November 2018, 21:21:18
@DasQ: bitte noch sagen, worueber dein MQTT2_DEVICE angebunden ist.Ich vermute MQTTT2_SERVER mit aktivierten autocreate. Und dass der 3D-Drucker sich dauernd ein neues MQTT clientID ausdenkt. In diesem Fall muss man autocreate abschalten, und im readingList die clientId (samt folgenden Doppelpunkt) entfernen.Autocreate bitte explizit deaktivieren, weil ich es demnaechst per Voreinstellung aktivieren will.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: DasQ am 17 November 2018, 22:44:22
Welcher mqtt2-Server (Broker) dacht ich das geht aus meinen Logs/codesnipsel hervor  ;)
Und da ich ja gerade fleißig am FHEM-basteln und FHEM-lernen (Perl-lernen) bin, bleibt des autocreate vorerst an und ich lösch ganz einfach die neuen Drucker.
Tut ja des was es soll und mit so kleinen Schönheitsfehler kann ich im Augenblick noch gut leben.
Sollte mal (wovon ich so schnell nicht ausgeh) alles laufen und „fertig“ sein. Mach ich autocreate einfach aus.

Für mich war ja mit ein Grund auf mqtt2 umzustellen, weil ich ein fauler Hund bin und eigentlich nenn MQTT-sniffer haben wollte, der mir die devices automatisch anlegt. Ala die Raute # in mqttfx oder eben jetzt dein Broker.

Mach das ganze jetzt knapp 4 Wochen und es geht richtig was vorwärts, hierfür möcht ich mich bei dir und dem Forum bedanken. Mein erster Anlauf mit FHEM ist garantiert 3-4 Jahre her und damals bin ich auf Granit gebissen. Sorry fürs OT

Danke

Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 18 November 2018, 11:56:27
- testweise den mosquitto ganz anderswo (Deutschland? :) ) installieren.

Mal schauen, ob ich das während der heute anstehenden Bahnfahrt umsetzen kann  8)

- statt mosquitto MQTT2_SERVER ausprobieren.

Diese Variante scheidet komplett aus.

Ich wuerde trotzdem einen Versuch mit keepalive = 5 und eins mit keepalive = 60 starten.

Ok, das ist die einfachste Testvariante, die werde ich mal kurzfristig umsetzen.

Trotzdem ist mir der Zusammenhang zwischen dem keepalive und dem Parameter SSL nicht ganz klar.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 18 November 2018, 12:01:27
Offensichtlich baut jemand die Verbindung bei SSL ab. Evtl. kann das ein frueheres/spaeteres Keepalive verhindern.
Ich habe doch gesagt, ich stochere im Dunkeln; wollte nur nett sein, und Dich nicht alleine stochern lassen :)
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 18 November 2018, 12:01:51
- testweise den mosquitto ganz anderswo (Deutschland? :) ) installieren.

*lach* ich hab grade festgestellt, dass der mosquitto in Frankfurt am Main läuft und nicht in Irland :)

Was mir auch gerade noch aufgefallen ist: Die Verbindungsprobleme bei SSL treten nur in einer der angebundenen FHEM Installationen auf. Dummerweise bei meiner wichtigsten...
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 18 November 2018, 12:02:20
Ich habe doch gesagt, ich stochere im Dunkeln; wollte nur nett sein, und Dich nicht alleine stochern lassen

Ich schätze Deine Hilfe sehr.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 18 November 2018, 12:06:10
Ich stochere auch mal...

Hast Du eigentlich mal getestet, wie sich MQTT2_CLIENT verhält, wenn es in einer FHEM Installation mehrere devices dieses Typs gibt?

In der "betroffenen" FHEM Installation gibt es zwei MQTT2_CLIENT devices.

Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 18 November 2018, 12:58:31
Ich wuerde trotzdem einen Versuch mit keepalive = 5

Da scheint dann komplett was schiefzulaufen,  (Client fhemHome disconnected ist korrekt durch "shutdown restart" nach Änderung des keepalive verursacht)

1542541920: Client fhemHome disconnected.
1542541937: New connection from <ip> on port 8883.
1542541941: New client connected from <ip> as fhemHome (c1, k5, u'udo').
1542541963: Socket error on client fhemHome, disconnecting.
1542541964: New connection from <ip> on port 8883.
1542541964: New client connected from <ip> as fhemHome (c1, k5, u'udo').
1542542044: Socket error on client fhemHome, disconnecting.
1542542045: New connection from <ip> on port 8883.
1542542045: New client connected from <ip> as fhemHome (c1, k5, u'udo').
1542542062: Client fhemHome has exceeded timeout, disconnecting.
1542542062: Socket error on client fhemHome, disconnecting.
1542542071: New connection from <ip> on port 8883.
1542542071: Socket error on client <unknown>, disconnecting.
1542542072: New connection from <ip> on port 8883.
1542542072: Socket error on client <unknown>, disconnecting.
1542542072: New connection from <ip> on port 8883.
1542542076: Socket error on client <unknown>, disconnecting.
1542542077: New connection from <ip> on port 8883.
1542542081: Socket error on client <unknown>, disconnecting.
1542542082: New connection from <ip> on port 8883.
1542542086: Socket error on client <unknown>, disconnecting.
1542542089: New connection from <ip> on port 8883.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 18 November 2018, 13:07:05
Ich wuerde trotzdem einen Versuch mit keepalive = 60 starten.

1542542358: New connection from <ip> on port 8883.
1542542358: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542384: Socket error on client fhemHome, disconnecting.
1542542385: New connection from <ip> on port 8883.
1542542385: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542455: Socket error on client fhemHome, disconnecting.
1542542456: New connection from <ip> on port 8883.
1542542456: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542526: Socket error on client fhemHome, disconnecting.
1542542527: New connection from <ip> on port 8883.
1542542527: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542600: Socket error on client fhemHome, disconnecting.
1542542605: New connection from <ip> on port 8883.
1542542605: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542672: Socket error on client fhemHome, disconnecting.
1542542672: New connection from <ip> on port 8883.
1542542672: New client connected from <ip> as fhemHome (c1, k60, u'udo').
1542542742: Socket error on client fhemHome, disconnecting.

BTW: warum ist das keepalive im Code von 00_MQTT2_CLIENTE.pm hart codiert?
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 18 November 2018, 13:23:38
  • mqtt2_Home verbindet zum externen mosquitto per SSL
  • mqtt2_local verbindet zum mosquitto im lokalen Netzwerk, ohne SSL.

Wenn ich mqtt2_local aus FHEM lösche, ändert das nichts an den Verbindungsabbrüchen bei mqtt2_Home.

1542543580: New connection from ... on port 8883.
1542543580: New client connected from ... as fhemHome (c1, k30, u'udo').
1542543606: Socket error on client fhemHome, disconnecting.
1542543607: New connection from ... on port 8883.
1542543607: New client connected from ... as fhemHome (c1, k30, u'udo').
1542543677: Socket error on client fhemHome, disconnecting.
1542543679: New connection from ... on port 8883.
1542543679: New client connected from ... as fhemHome (c1, k30, u'udo').
1542543750: Socket error on client fhemHome, disconnecting.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 18 November 2018, 16:51:54
Zitat
BTW: warum ist das keepalive im Code von 00_MQTT2_CLIENTE.pm hart codiert?
Weil:
- ich nicht unendlich viel programmieren kann
- ich nicht erwartet habe, dass damit Probleme gibt
- ich auch fuer die Zukunft was lassen wollte.
Ich weiss schon, immer dieses ich,ich,ich :)
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 18 November 2018, 18:43:29
Zitat
Hast Du eigentlich mal getestet, wie sich MQTT2_CLIENT verhält, wenn es in einer FHEM Installation mehrere devices dieses Typs gibt?
Das habe ich gerade zum ersten mal versucht (per SSL zu Mosquitto und ohne SSL zu MQTT2_SERVER): ich sehe keine Besonderheiten. Uebrigens die Disconnect Abstaende sind 27 71 71 78 67, d.h. es hat nichts mit dem keepalive zu tun.

Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 19 November 2018, 22:43:22
Das ganze MQTT2 Gedöns ist für einen wirklich stabilen Einsatz einfach nicht zu gebrauchen. Die Umstellung ist nun zum zweiten Mal gescheitert. Der erste Versuch war direkt nach der Veröffentlichung der MQTT2-Module.

Seit gestern Abend flutet mir MQTT2_CLIENT nun auch das Logfile bei nicht-SSL Verbindungen, und das sogar bei einem mqtt-Server im lokalen Netzwerk. Da ich seit gestern 14:30 Uhr dienstlich unterwegs war, kann ich mit Sicherheit sagen, dass ich an der Konfiguration nichts verändert habe, was gestern ab ca. 20 Uhr zu den Verbindungsproblemen innerhalb des lokalen Netzes hätte führen können.

Vermutlich werde ich nochmal zwei Stunden Zeit investieren und meine FHEM Installationen wieder auf mqtt umstellen.

Bin gerade sehr enttäuscht :(
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 19 November 2018, 22:56:27
Zitat
Das ganze MQTT2 Gedöns ist für einen wirklich stabilen Einsatz einfach nicht zu gebrauchen.
Das ist so generisch nicht wahr, bei mir laeuft das ohne Probleme seit August.

Zitat
Bin gerade sehr enttäuscht
Mag sein, aber mit so einer Art von Beschreibung geht man lieber zum Pfarrer oder Therapeuten.
Ich brauche mehr Details, wenn ich helfen soll.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 19 November 2018, 23:45:06
Das ist so generisch nicht wahr, bei mir laeuft das ohne Probleme seit August.

Das freut mich für Dich. Aber Deine Laborbedingungen müssen ja nicht unbedingt allen real existierenden Einsatzszenarien entsprechen.

Für mich ist meine Aussage nicht nur generisch richtig, sondern auch faktisch. Inzwischen habe schon zweimal eine Menge Zeit investiert, mich mit dem Thema MQTT2 zu befassen. Ein drittes Mal werde ich das vermutlich nicht tun.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: DasQ am 20 November 2018, 10:04:14
Also hier läuft das gedöns eigentlich recht gut und man sollte so ehrlich sein, das mqtt2 noch in den Kinderschuhen steckt. Da sind Fehler aus den man lernt an der Tagesordnung.

Btw. Ich hab mir auch erst vorgestern angetan, von FHEM.cfg auf mariaDB umzustellen. Was mit einer 2 Jahre alten und inzwischen überholten Manuel hier aus dem Forum und einigen veralteten youtubevideos, sich sehr spannend gestaltete.
 Nu bin ich auf Datenbank, für log und config umgestiegen und es bleibt weiter spannend, deswegen red ich’s jetzt aber nicht gleich schlecht oder mach’s madig.

Soll jeder für sich selbst entscheiden was gut ist für ihn.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: mark79 am 20 November 2018, 18:11:25
Ich habe MQTT2 erstmal auf ein Testsystem ausprobiert, das lief und jetzt habe ich vorerst nur die Zigbee2MQTT Devices über MQTT2 angebunden. Das läuft wie ich finde schon sehr gut und ich bin dankbar dafür! :) Die neuen Module nehmen einen schon ne Menge arbeit ab und für Anfänger ist das auch leichter zu verstehen.

Den Rest wie Tasmota, ESPeasy und OpenMQTTGateway habe ich noch über das alte MQTT am laufen, weil ich noch keine Zeit und Lust hatte alles umzustellen.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 21 November 2018, 17:19:09
Ich teste den MQTT2_CLIENT seit ein paar Tagen. Vielleicht können meine Beobachtungen ja bei der Fehlersuche helfen.

Setup:

Habe MQTT2_CLIENT wie folgt definiert:
defmod mosquitto MQTT2_CLIENT reddocker:8883
attr mosquitto SSL 1
attr mosquitto clientId fhemMQTT2CLIENT
attr mosquitto icon mqtt_broker
attr mosquitto room MQTT,Zentralen
und die MQTT_GENERIC_BRIDGE so:
defmod mqttGenericBridge MQTT_GENERIC_BRIDGE mqtt room=ZWave,room=EnOcean,room=HomeMatic
attr mqttGenericBridge IODev mosquitto
attr mqttGenericBridge globalPublish *:topic={"fhempub/$device/$reading"}
attr mqttGenericBridge globalTypeExclude *:power\
*:energy
attr mqttGenericBridge icon mqtt_device
attr mqttGenericBridge room MQTT,Zentralen

Kurz OT: Kann man dem MQTT2_CLIENT auch einen Benutzernamen/Passwort mitgeben?

Was läuft genau nicht?
Vorgestern hatte ich dieselben Probleme wie heute - andauernde DISCONNECTS und CONNECTS, wobei keine Nachrichten versendet werden können. Gestern lief es lustigerweise mit denselben Settings, wenngleich auch ein paar DISCONNECTS und CONNECTS vorkamen.

Da das Verhalten mMn nicht ganz deterministisch ist (oder ich es nicht als solches erkenne ;)) hier zunächst die Logmessages vom Mosquitto, nachdem ich fhem über shutdown restart neu starte:
1542810911: New connection from 192.168.178.72 on port 8883.
1542810912: New client connected from 192.168.178.72 as fhemMQTT2CLIENT (c1, k30).
1542810912: Sending CONNACK to fhemMQTT2CLIENT (0, 0)
1542810912: Received SUBSCRIBE from fhemMQTT2CLIENT
1542810912:     # (QoS 0)
1542810912: fhemMQTT2CLIENT 0 #
1542810912: Sending SUBACK to fhemMQTT2CLIENT
1542810913: Received PINGREQ from MQTT_FX_Client
1542810913: Sending PINGRESP to MQTT_FX_Client
[...]
1542810923: Socket error on client fhemMQTT2CLIENT, disconnecting.
1542810923: New connection from 192.168.178.72 on port 8883.
1542810923: Socket error on client <unknown>, disconnecting.
1542810924: New connection from 192.168.178.72 on port 8883.
1542810924: Socket error on client <unknown>, disconnecting.
1542810924: New connection from 192.168.178.72 on port 8883.
Also zunächst wird der Client als fhemMQTT2CLIENT erkannt, nach dem reconnect bleibt er aber <unknown>.

Im Eventlog von fhem erscheinen folgende Nachrichten:
2018-11-21 15:39:25 MQTT_GENERIC_BRIDGE mqttGenericBridge transmission-state: outgoing publish sent
2018-11-21 15:39:25 MQTT_GENERIC_BRIDGE mqttGenericBridge outgoing-count: 6
2018-11-21 15:39:25 HMCCURPCPROC d_rpcBidCos_RF rpcstate: running
2018-11-21 15:39:25 MQTT_GENERIC_BRIDGE mqttGenericBridge transmission-state: outgoing publish sent
2018-11-21 15:39:25 MQTT_GENERIC_BRIDGE mqttGenericBridge outgoing-count: 7
[...]
2018-11-21 15:39:25 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:39:25 MQTT2_CLIENT mosquitto CONNECTED
2018-11-21 15:39:25 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:39:25 MQTT2_CLIENT mosquitto CONNECTED
2018-11-21 15:39:55 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:39:55 MQTT2_CLIENT mosquitto CONNECTED
Die MQTT2_CLIENT Nachrichten erscheinen ca. alle 30 Sekunden, die MQTT_GENERIC_BRIDGE messages alle 10 Minuten.

Das fhem Logfile liefert:
2018.11.21 15:39:13 3: mosquitto device opened
2018.11.21 15:39:24 1: reddocker:8883 disconnected, waiting to reappear (mosquitto)
2018.11.21 15:39:25 1: reddocker:8883 reappeared (mosquitto)
2018.11.21 15:39:25 1: reddocker:8883 disconnected, waiting to reappear (mosquitto)
2018.11.21 15:39:25 1: reddocker:8883 reappeared (mosquitto)
2018.11.21 15:39:25 1: reddocker:8883 disconnected, waiting to reappear (mosquitto)
2018.11.21 15:39:25 1: reddocker:8883 reappeared (mosquitto)
2018.11.21 15:39:55 1: reddocker:8883 disconnected, waiting to reappear (mosquitto)
2018.11.21 15:39:55 1: reddocker:8883 reappeared (mosquitto)
2018.11.21 15:40:25 1: reddocker:8883 disconnected, waiting to reappear (mosquitto)
2018.11.21 15:40:25 1: reddocker:8883 reappeared (mosquitto)

Ein Test-Publish vom MQTT2_CLIENT set mosquitto publish fhempub/TOPICVONHAND liefert:
2018-11-21 15:54:25 MQTT2_CLIENT mosquitto publish fhempub/TOPICVONHAND
2018-11-21 15:54:25 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:54:25 MQTT2_CLIENT mosquitto CONNECTED
2018-11-21 15:54:25 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:54:25 MQTT2_CLIENT mosquitto CONNECTED
2018-11-21 15:54:55 MQTT2_CLIENT mosquitto DISCONNECTED
2018-11-21 15:54:55 MQTT2_CLIENT mosquitto CONNECTED

und im Mosquitto Log:
1542812065: Socket error on client <unknown>, disconnecting.
Das gleiche Topic über den MQTT.fx Client klappt einwandfrei.
Zunächst der Connect des MQTT.fx Clients (Mosquitto log):
1542817031: New connection from 192.168.178.102 on port 8883.
1542817031: New client connected from 192.168.178.102 as MQTT_FX_Client (c1, k60).
1542817031: Sending CONNACK to MQTT_FX_Client (0, 0)

Und das das Logfile beim Versenden eines Test Topics (Mosquitto):
1542812378: Received PUBLISH from MQTT_FX_Client (d0, q0, r0, m0, 'test/blub', ... (0 bytes))
1542812378: Sending PUBLISH to mqtt_a3e42221.393db (d0, q0, r0, m0, 'test/blub', ... (0 bytes))
1542812378: Sending PUBLISH to MQTT_FX_Client (d0, q0, r0, m0, 'test/blub', ... (0 bytes))
1542812385: Received PINGREQ from WZ_Sonoff_4FachLeiste1_2

Hilft das weiter? Wenn nicht, kann ich irgendwie anders helfen?

Viele Grüße
Sascha
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Beta-User am 21 November 2018, 19:37:55
Zu OT: MQTT2_CLIENT sollte mit allowed zusammenarbeiten (das ist - neben der Unterstützung von MQTT2_DEVICE der wesentliche Vorteil gg. der alten MQTT-Implementierung).
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 22 November 2018, 11:48:35
Zu OT: MQTT2_CLIENT ist (im Gegensatz zu MQTT2_SERVER) nicht per allowed zu berechtigen, sondern per "attr mosquitto username XXX" und "set mosquitto password YYY". Hintergrund: allowed ist fuer die Server-Seite gedacht, wo man Benutzername/Passwort prueft. allowed speichert nur den Hashwert fuer das Passwort (nicht den Klartext), und man kann mehrere allowed Instanzen einem Server zuweisen, um unterschiedliche Berechtigungen (ausfuehrbare Befehle) zu realisieren, jenachdem, wer sich angemeldet hat.

Zu den Logs: vielen Dank, reicht aber noch nicht, vulgo ich habe keine Idee. Was auffaellt: mosquitto meldet Socket error 11 Sekunden nach dem Connect, da sollte keepalive noch keine Rolle spielen. Insb. macht MQTT2_CLIENT selbst die Verbindung nur beim Attribut aendern oder Shutdown/etc zu, aber dann mit einer MQTT-DISCONNECT Meldung.

Koenntest du ein Problemfall in FHEM mit "attr mosquitto verbose 5" dokumentieren? Ich wuesste gerne, ob FHEM vorher noch was senden will.
Wie sind die beiden Partner (FHEM und mosquitto) verbunden? Gibt es Firewalls, Proxy, etc dazwischen? Ich vermute z.Zt. dass irgendsowas die Verbindung zuklappt.
Gibt es auch ohne SSL Probleme?
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: betateilchen am 22 November 2018, 12:39:30
Was bin ich doch froh, dass ich nicht der einzige mit dem Verbindungsproblem bin...
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 24 November 2018, 09:51:40
Zu den Logs: vielen Dank, reicht aber noch nicht, vulgo ich habe keine Idee. Was auffaellt: mosquitto meldet Socket error 11 Sekunden nach dem Connect, da sollte keepalive noch keine Rolle spielen. Insb. macht MQTT2_CLIENT selbst die Verbindung nur beim Attribut aendern oder Shutdown/etc zu, aber dann mit einer MQTT-DISCONNECT Meldung.

Koenntest du ein Problemfall in FHEM mit "attr mosquitto verbose 5" dokumentieren? Ich wuesste gerne, ob FHEM vorher noch was senden will.
Wie sind die beiden Partner (FHEM und mosquitto) verbunden? Gibt es Firewalls, Proxy, etc dazwischen? Ich vermute z.Zt. dass irgendsowas die Verbindung zuklappt.
Gibt es auch ohne SSL Probleme?

Hallo Rudi,
Firewall und Proxy gibt es zwischen den beiden hosts nicht. Um es sauber zu dokumentieren, habe ich jetzt einmal alles MQTT-mäßige in fhem entfernt und starte eine neue Versuchsreihe, um dem Fehler (hoffentlich) systematisch auf die Spur zu kommen.

Hier die geplante Versuchsreihe (schaffe ich aber sicherlich nicht alles heute und morgen):

Grundkonfiguration

Testreihe
Ver host hostname usr pwd tls
1 local localhost no no no
2 local smartgulp2 - - -
3 local smartgulp2 yes yes no
4 local smartgulp2 yes yes yes

Ver = Version, host = der host, auf dem Mosquitto läuft, hostname = der Name mit dem ich den host in der Config zu MQTT2_CLIENT anspreche, usr = Benutzername wird verwendet, pwd = Passwort wird verwendet, tls = Attribut SSL auf 1

Die einzelnen Versuchsrehien folgen als eigenständiges Posting, sonst verliere ich selbst den Überblick. Die erste habe ich gerade durchgeführt, kommt also sofort. Kann danach erst heute Abend weitermachen.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 24 November 2018, 09:57:17
Versuch V1

Config
defmod mosquittolocal MQTT2_CLIENT localhost:1883
attr mosquittolocal room MQTT,Zentralen
attr mosquittolocal verbose 5

Verbindungsaufbau
Verbindungsaufbau fhem (logfile Mosquitto):
1543048260: New connection from 127.0.0.1 on port 1883.
1543048260: New client connected from 127.0.0.1 as mosquittolocal (c1, k30).
1543048260: Sending CONNACK to mosquittolocal (0, 0)
1543048260: Received SUBSCRIBE from mosquittolocal
1543048260:     # (QoS 0)
1543048260: mosquittolocal 0 #
1543048260: Sending SUBACK to mosquittolocal
1543048290: Received PINGREQ from mosquittolocal

Verbindungsaufbau fhem (logfile fhem):
2018.11.24 09:30:54 5: HttpUtils url=http://localhost:1883/
2018.11.24 09:31:00 5: HttpUtils url=http://localhost:1883/
2018.11.24 09:31:00 1: localhost:1883 reappeared (mosquittolocal)
2018.11.24 09:31:00 5: mosquittolocal: received CONNACK (0)(0)
2018.11.24 09:31:00 5: mosquittolocal: received SUBACK (0)(4)(0)
2018.11.24 09:31:30 5: mosquittolocal: keepalive 30
2018.11.24 09:31:30 5: mosquittolocal: received PINGRESP
2018.11.24 09:32:00 5: mosquittolocal: keepalive 30

Verbindungsaufbau MQTT.fx (logfile Mosquitto):
1543048489: New connection from 192.168.178.102 on port 1883.
1543048489: New client connected from 192.168.178.102 as MQTT_FX_Client (c1, k60).
1543048489: Sending CONNACK to MQTT_FX_Client (0, 0)
1543048500: Received PINGREQ from mosquittolocal
1543048500: Sending PINGRESP to mosquittolocal
1543048530: Received PINGREQ from mosquittolocal
1543048530: Sending PINGRESP to mosquittolocal
1543048549: Received PINGREQ from MQTT_FX_Client
1543048549: Sending PINGRESP to MQTT_FX_Client
1543048560: Received PINGREQ from mosquittolocal

Subscribe von MQTT.fx (logfile Mosquitto):
1543048682: Received SUBSCRIBE from MQTT_FX_Client
1543048682:     # (QoS 0)
1543048682: MQTT_FX_Client 0 #
1543048682: Sending SUBACK to MQTT_FX_Client

Topic publishen
publish von MQTT2_CLIENT (Logfile Mosquitto):
1543048922: Received PUBLISH from mosquittolocal (d0, q0, r0, m0, 'fhem/test', ... (0 bytes))
1543048922: Sending PUBLISH to mosquittolocal (d0, q0, r0, m0, 'fhem/test', ... (0 bytes))
1543048922: Sending PUBLISH to MQTT_FX_Client (d0, q0, r0, m0, 'fhem/test', ... (0 bytes))

publish von MQTT2_CLIENT (Logfile fhem):
2018.11.24 09:42:02 5: mosquittolocal: sending PUBLISH fhem/test
2018.11.24 09:42:02 1: PERL WARNING: Use of uninitialized value $a[0] in string eq at ./FHEM/00_MQTT2_CLIENT.pm line 238.
2018.11.24 09:42:02 5: mosquittolocal: received PUBLISH (0)(9)fhem/test
2018.11.24 09:42:02 5: mosquittolocal: dispatch mosquittolocal:fhem/test:
2018.11.24 09:42:30 5: mosquittolocal: keepalive 30

Vielleicht hilft hier das PERL WARNING ja schon weiter?

Wie gesagt, weitere Versuche erst heute Abend.

Viele Grüße
Sascha
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 24 November 2018, 17:09:43
Zitat
Vielleicht hilft hier das PERL WARNING ja schon weiter?
Ja, danke :)
Ich habe jetzt ein Problem mit gleichen Symptomen behoben.
Es trat auf, wenn man ein set (publish oder passwort) oder ein Connect-spezifisches Attribut (user, LWT, etc) nach dem FHEM-Start gesetzt hat.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 25 November 2018, 08:39:23
Ja, danke :)
Ich habe jetzt ein Problem mit gleichen Symptomen behoben.
Es trat auf, wenn man ein set (publish oder passwort) oder ein Connect-spezifisches Attribut (user, LWT, etc) nach dem FHEM-Start gesetzt hat.

OK, habe nach dem morgentlichen Update noch mal ein publish durchgeführt. Das Warning ist verschwunden:
2018.11.25 08:35:28 5: mosquittolocal: sending PUBLISH test/blub
2018.11.25 08:35:28 5: mosquittolocal: received PUBLISH (0)(9)test/blub
2018.11.25 08:35:28 5: mosquittolocal: dispatch mosquittolocal:test/blub:
2018.11.25 08:35:31 5: mosquittolocal: keepalive 30
2018.11.25 08:35:31 5: mosquittolocal: received PINGRESP

*thumbsup* :)
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 25 November 2018, 10:50:49
Durch Deine Antwort bin ich jetzt mal mutig geworden und habe mich gleich an die Tests mit Zertifikaten gemacht (Version 5).

Zwischenstand: Lokaler MQTT2_CLIENT mit SSL aktiviert, Benutzername und Passwort und eingebundener MQTT_GENERIC_BRIDGE hat jetzt (in 30 Minuten Testphase) keine disconnects mehr geliefert.
Lasse das Ganze jetzt laufen und schaue heute Abend noch mal drauf.
Wenn das ordentlich funktioniert, geh ich noch mal auf den Mosquitto auf einem anderen Rechner und schaue, wie sich das Ganze verhält.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 26 November 2018, 09:07:22
Leider kommen die connects und disconnects nach dem Update von heute wieder. Habe noch dieselbe config von gestern laufen  :(

2018.11.26 08:27:50 5: HttpUtils url=https://smartgulp2:8883/
2018.11.26 08:27:50 4: IP: smartgulp2 -> 127.0.1.1
2018.11.26 08:27:50 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.26 08:28:20 5: mosquittolocal: keepalive 30
2018.11.26 08:28:20 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.26 08:28:20 5: HttpUtils url=https://smartgulp2:8883/

Habe testweise den hostname um .local ergänzt (wird von der Fritzbox an die hostnamen im lokalen Netz angehangen) und neu gestartet.

2018.11.26 08:29:33 1: smartgulp2.local:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.26 08:29:33 5: HttpUtils url=https://smartgulp2.local:8883/
2018.11.26 08:29:33 4: IP: smartgulp2.local -> 192.168.178.72
2018.11.26 08:29:33 1: smartgulp2.local:8883 reappeared (mosquittolocal)
2018.11.26 08:29:33 1: smartgulp2.local:8883 disconnected, waiting to reappear (mosquittolocal)

Nach ein paar Minuten switched der  MQTT2_CLIENT auf ein virtuelles Netzwerk-Interface meiner Docker-Umgebung:
2018.11.26 08:33:03 1: smartgulp2.local:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.26 08:33:03 5: HttpUtils url=https://smartgulp2.local:8883/
2018.11.26 08:33:03 4: IP: smartgulp2.local -> 192.168.178.72
2018.11.26 08:33:03 1: smartgulp2.local:8883 reappeared (mosquittolocal)
2018.11.26 08:33:33 5: mosquittolocal: keepalive 30
2018.11.26 08:33:33 1: smartgulp2.local:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.26 08:33:33 5: HttpUtils url=https://smartgulp2.local:8883/
2018.11.26 08:33:33 4: IP: smartgulp2.local -> 169.254.68.85
2018.11.26 08:33:33 1: smartgulp2.local:8883 reappeared (mosquittolocal)
2018.11.26 08:34:03 5: mosquittolocal: keepalive 30

Die IP ist dem virtuellen Device veth3ea2eee zugewiesen.

Sämtliche Dienste funktionieren einwandfrei und ich kann auch ganz normal auf den Rechner zugreifen.

Ich habe dann testhalber den Rechner neu gestartet (vorher das .local aus der Konfiguration entfernt):

2018.11.26 08:47:15 1: smartgulp2.local:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.26 08:47:15 5: HttpUtils url=https://smartgulp2.local:8883/
2018.11.26 08:47:15 4: IP: smartgulp2.local -> 172.18.0.1
2018.11.26 08:47:15 1: smartgulp2.local:8883 reappeared (mosquittolocal)
2018.11.26 08:47:15 1: smartgulp2.local:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.26 08:47:15 5: HttpUtils url=https://smartgulp2.local:8883/
2018.11.26 08:47:15 4: IP: smartgulp2.local -> 172.18.0.1
2018.11.26 08:47:15 1: smartgulp2.local:8883 reappeared (mosquittolocal)
2018.11.26 08:47:37 5: mosquittolocal: keepalive 30
2018.11.26 08:47:37 1: smartgulp2.local:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.26 08:47:37 5: HttpUtils url=https://smartgulp2.local:8883/
2018.11.26 08:47:37 4: IP: smartgulp2.local -> 169.254.106.241
2018.11.26 08:47:37 1: smartgulp2.local:8883 reappeared (mosquittolocal)
2018.11.26 08:48:07 5: mosquittolocal: keepalive 30

Die 172.18.0.1 ist meine Docker-Bridge, die 169.254.106.241 wieder ein virtuelles Device ...

nach einem shutdown restart von fhem flutet der MQTT2_CLIENT das Logfile mit folgenden Nachrichten:
2018.11.26 08:53:14 1: smartgulp2.local:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.26 08:53:14 5: HttpUtils url=https://smartgulp2.local:8883/
2018.11.26 08:53:14 4: IP: smartgulp2.local -> 172.17.0.1
2018.11.26 08:53:14 1: smartgulp2.local:8883 reappeared (mosquittolocal)
2018.11.26 08:53:14 5: mosquittolocal: received CONNACK (0)(5)
2018.11.26 08:53:14 1: mosquittolocal: Connection refused, not authorized
2018.11.26 08:53:14 5: SW: e000

Wie gesagt, an meiner ursprünglichen config habeich nichts verändert!
Aufgrund dieser Meldungen habe ich das mosquittolocal device komplett gelöscht und neu angelegt. Anschließend funktioniert wieder alles (also tls verschlüsselte Verbindung, Benutzername + Passwort).
Auch nach Neustart des Docker-Dämons scheint es jetzt wieder stabil zu laufen.

Eine Idee?
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 26 November 2018, 10:05:38
Ich habe MQTT2_DEBUG jetzt umgebaut, damit bei verbose 5 alles was gesendet wird, protokolliert wird.
Waere nett, wenn du das bei mosquitto auch aktivieren koenntest, und das Log beider Seiten hier anhaengst.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 27 November 2018, 21:05:10
Ich habe MQTT2_DEBUG jetzt umgebaut, damit bei verbose 5 alles was gesendet wird, protokolliert wird.
Waere nett, wenn du das bei mosquitto auch aktivieren koenntest, und das Log beider Seiten hier anhaengst.
Hallo Rudi,
ich bin erst morgen wieder daheim und werde es dann testen.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 28 November 2018, 10:19:04
Ich habe MQTT2_DEBUG jetzt umgebaut, damit bei verbose 5 alles was gesendet wird, protokolliert wird.
Waere nett, wenn du das bei mosquitto auch aktivieren koenntest, und das Log beider Seiten hier anhaengst.

"Glücklicherweise" konnte ich heute morgen nach dem Update recht fix das Problem protokollieren:
Ich habe aktiv nichts gepublished, die Instabilität (disconnect / connect / ...) tritt also auch auf, wenn man nichts published.

Sicherheitshalber noch mal die configs:

MQTT2_CLIENT:
defmod mosquittolocal MQTT2_CLIENT smartgulp2:8883
attr mosquittolocal SSL 1
attr mosquittolocal room MQTT,Zentralen
attr mosquittolocal username fhem
attr mosquittolocal verbose 5

setstate mosquittolocal opened
setstate mosquittolocal 2018-11-28 09:14:29 state opened
wobei man in der Übersichtseite des Devices den Status immer von opened auf disconnected und dann wieder auf opened wechseln sieht.

MQTT_GENERIC_BRIDGE:
defmod mqttGenericBridge MQTT_GENERIC_BRIDGE mqtt room=ZWave,room=EnOcean,room=HomeMatic
attr mqttGenericBridge IODev mosquittolocal
attr mqttGenericBridge globalPublish *:topic={"fhempub/$device/$reading"}
attr mqttGenericBridge globalTypeExclude *:power\
*:energy
attr mqttGenericBridge icon mqtt_device
attr mqttGenericBridge room MQTT,Zentralen

setstate mqttGenericBridge 2018-11-28 08:27:15 device-count 0
setstate mqttGenericBridge 2018-11-28 08:27:14 incoming-count 0
setstate mqttGenericBridge 2018-11-28 10:07:27 outgoing-count 50
setstate mqttGenericBridge 2018-11-28 10:07:27 transmission-state outgoing publish sent
setstate mqttGenericBridge 2018-11-28 08:27:14 updated-reading-count 0
setstate mqttGenericBridge 2018-11-28 08:27:14 updated-set-count 0



Das Logfile von fhem (gekürzt um Teile von anderen Komponenten):
2018.11.28 08:20:17 5: mosquittolocal: keepalive 30
2018.11.28 08:20:17 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:20:17 5: mosquittolocal: received PINGRESP
2018.11.28 08:20:41 2: HMCCURPCPROC: [d_rpcBidCos_RF] Received no events from interface CB2001178072 for 600 seconds
2018.11.28 08:20:41 5: mosquittolocal: sending  PUBLISH 0N(0)(25)fhempub/d_rpcBidCos_RF/Noevents from interface CB2001178072 for 600 seconds
2018.11.28 08:20:41 5: mosquittolocal: received PUBLISH (0)(25)fhempub/d_rpcBidCos_RF/Noevents from interface CB2001178072 for 600 seconds
2018.11.28 08:20:41 5: mosquittolocal: dispatch mosquittolocal:fhempub/d_rpcBidCos_RF/No:events from interface CB2001178072 for 600 seconds
2018.11.28 08:20:47 5: mosquittolocal: keepalive 30
2018.11.28 08:20:47 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:20:47 5: mosquittolocal: received PINGRESP
2018.11.28 08:21:17 5: mosquittolocal: keepalive 30
2018.11.28 08:21:17 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:21:17 5: mosquittolocal: received PINGRESP
2018.11.28 08:21:47 5: mosquittolocal: keepalive 30
2018.11.28 08:21:47 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:21:47 5: mosquittolocal: received PINGRESP
2018.11.28 08:22:17 5: mosquittolocal: keepalive 30
2018.11.28 08:22:17 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:22:17 5: mosquittolocal: received PINGRESP
2018.11.28 08:22:47 5: mosquittolocal: keepalive 30
2018.11.28 08:22:47 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:22:47 5: mosquittolocal: received PINGRESP
2018.11.28 08:23:17 5: mosquittolocal: keepalive 30
2018.11.28 08:23:17 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:23:17 5: mosquittolocal: received PINGRESP
2018.11.28 08:23:47 5: mosquittolocal: keepalive 30
2018.11.28 08:23:47 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:23:47 5: mosquittolocal: received PINGRESP
2018.11.28 08:24:17 5: mosquittolocal: keepalive 30
2018.11.28 08:24:17 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:24:17 5: mosquittolocal: received PINGRESP
2018.11.28 08:24:47 5: mosquittolocal: keepalive 30
2018.11.28 08:24:47 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:24:47 5: mosquittolocal: received PINGRESP
2018.11.28 08:25:18 5: mosquittolocal: keepalive 30
2018.11.28 08:25:18 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:25:18 5: mosquittolocal: received PINGRESP
2018.11.28 08:25:48 5: mosquittolocal: keepalive 30
2018.11.28 08:25:48 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:25:48 5: mosquittolocal: received PINGRESP
2018.11.28 08:26:18 5: mosquittolocal: keepalive 30
2018.11.28 08:26:18 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:26:18 5: mosquittolocal: received PINGRESP
2018.11.28 08:26:48 5: mosquittolocal: keepalive 30
2018.11.28 08:26:48 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:26:48 5: mosquittolocal: received PINGRESP
2018.11.28 08:27:07 0: Server shutdown
2018.11.28 08:27:07 5: mosquittolocal: sending  PUBLISH 0(25)(0)(19)fhempub/d_ccu/statebusy
2018.11.28 08:27:07 1: HMCCURPCPROC: [d_rpcBidCos_RF] Stopping RPC server CB2001178072
2018.11.28 08:27:07 5: mosquittolocal: sending  PUBLISH 0"(0)(28)fhempub/d_rpcBidCos_RF/statebusy
2018.11.28 08:27:07 1: HMCCURPCPROC: [d_rpcBidCos_RF] Deregistering RPC server http://192.168.178.XX:XX/XX with ID CB2001178072 at http://192.168.178.XX:XX
2018.11.28 08:27:07 5: mosquittolocal: sending  PUBLISH 0-(0)(31)fhempub/d_rpcBidCos_RF/rpcstatederegistered
2018.11.28 08:27:07 1: HMCCURPCPROC: [d_rpcBidCos_RF] Callback for RPC server CB2001178072 deregistered
2018.11.28 08:27:07 5: mosquittolocal: sending  PUBLISH 0)(0)(31)fhempub/d_rpcBidCos_RF/rpcstatestopping
2018.11.28 08:27:07 2: HMCCURPCPROC: [d_rpcBidCos_RF] Sending signal INT to RPC server process CB2001178072 with PID=14197
2018.11.28 08:27:07 2: CCURPC: [d_rpcBidCos_RF] CB2001178072 received signal INT
2018.11.28 08:27:07 1: CCURPC: [d_rpcBidCos_RF] RPC server CB2001178072 stopped handling connections. PID=14197
2018.11.28 08:27:07 2: CCURPC: [d_rpcBidCos_RF] Number of I/O errors = 0
2018.11.28 08:27:08 2: HMCCURPCPROC: [d_rpcBidCos_RF] Found no running processes. Cleaning up ...
2018.11.28 08:27:08 1: HMCCURPCPROC: [d_rpcBidCos_RF] Housekeeping called. Cleaning up RPC environment
2018.11.28 08:27:08 5: mosquittolocal: sending  PUBLISH 0)(0)(31)fhempub/d_rpcBidCos_RF/rpcstateinactive
2018.11.28 08:27:08 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process CB2001178072 not runnning
2018.11.28 08:27:08 5: mosquittolocal: sending  PUBLISH 0 (0)(22)fhempub/d_ccu/rpcstateinactive
2018.11.28 08:27:08 1: HMCCU: [d_ccu] All RPC servers inactive
2018.11.28 08:27:08 5: mosquittolocal: sending  PUBLISH 0#(0)(17)fhempub/d_ccu/RPCserver inactive
2018.11.28 08:27:08 5: mosquittolocal: sending  PUBLISH 0(23)(0)(19)fhempub/d_ccu/stateOK
2018.11.28 08:27:08 2: HMCCURPCPROC: [d_rpcBidCos_RF] Stop I/O handling
2018.11.28 08:27:08 5: mosquittolocal: sending  PUBLISH 0 (0)(28)fhempub/d_rpcBidCos_RF/stateOK
2018.11.28 08:27:08 5: mosquittolocal: sending  PUBLISH 08(0)(26)fhempub/d_rpcBidCos_RF/RPCserver CB2001178072 stopped
2018.11.28 08:27:08 5: mosquittolocal: sending  DISCONNECT (224)(0)
2018.11.28 08:27:08 5: SW: e000
2018.11.28 08:27:09 1: Including fhem.cfg
[...]
2018.11.28 08:27:15 0: Server started with 89 defined entities (fhem.pl:17779/2018-11-18 perl:5.024001 os:linux user:fhem pid:16813)
2018.11.28 08:27:15 3: Opening mosquittolocal device smartgulp2:8883
2018.11.28 08:27:15 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:27:15 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:27:15 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
2018.11.28 08:27:15 5: mosquittolocal: sending  CONNECT (16)D(0)(6)MQIsdp(3)(194)(0)(30)(0)(14)mosquittolocal(0)(4)fhem(0) SECRETPASSWORDGEAENDERT
2018.11.28 08:27:15 3: mosquittolocal device opened
2018.11.28 08:27:15 5: mosquittolocal: received CONNACK (0)(0)
2018.11.28 08:27:15 5: mosquittolocal: sending  SUBSCRIBE (128)(6)(0)(4)(0)(1)#(0)
2018.11.28 08:27:15 5: mosquittolocal: received SUBACK (0)(4)(0)
2018.11.28 08:27:27 2: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process started for interface BidCos-RF with PID=16817
2018.11.28 08:27:27 2: CCURPC: [d_rpcBidCos_RF] Initializing RPC server CB2001178072 for interface BidCos-RF
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0)(0)(31)fhempub/d_rpcBidCos_RF/rpcstatestarting
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0"(0)(28)fhempub/d_rpcBidCos_RF/statebusy
2018.11.28 08:27:27 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server starting
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0(25)(0)(19)fhempub/d_ccu/statebusy
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0,(0)(26)fhempub/d_rpcBidCos_RF/RPCserver starting
2018.11.28 08:27:27 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:27:27 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:27:27 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:27:27 5: mosquittolocal: sending  CONNECT (16)D(0)(6)MQIsdp(3)(194)(0)(30)(0)(14)mosquittolocal(0)(4)fhem(0) SECRETPASSWORTGEAENDERT
2018.11.28 08:27:27 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:27:27 2: HMCCURPCPROC: [d_rpcBidCos_RF] Callback server CB2001178072 created. Listening on port 7411
2018.11.28 08:27:27 2: CCURPC: [d_rpcBidCos_RF] CB2001178072 accepting connections. PID=16817
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0((0)(31)fhempub/d_rpcBidCos_RF/rpcstateworking
2018.11.28 08:27:27 2: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB2001178072 enters server loop
2018.11.28 08:27:27 2: HMCCURPCPROC: [d_rpcBidCos_RF] Registering callback http://192.168.178.XX:XX/XX of type A with ID CB2001178072 at http://192.168.178.XX:XX
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0((0)(31)fhempub/d_rpcBidCos_RF/rpcstaterunning
2018.11.28 08:27:27 1: HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB2001178072 running
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0(31)(0)(22)fhempub/d_ccu/rpcstaterunning
2018.11.28 08:27:27 1: HMCCU: [d_ccu] All RPC servers running
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0"(0)(17)fhempub/d_ccu/RPCserver running
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0:(0)3fhempub/HM_wz_Rolladentaster/0.DEVICE_IN_BOOTLOADERfalse
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0((0)$fhempub/HM_wz_Rolladentaster/batteryok
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0-(0)*fhempub/HM_wz_Rolladentaster/0.RSSI_DEVICE1
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 04(0)-fhempub/HM_wz_Rolladentaster/0.STICKY_UNREACHfalse
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0+(0)&fhempub/HM_wz_Rolladentaster/0.AES_KEYoff
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 04(0)-fhempub/HM_wz_Rolladentaster/0.UPDATE_PENDINGfalse
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0,(0)%fhempub/HM_wz_Rolladentaster/activityalive
2018.11.28 08:27:27 2: CCURPC: [d_rpcBidCos_RF] CB2001178072 NewDevice received 68 device and channel specifications
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 04(0)-fhempub/HM_wz_Rolladentaster/0.CONFIG_PENDINGfalse
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0+(0)(fhempub/HM_wz_Rolladentaster/0.RSSI_PEER1
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 01(0)$fhempub/HM_wz_Rolladentaster/hmstateInitialized
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 01(0)*fhempub/HM_RCV_50_BidCoS_RF/0.INSTALL_MODEfalse
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 00(0)#fhempub/HM_RCV_50_BidCoS_RF/hmstateInitialized
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 09(0)2fhempub/HM_sz_Zentraltaster/0.DEVICE_IN_BOOTLOADERfalse
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 03(0),fhempub/HM_sz_Zentraltaster/0.STICKY_UNREACHfalse
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0,(0))fhempub/HM_sz_Zentraltaster/0.RSSI_DEVICE1
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0'(0)#fhempub/HM_sz_Zentraltaster/batteryok
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 03(0),fhempub/HM_sz_Zentraltaster/0.CONFIG_PENDINGfalse
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0*(0)%fhempub/HM_sz_Zentraltaster/0.AES_KEYoff
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 03(0),fhempub/HM_sz_Zentraltaster/0.UPDATE_PENDINGfalse
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0+(0)$fhempub/HM_sz_Zentraltaster/activityalive
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0*(0)'fhempub/HM_sz_Zentraltaster/0.RSSI_PEER1
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 00(0)#fhempub/HM_sz_Zentraltaster/hmstateInitialized
2018.11.28 08:27:27 2: HMCCU: [d_ccu] Updated devices. Success=3 Failed=0
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0(23)(0)(19)fhempub/d_ccu/stateOK
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 0 (0)(28)fhempub/d_rpcBidCos_RF/stateOK
2018.11.28 08:27:27 5: mosquittolocal: sending  PUBLISH 08(0)(26)fhempub/d_rpcBidCos_RF/RPCserver CB2001178072 running
2018.11.28 08:27:27 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:27:27 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:27:27 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:27:27 5: mosquittolocal: sending  SUBSCRIBE (128)(6)(0)(4)(0)(1)#(0)
2018.11.28 08:27:27 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:27:27 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:27:27 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:27:27 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:27:27 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:27:57 5: mosquittolocal: keepalive 30
2018.11.28 08:27:57 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:27:57 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:27:57 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:27:57 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:27:57 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:28:27 5: mosquittolocal: keepalive 30
2018.11.28 08:28:27 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:28:27 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:28:27 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:28:27 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:28:27 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:28:50 5: mosquittolocal: sending  PUBLISH 0-(0)(22)fhempub/ku_Rollade/CMDZW_APPLICATION_UPDATE
2018.11.28 08:28:50 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:28:50 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:28:50 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:28:50 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:28:56 5: mosquittolocal: sending  PUBLISH 0-(0)(22)fhempub/ku_Rollade/CMDZW_APPLICATION_UPDATE
2018.11.28 08:28:56 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:28:56 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:28:56 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:28:56 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:28:57 5: mosquittolocal: keepalive 30
2018.11.28 08:28:57 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:28:57 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:28:57 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:28:57 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:28:57 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:29:27 5: mosquittolocal: keepalive 30
2018.11.28 08:29:27 5: mosquittolocal: sending  PINGREQ (192)(0)
2018.11.28 08:29:27 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:29:27 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:29:27 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:29:27 1: smartgulp2:8883 reappeared (mosquittolocal)



Das Event-Log von fhem:
2018.11.28 08:20:17 5 : mosquittolocal: keepalive 30
2018.11.28 08:20:17 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:20:17 5 : mosquittolocal: received PINGRESP
2018.11.28 08:20:41 2 : HMCCURPCPROC: [d_rpcBidCos_RF] Received no events from interface CB2001178072 for 600 seconds
2018.11.28 08:20:41 5 : mosquittolocal: sending PUBLISH 0N(0)(25)fhempub/d_rpcBidCos_RF/Noevents from interface CB2001178072 for 600 seconds
2018.11.28 08:20:41 5 : mosquittolocal: received PUBLISH (0)(25)fhempub/d_rpcBidCos_RF/Noevents from interface CB2001178072 for 600 seconds
2018.11.28 08:20:41 5 : mosquittolocal: dispatch mosquittolocal:fhempub/d_rpcBidCos_RF/No:events from interface CB2001178072 for 600 seconds
2018.11.28 08:20:47 5 : mosquittolocal: keepalive 30
2018.11.28 08:20:47 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:20:47 5 : mosquittolocal: received PINGRESP
2018.11.28 08:21:17 5 : mosquittolocal: keepalive 30
2018.11.28 08:21:17 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:21:17 5 : mosquittolocal: received PINGRESP
2018.11.28 08:21:47 5 : mosquittolocal: keepalive 30
2018.11.28 08:21:47 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:21:47 5 : mosquittolocal: received PINGRESP
2018.11.28 08:22:17 5 : mosquittolocal: keepalive 30
2018.11.28 08:22:17 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:22:17 5 : mosquittolocal: received PINGRESP
2018.11.28 08:22:47 5 : mosquittolocal: keepalive 30
2018.11.28 08:22:47 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:22:47 5 : mosquittolocal: received PINGRESP
2018.11.28 08:23:17 5 : mosquittolocal: keepalive 30
2018.11.28 08:23:17 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:23:17 5 : mosquittolocal: received PINGRESP
2018.11.28 08:23:47 5 : mosquittolocal: keepalive 30
2018.11.28 08:23:47 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:23:47 5 : mosquittolocal: received PINGRESP
2018.11.28 08:24:17 5 : mosquittolocal: keepalive 30
2018.11.28 08:24:17 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:24:17 5 : mosquittolocal: received PINGRESP
2018.11.28 08:24:47 5 : mosquittolocal: keepalive 30
2018.11.28 08:24:47 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:24:47 5 : mosquittolocal: received PINGRESP
2018.11.28 08:25:18 5 : mosquittolocal: keepalive 30
2018.11.28 08:25:18 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:25:18 5 : mosquittolocal: received PINGRESP
2018.11.28 08:25:48 5 : mosquittolocal: keepalive 30
2018.11.28 08:25:48 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:25:48 5 : mosquittolocal: received PINGRESP
2018.11.28 08:26:18 5 : mosquittolocal: keepalive 30
2018.11.28 08:26:18 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:26:18 5 : mosquittolocal: received PINGRESP
2018.11.28 08:26:48 5 : mosquittolocal: keepalive 30
2018.11.28 08:26:48 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:26:48 5 : mosquittolocal: received PINGRESP
2018.11.28 08:27:15 5 : mosquittolocal: received SUBACK (0)(4)(0)
2018.11.28 08:27:27 2 : HMCCURPCPROC: [d_rpcBidCos_RF] RPC server process started for interface BidCos-RF with PID=16817
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0)(0)(31)fhempub/d_rpcBidCos_RF/rpcstatestarting
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0"(0)(28)fhempub/d_rpcBidCos_RF/statebusy
2018.11.28 08:27:27 1 : HMCCURPCPROC: [d_rpcBidCos_RF] RPC server starting
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0(25)(0)(19)fhempub/d_ccu/statebusy
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0,(0)(26)fhempub/d_rpcBidCos_RF/RPCserver starting
2018.11.28 08:27:27 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:27:27 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:27:27 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:27:27 5 : mosquittolocal: sending CONNECT (16)D(0)(6)MQIsdp(3)(194)(0)(30)(0)(14)mosquittolocal(0)(4)fhem(0) SECRETPASSWORDGEAENDERT
2018.11.28 08:27:27 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0((0)(31)fhempub/d_rpcBidCos_RF/rpcstateworking
2018.11.28 08:27:27 2 : HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB2001178072 enters server loop
2018.11.28 08:27:27 2 : HMCCURPCPROC: [d_rpcBidCos_RF] Registering callback http://192.168.178.XX:XX/XX of type A with ID CB2001178072 at http://192.168.178.XX:XX
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0((0)(31)fhempub/d_rpcBidCos_RF/rpcstaterunning
2018.11.28 08:27:27 1 : HMCCURPCPROC: [d_rpcBidCos_RF] RPC server CB2001178072 running
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0(31)(0)(22)fhempub/d_ccu/rpcstaterunning
2018.11.28 08:27:27 1 : HMCCU: [d_ccu] All RPC servers running
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0"(0)(17)fhempub/d_ccu/RPCserver running
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0:(0)3fhempub/HM_wz_Rolladentaster/0.DEVICE_IN_BOOTLOADERfalse
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0((0)$fhempub/HM_wz_Rolladentaster/batteryok
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0-(0)*fhempub/HM_wz_Rolladentaster/0.RSSI_DEVICE1
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 04(0)-fhempub/HM_wz_Rolladentaster/0.STICKY_UNREACHfalse
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0+(0)&fhempub/HM_wz_Rolladentaster/0.AES_KEYoff
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 04(0)-fhempub/HM_wz_Rolladentaster/0.UPDATE_PENDINGfalse
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0,(0)%fhempub/HM_wz_Rolladentaster/activityalive
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 04(0)-fhempub/HM_wz_Rolladentaster/0.CONFIG_PENDINGfalse
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0+(0)(fhempub/HM_wz_Rolladentaster/0.RSSI_PEER1
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 01(0)$fhempub/HM_wz_Rolladentaster/hmstateInitialized
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 01(0)*fhempub/HM_RCV_50_BidCoS_RF/0.INSTALL_MODEfalse
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 00(0)#fhempub/HM_RCV_50_BidCoS_RF/hmstateInitialized
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 09(0)2fhempub/HM_sz_Zentraltaster/0.DEVICE_IN_BOOTLOADERfalse
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 03(0),fhempub/HM_sz_Zentraltaster/0.STICKY_UNREACHfalse
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0,(0))fhempub/HM_sz_Zentraltaster/0.RSSI_DEVICE1
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0'(0)#fhempub/HM_sz_Zentraltaster/batteryok
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 03(0),fhempub/HM_sz_Zentraltaster/0.CONFIG_PENDINGfalse
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0*(0)%fhempub/HM_sz_Zentraltaster/0.AES_KEYoff
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 03(0),fhempub/HM_sz_Zentraltaster/0.UPDATE_PENDINGfalse
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0+(0)$fhempub/HM_sz_Zentraltaster/activityalive
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0*(0)'fhempub/HM_sz_Zentraltaster/0.RSSI_PEER1
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 00(0)#fhempub/HM_sz_Zentraltaster/hmstateInitialized
2018.11.28 08:27:27 2 : HMCCU: [d_ccu] Updated devices. Success=3 Failed=0
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0(23)(0)(19)fhempub/d_ccu/stateOK
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 0 (0)(28)fhempub/d_rpcBidCos_RF/stateOK
2018.11.28 08:27:27 5 : mosquittolocal: sending PUBLISH 08(0)(26)fhempub/d_rpcBidCos_RF/RPCserver CB2001178072 running
2018.11.28 08:27:27 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:27:27 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:27:27 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:27:27 5 : mosquittolocal: sending SUBSCRIBE (128)(6)(0)(4)(0)(1)#(0)
2018.11.28 08:27:27 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:27:27 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:27:27 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:27:27 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:27:27 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:27:57 5 : mosquittolocal: keepalive 30
2018.11.28 08:27:57 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:27:57 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:27:57 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:27:57 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:27:57 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:28:27 5 : mosquittolocal: keepalive 30
2018.11.28 08:28:27 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:28:27 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:28:27 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:28:27 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:28:27 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:28:50 5 : mosquittolocal: sending PUBLISH 0-(0)(22)fhempub/ku_Rollade/CMDZW_APPLICATION_UPDATE
2018.11.28 08:28:50 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:28:50 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:28:50 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:28:50 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:28:56 5 : mosquittolocal: sending PUBLISH 0-(0)(22)fhempub/ku_Rollade/CMDZW_APPLICATION_UPDATE
2018.11.28 08:28:56 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:28:56 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:28:56 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:28:56 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:28:57 5 : mosquittolocal: keepalive 30
2018.11.28 08:28:57 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:28:57 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 08:28:57 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 08:28:57 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 08:28:57 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 08:29:27 5 : mosquittolocal: keepalive 30
2018.11.28 08:29:27 5 : mosquittolocal: sending PINGREQ (192)(0)
2018.11.28 08:29:27 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)

Für den korrekten Abschnitt des Mosquitto-Logfiles noch den Timestamp berechnet: (aus Bequemlichkeit hier, damit ich den Wert gleich beim Fensterwechsel besser finde. :) )
pi@smartgulp2:~ $ date -d '2018-11-28 08:20:17' +%s
1543389617
pi@smartgulp2:~ $ date -d '2018-11-28 08:29:27' +%s
1543390167

Das zugehörige Logfile von Mosquitto (Logging ist auf max mittels: log_type all):
1543389551: Received PINGREQ from mqtt_10d8a6c9.f36389
1543389551: Sending PINGRESP to mqtt_10d8a6c9.f36389
1543389557: Received PINGREQ from mosquittolocal
1543389557: Sending PINGRESP to mosquittolocal
1543389562: Received PINGREQ from MQTT_FX_Client
1543389562: Sending PINGRESP to MQTT_FX_Client
1543389587: Received PINGREQ from mosquittolocal
1543389587: Sending PINGRESP to mosquittolocal
1543389611: Received PINGREQ from mqtt_10d8a6c9.f36389
1543389611: Sending PINGRESP to mqtt_10d8a6c9.f36389
1543390197: Socket error on client <unknown>, disconnecting.
1543390197: New connection from 127.0.0.1 on port 8883.
1543390212: Received PINGREQ from mqtt_10d8a6c9.f36389
1543390212: Sending PINGRESP to mqtt_10d8a6c9.f36389
1543390222: Received PINGREQ from MQTT_FX_Client
1543390222: Sending PINGRESP to MQTT_FX_Client
1543390227: Socket error on client <unknown>, disconnecting.
1543390227: New connection from 127.0.0.1 on port 8883.
1543390257: Socket error on client <unknown>, disconnecting.
1543390257: New connection from 127.0.0.1 on port 8883.
1543390272: Received PINGREQ from mqtt_10d8a6c9.f36389
1543390272: Sending PINGRESP to mqtt_10d8a6c9.f36389
1543390282: Received PINGREQ from MQTT_FX_Client
1543390282: Sending PINGRESP to MQTT_FX_Client
1543390287: Socket error on client <unknown>, disconnecting.
1543390287: New connection from 127.0.0.1 on port 8883.
1543390317: Socket error on client <unknown>, disconnecting.

Nach Neustart des Mosquitto Servers ('2018-11-28 09:43:59' / LTS: 1543394639 kommen folgenden Nachrichten:

fhem Logfile:
2018.11.28 09:43:30 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 09:43:59 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 09:43:59 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:43:59 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:43:59 4: HttpUtils: smartgulp2: Connection refused
2018.11.28 09:44:04 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:44:04 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:44:05 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 09:45:34 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 09:45:34 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:45:34 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:45:34 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 09:47:04 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 09:47:04 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:47:04 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:47:04 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 09:47:27 2: HMCCURPCPROC: [d_rpcBidCos_RF] Received no events from interface CB2001178072 for 600 seconds
2018.11.28 09:47:27 5: mosquittolocal: sending  PUBLISH 0N(0)(25)fhempub/d_rpcBidCos_RF/Noevents from interface CB2001178072 for 600 seconds
2018.11.28 09:47:27 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 09:47:27 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:47:27 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:47:27 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 09:48:56 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 09:48:56 5: HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:48:56 4: IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:48:56 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 09:50:26 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 09:50:26 5: HttpUtils url=https://smartgulp2:8883/

fhem Eventlog:
2018.11.28 09:43:30 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 09:43:59 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 09:43:59 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:43:59 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:43:59 4 : HttpUtils: smartgulp2: Connection refused
2018.11.28 09:44:04 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:44:04 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:44:05 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 09:45:34 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 09:45:34 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:45:34 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:45:34 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 09:47:04 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 09:47:04 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:47:04 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:47:04 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 09:47:27 2 : HMCCURPCPROC: [d_rpcBidCos_RF] Received no events from interface CB2001178072 for 600 seconds
2018.11.28 09:47:27 5 : mosquittolocal: sending PUBLISH 0N(0)(25)fhempub/d_rpcBidCos_RF/Noevents from interface CB2001178072 for 600 seconds
2018.11.28 09:47:27 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 09:47:27 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:47:27 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:47:27 1 : smartgulp2:8883 reappeared (mosquittolocal)
2018.11.28 09:48:56 1 : smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.11.28 09:48:56 5 : HttpUtils url=https://smartgulp2:8883/
2018.11.28 09:48:56 4 : IP: smartgulp2 -> 127.0.1.1
2018.11.28 09:48:56 1 : smartgulp2:8883 reappeared (mosquittolocal)


Mosquitto:
1543394639: mosquitto version 1.4.10 (build date Wed, 17 Oct 2018 19:03:03 +0200) starting
1543394639: Config loaded from /etc/mosquitto/mosquitto.conf.
1543394639: Opening ipv4 listen socket on port 1883.
1543394639: Opening ipv6 listen socket on port 1883.
1543394639: Opening ipv4 listen socket on port 8883.
1543394639: Opening ipv6 listen socket on port 8883.
1543394645: New connection from 127.0.0.1 on port 8883.
1543394654: New connection from 172.18.0.2 on port 8883.
1543394654: New client connected from 172.18.0.2 as mqtt_10d8a6c9.f36389 (c1, k60, u'fhem').
1543394654: Sending CONNACK to mqtt_10d8a6c9.f36389 (0, 0)
1543394654: Received SUBSCRIBE from mqtt_10d8a6c9.f36389
1543394654:     fhempub/ku_Fenstergriff/state (QoS 2)
1543394654: mqtt_10d8a6c9.f36389 2 fhempub/ku_Fenstergriff/state
1543394654:     fhempub/az_Licht/# (QoS 2)
1543394654: mqtt_10d8a6c9.f36389 2 fhempub/az_Licht/#
1543394654: Sending SUBACK to mqtt_10d8a6c9.f36389
1543394714: Received PINGREQ from mqtt_10d8a6c9.f36389
1543394714: Sending PINGRESP to mqtt_10d8a6c9.f36389
1543394734: Client <unknown> has exceeded timeout, disconnecting.


Zum Vergleich auch noch mal das Connecten des MQTT.fx clients und Subscribe auf das Topic "#":
Mosquitto-Log:
1543394799: New connection from 192.168.178.102 on port 8883.
1543394799: New client connected from 192.168.178.102 as MQTT_FX_Client (c1, k60, u'fhem').
1543394799: Sending CONNACK to MQTT_FX_Client (0, 0)
1543394807: Received SUBSCRIBE from MQTT_FX_Client
1543394807:     # (QoS 0)
1543394807: MQTT_FX_Client 0 #
1543394807: Sending SUBACK to MQTT_FX_Client

Ich hoffe, das hilft bei der Fehlersuche. Schon mal vielen, vielen Dank im Voraus für Deinen Einsatz!
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 28 November 2018, 13:02:30
Ich kann Einiges nicht erklaeren:
- Wieso bricht die Verbindung um 08:27:27 ab.
- Warum wird nach dem Verbindungsaufbau sofort ein PINGREQ gesendet? Die erste Meldung nach IP:... muss "sending CONNECT" sein, fuer alles Andere is der Verbindungsabbruch der anderen Seite korrekt. Uebrigens bei mir kommt nach IP erst CONNECT+SUBSCRIBE, und PINGREQ nach 30 Sekunden.
- Wieso wird der erneute Verbindungsaufbau nur einmal alle 30 Sekunden versucht? Bei mir wird es einmal sofort, und dann alle 5 Sekunden versucht. Ist FHEM aktuell bzw. ungepatcht?
- In den mosquitto-log finde ich keine passenden Meldungen (hoffentlich sind die beiden Zeitsynchronisiert):
1543390047 == 2018.11.28 08:27:27 => Erster Abbruch in FHEM, keine Zeile in mosquitto
1543390136 == 2018.11.28 08:28:56 => Abbruch in FHEM, keine Zeile in mosquitto
1543390197 == 2018.11.28 08:29:57 => Fehler in mosquitto, FHEM-Log endet vorher.
Ich habe die Vermutung, dass der mosquitto log nicht weiterhilft, weil nur "Socket error" meldet, egal warum.

Ich habe jetzt eine extra Pruefung eingebaut, damit Nachrichten (wie PINGREQ) nur dann gesendet werden, falls die Verbindung mit CONNECT/SUBSCRIBE komplett aufgebaut ist. Vorher werden alle anderen Nachrichten ignoriert und auf verbose 5 als Solches protokolliert. Ist mehr Symptom behandeln, als Ursache fixen, aber vlt. kommen wir damit weiter. Waere nett, wenn Du es testen koenntest.

Weiterhin gibt es ein keepaliveTimeout Attribut, die Voreinstellung ist (wie bisher) 30 Sekunden.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 28 November 2018, 15:18:45
Ich kann Einiges nicht erklaeren:
- Wieso bricht die Verbindung um 08:27:27 ab.

Der Absturz scheint zu erfolgen, nachdem versucht wird von meinen HomeMatic 6fach Tastern die Statusinfos zu publishen. Vielleicht ein Überlauf von einem Puffer, da alles in derselben Sekunde zu passieren scheint? Macht es Sinn, dass ich testhalber die HM-Geräte aus dem fhem-Publishing der MQTT_GENERIC_BRIDGE rausnehmen?

- Warum wird nach dem Verbindungsaufbau sofort ein PINGREQ gesendet? Die erste Meldung nach IP:... muss "sending CONNECT" sein, fuer alles Andere is der Verbindungsabbruch der anderen Seite korrekt. Uebrigens bei mir kommt nach IP erst CONNECT+SUBSCRIBE, und PINGREQ nach 30 Sekunden.

Kann ich leider auch nicht erklären.

- Wieso wird der erneute Verbindungsaufbau nur einmal alle 30 Sekunden versucht? Bei mir wird es einmal sofort, und dann alle 5 Sekunden versucht. Ist FHEM aktuell bzw. ungepatcht?


FHEM ist aktuell und ungepatched.

Hier die Ausgabe von version:
Latest Revision: 17863

File                      Rev   Last Change

fhem.pl                   17779 2018-11-18 17:49:14Z rudolfkoenig
98_autocreate.pm          17684 2018-11-05 15:52:53Z rudolfkoenig
10_EnOcean.pm             17796 2018-11-20 05:31:33Z klaus.schauer
91_eventTypes.pm          14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm             17750 2018-11-15 11:27:54Z rudolfkoenig
92_FileLog.pm             17181 2018-08-20 17:23:26Z rudolfkoenig
88_HMCCU.pm               17824 2018-11-23 08:31:13Z zap
88_HMCCUDEV.pm            17672 2018-11-04 12:40:18Z zap
88_HMCCURPCPROC.pm        17824 2018-11-23 08:31:13Z zap
00_MQTT.pm                17362 2018-09-17 12:57:29Z hexenmeister
00_MQTT2_CLIENT.pm        17848 2018-11-26 09:04:02Z rudolfkoenig
10_MQTT_GENERIC_BRIDGE.pm 17841 2018-11-25 15:06:01Z hexenmeister
91_notify.pm              17225 2018-08-29 12:34:29Z rudolfkoenig
98_structure.pm           16865 2018-06-14 07:21:25Z rudolfkoenig
99_SUNRISE_EL.pm          16632 2018-04-17 19:00:21Z rudolfkoenig
98_SVG.pm                 17779 2018-11-18 17:49:14Z rudolfkoenig
00_TCM.pm                 17688 2018-11-05 18:01:41Z klaus.schauer
98_telnet.pm              17529 2018-10-14 12:57:06Z rudolfkoenig
99_Utils.pm               15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm             15140 2017-09-26 09:20:09Z markusbloch
10_ZWave.pm               17186 2018-08-20 20:10:55Z rudolfkoenig
00_ZWDongle.pm            17186 2018-08-20 20:10:55Z rudolfkoenig

AttrTemplate.pm           17782 2018-11-18 20:18:15Z rudolfkoenig
Blocking.pm               17553 2018-10-17 15:56:35Z rudolfkoenig
DevIo.pm                  17702 2018-11-07 19:02:28Z rudolfkoenig
GPUtils.pm                 6653 2014-10-02 11:59:37Z ntruchsess
HMCCUConf.pm              17824 2018-11-23 08:31:13Z zap
HttpUtils.pm              17831 2018-11-24 15:09:17Z rudolfkoenig
RTypes.pm                 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm          17774 2018-11-18 08:13:48Z rudolfkoenig
SubProcess.pm             14334 2017-05-20 23:11:06Z neubert
TcpServerUtils.pm         17529 2018-10-14 12:57:06Z rudolfkoenig
ZWLib.pm                  17186 2018-08-20 20:10:55Z rudolfkoenig

fhemweb.js                 17826 2018-11-23 10:40:33Z rudolfkoenig

- In den mosquitto-log finde ich keine passenden Meldungen (hoffentlich sind die beiden Zeitsynchronisiert):

Die beiden laufen ja aktuell auf demselben System, aber auch dann: auf allen meinen raspis läuft timesyncd (seit Jessy Ersatz zu ntpd):

pi@smartgulp2:~ $ timedatectl
      Local time: Wed 2018-11-28 15:07:30 CET
  Universal time: Wed 2018-11-28 14:07:30 UTC
        RTC time: n/a
       Time zone: Europe/Berlin (CET, +0100)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

1543390047 == 2018.11.28 08:27:27 => Erster Abbruch in FHEM, keine Zeile in mosquitto
1543390136 == 2018.11.28 08:28:56 => Abbruch in FHEM, keine Zeile in mosquitto
1543390197 == 2018.11.28 08:29:57 => Fehler in mosquitto, FHEM-Log endet vorher.
Ich habe die Vermutung, dass der mosquitto log nicht weiterhilft, weil nur "Socket error" meldet, egal warum.

Ich recherchiere mal, wie man Mosquitto noch mehr Log entlocken kann, als mit log_type all.


Ich habe jetzt eine extra Pruefung eingebaut, damit Nachrichten (wie PINGREQ) nur dann gesendet werden, falls die Verbindung mit CONNECT/SUBSCRIBE komplett aufgebaut ist. Vorher werden alle anderen Nachrichten ignoriert und auf verbose 5 als Solches protokolliert. Ist mehr Symptom behandeln, als Ursache fixen, aber vlt. kommen wir damit weiter. Waere nett, wenn Du es testen koenntest.

Mache ich - vermutlich komme ich aber erst morgen früh wieder dazu.

Weiterhin gibt es ein keepaliveTimeout Attribut, die Voreinstellung ist (wie bisher) 30 Sekunden.

OK, würde ich erst einmal - es sei denn Du sagst es macht Sinn den Wert zu verändern - so belassen.

Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 29 November 2018, 11:26:27
Zitat
Mache ich - vermutlich komme ich aber erst morgen früh wieder dazu.
Sorry, habe gerade gesehen, dass ich gestern das Einchecken verpennt habe: ich habe es gerade (samt fhemupdate) nachgeholt.

Zitat
Der Absturz scheint zu erfolgen, nachdem versucht wird von meinen HomeMatic 6fach Tastern die Statusinfos zu publishen. Vielleicht ein Überlauf von einem Puffer, da alles in derselben Sekunde zu passieren scheint?
Ich habe jetzt ein dummy angelegt, was mit einem aus einem Forumsbeitrag "geklauten" JSON und json2reading 71 Readings auf einem Ruck aktualisiert. Ein MQTT_GENERIC_BRIDGE schickt die Daten an mosquitto (die ist per MQTT2_CLIENT und SSL angebunden). Ich habe nach mehreren Versuchen keine Probleme gesehen, mosquitto schickt alles brav zurueck, was wiederum das generische MQTT2_DEVICE erneut als FHEM Event zur Verfuegung stellt. Alles in allem viel Verkehr, und kein Verbindungsabbruch.

Zitat
Macht es Sinn, dass ich testhalber die HM-Geräte aus dem fhem-Publishing der MQTT_GENERIC_BRIDGE rausnehmen?
Da ich ja offensichtlich nicht weiss, was die Ursache ist, macht vmtl. alles Sinn. :)
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 29 November 2018, 12:12:54
Mir ist gerade aufgefallen, dass - nachdem ich das Passwort für den Benutzer zur Anmeldung am Mosquitto im MQTT2_CLIENT erneut eingegeben habe - (mit demselben Passwort wie vorher), die connects und reconnects aufhören und die Verbindung stabil bleibt.
Das Passwort ist definitiv dasselbe, welches ich vorher verwendet hatte - lief ja auch zu Beginn.
Könnte es da bei der Speicherung ein Problem geben? Ich verwende Sonderzeichen und die Länge ist < 64 Zeichen).

Habe noch nicht die neue Version drauf. Aktuell in Verwendung:
00_MQTT.pm                17362 2018-09-17 12:57:29Z hexenmeister
00_MQTT2_CLIENT.pm        17867 2018-11-29 09:55:51Z rudolfkoenig
10_MQTT_GENERIC_BRIDGE.pm 17841 2018-11-25 15:06:01Z hexenmeister

Wobei ich mich gerade frage, warum 00_MQTT.pm verwendet wird - ich habe kein normales MQTT-Device definiert (gerade noch mal im Raum Everything gecheckt). Wird vermutlich von 10_MQTT_GENERIC_BRIDGE.pm benötigt?
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 29 November 2018, 12:16:26
Zitat
Wird vermutlich von 10_MQTT_GENERIC_BRIDGE.pm benötigt?
Ja, da steht "main::LoadModule("MQTT");"

Zitat
Könnte es da bei der Speicherung ein Problem geben?
Klar, allerdings sollte das beim Vergleich der Debug-CONNECT Zeilen einfach feststellbar sein.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: hexenmeister am 29 November 2018, 12:37:02
Die MQTT_GENERIC_BRIDGE wurde ursprünglich für MQTT-Modul entwickelt. Die MQTT2*-Unterstützung kam erst neulich dazu. Ich muss überlegen, wie ich es am besten dynamisch machen kann. Also zunächst die IODev-Type bestimmen und dann die (und nur die) benötigten Module laden. Muss allerdings alles durchkämen und sicherstellen, dass keine subs aus MQTT-Modul verwendet werden. Da werden jedoch derzeit auch allgemeingültige Routinen aufgerufen, die nichts mit IO zu tun haben. Also eine Art 'Frühjahresputz' ist angesagt.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 04 Dezember 2018, 10:11:12
Sorry, habe gerade gesehen, dass ich gestern das Einchecken verpennt habe: ich habe es gerade (samt fhemupdate) nachgeholt.
Ich habe jetzt ein dummy angelegt, was mit einem aus einem Forumsbeitrag "geklauten" JSON und json2reading 71 Readings auf einem Ruck aktualisiert. Ein MQTT_GENERIC_BRIDGE schickt die Daten an mosquitto (die ist per MQTT2_CLIENT und SSL angebunden). Ich habe nach mehreren Versuchen keine Probleme gesehen, mosquitto schickt alles brav zurueck, was wiederum das generische MQTT2_DEVICE erneut als FHEM Event zur Verfuegung stellt. Alles in allem viel Verkehr, und kein Verbindungsabbruch.
Da ich ja offensichtlich nicht weiss, was die Ursache ist, macht vmtl. alles Sinn. :)

Ich hatte MQTT2_CLIENT jetzt ein paar Tage stabil laufen. Habe zwar in der Zwischenzeit nicht wirklich etwas gemacht (da mich die Grippe dahingerafft hat), aber vorher war der CLIENT auch ohne mein Hinzutun (nur nach Update) in den connect/disconnect Zyklus gegangen. Die Updates habe ich täglich durchgeführt, um das zu überprüfen, diese waren aber ohne Einfluss, das Modul lief stabil weiter.

Jetzt wollte ich mich gerade daran machen, mit dem toJSON zu experimentieren, um auch korrekten JSON-Code mit dem MQTT2_CLIENT (und wenn das funktioniert, mit der MQTT_GENERIC_BRIDGE) versenden zu können.

Ein einfaches Publish Beispiel funktionierten:
set mosquitolocal publish fhempub/testohne den MQTT_CLIENT zum Absturz zu bringen.

Da Node Red aber - zu Recht - über das fehlerhafte JSON-Objekt meckert
Zitat
Unexpected end of JSON input
wollte ich den Payload JSON-konform übergeben:

set mosquitolocal publish fhempub/test {toJSON({ 'state' => 'OFF'})}
Das hat meinen MQTT2_CLIENT ins Nirvana - disconnect/connect Orgie - geschickt. Auch ein Neustart von fhem behebt das nicht - der MQTT2_CLIENT befindet sich in der Dauer (dis)connect Schleife.

Hier das Log zu obiger Eingabe:
2018.12.04 09:07:53 5: mosquittolocal: keepalive 30
2018.12.04 09:07:53 5: mosquittolocal: sending PINGREQ (192)(0)
2018.12.04 09:07:53 5: mosquittolocal: received PINGRESP
2018.12.04 09:08:01 5: mosquittolocal: sending PUBLISH 0(14)(0)(12)fhempub/test
2018.12.04 09:08:01 5: mosquittolocal: received PUBLISH (0)(12)fhempub/test
2018.12.04 09:08:01 5: mosquittolocal: dispatch mosquittolocal:fhempub/test:
2018.12.04 09:08:23 5: mosquittolocal: keepalive 30
2018.12.04 09:08:23 5: mosquittolocal: sending PINGREQ (192)(0)
2018.12.04 09:08:23 5: mosquittolocal: received PINGRESP
2018.12.04 09:08:33 5: mosquittolocal: discarding DISCONNECT (224)(0)
2018.12.04 09:08:33 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.12.04 09:08:33 5: HttpUtils url=https://smartgulp2:8883/
2018.12.04 09:08:33 4: IP: smartgulp2 -> 127.0.1.1
2018.12.04 09:08:33 5: mosquittolocal: sending CONNECT (16)0(0)(6)MQIsdp(3)(194)(0)(30)(0)(14)mosquittolocal(0)(4)fhem(0)(12)fhempub/test
2018.12.04 09:08:33 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.12.04 09:08:33 5: mosquittolocal: received CONNACK (0)(5)
2018.12.04 09:08:33 1: mosquittolocal: Connection refused, not authorized
2018.12.04 09:08:33 5: mosquittolocal: discarding DISCONNECT (224)(0)
2018.12.04 09:08:33 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.12.04 09:08:33 5: HttpUtils url=https://smartgulp2:8883/
2018.12.04 09:08:33 4: IP: smartgulp2 -> 127.0.1.1
2018.12.04 09:08:33 5: mosquittolocal: sending CONNECT (16)0(0)(6)MQIsdp(3)(194)(0)(30)(0)(14)mosquittolocal(0)(4)fhem(0)(12)fhempub/test
2018.12.04 09:08:33 1: smartgulp2:8883 reappeared (mosquittolocal)
2018.12.04 09:08:33 5: mosquittolocal: received CONNACK (0)(5)
2018.12.04 09:08:33 1: mosquittolocal: Connection refused, not authorized
2018.12.04 09:08:33 5: mosquittolocal: discarding DISCONNECT (224)(0)
2018.12.04 09:08:33 1: smartgulp2:8883 disconnected, waiting to reappear (mosquittolocal)
2018.12.04 09:08:33 5: HttpUtils url=https://smartgulp2:8883/
2018.12.04 09:08:33 4: IP: smartgulp2 -> 127.0.1.1
2018.12.04 09:08:33 5: mosquittolocal: sending CONNECT (16)0(0)(6)MQIsdp(3)(194)(0)(30)(0)(14)mosquittolocal(0)(4)fhem(0)(12)fhempub/test

Ich denke, das sollte nicht passieren, dass ein Publish den MQTT2_CLIENT unbrauchbar macht.

Nach Neuanlegen des Devices und einem
set mosquitolocal publish fhempub/test { "state":"OFF"}wird dieses korrekt von Node-Red interpretiert.

Ist es überhaupt möglich, dem publish Perl-Code zu übergeben (siehe mein fehlgeschlagenes Beispiel)?

Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 04 Dezember 2018, 11:23:51
Zitat
set mosquitolocal publish fhempub/test {toJSON({ 'state' => 'OFF'})}
Netter Versuch, aber set publish in MQTT2_CLIENT interpretiert {} nicht als Perl Ausdruck, sondern sendet es unveraendert an den Server.
Sowas ist mW auch nirgendwo dokumentiert, wenn doch, bitte sagen.

Ich habe versucht die Endlosschleife nachzustellen:
- mosquitto mit SSL und aktivierten Benutzer/Passwort gestartet
- MQTT2_CLIENT passend konfiguriert.
- geprueft, dass beim falschen Passwort "Connection refused, not authorized" kommt, danach korrektes Passwort wieder gesetzt
- das erwaehnte set abgesetzt.

Mosquitto liefert das topic zurueck, wg. autocreate erweitert FHEM das angelegte MQTT2_DEVICE, das ein reading mit dem Namen test und mit dem Wert {toJSON({ 'state' => 'OFF'})} kriegt.
=> Works as designed.

Bin bereit weiter zu debuggen, wenn ich das Problem nachstellen kann.

Btw: die Perl Auswertung kann man mittels den global (d.h. fuer alle sets) verfuegbaren Set-Magic errreichen:set mosquitolocal publish fhempub/test {( toJSON({'state'=>'OFF'}) )}
Man achte auf {(...)}
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: HomeAlone am 06 Dezember 2018, 09:45:25
Netter Versuch, aber set publish in MQTT2_CLIENT interpretiert {} nicht als Perl Ausdruck, sondern sendet es unveraendert an den Server.
Sowas ist mW auch nirgendwo dokumentiert, wenn doch, bitte sagen.
Nein, hast Du nirgends geschrieben, aber ich dachte Versuch macht kluch... ;)


Ich habe versucht die Endlosschleife nachzustellen:
- mosquitto mit SSL und aktivierten Benutzer/Passwort gestartet
- MQTT2_CLIENT passend konfiguriert.
- geprueft, dass beim falschen Passwort "Connection refused, not authorized" kommt, danach korrektes Passwort wieder gesetzt
- das erwaehnte set abgesetzt.

Mosquitto liefert das topic zurueck, wg. autocreate erweitert FHEM das angelegte MQTT2_DEVICE, das ein reading mit dem Namen test und mit dem Wert {toJSON({ 'state' => 'OFF'})} kriegt.
=> Works as designed.

Bin bereit weiter zu debuggen, wenn ich das Problem nachstellen kann.
Aktuell läuft es bei mir stabil, habe seit Deinem Posting keine Abstürze mehr gehabt. Ich habe bei mir auch kein MQTT2_DEVICE in der Config. Werde mir zu Testzwecken aber eines anlegen, da ich es vermutlich spätenstens, wenn ich nicht nur publishen sondern auch subscriben will benötigen werde.

Btw: die Perl Auswertung kann man mittels den global (d.h. fuer alle sets) verfuegbaren Set-Magic errreichen:set mosquitolocal publish fhempub/test {( toJSON({'state'=>'OFF'}) )}
Man achte auf {(...)}
Vielen Dank, habe ich ausprobiert und - oh Wunder ;) - es funktioniert. "set magic" kannte ich bisher noch nicht - muss ich mir mal genauer ansehen. Für interessierte Leser zum Ersparen der Googleanfrage: https://wiki.fhem.de/wiki/Set_magic

Noch mal vielen Dank für Deinen Einsatz, Rudi!
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: OdfFhem am 09 Dezember 2018, 14:39:22
Im Produktiv-System nutze ich derzeit folgende (schon etwas ältere) MQTT2-Version
00_MQTT2_CLIENT.pm    17867 2018-11-29 09:55:51Z rudolfkoenig
10_MQTT2_DEVICE.pm    17832 2018-11-24 15:24:30Z rudolfkoenig
und habe damit keine nennenswerten Probleme.

Nun wollte ich mal im Test-System mit dem aktuell verteilten MQTT2-Stand komplett neu aufsetzen.


Dabei stoße ich schon sehr früh auf folgende (ernsten) Probleme:


Ich nutze MQTT2_CLIENT mit externem mosquitto-Server. Bis man das Passwort gesetzt hat, schaltet der Status vom MQTT2_CLIENT-Device in rasantem Tempo zwischen opened bzw. disconnected hin und her und "müllt" dabei munter das Logfile zu.
Ein wirklich sehr kleiner Auszug aus dem Logfile
2018.12.09 13:27:43.932 3: Opening myMqttClient device raspberrypi:1883
2018.12.09 13:27:43.946 3: myMqttClient device opened
2018.12.09 13:27:43.968 1: raspberrypi:1883 disconnected, waiting to reappear (myMqttClient)
2018.12.09 13:27:43.976 1: raspberrypi:1883 reappeared (myMqttClient)
2018.12.09 13:27:43.980 1: raspberrypi:1883 disconnected, waiting to reappear (myMqttClient)
2018.12.09 13:27:43.987 1: raspberrypi:1883 reappeared (myMqttClient)
2018.12.09 13:27:43.991 1: myMqttClient: Connection refused, not authorized
2018.12.09 13:27:43.993 1: raspberrypi:1883 disconnected, waiting to reappear (myMqttClient)
2018.12.09 13:27:44.190 1: raspberrypi:1883 reappeared (myMqttClient)
.
.
.


Das zum CLIENT gehörige MQTT2-Device wird automatisch angelegt, heißt aber aus meiner Sicht falsch - MQTT2_my_qtt_lient statt MQTT2_myMqttClient.
autocreate: define MQTT2_my_qtt_lient MQTT2_DEVICE myMqttClient


Dieses Problem setzt sich dann auch nach dem Setzen von bridgeRegexp für die automatisch angelegten, eigentlichen MQTT2_DEVICEs fort.
autocreate: define MQTT2_zigbee_dimmer_witch1 MQTT2_DEVICE zigbee_dimmerSwitch1


Noch ein Hinweis zum bridgeRegexp: Verwendet man die 0x-Variante für zigbee2mqtt, darf man keine friendly_names verwenden.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 09 Dezember 2018, 18:32:20
Zitat
Dabei stoße ich schon sehr früh auf folgende (ernsten) Probleme:
Unter ernst verstehe ich sowas wie "funktioniert gar nicht".

Zitat
Bis man das Passwort gesetzt hat, schaltet der Status vom MQTT2_CLIENT-Device in rasantem Tempo zwischen opened bzw. disconnected hin und her und "müllt" dabei munter das Logfile zu.
Interessant, bei mir werden nur alle 3 Sekunden Meldungen geschrieben. Laeuft dein FHEM auf Windows?
Ab sofort wird bei CONNACK mit Fehler das authError Internal gesetzt, was ein reconnect verhindert.
Dieses Internal wird entfernt, wenn man "attr m2c username" oder "set m2c password" ausfuehrt oder FHEM neu startet.

Zitat
Das zum CLIENT gehörige MQTT2-Device wird automatisch angelegt, heißt aber aus meiner Sicht falsch - MQTT2_my_qtt_lient statt MQTT2_myMqttClient.
Danke fuer den Hinweis, ich habe es gefixt.

Zitat
Noch ein Hinweis zum bridgeRegexp: Verwendet man die 0x-Variante für zigbee2mqtt, darf man keine friendly_names verwenden.
Das habe ich nicht verstanden, bitte anders formulieren, oder ein konkretes Beispiel anhaengen.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: OdfFhem am 09 Dezember 2018, 21:51:29
Zitat
Unter ernst verstehe ich sowas wie "funktioniert gar nicht".
Daher hatte ich "ernst" eingeklammert und bezog sich eigentlich auch mehr auf die autocreate-Funktionalität; im Produktiv-System z.B. wären ja vermutlich lauter neue, unkonfigurierte Devices angelegt worden und die alten, bereits konfigurierten Devices würden nicht mehr aktualisiert - wären somit ohne Funktion.

Zitat
Laeuft dein FHEM auf Windows?
Nein - läuft unter Raspbian Stretch auf einem Raspberry Pi.

Zitat
Das habe ich nicht verstanden, bitte anders formulieren, oder ein konkretes Beispiel anhaengen.
Bei zigbee2mqtt wird jedes Gerät über eine eindeutige Hex-ID (z.B. 0x123456789) identifiziert. Dieser doch sehr technische Name kann durch die rename-Funktionalität mit einem etwas sprechenderen Namen (z.B. dimmerSwitch1) - dem friendly_name -  versehen werden. Macht man dies, werden die MQTT-Publish-Meldungen von zigbee2mqtt zukünftig unter dem friendly_name und nicht mehr unter der Hex-ID verbreitet, was unmittelbar Auswirkung auf bridgeRegexp, readingList, usw. hat.

Statt
zigbee2mqtt/0x123456789:.* { json2nameValue($EVENT) }
müsste das readingList-Attribut beim FHEM-Device dann so aussehen
zigbee2mqtt/dimmerSwitch1:.* { json2nameValue($EVENT) }
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 10 Dezember 2018, 09:10:48
Zitat
Dieser doch sehr technische Name kann durch die rename-Funktionalität mit einem etwas sprechenderen Namen (z.B. dimmerSwitch1) - dem friendly_name -  versehen werden. Macht man dies, werden die MQTT-Publish-Meldungen von zigbee2mqtt zukünftig unter dem friendly_name und nicht mehr unter der Hex-ID verbreitet, was unmittelbar Auswirkung auf bridgeRegexp, readingList, usw. hat.
Das Problem in diesem Fall ist einen Algorithmus zu finden, was den bridge vom Rest unterscheidet.
Wenn jemand eine Idee hat, bitte melden.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Beta-User am 10 Dezember 2018, 09:22:36
Eine Idee habe ich dazu nicht, (mal abgesehen davon, dass alle Statusmeldungen über "zigbee2mqtt/log" reinkommen, man also eine Art negativer Auslese machen könnte).
Aber in's Wiki kommt der deutliche Hinweis, dass man nach Möglichkeit die Devices an der Stelle (friendly name) entweder unbearbeitet lassen sollte oder eben ein "0x" voranstellen. M.E. ist es ausreichend, dass man in FHEM einen "sprechenden Namen" vergeben kann.
Wer unbedingt will (z.B., weil das für eine andere HA-Software erforderlich ist), kann immer noch die bridgeRegexp erweitern; da sind ja auch mehrere Einträge zulässig...
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Wallmeier am 03 Januar 2019, 12:32:14
Ich hatte heute wieder die Situation, dass sich die Logzeilen "127.0.0.1:1883 reappeared (mqtt2)" und "127.0.0.1:1883 disconnected, waiting to reappear (mqtt2)" immer wieder abgewechselt haben. Nachdem ich Verbose für mqtt2 auf 5 gesetzt habe, bin ich noch nicht weiter gekommen und habe daraufhin noch einen tcpdump gemacht...

2019.01.03 12:16:37.697 1: 127.0.0.1:1883 disconnected, waiting to reappear (mqtt2)
2019.01.03 12:16:37.726 5: HttpUtils url=http://127.0.0.1:1883/
2019.01.03 12:16:37.728 4: IP: 127.0.0.1 -> 127.0.0.1
2019.01.03 12:16:37.732 1: 127.0.0.1:1883 reappeared (mqtt2)
2019.01.03 12:18:07.698 1: 127.0.0.1:1883 disconnected, waiting to reappear (mqtt2)

Der dazugehörige tcpdump ist angehängt...

Für mich sieht der dump so aus, dass der tcp-connect sauber durchgeführt wird, aber danach MQTT2_CLIENT keine CONNECT Nachricht an den Broker (mosquitto) schickt... Nach 90 Sekunden ohne Aktivität auf dem Socket schliesst dann Mosquitto den Socket...
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Papaloewe am 03 Januar 2019, 13:34:21
Ich habe den keepalive = 120 jetzt einmal testweise laufen und zumindest bis heute morgen lief es ohne Fehlermeldungen druch.
...mal abwarten.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 03 Januar 2019, 20:10:00
Zitat
Für mich sieht der dump so aus, dass der tcp-connect sauber durchgeführt wird, aber danach MQTT2_CLIENT keine CONNECT Nachricht an den Broker (mosquitto) schickt...
Hier haette mich noch das "attr MQTT2_CLIENT verbose 5" Output interessiert.
Was fuer ein OS is das?
Eigentlich sendet MQTT2_CLIENT alle 30 Sekunden zusaetzlich auch ein PINGREQ, das haette man in deinem dump auch sehen sollen.
Die Daten gehen normalerweise ueber den select(write) Filter, damit FHEM sich wegen einem toten mosquitto nicht aufhaengt, evtl. haengt das Problem damit zusammen.

Ich habe jetzt eine Weile mit "kaputten" mosquitto (falsches password, SSL vs keins, usw) rumexperimentiert, und ich kann das Problem nur dann reproduzieren, falls mosquitto SSL erwartet, im FHEM das SSL Attribut aber nicht gesetzt ist.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Wallmeier am 03 Januar 2019, 21:30:29
Verbose war bereits auf 5 gesetzt... Mehr als die Zeilen, die in meinem ersten Post zu dem Thema standen, gibt es schlicht nicht.

FHEM läuft bei mir auf Raspbian Strech (Raspberry Pi 3).

Ich gehe davon aus, dass der PINGREQ aber erst nach einem CONNECT überhaupt geschickt wird - und schon dieser fehlt.

Reproduzieren kann ich dieses zuverlässig in der Nacht - dort läuft um 3:00 von DbLog ein reduceLog, was dazu führt das fhem für ca. 92 Sekunden blockiert ist... Danach steht im Log ein "disconnected, waiting to reappear (mqtt2)" und es gibt die Endlosschleife aus "reappeared" und 90 Sekunden später "disconnected, waiting to reappear".
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 03 Januar 2019, 22:21:00
Zitat
dort läuft um 3:00 von DbLog ein reduceLog, was dazu führt das fhem für ca. 92 Sekunden blockiert ist
Das sollte vermieden, bzw. dringend gefixt werden.

Ich habe die Ursache mit einem { sleep(60) } nachgestellt, und mosquitto hat erwartungsgemaess die Verbindung zugemacht.
Danach gibg es aber bei mir weiter. Hier ist die Ausgabe  nach dem sleep:
Zitat
2019.01.03 22:17:44 5: mc: keepalive 30
2019.01.03 22:17:44 5: mc: sending PINGREQ (192)(0)
2019.01.03 22:17:44 1: localhost:1883 disconnected, waiting to reappear (mc)
2019.01.03 22:17:49 5: HttpUtils url=https://localhost:1883/
2019.01.03 22:17:49 4: IP: localhost -> 127.0.0.1
2019.01.03 22:17:49 5: mc: sending CONNECT (16) (0)(6)MQIsdp(3)(194)(0)(30)(0)(2)mc(0)(4)user(0)(8)password
2019.01.03 22:17:49 5: SW: 102000064d514973647003c2001e00026d63000475736572000870617373776f7264
2019.01.03 22:17:49 1: localhost:1883 reappeared (mc)
2019.01.03 22:17:49 5: mc: received CONNACK (0)(0)
2019.01.03 22:17:49 5: mc: sending SUBSCRIBE (128)(6)(0)(4)(0)(1)#(0)
2019.01.03 22:17:49 5: mc: received PINGRESP
2019.01.03 22:17:49 5: mc: received SUBACK (0)(4)(0)
2019.01.03 22:18:19 5: mc: keepalive 30
2019.01.03 22:18:19 5: mc: sending PINGREQ (192)(0)...
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Wallmeier am 03 Januar 2019, 22:47:11
War bei dem Test die SVN Rev. 18127 schon aktiv?
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: rudolfkoenig am 04 Januar 2019, 00:01:42
Zitat
War bei dem Test die SVN Rev. 18127 schon aktiv?
Ja, das wird aber dein Problem nicht loesen.
Die Aenderung in 18127 wuerde ein select-Problem umschiffen, soweit kommt es aber laut dem Log gar nicht.
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Wallmeier am 04 Januar 2019, 08:33:43
Ich hatte gestern Abend die Änderung von Rev. 18127 in meine Installation manuell reingepatcht gehabt - und heute Nacht hatte ich zwar auch wieder folgende Logzeilen
2019.01.04 03:01:36.668 1: 127.0.0.1:1883 disconnected, waiting to reappear (mqtt2)
2019.01.04 03:01:36.692 1: 127.0.0.1:1883 reappeared (mqtt2)
Aber diesmal mit dem großen Unterschied, dass es jetzt keine Endlosschleife geworden ist und die mqtt2-Instanz benutzbar ist  ;D
Titel: Antw:MQTT2_CLIENT Probleme
Beitrag von: Reinhart am 04 Januar 2019, 10:53:22
@Wallmeier

hast die eine SQLite Datenbank die du um 03:00 komprimierst bzw. alte Einträge löscht ( reduceLogNbl ) ?
Ich hatte den selben Fehler und die kamen eindeutig von dem Datenbank Job. Wenn ja, dann mach in der myDblog einen "configCheck" und befolge die Ratschläge, dann sind die Fehler im MQTT2_Client weg. Durch setzen des Attributes "asyncMode 1" ist das dann behoben.

2019.01.02 01:02:34 1: localhost:1883 disconnected, waiting to reappear (ebusMQTT)
2019.01.02 01:02:34 1: localhost:1883 reappeared (ebusMQTT)
2019.01.02 01:04:04 1: localhost:1883 disconnected, waiting to reappear (ebusMQTT)
2019.01.02 01:04:04 1: localhost:1883 reappeared (ebusMQTT)
2019.01.02 01:05:34 1: localhost:1883 disconnected, waiting to reappear (ebusMQTT)
das waren meine Fehlermeldungen im MQTT2_Client

2019.01.02 01:00:00 3: DbLog myDbLog -> Deletion of records older than 30 days in database /opt/fhem/fhem.db requestedund das der Auslöser wenn "asyncMode" nicht "1" ist.

LG
Reinhart