MQTT

[Billy]

da ich mich nicht wirklich mit perl auskenne, habe ich mit meinen Mitteln versucht, eine Verbesserung zu realisieren.

Nachdem dies mangelhaft zu sein scheint, ziehe ich den code natürlich zurück.

vG
Wolfgang

Das ist schade, kannst du mir den Code per PM zukommen lassen?

Billy

[Gisbert]

Hallo,

ich hab den MQTT-Broker mit <user:password> in Fhem angelegt.
Auf den RPi3B hab ich einen user in MQTT angelegt.
Der MQTT-Broker ist in Fhem opened - soweit sieht es gut aus.

Ich nutze ESPEasy Build 136.
Ohne user:password funktioniert die Einstellung Protocol: PiDome MQTT; mit user:password finde ich keine Einstellung, die Daten nach Fhem schreibt.

Was mache ich falsch bzw. hat jemand den hier genannten patch in Kombination mit ESPEasy erfolgreich zum Laufen gebraucht?

Viele Grüße Gisbert

[P.A.Trick]

Hallo,

ich hab den MQTT-Broker mit <user:password> in Fhem angelegt.
Auf den RPi3B hab ich einen user in MQTT angelegt.
Der MQTT-Broker ist in Fhem opened - soweit sieht es gut aus.

Ich nutze ESPEasy Build 136.
Ohne user:password funktioniert die Einstellung Protocol: PiDome MQTT; mit user:password finde ich keine Einstellung, die Daten nach Fhem schreibt.

Was mache ich falsch bzw. hat jemand den hier genannten patch in Kombination mit ESPEasy erfolgreich zum Laufen gebraucht?

Viele Grüße Gisbert

Du solltest den Openhab MQTT im ESPEasy konfigurieren. Danach musst doch noch die Subcribe- und Publish Template anpassen!
Dieser Artikel hat mir geholfen: http://xbmcnut.blogspot.de/2017/02/how-to-flash-espeasy-onto-sonoff-touch.html

[Gisbert]

Hallo P.A.Trick,

vielen Dank für den Hinweis die Subcribe- und Publish-Templates anzupassen.
Damit hat es geklappt und Fhem registriert Daten.
Was noch etwas verwirrend war, ist die Angabe für user und password, die je nach Quelle unterschiedlich ist, mal mit Leerzeichen, mal mit Doppelpunkt.
Bei mir hat nur die Schreibweise <user:password> mit Doppelpunkt zwischen user und password funktioniert.

Viele Grüße Gisbert

[AutomationBaer]

Leider scheitert die Verwendung des MQTT_DEVICES mit ein vertxMQTT Broker. Und das Problem scheint im MQTT_DEVICES/MQTT Perl Modul zu liegen. Denn mit verschiedenen anderen Clients gelingt problemlos ein abonnieren der Topics. Den Test habe ich auch vom FHEM Knoten aus mit Net::MQTT erfolgreich absolviert.

Der eigentliche Connect zum Broker gelingt:

Code Auswählen Erweitern


2017.03.03 17:00:17 3: Opening vertxMQTT device 192.168.###.###:1885
2017.03.03 17:00:17 3: vertxMQTT device opened

bzw. auf der Server Seite:

Code Auswählen Erweitern

2017-03-03 17:00:17 INFORMATION io.github.giovibal.mqtt.MQTTSession New connection client : clientID: NetMQTTpm5058, MQTT protocol: MQIsdp


Versuche ich dann aber eine Subscription durchzuführen - aktivieren des Attributs

Code Auswählen Erweitern

attr environment_Treppenhaus subscribeReading_Environment /sensor/indoor/treppenhaus/environment
kommt es unmittelbar zu einer Exception beim Broker:

Code Auswählen Erweitern


2017-03-03 17:00:17 SCHWERWIEGEND io.github.giovibal.mqtt.MQTTSocket clientID: NetMQTTpm5058, MQTT protocol: MQIsdp, Bad error in processing the message
io.netty.handler.codec.CorruptedFrameException: Received a message with fixed header flags (a) != expected (2)
at io.github.giovibal.mqtt.parser.DemuxDecoder.genericDecodeCommonHeader(DemuxDecoder.java:50)
at io.github.giovibal.mqtt.parser.DemuxDecoder.decodeCommonHeader(DemuxDecoder.java:29)
at io.github.giovibal.mqtt.parser.SubscribeDecoder.decode(SubscribeDecoder.java:22)
at io.github.giovibal.mqtt.parser.MQTTDecoder.decode(MQTTDecoder.java:69)
at io.github.giovibal.mqtt.parser.MQTTDecoder.dec(MQTTDecoder.java:44)
at io.github.giovibal.mqtt.MQTTSocket.onToken(MQTTSocket.java:63)
...


Offensichtlich ist im Flag Nibble der MQTT Nachricht vom FHEM Modul an den Broker sowohl das Bit 3 und das Bit 1 gesetzt. Diese Bit-Kombination ist für den Broker nicht zulässig und gemäß Spezifikation
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.html#_Toc385349758
schließt er unmittelbar die Verbindung:

Code Auswählen Erweitern


2017-03-03 17:00:17 INFORMATION io.github.giovibal.mqtt.MQTTNetSocket clientID: NetMQTTpm5058, MQTT protocol: MQIsdp, net-socket closed ... d6db662f-0182-4bbd-9ddb-c2b83161619f

bzw.

Code Auswählen Erweitern


2017.03.03 17:00:17 1: 192.168.###.###:1885 disconnected, waiting to reappear (vertxMQTT)
2017.03.03 17:00:17 1: 192.168.###.###:1885 reappeared (vertxMQTT)


Wie kann ich das Problem in den beiden Perl Modulen weiter eingrenzen?


Vielen Dank

[eisler]

Hallo AutomationBaer,

zum weiter eingrenzen beim MQTT und beim MQTT_DEVICE verbose auf 5 stellen.

Grüße
Stephan

[AutomationBaer]

Hallo Stephan,

leider gab die zusätzlichen Logausgaben keine verwertbaren Hinweise. Nach einigen Wiederholungen ergibt sich jetzt das folgende Bild: das Anlegen des MQTT IO-Devices funktioniert problemlos. Ebenso die Definition von MQTT_DEVICEs solange diese keine Subscription machen. Das heißt, ich kann das folgende in die fhem.cfg eintragen:

Code Auswählen Erweitern


#
# MQTT
define vertxMQTT MQTT 192.168.###.###:1885
attr vertxMQTT icon it_net
attr vertxMQTT verbose 5

#
# MQTT Subscriptions
# Bewegungsmelder Treppenhaus EG
define bewegungsmelder_Treppenhaus MQTT_DEVICE
attr bewegungsmelder_Treppenhaus IODev vertxMQTT
attr bewegungsmelder_Treppenhaus verbose 5
attr bewegungsmelder_Treppenhaus icon people_sensor
attr bewegungsmelder_Treppenhaus room Treppenhaus
attr bewegungsmelder_Treppenhaus stateFormat transmission-state
#attr bewegungsmelder_Treppenhaus subscribeReading_Motion sensor/indoor/treppenhaus/eg/motion


und FHEM damit (re)starten. Es kommt zu keinen Fehlermeldungen und beide Devices werden im Web-Frontend angezeigt. Der Status des IODevices wird als active und opened angezeigt. Editiere ich jetzt über das Web-Frontend die fhem.cfg und entferne den Kommentar-Hash vor der Subscription - aktiviere also den Eintrag - und speiche die Konfiguration ab, dann tritt unmittelbar das beschriebene Fehlverhalten auf.  Das Device wechselt zwischen subscribed und unsubscribed hin und her. Synchron dazu wirft der Broker die Exception. Nur durch das Löschen des Attributs kehrt wieder Ruhe ein.

Und nun das Erstaunliche: aktiviere ich die Subscription nicht durch das Editieren der Konfiguration, sondern setzte das Attribut über die Komandozeile des Web-Frontends dann wird die Subscription ohne Fehler durchgeführt und das Topic auch ausgelesen. Auch das Speichern der jetzt aktiven Konfiguration gelingt und die Kommunikation läuft problemlos weiter...?! Auf diesem Weg gelingt auch das Aktivieren weiterer Devices.

Wird jetzt allerdings FHEM neu gestartet, zum Beispiel via shutdown restart stellt sich wieder das Eingangs geschilderte Problem ein und der Broker wirft Exceptions. Das Problem scheint also in den Statusübergängen bei FHEM respektive in den beiden MQTT Modulen begründet zu sein.


Ratlose Grüße von

thomas

[eisler]

Hallo Thomas,

Da die FHEM Module auf Net::MQTT basieren verstehe ich nicht das es mit Net::MQTT funktioniert aber mit den FHEM MQTT Modulen nicht.
Kannst du mir dein Net::MQTT Test zukommen lassen?
Ich werde mir mal testweise den vertx-mqtt-broker installieren.

Grüße
Stephan

[AutomationBaer]

Hallo Stephan,

vielen Dank für dein Angebot, doch ich glaube ein Test von Net::MQTT und vertxMQTT führt nicht auf die Spur. Denn die Diskrepanz zwischen der native Nutzung und der Nutzung via FHEM hat mich auch verwundert. Darauf hin habe ich einen Blick auf die Module in FHEM geworfen. Meine Perl Kenntnisse sind mehr als eingerostet, aber soweit ich die die Module 00_MQTT.pm und 10_MQTT_DEVICE.pm verstanden habe verwenden diese Net::MQTT nicht zur Kommunikation. Aus Net::MQTT werden die Konstanten und der Message Builder verwendet - quasi als Utility. Der eigentliche Statusautomat ist in den beiden Modulen realisiert. Zur Low-Level Kommunikation wiederum wird DevIo.pm verwendet.

Im Moment vermute ich, daß das Problem in der init_done Section begründet ist. Ich vermute die meisten/alle verwenden lokale MQTT Broker und nicht wie ich einen Remoten Cluster, so daß Latenzen in der Kommunikation bisher nicht aufgefallen sind:

Code Auswählen Erweitern


sub client_subscribe_topic($$) {
  my ($client,$topic) = @_;
  push @{$client->{subscribe}},$topic unless grep {$_ eq $topic} @{$client->{subscribe}};
  my $expr = topic_to_regexp($topic);
  push @{$client->{subscribeExpr}},$expr unless grep {$_ eq $expr} @{$client->{subscribeExpr}};
  if ($main::init_done) {
    if (my $mqtt = $client->{IODev}) {;
      my $msgid = send_subscribe($mqtt,
        topics => [[$topic => $client->{qos} || MQTT_QOS_AT_MOST_ONCE]],
      );
      $client->{message_ids}->{$msgid}++;
      readingsSingleUpdate($client,"transmission-state","subscribe sent",1)
    }
  }
};


Der Grund kann aber auch ein ganz anderer sein... Ich bin im Moment zumindest Ratlos 

By the way: warum wird in der Sequenz des Subscribes mit zwei verschiedenen QOS Werten gearbeitet? client_subscribe_topic setzt MQTT_QOS_AT_MOST_ONCE, in der dann  aufgerufenen Funktion send_subscribe wird dann MQTT_QOS_AT_LEAST_ONCE verwendet...


Einen schönen Sonntag wünscht

thomas

[Gisbert]

Hallo Stephan,

wenn ich folgende Definition nutze, und das Modul 00_MQTT.pm update, dann bekomme ich keine Verbindung hin.

Code Auswählen Erweitern

define <name> MQTT <ip:port> [<username>] [<password>]

Im logfile erscheint alle 100-200 ms der folgende Eintrag:

Code Auswählen Erweitern

2017.03.09 16:30:20 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.03.09 16:30:20 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)

Im define steht:

Code Auswählen Erweitern

define <name> MQTT <ip:port>
Obwohl das Gerät modifiziert wurde (mit  [<username>] [<password>]) und abgspeichert wurde, fehlen <username> und <password>.

Ich habe 00_MQTT.pm vom update ausgeschlossen.
Die auf der 1. Seite dieses Threads vorhandene 00_MQTT.pm funktioniert, wenn die Definition wie folgt ausssieht:

Code Auswählen Erweitern

define <name> MQTT <ip:port> <username>:<password>

Ich wüsste gerne, wie die Definition richtig heißt, wenn das Modul aus dem update in FHEM benutzt.
Ich würde gerne alle Module updaten, da in der Regel das von Vorteil ist.

Viele Grüße Gisbert

[eisler]

Code Auswählen Erweitern

define <name> MQTT <ip:port> [<username>] [<password>]
passt.

Das nach dem speichern <username> und <password> fehlen ist beabsichtigt.
<username> und <password> werden in $modpath/FHEM/FhemUtils/uniqueID gespeichert.

Grüße
Stephan

[PatrickR]

Mahlzeit!

Ich klinke mich mal hier ein, weil ich ein Problem habe, was vermutlich mit dem Username-Patch zusammenhängt. Nach dem Neustart meines fhem-Servers flutet MQTT reproduzierbar das Log mit Fehlermeldungen:

Code Auswählen Erweitern


2017.03.09 20:23:38.972 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:38.979 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:39.513 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:39.520 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:40.076 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:40.083 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:40.635 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:40.642 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:41.197 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:41.204 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:41.759 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:41.766 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:42.327 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:42.333 1: localhost:1883 reappeared (MQTTBroker)


Das Problem lässt sich beheben, indem man im Webinterface auf "DEF" klickt und den Benutzernamen und das Passwort anhängt. Dann läuft es wieder.

Patrick

P. S.: Ich bin persönlich kein Freund von dem informatischen Taschenspielertrick mit der uniqueID, zumal damit das Risiko massiv steigt, dass man unvollständige Backups erzeugt/restored.

[fstefan1960]

Ich habe das gleiche Phänomen. Löschen und Wieder anlegen des Devices hilft. Ob es was nützt, die Definition in der fhme.cfg weiter nach oben zu ziehen? Einen "shutdown restart" hat das jedenfalls bei mir überlebt. Ob es auch ein Update überlebt, werden wir sehen ...

[fstefan1960]

Nach update und restart startet FHEM heute gar nicht mehr.
Letzte Zeile im Log:

Code Auswählen Erweitern

Undefined subroutine &MQTT::BRIDGE::client_attr called at ./FHEM/10_MQTT_BRIDGE.pm line 166, <$fh> line 744
Mal sehen, ob ich das wieder gestartet bekomme ...

[fstefan1960]

Hallo,

ich pushe das hier mal. Nach einem FHEM "update" - "shutdown restart" startet FHEM nicht.

Workaround bei mir:
Manuell die fhem.cfg editieren (pfui!) und die MQTT-Basis-Definition löschen, (nicht die devices).
FHEM starten und neu definieren.

Läuft, aber geht natürlich nicht per cron oder so ... 

Hat jemand eine Idee, woran das liegt?