Verbindung zw Fhem und MQTT2 4CH RElais verloren auf Port 1883

[TomLee]

(beide online)

Sicher ?

Der obige Befehl (list .* keepalive lwt) zeigt nur dann was Relevantes an, wenn das fragliche Geraet gerade Kontakt zu FHEM hat, weil damit die Verbindungsdaten abgefragt werden (das was "zaehlt").

Schau mal jetzt in der Konsole von 192.168.1.7 was da abgeht, ist da alles normal ?

[DieterN]

(beide online)

Sicher ?

Der obige Befehl (list .* keepalive lwt) zeigt nur dann was Relevantes an, wenn das fragliche Geraet gerade Kontakt zu FHEM hat, weil damit die Verbindungsdaten abgefragt werden (das was "zaehlt").

Schau mal jetzt in der Konsole von 192.168.1.7 was da abgeht, ist da alles normal ?

ja, nur die Uhrzeit war nicht aktuell. Mittlerweile schon. ich glaube es waren beide Device nicht online. Ping war nicht erfolgreich.

Ich glaube wir (ich) muss den Test nochmal geziehlt machen.

[DieterN]

(beide online)

Sicher ?

Der obige Befehl (list .* keepalive lwt) zeigt nur dann was Relevantes an, wenn das fragliche Geraet gerade Kontakt zu FHEM hat, weil damit die Verbindungsdaten abgefragt werden (das was "zaehlt").

Schau mal jetzt in der Konsole von 192.168.1.7 was da abgeht, ist da alles normal ?

nein. War nicht online

[Beta-User]

Ich glaube wir (ich) muss den Test nochmal geziehlt machen.

...Soweit von hier erkennbar, macht LWT doch genau das, was man von ihm erwartet. Der MQTT2_SERVER muss halt warten, bis er ein Device wirklich für "tot" erklären kann und das Testament eröffnen darf. Oder was genau ist jetzt noch das Problem (außer der miesen WLAN-Verbindung)?

[DieterN]

Hallo hier zwei Sreenshots.
Warum hat das eine Device als MQTT host die Adr, des anderen Devices?
Das wird der Grund sein, warum hier alles durcheinander kommt.

Habe jetzt in beiden Konsolen MqttHost eingegeben und jetzt erscheint in Fhem: MqttHost 192.168.1.101(Fhem Server Adr)
Sollte jetzt so stimmen oder?
BG Dieter

[Beta-User]

Keine Ahnung, warum deine Devices überhaupt dieses Reading "MqttHost" haben, aber in der Tasmota-MQTT-Konfiguration kommt unter "Host ()" in jedem Fall die IP-Adresse des MQTT-Servers (hier also deines FHEM-Rechners) rein - selbstredend bei beiden.

Und kannst du bitte künftig statt screenshots TEXT liefern, wenn es um FHEM geht?

Warum? Aus dem alten "copy for forum" (das war nur bei einem Device drin, und offenkundig ist es "uralt"):

Code Auswählen Erweitern

#     2023-12-24 12:51:31   MqttHost        192.168.1.6Wegen des Alters gehe ich nicht davon aus, dass das noch irgendeine Auswirkung hatte => wirf die SSID der Fritte aus der WLAN-Konfiguration der Devices...

[DieterN]

Und kannst du bitte künftig statt screenshots TEXT liefern, wenn es um FHEM geht?

mach ich.

wirf die SSID der Fritte aus der WLAN-Konfiguration der Devices...

habe ich raus.
Jetzt steht bei beiden Devices 192.168.1.101(Fhem Server)

Vielen Dank

[DieterN]

jetzt habe ich noch das 73_PRESENCE.pm Modul getauscht.(Gegen das vorletzte aus dem Chat)
Aber ich soll ja nicht mit lan-ping abfragen sondern mit LWT offline!!

Kannst du mir auf die Schnelle verraten wie das geht konkret?
Wie komme ich an das reading?

BG Dieter

[Beta-User]

wirf die SSID der Fritte aus der WLAN-Konfiguration der Devices...

habe ich raus.
Jetzt steht bei beiden Devices 192.168.1.101(Fhem Server)

Den Zusammenhang zwischen diesen beiden Dingen verstehe ich nicht, aber ist auch egal...

Kannst du mir auf die Schnelle verraten wie das geht konkret?

Man nehme ein notify, baue den trigger (ggf. mit Hilfe des wizzards) so, dass er auf diese beiden Devices und das Event "LWT:.Offline" höre, und sende dann seine Nachricht. Ist doch auch nicht anders wie das, was du bisher mit dem Zwischenschritt über PRESENCE gemacht hast...

[DieterN]

Man nehme ein notify, baue den trigger (ggf. mit Hilfe des wizzards) so, dass er auf diese beiden Devices und das Event "LWT:.Offline" höre, und sende dann seine Nachricht. Ist doch auch nicht anders wie das, was du bisher mit dem Zwischenschritt über PRESENCE gemacht hast...

Hi
so geht es nicht:
notify mit:
MQTT2_DVES_55220C:LWT:.Offline { DebianMail(........)} (mit wizzard)

[TomLee]

Wenn ein FHEM-Device oder eine Automatisierung nicht so funktioniert, wie ihr euch das vorstellt, macht ein "list" aller beteiligten Devices und copy/pastet den Output in euren post

Code Auswählen Erweitern

list <devicename>

Helfer triggert man immer mit Informationen, zuviel gibts nicht. Grundvoraussetzung (das mindeste) das überhaupt jemand helfen könnte, ohne in die Glaskugel zu schauen, sind die oben genannten, hier am besten im zeitlichen Zusammenhang.

[rudolfkoenig]

so geht es nicht:
notify mit:
MQTT2_DVES_55220C:LWT:.Offline { DebianMail(........)} (mit wizzard)

Dass es prinizipiell geht, habe ich mit folgender fhem.cfg

Code Auswählen Erweitern

define a autocreate
define m2s MQTT2_SERVER 1883
define n notify MQTT2_m2pub:LWT:.Offline { Log 1, "Hello" }
und danach diesem Befehl im Shell:

Code Auswählen Erweitern

mosquitto_sub -i m2pub --will-topic LWT --will-payload Offline -t '#' & sleep 1 ; kill -9 %1
verifiziert.

Dabei ist mir ein Kommentar im Code aufgefallen: "no LWT on disconnect, see doc, chapter 3.14". Da steht:

On receipt of DISCONNECT the Server:
MUST discard any Will Message associated with the current connection without publishing it, as described in Section 3.1.2.5

D.h. wenn die Gegenseite "Tschuess" sagt, dann wird kein Testament eroeffnet.

[DieterN]

Hallo Rudolf
vielen Dank für deinen Einsatz und Hilfe.
Jetzt geht es.
Der Fehler war ,ich habe das NOTIFY erstellt nachdem das Device offline war. Nach einschalten und warten von 20 min.
kam das Mail und der LOG Eintrag : MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.1.6_50506/DVES_55220C left us (keepalive check)
Habe jetzt alle lan-ping bis auf den ping auf mein Handy auf notify geändert.

PS: warum ist das alternative Modul 73_PRESENCE.pm aus dem Chat nicht Standard? und welches Modul aus dem Chat ist das aktuelle?
Es gibt 4 verschiedene Versionen im Chat. Das letzte füllt den log voll. Ich habe das vorletzte im Einsatz

[Beta-User]

PS: warum ist das alternative Modul 73_PRESENCE.pm aus dem Chat nicht Standard? und welches Modul aus dem Chat ist das aktuelle?
Es gibt 4 verschiedene Versionen im Chat. Das letzte füllt den log voll. Ich habe das vorletzte im Einsatz

Du hast schon gesehen, dass der Autor der "Spezialversion" eine längere Erklärung geliefert hat, warum er Handlungsbedarf sieht, aber definitiv klargestellt, dass er nicht dauerhaft die Pflege übernehmen will oder ein "PRESENCE2" maintainen?

Ist halt so: der, der den Hut auf hat entscheidet, was rein kommt in die "offizielle" Fassung. Und: es gibt einen (anderen) neuen Maintainer. Mal schauen, wie es damit dann weitergeht, bin optimistisch, dass die Einarbeitungswewehchen dann auch bald Vergangenheit sind .

@Rudi:
Kann es sein, dass LWT "vergessen" wird, wenn man den FHEM-Server neu startet, nicht aber die Clients? Zumindest war das meine Vermutung nach einem kurzen Test neulich. Wäre zumindest spontan dafür, diese Infos nicht "zu vergessen"... (habe aber nicht gesucht, was andere Server-Dienste mit den LWT-Infos anstellen, wenn man die neu startet).

[rudolfkoenig]

Kann es sein, dass LWT "vergessen" wird, wenn man den FHEM-Server neu startet, nicht aber die Clients?

Normalerweise nicht: die Clients muessen sich neu anmelden, und LWT ist Teil der CONNECT Nachricht.
Wenn aber ein Client danach sich nicht mehr neu anmeldet, kriegen die Anderen das nicht mit.
Habe z.Zt. auch keine Idee, wie man so ein "Loch" stopft.