MQTT

eisler · 15 April 2017, 08:42:23

Hallo fstefan1960,

in der fhem.cfg hats du zuerst MQTT und dann MQTT_BRIDGE definiert?
Für mich sieht das so aus wie wenn 10_MQTT_BRIDGE.pm ausgeführt wird aber 00_MQTT.pm noch nicht geladen ist.

Grüße
Stephan

fstefan1960 · 15 April 2017, 10:18:23

Ja, danke.
Durch die nötige Redefinition stand MQTT jetzt natürlich am Ende der fhem.cfg.

PatrickR · 18 April 2017, 20:16:27

@eisler:
Brauchst Du zu meinem Problem noch Infos?

Von unterwegs gesendet.

eisler · 18 April 2017, 23:10:05

Hallo PatrickR,

falls du noch Infos hat gerne.
Das sieht für mich nach fehlendem Username und Passwort aus.
Username und Passwort werden in $modpath/FHEM/FhemUtils/uniqueID gespeichert
und werden beim einem Neustart von FHEM von dort gelesen.

Grüße
Stephan

PatrickR · 18 April 2017, 23:12:47

Hallo Stephan, dieser schaudrige Umstand war mir schon bewusst. Werde bei Gelegenheit mal probieren, ob ich das Problem rekonstruieren kann.

Patrick

Von unterwegs gesendet.

PatrickR · 07 Mai 2017, 19:21:07

Mahlzeit!

Da ich heute wegen eines Kernel-Updates mal wieder die Systeme durchbooten musste, hatte ich die Gelegenheit, die Problematik der vergessenen Passwörter näher anzusehen. Zur Erinnerung: Nach dem Neustart kommt keine Verbindung zum MQTT-Broker zu stande:

Code Auswählen


2017.05.07 15:09:07.641 1: localhost:1883 reappeared (MQTTBroker)
2017.05.07 15:09:10.332 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.05.07 15:09:10.339 1: localhost:1883 reappeared (MQTTBroker)
2017.05.07 15:09:13.038 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.05.07 15:09:13.057 1: localhost:1883 reappeared (MQTTBroker)
2017.05.07 15:09:15.758 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)

Das Problem lässt sich lösen, indem man in FHEMWEB den Benutzernamen und das Passwort an die vorhandene Definition anhängt und fhem durchstartet. So weit so bekannt.

Vor der Behebung des Problems waren MQTT-Daten nicht in der uniqueID vorhanden:

Code Auswählen


################################################################
# [...]
################################################################

uniqueID:BBBBBBBBB
FRITZBOX_OG.WO.Fritzbox_passwd:AAAAAAAAA

Nach der Änderung in FHEMWEB und restart:

Code Auswählen


################################################################
# [...]
################################################################

uniqueID:BBBBBBBBB
FRITZBOX_OG.WO.Fritzbox_passwd:AAAAAAAAA
MQTTBroker_user:fhem
MQTTBroker_pass:XXXXXXXXX

Nachdem ich etwas Debugcode eingebaut habe, stellt sich die Situation wie folgt dar:

Code Auswählen


2017.05.07 17:53:49.039 1: getKeyValue(MQTTBroker_user): fhem
2017.05.07 17:53:49.039 1: getKeyValue(MQTTBroker_pass): XXXXXXXXX
2017.05.07 17:53:49.163 0: Server started with 419 defined entities (fhem.pl:14152/2017-05-01 perl:5.020002 os:linux user:root pid:1928)
2017.05.07 18:49:31.473 1: MQTTDEBUG, Undef()
2017.05.07 18:49:31.473 1: setKeyValue(MQTTBroker_user): undef
2017.05.07 18:49:31.475 1: setKeyValue(MQTTBroker_pass): undef
2017.05.07 18:49:31.500 1: Including fhem.cfg

Man sieht sehr schön, dass zunächst die korrekten Zugangsdaten vorliegen, dann aber die Werte durch die UndefFn von 00_MQTT explizit gelöscht werden. Lt. Doku wird die UndefFn sowohl bei delete als auch bei rereadcfg aufgerufen. Mir ist zugegebenermaßen nicht klar, was den Aufruf der UndefFn in meinem Fall ausgelöst hat. Dennoch ist das Löschen der Zugangsdaten an dieser Stelle m. E. ein Bug. 00_MQTT speichert die Logindaten nicht zwischen sondern bemüht bei Bedarf _immer_ getKeyValue. Rereadcfg würde die Daten also an der einzigen Stelle vernichten, an der sie vorliegen. Die Doku empiehlt derartige Arbeiten in der DeleteFn:

Zitat
[X_Delete] dient eher zum Aufräumen von dauerhaften Daten, welche durch das Modul evtl. für dieses Gerät spezifisch erstellt worden sind.

Patrick

eisler · 07 Mai 2017, 22:51:12

Hallo Patrick,

Danke fürs genaue Debuggen. Schaue ich mir noch mal genau an und werde das fixen.

Grüße
Stephan

Gisbert · 04 Juni 2017, 11:53:14

Hallo zusammen,

ich bin der Verzweifelung nahe.

Ich habe Linux upgedatet, dannach bekomme ich keine Verbindung mehr zum MQTT-Broker:

Code Auswählen

2017.06.04 11:22:17 3: Opening MyBroker device 192.168.178.26:1883
2017.06.04 11:22:17 3: Can't connect to 192.168.178.26:1883: Connection refused

Ich habe 00_MQTT.pm von der 1. Seite nach FHEM kopiert und vom update-Prozess ausgeschlossen; das hat bisher auch nach einem Linux-update immer funktioniert.

Wie bekomme ich wieder eine Verbindung?
Wie genau muss die Definition des MQTT, insbesondere user password aussehen?
Was muss ich noch beachten?

Viele Grüße Gisbert

eisler · 04 Juni 2017, 12:16:37

Hallo Gisbert,

läuft der MQTT-Broker nach dem update noch?

>Wie genau muss die Definition des MQTT, insbesondere user password aussehehn?

Code Auswählen

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

Code Auswählen

define MyBroker MQTT 192.168.178.26:1883 username password

Grüße
Stephan

Gisbert · 04 Juni 2017, 12:30:10

Hallo Stephan,

Zitatläuft der MQTT-Broker nach dem update noch?

Da hätte ich auch eher draufkommen können; danke für deine Hilfe.
Er lief nicht mehr - aber warum?
Bisher hat er nach einem reboot des RPi von selbst gestartet.
Mal sehen, wie ich das einstellen kann.

Nach der Definition des Brokers "verschwinden" user und password; ist das richtig so?

Code Auswählen

define MyBroker MQTT 192.168.178.26:1883 username password
Muss 00_MQTT.pm noch vom update auschlossen werden?

Im Moment läuft der MQTT-Broker wieder; ich werde mal ein reboot bei RPi versuchen.

Viele Grüße Gisbert

Gisbert · 04 Juni 2017, 12:53:24

Hallo Stephan,

nach einem reboot des RPi startet der MQTT service nicht von selbst wie vor dem update des RPi.

Noch 2 Fragen:
Wie kann ich den Start des Service automatisieren?
Muss 00_MQTT.pm weiterhin vom update ausgeschlossen werden?

Viele Grüße Gisbert

eisler · 04 Juni 2017, 13:18:37

Hallo Gisbert,

vermutlich muss dein mosquitto broker im autostart deines systems eingetragen sein.
Gab es einen Grund warum du die 00_MQTT.pm vom update ausgeschlossen hast?

Grüße
Stephan

Gisbert · 04 Juni 2017, 13:51:05

Hallo Stephan,

Mosquitto steht im Autostart:

Code Auswählen

/etc/init.d/mosquitto
fährt aber trotzdem bei Booten des RPi / Jessie nicht hoch.

Den Ausschluss des Moduls vom update hatte ich gemacht, da ich Probleme bei dem Setzen von user und password hatte.
Heißt das, dass ich 00_MQTT.pm wieder updaten sollte?
Ich werde es erst Ende nächster Woche probieren, da ich die zuhause gebliebenen nicht auf dem Trockenen sitzen lassen möchte.

Viele Grüße Gisbert

PatrickR · 04 Juni 2017, 14:40:30

Mahlzeit!

Zitat von: eisler am 07 Mai 2017, 22:51:12
Danke fürs genaue Debuggen. Schaue ich mir noch mal genau an und werde das fixen.

Wenn Du noch Hilfe brauchst, einfach melden.

Da ich aktuell schrittweise Geräte auf MQTT umstelle habe ich noch ein weiteres Anliegen. Ich müsste MQTT-Nachrichten mit Leerzeichen publishen können. publishSet scheint das aber nicht zuzulassen.

Patrick

Gisbert · 10 Juni 2017, 07:04:08

Zitat von: eisler am 04 Juni 2017, 13:18:37
Hallo Gisbert,

vermutlich muss dein mosquitto broker im autostart deines systems eingetragen sein.
Gab es einen Grund warum du die 00_MQTT.pm vom update ausgeschlossen hast?

Grüße
Stephan

Hallo Stephan,

zur obigen Vermutung konnte ich Hilfe bei meinem Sohn bekommen.
Um den Service dauerhaft nach einem Neustart des RPi zu bekommen, muss folgender Befehl beim RPi (Jessie) eingegeben werden:

Code Auswählen

sudo systemctl enable mosquitto.service

Zum anderen Thema:
Ich hab 00_MQTT.pm upgedated. Mit der Definition

Code Auswählen

define MyBroker MQTT 192.168.178.26:1883 user password
funktioniert MQTT, so dass es keinen Grund gibt 00_MQTT.pm vom update auszuschließen.

Viele Grüße Gisbert