MQTT2_SERVER: Probleme mit FHEM Docker Image

[Rudibarani]

Liebe alle,

ich habe nun einige Tasmota Steckdosen bei uns installiert und nutze dafür den neuen MQTT2_Server. Leider gibt es immer wieder Momente, wo ich diese nicht per MQTT über FHEM steuern kann. Parallel dazu sehe ich hunderte dieser Einträge in meiner Log-Datei:

Code Auswählen Erweitern

2018.11.12 11:45:06 3: m2s: m2s_172.17.0.1_40747 left us (keepalive check)
2018.11.12 11:47:16 3: m2s: m2s_172.17.0.1_40835 left us (keepalive check)
2018.11.12 11:49:06 3: m2s: m2s_172.17.0.1_40890 left us (keepalive check)
2018.11.12 11:50:36 3: m2s: m2s_172.17.0.1_40975 left us (keepalive check)
2018.11.12 11:51:36 3: m2s: m2s_172.17.0.1_41009 left us (keepalive check)
2018.11.12 11:52:56 3: m2s: m2s_172.17.0.1_41044 left us (keepalive check)
2018.11.12 12:09:16 3: m2s: m2s_172.17.0.1_41098 left us (keepalive check)
2018.11.12 12:09:46 3: m2s: m2s_172.17.0.1_41594 left us (keepalive check)

FHEM läuft bei mir in einem Docker-Image (diggewuff/fhem-docker) auf einer Synology DiskStation. Die IP 172.17.0.1 ist der zentrale Gateway, über den die Docker-Images Netzzugang bekommen. Alle mir bekannten Ports (inkl. 1883 für MQTT) sind freigegeben. FHEM läuft ansonsten reaktionsschnell und einwandfrei.

Kann mir jemand sagen, woher diese Log-Einträge kommen? Braucht m2s weitere Ports außer 1883? Wenn ja, kann ich das irgendwie auf einen Port festnageln, so dass ich diesen mit in die Freigabetabelle aufnehmen kann? Oder liege ich komplett falsch, das Problem beim FHEM-Betrieb im Docker-Image zu suchen?

[hexenmeister]

Hast Du schon mit einem klassischem Mosquitto probiert (mittels MQTT2_CLIENT in FHEM angebunden)?
Im Sinne der Performance, Stabilität und Ressourcen gewinnt er allemals

[Rudibarani]

Danke Hexenmeister für das Feedback. Das wäre sicher ein Weg, das vorübergehend verlässlich aufzusetzen.

Da es MQTT2_Server anscheinend erst seit kurzem gibt, könnte es ja sein, dass ich durch den Docker-Betrieb auf ein noch nicht bedachtes Problem gestoßen bin. Daher fände ich es auch lohnenswert herauszufinden, woher das Problem kommt. Der MQTT2_Server soll, wenn ich das richtig verstanden haben, ja für die meisten Nutzer und Anwendungsfälle eine schlanke integrierte Lösung bieten.

[hexenmeister]

Nun ja, das ist in der Tat eine Lösung für diejenigen Nutzer, die mit einer Mosquitto-Installation überfordert sind.
Schlank würde ich es nicht nennen. Man bedenke - FHEM ist eine thingle threaded Anwendung, d.h. alles, was im FHEM CPU verbraucht, bremst alles andere in FHEM dementsprechend. Daher sollte man alles, was man auslagern kann, auch auslagern. Vor allem bewährte Serversoftware.
Aus meiner Sicht ist der einzige legitime Anwendungsfall - ist eine schnell aufgesetzte Testserver, den man "nur mal kurz" braucht. Aber das ist natürlich meine persönliche Meinung.

[rudolfkoenig]

@Rudibarani: MQTT2_SERVER braucht nur den im define spezifizierten Port. Die Meldung bedeutet, dass einer der clients sein keepalive nicht rechtzeitig gesendet hat. Rechtzeitig heisst, 1.5 mal laenger nicht, als er das selbst spezifiziert hat. Es gibt in MQTT2_SERVER ein Attribut keepaliveFactor, mit dem man diesen Faktor 1.5 (fuer alle clients) aendern kann.
Ich habe die Meldung jetzt erweitert, damit auch der clientId ausgegeben wird. Und ich sehe gerade, dass keepaliveFactor zwar implementiert und dokumentiert ist, aber nicht in der Attributliste auftaucht: das habe ich jetzt nachgeholt.

@hexenmeister: MQTT2_SERVER ist dafuer da, Sensoren und Aktoren in FHEM einzubinden. Wenn man mit einer FHEM Installation und einen externen Server wie mosquitto vorher keine Probleme hatte, dann werden durch den ersatz MQTT2_SERVER keine Neuen dazukommen, da der Datenaustausch nicht blockierend ist. Weiterhin erhaelt FHEM nur durch MQTT2_SERVER die clientId der Verbindung, was fuer alle direkt (nicht via MQTT bridge) angebundenen Geraete ein autocreate ermoeglicht.
Wenn man mit MQTT audio uebertragen oder Festplatten synchronisieren will, dann soll man gerne was Anderes verwenden.

[hexenmeister]

MQTT2_SERVER ist dafuer da, Sensoren und Aktoren in FHEM einzubinden. Wenn man mit einer FHEM Installation und einen externen Server wie mosquitto vorher keine Probleme hatte, dann werden durch den ersatz MQTT2_SERVER keine Neuen dazukommen, da der Datenaustausch nicht blockierend ist. Weiterhin erhaelt FHEM nur durch MQTT2_SERVER die clientId der Verbindung, was fuer alle direkt (nicht via MQTT bridge) angebundenen Geraete ein autocreate ermoeglicht.
Wenn man mit MQTT audio uebertragen oder Festplatten synchronisieren will, dann soll man gerne was Anderes verwenden.

Ist mir schon klar, und ja, Du hast recht, in den allgemeinen Fällen wird es nicht zu Problemen führen. Dennoch widerstrebt es mir, bestehende und bewährte native Anwendungen nachzubauen und dann noch als Teil eines (für etwas anderes zuständiges) Systems zu betreiben. Ich betreibe separation of concerns überall, wo ich das kann
Ob der Datenaustausch blockierend ist oder nicht, die Verarbeitung der Logik kostet trotzdem unnötig Verarbeitungszeit, die auf alle Aufgaben geteilt werden muss. Ich bin nun mal vorgeschädigt durch meinen beruflichen Umgang mit hochbelasteten Systemen, wo jede Millisekunde zu viel ein Problem ist.
ClientID habe ich auch schon in dem MQTT-Protokoll (in den gesendeten Nachrichten) vermisst, würde einiges einfacher machen. Dennoch halte ich die fehlende autocreate nicht wirklich für ein Verlust. Wenn man darauf verzichtet und alles selbst macht, dann versteht man, wie es funktioniert und erlebt keine Überraschungen durch die ganze 'magic', das im Hintergrund abläuft.
Verstehe mich dennoch nicht falsch, ich finde deine Module gut und plane auch alle meine Installationen auf MQTT2_CLIENT unzutellen.

[Rudibarani]

MQTT2_SERVER braucht nur den im define spezifizierten Port. Die Meldung bedeutet, dass einer der clients sein keepalive nicht rechtzeitig gesendet hat. Rechtzeitig heisst, 1.5 mal laenger nicht, als er das selbst spezifiziert hat. Es gibt in MQTT2_SERVER ein Attribut keepaliveFactor, mit dem man diesen Faktor 1.5 (fuer alle clients) aendern kann.
Ich habe die Meldung jetzt erweitert, damit auch der clientId ausgegeben wird. Und ich sehe gerade, dass keepaliveFactor zwar implementiert und dokumentiert ist, aber nicht in der Attributliste auftaucht: das habe ich jetzt nachgeholt.

Vielen Dank für die schnelle Hilfe!! Ich werde MQTT2_Server aktualisieren und dem erneut nachgehen. Wäre schön, wenn es tatsächlich nur eine schlechte Funkverbindung der Tasmota Steckdose ist.

[rudolfkoenig]

Dennoch halte ich die fehlende autocreate nicht wirklich für ein Verlust.

Ja, aber nicht jeder hat dein Wissensstand und Anfaenger sind dankbar fuer jedes autocreate.
Ich will mit MQTT2_SERVER den Einstieg vereinfachen, und nicht mosquitto oder die alten FHEM-MQTT Module abloesen.

[hexenmeister]

War keineswegs überheblich gemeint. Vermutlich ist das gut, den Anfängern zunächst ein schnelles Erfolgserlebnis zu ermöglichen.

[Omega]

Ich bin jetzt hier gelandet, da ich auch immer wieder mal Meldungen im Log habe wie

Code Auswählen Erweitern

MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.0.41_16040/DVES_D09190 left us (keepalive check).
Das Device hat eine konstante Signalqualität von -58 dBm (es sind aber noch einige andere Devices, die sich immer wieder mal melden). An der reinen WLAN-Verbindung sollte es daher eher weniger liegen. Da ich nicht herausfinden kann, was die wirkliche Ursache für die Meldungen sind, möchte ich sie zumindest minimieren und denke, dafür könnte der keepaliveFactor eine Lösung sein.

Was ich derzeit nicht sehen kann, ist welchen Wert der keepaliveFactor aktuell (bzw. default) hat: 1.5 oder 10?
Schön wäre es, wenn in der Commandref bei Parametern der default-Wert konkret mit angegeben wird. Erhöht das Verständnis und man muss weniger raten. Eine - vielleicht noch bessere - Variante: irgendeinen Wert hat der keepaliveFactor. Dann könnte er auch in den Internals oder den Readings angezeigt werden.

LG
Holger

[rudolfkoenig]

Schön wäre es, wenn in der Commandref bei Parametern der default-Wert konkret mit angegeben wird

Schoen waere, wenn man vor der Beschwerde den Text lesen wuerde

keepaliveFactor
      the oasis spec requires a disconnect, if after 1.5 times the client
      supplied keepalive no data or PINGREQ is sent. With this attribute you
      can modify this factor, 0 disables the check.
      Notes:
        dont complain if you set this attribute to less or equal to 1.
        MQTT2_SERVER checks the keepalive only every 10 second.

Faellt dir eine bessere Formulierung ein?

Falls du keepalive meinst, das wuerde ich mit "list TYPE=MQTT2_SERVER lwt keepalive" abfragen.
Diese Werte zu dokumentieren ist aber nicht meine Aufgabe.

[Omega]

Ich möchte mich ungerne entschuldigen dafür dass meine Englischkenntnisse nicht die Besten sind. Deutsch ist nun mal meine Muttersprache  . Und MQTT kann ich leider auch nur in kleinem Umfang anwenden.

Ich habe halt vor dem Text gestanden und geraten, was denn nun gemeint sein könnte. Und eine Commandref ist im Prinzip ja wie eine Syntaxbeschreibung - und zumindest von da kenne ich es, dass in vielen Fällen der default-Wert mit angegeben ist. Von daher meine Frage und mein - hoffentlich konstruktiv verstandener - Vorschlag. Eine Beschwerde war es mit Sicherheit nicht. Ich weiß sehr zu schätzen, was viele hier im Forum leisten. Manche Leistung geht halt leider verloren, wenn man nicht "abgeholt" wird.

LG
Holger