publishSet "publisht" nicht immer

Strolchi · 13 November 2018, 20:06:54

Hallo,
ich bin erst seit ein paar Tagen mit FHEM unterwegs und hab ein Problem wozu ich trotz intensiver Suche keine Lösung gefunden habe.

FHEM und Mosquitto als MQTT-Broker laufen bei mir auf einem RaspberryPi 3. Das sieht zusammen insgesamt recht gut aus. FHEM und Mosquitto haben sich gefunden und verstehen sich untereinander auch meistens.

Nun zum Problem.
Ich habe ein MQTT_DEVICE angelegt um eine Lampe zwischen den Zuständen ON, OFF und AUTO umzuschalten.

Code Auswählen


defmod Gartenlampen MQTT_DEVICE
attr Gartenlampen IODev Mosquitto
attr Gartenlampen icon icoLichtBaum
attr Gartenlampen publishSet ON OFF AUTO 091/Gartenlampen
attr Gartenlampen room Garten
attr Gartenlampen stateFormat Gartenlampen
attr Gartenlampen subscribeReading_Gartenlampen 060/VH/Gartenlampen

setstate Gartenlampen AUTO
setstate Gartenlampen 2018-11-13 19:36:45 Gartenlampen AUTO
setstate Gartenlampen 2018-11-13 19:32:40 state AUTO
setstate Gartenlampen 2018-11-13 19:36:50 transmission-state subscribe sent

Die Umschaltung selbst funktioniert am PC. Der Zustand von "state" ändert sich mit jeder neuen Umschaltung/Auswahl.
Auch von einem Tablet aus bedient ändert sich "state" immer mit jeder neuen Eingabe.

Nur zu Mosquitto wird die Änderung nicht immer weiter geleitet. Das kontrolliere ich mit MQTT.fx".
Ich muss oft mehrmals hin und her schalten damit der MQTT-Broker eine geänderte Einstellung mitbekommt.
Woran kann das liegen?

Viele Grüße
Strolchi

hexenmeister · 13 November 2018, 20:35:37

Sehr strange. Normalerweise geht es, oder geht es gar nicht. Steht die Verbindung? Verbindungsabbrüche im Log? Welchen Status zeigt die MQTT-Instanz?

Probiere ggf., mal mit MQTT_GENERIC_BRIDGE und einem Dummy
Mein Beispiel für eine Deckenlampe ('auto' musst du noch da rein integrieren)

Code Auswählen

defmod DG_WZ_Licht_Top dummy
attr DG_WZ_Licht_Top devStateIcon off:light_light_dim_00@gray on:light_light_dim_100@#FF5722 .*:hourglass
attr DG_WZ_Licht_Top mqttForward none
attr DG_WZ_Licht_Top mqttPublish state|select:topic=/ha/dg/wz/licht/top/set
attr DG_WZ_Licht_Top mqttSubscribe state|select:topic=/ha/dg/wz/licht/top/state
attr DG_WZ_Licht_Top readingList select
attr DG_WZ_Licht_Top setList on:noArg off:noArg select:iconRadio,use4icon@000000,off,light_light_dim_00@808080,on,light_light_dim_100@808080
attr DG_WZ_Licht_Top webCmd select

Bridge (muss nur einmal definiert werden):

Code Auswählen

defmod mqttGenericBridge MQTT_GENERIC_BRIDGE
attr mqttGenericBridge IODev mqtt
attr mqttGenericBridge alias MQTT generic bridge
attr mqttGenericBridge icon mqtt
attr mqttGenericBridge stateFormat dev: device-count in: incoming-count out: outgoing-count

Strolchi · 13 November 2018, 21:07:24

Hallo und herzlichen Dank für die sehr schnelle Antwort.

Ich fange erst mal mit dem Log-File an. Das ist voll von folgenden Meldungen:

Code Auswählen


...
2018.02.28 23:59:04 1: 127.0.0.1:1883 reappeared (Mosquitto)
2018.02.28 23:59:04 1: 127.0.0.1:1883 disconnected, waiting to reappear (mqtt)
2018.02.28 23:59:09 1: 127.0.0.1:1883 reappeared (mqtt)
2018.02.28 23:59:09 1: 127.0.0.1:1883 disconnected, waiting to reappear (Mosquitto)
2018.02.28 23:59:14 1: 127.0.0.1:1883 reappeared (Mosquitto)
2018.02.28 23:59:14 1: 127.0.0.1:1883 disconnected, waiting to reappear (mqtt)
2018.02.28 23:59:19 1: 127.0.0.1:1883 reappeared (mqtt)
2018.02.28 23:59:19 1: 127.0.0.1:1883 disconnected, waiting to reappear (Mosquitto
...

also alle 5s ein disconnected und reconnected. Auch für den aktuellen Monat.

Ist das normal?
oder vielleicht schon die Ursache?
Wenn es nicht normal ist, wie kann ich dann den Fehler beseitigen?

Den restlichen Teilen der Antwort gehe ich erst nach wenn der ständige disconnected und reconnected nicht die Ursache für das Problem ist.

Gruß Strolchi

hexenmeister · 13 November 2018, 21:16:47

Nein, ist nicht normal und ist auch die Ursache. Wenn keine Verbindung, wird auch nicht gesendet.
Hind und wieder kann es schon passieren, aber alle 5 Sekunden? Ganz schlecht. Die MQTT-Instanz braucht leider recht lange, bis es sich wieer neu verbindet.
Die GenericBridge kann geringfügig helfen (sie Speichert die zu sendenden Nachrichten zwishen, wenn disconnected), aber das ist nicht 100% zuerlässig und Antworten kommen auch nicht an.

Probleme sind wohl im Netztwerk und/oder Konfiguration zu suchen. Warum? Da bin leider überfragt. Ich weiß jedoch, dass MQTT-Server die Verbindung schliesst, wenn sich mehrere Clients mit der gleichen ClientID anmelden. hast Du mehrere FHEM-Instanzen mit gleihen ClientID definiert?

Du kannst auch MQTT2-Module versuchen. Vlt. klappt dort die Verbindung besser. Die GenericBridge geht für MQTT2 jedoch noch nicht.

slor · 13 November 2018, 21:24:03

guck mal hier: https://github.com/klein0r/fhem-docker/issues/15
Ich hatte das Problem auch mal und habe es durch setzen von keep-alive auf 30 beheben können

Code Auswählen

attr MQTTBroker keep-alive 30

Strolchi · 13 November 2018, 22:50:34

Ein kleiner Zwischenbericht.
Netzwerkprobleme würde ich erst mal als unwahrscheinlich ansehen weil FHEM und der MQTT-Broker auf dem gleichen Raspberry laufen. Die reden über Localhost (127.0.0.1) Port 1883 miteinander.
Ob ich mehrere FHEM-Instanzen mit gleihen ClientIDs definiert habe??? Eigentlich nicht, es läuft nur eine FHEM-Instanz. Wie kann ich das kontrollieren? ClientIDs habe ich glaube ich nicht händisch definiert.
Genau weiß ich das aber nicht mehr. FHEM und Mosquitto habe ich im letzten Februar installiert. In meinem Alter vergisst man manchmal solche Details.

In Wahrheit findet dieses disconnected und reconnected Spielchen scheinbar mehrmals pro Sekunde statt. Scheinbar hat das Logfile nur 5s Auflösung.
Auszug aus dem Logfile von Mosquitto: Alle Einträge haben die gleiche Sekunde im Timestamp!!

Code Auswählen


...
1542086706: New connection from 127.0.0.1 on port 1883.
1542086706: Client NetMQTTpm604 already connected, closing old connection.
1542086706: Client NetMQTTpm604 disconnected.
1542086706: New client connected from 127.0.0.1 as NetMQTTpm604 (c1, k60).
1542086706: New connection from 127.0.0.1 on port 1883.
1542086706: Client NetMQTTpm604 already connected, closing old connection.
1542086706: Client NetMQTTpm604 disconnected.
1542086706: New client connected from 127.0.0.1 as NetMQTTpm604 (c1, k60).
...

Den Tipp mit "attr MQTTBroker keep-alive 30" habe ich auch probiert. Das hat aber nichts geändert. Den Link wegen "define MQTT_SERVER MQTT IP-Adresse:1883" habe ich erst mal nicht verstanden. Ich glaube nicht dass ich da noch was einstellen muss? FHEM und Mosquitto finden sich doch bei mir.

MQTT2-Module probiere ich wenn ich sonst keine Lösung finde. Ich bin ja noch ganz neu mit FHEM unterwegs. Hatte es zwar bereits im Februar installiert, aber bis gestern nichts damit gemacht. Deshalb weiß ich auch (noch) nicht was "die GenericBridge" ist, wozu man die gebrauchen kann und ob ich die künftig brauchen werde.

Gruß Strolchi

hexenmeister · 13 November 2018, 23:05:35

MQTT2_SERVER ist eine Art Mosquitto-Ersatz. Wenn schon, dann MQTT2_CLIENT.
MQTT_GENERIC_BRIDGE "verleiht" praktish jedem FHEM-Device eine Art "MQTT-Funktionalität", soll heißen, die Module MQTT_DEVICE und MQTT_BRIDGE werden nicht weiter benötigt, das notwendige Mapping an die MQTT-Topict definiert man dierekt in dem gewünschten Device mit entsprechenden mqtt* Attributen.

ClientID kannst Du versuchen zu setzen, schadet nicht, habe jedoch ehrlich gesagt wenig Hoffnung.
Was ich meine noch gehört zu haben, dass ähnliche Probleme mit einer alten Mosquitto-Version gegeben sein soll. Probiere mal diese zu aktualisieren.
Ggf. auch mal ein Update in FHEM.

Strolchi · 14 November 2018, 15:31:50

MQTT2_SERVER, MQTT2_CLIENT, MQTT_GENERIC_BRIDGE und MQTT_BRIDGE schaue ich mir an wenn es für meine geplanten Aufgaben nötig werden sollte.

FHEM und Mosquitto habe ich aktualisiert. Für beide gab es Updates, aber das Problem bestand danach weiterhin.

In meiner FHEM Installation sind auch die Devices "Mosquitto" und "mqtt" angelegt. Warum das so ist und ob ich die mal selbst integriert habe weiß ich nicht mehr.
Bei beiden Devices gibt es Settings (connect, disconnect und puplish).

Wenn ich bei dem Device "mqtt" 'disconnect' auswähle ist der ganze Zauber mit dem ständigen disconnected und reconnected zu Mosquitto vorbei.
Meine beiden bisher selbst angelegten " MQTT_DEVICE" funktionieren dann wie gewünscht tadellos. Die Umschaltung "ON OFF AUTO" (siehe Eingangspost) funktioniert dann auch vom Tablet aus.
Also alles im Lot und auch das Logfile und der Event monitor wird nicht mehr zugemüllt.

Das Device "mqtt" habe ich dann gelöscht und es funktioniert immer noch alles. Wofür es gut war, außer um Ärger zu machen, weiß ich nicht. Ich hoffe ich werde es künftig nicht mehr brauchen.

Es ist nicht geplant an den Raspberry irgendwelche Sensoren direkt anzuschließen. Aktuell gibt es einen Arduino und einen ESP8266 im Netzwerk welche dem MQTT-Broker Daten zuspielen.
FHEM soll mir erst mal nur dazu dienen diese Daten zu beobachten. Die gesamte Signal Ein- und Ausgabe soll komplett über MQTT laufen.

Was auf jeden Fall noch dazu soll sind Plotfuntionen für die Kurvendarstellung von analogen Messwerten. Und evtl. auch noch Datenbankfunktionen. Wahrscheinlich sind aber Plotfunktionen ohne Datenbank sinnlos weil man nicht in die Vergangenheit schauen kann?

Danke für eure Hilfe
Strolchi

hexenmeister · 14 November 2018, 17:15:27

Wenn ich richtig verstanden habe, hattest du zwei MQTT clients definiert die sich mit dem selben Server verbunden haben. Per default haben sie dann dieselbe Clientids, was zu dem beobachteten Problem geführt hat.

Plots sind auch am Basis von Logdateien möglich.

Strolchi · 14 November 2018, 19:45:29

Zitat von: hexenmeister am 14 November 2018, 17:15:27
Wenn ich richtig verstanden habe, hattest du zwei MQTT clients definiert die sich mit dem selben Server verbunden haben.
...

Wenn man genau hinschaut war es wohl so.

Code Auswählen

defmod mqtt MQTT 127.0.0.1:1883
und

Code Auswählen

defmod Mosquitto MQTT 127.0.0.1:1883
Als Einsteiger übersieht man dann leider mal die kleinen aber feinen Details. Hier zwei mal "MQTT" und zur kompletten Verwirrung dann noch ein mal der Name "mqtt".
Man glaubt ja nicht welchen Mist man bauen kann wenn man von der Materie keine Ahnung hat und die Zusammenhänge nur oberflächlich kennt.

Für den ersten Einstieg in die Plots und um zu sehen was die hergeben versuche ich es mal mit Logdateien für die Daten.
Wenn mir die Möglichkeiten der Plots zusagen kann ich dann immer noch auf die Datenbankversion umsteigen.
Die Datenbank selbst dürfte dann aber nicht auf dem Raspberry selbst liegen sondern auf einer Festplatte im Netzwerk wenn das möglich ist.
Vermutlich wegen dem Fehler von oben und den dadurch bedingten häufigen Schreibzugriffen auf die Logfiles hat mir der Raspberry nämlich innerhalb von 3 Monaten schon eine SD-Karte kaputt geschrieben. Ich bin da also ein gebranntes Kind.

An Daten kommt bei mir einiges zusammen. Alle 15s derzeit ca. 200 Messwerte. Tendenz steigend weil noch weitere ESPs oder Arduinos als Quelle dazu kommen sollen die ihrerseits auch ihre Messwerte los werden wollen.

Jedenfalls war dieser Thread für mich bisher sehr hilfreich.
Danke für die Unterstützung.
Strolchi