MQTT2 und LWT

[gestein]

Hallo,

Ich habe meine Shellys über MQTT2 angebunden.
Seit kurzem kämpfe ich damit, dass Shelly aus irgendwelchen Gründen offline gehen, aber fhem das nicht mitbekommt.

Wenn ich im MQTT2_Server das ,,verbose=5" setze, sieht man für viele Devices das PINGREQ/PINGRESP:

Code Auswählen Erweitern

2022.01.25 21:18:08.896 5: in@311 PINGREQ: (192)(0)
2022.01.25 21:18:08.897 4:   MQTT2_FHEM_Server_192.168.0.83_3374 shelly1pm-8CAAB5056CA8 PINGREQ
2022.01.25 21:18:08.897 5: out@311 PINGRESP: (208)(0)

Allerdings nicht für das betreffende Device.
Auch das Device selbst bringt mit ,,verbose=5" keine log-Einträge, die auf ein PINGREQ schließen lassen.

Wer stößt eigentlich das PINGREQ/PINGRESP regelmäßig an? Der MQTT2_Server oder das MQTT2_Device?

Und wenn mal ein PINGRESP ausbleibt, wird dann das regelmäßige PINGREQ eingestellt oder trotzdem noch wiederholt, bis das Gerät wieder online ist?

Wäre es möglich in den log-Einträgen des MQTT2_Servers für PINGREQ/PINGRESP auch die jeweilige IP-Adresse mitzuloggen?
Ansonsten ist es fast unmöglich das zu filtern.

Danke, Lg, Gerhard

[rudolfkoenig]

Seit kurzem kämpfe ich damit, dass Shelly aus irgendwelchen Gründen offline gehen, aber fhem das nicht mitbekommt.

Das ist moeglicherweise ein WLAN Problem, haeufig ausgeloest durch ueberlastung des Access-Points.

Wer stößt eigentlich das PINGREQ/PINGRESP regelmäßig an? Der MQTT2_Server oder das MQTT2_Device?

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718081
"The PINGREQ Packet is sent from a Client to the Server. ...".
MQTT2_SERVER antwortet mit PINGRESP, das kann man gut im Log sehen.

Wäre es möglich in den log-Einträgen des MQTT2_Servers für PINGREQ/PINGRESP auch die jeweilige IP-Adresse mitzuloggen?

In der Log-Message ist 311  (nach in@ oder out@) der FileDeskriptor der Verbindung, mehr Details ueber diese Verbindung kriegt man mit "list .* FD=311".
Da das muehsam ist, habe ich es durch die aktuelle IP:PORT Kombination ersetzt.

[gestein]

Hallo Rudi,

Es ist leider wirklich so, dass die WLAN-APs die Verbindung kappen, wenn zu viele Clients verbunden sind.
Ein Hersteller hat mir bestätigt, dass das bereits bei ca. 15-20 Clients passiert.

Daher ist WLAN für Smart Home eigentlich unbrauchbar.
Das sagt Dir aber niemand. Hat länger gedauert, bis ich das rausgefunden habe.

Da ich relativ viele Shelly habe, musst ich ein zusätzliches WLAN aufsetzen, dass explizit für die Shelly benutzt wird.
Und in den Shellys habe ich ein "backup WiFi" eingetragen, falls der die Verbindung verliert - mühsam.

Danke auch für die Erklärung bzgl. PINGREQ/PINGRESP.
Damit wird einiges klarer.
Auch die IP:Port-Kombination macht das dann leichter nachvollziehbar.

Warum aber das MQTT2-Device in fhem nicht auf offline geht, wenn keine PINGREQ mehr kommen, muss ich mir noch genauer anschauen.
Danke auf alle Fälle.

lg, Gerhard

[MadMax-FHEM]

Daher ist WLAN für Smart Home eigentlich unbrauchbar.
Das sagt Dir aber niemand. Hat länger gedauert, bis ich das rausgefunden habe.

In fast allen Threads wo "großmütig" WLAN-Geräte (inkl. Shelly etc.) als "super toll" angepriesen werden gibt es mindestens einen Beitrag, der genau das "sagt": WLAN für SmartHome naja bzw. man muss halt schauen, dass die Infrastruktur (inkl. Umgebung) das auch "ab kann"...

WLAN (im Gegensatz zu anderen SmartHome Funk-Systemen) ist halt eher "Dauerfunk", d.h. die "Luft ist voll" und nat. muss ein AP neben dem Funk auseinander halten auch die Clients "auseinanderhalten" und "bedienen" können (da braucht man nicht viel Wissen/Phantasie)...

Ganz "berühmt" ist ja (offenbar) Fritzbox und ESPs (und da gehören die Shelly dazu)...

Gruß, Joachim

[rudolfkoenig]

Daher ist WLAN für Smart Home eigentlich unbrauchbar.

Das ist so pauschal nicht richtig, ab einer bestimmten Anzahl von Endgeraeten muss man aber mit "passenden" Access-Points arbeiten.
Der Einstieg ist guenstiger, eine grosse Installation nicht unbedingt.

Warum aber das MQTT2-Device in fhem nicht auf offline geht, wenn keine PINGREQ mehr kommen, muss ich mir noch genauer anschauen.

Vermutlich weil der Client kein keepalive konfiguriert hat.
keepalive sagt dem Server, wie oft vom Client was kommen muss (z.Bsp. PINGREQ).
Beim Ausbleiben der Daten schliesst MQTT2_SERVER die Verbindung, und aktiviert LWT.

[Beta-User]

Vermutlich weil der Client kein keepalive konfiguriert hat.

Afaik haben die Shelly durchaus in der Regel eine "ordentliche" LWT-Implementierung.

Könnte es nicht sein, dass sich die jeweiligen Clients "immer mal wieder" (rechtzeitig) ins WLAN einbuchen können und dann den Ping erwartungsgemäß absetzen?

PS:
Den Effekt, dass ESP-basierte Geräte Anweisungen per MQTT nicht bekommen, obwohl sie "anscheinend" online sind (und insbesondere über das WEB-Interface direkt steuerbar waren), haben hier im Verlauf der Jahre mehrere User geschildert...

[gestein]

Da hat wohl der Frust aus mir gesprochen.
Es stimmt schon: Für den Einstieg ist Wlan ok, wenn man dann seine Installation vergrößern möchte, stößt man halt auf dieses Thema, das mich ziemlich gefrustet hat.
Wahrscheinlich habe ich auch das irgendwie gelesen, aber nicht richtig - für mich - zuordnen können.
Bis es mich dann betroffen hat.

Die Shellys schicken durchaus ein LWT:

Code Auswählen Erweitern

2022.01.26 13:11:08.577 5: in@370 CONNECT: (16)Q(0)(4)MQTT(4)(6)(0)<(0)(22)shelly1pm-D8BFC01A0D09(0)&shellies/shelly1pm-D8BFC01A0D09/online(0)(5)false
2022.01.26 13:11:08.577 4:   MQTT2_FHEM_Server_192.168.0.55_28885 cid:shelly1pm-D8BFC01A0D09 CONNECT V:4 keepAlive:60 LWT:shellies/shelly1pm-D8BFC01A0D09/online:false
2022.01.26 13:11:08.578 5: out@370 CONNACK:  (2)(0)(0)
Aber es scheint, dass das nicht alle geschickt haben. Zumindest finde ich nicht viele Einträge im Logfile wie ich Geräte habe.
Ich werde dann mal updaten und mir das länger anschauen.

Muss man das irgendwie im MQTT2-Device noch extra behandeln?
Oder passiert das automatisch?
Irgendwie blicke ich da noch nicht ganz durch.

Im MQTT2-Device gibt es nur den Eintrag für "online" in der readingList:

Code Auswählen Erweitern

shellies/shellydimmer2-D8BFC01A0128/online:.* online
Reicht das schon?

Danke, lg, Gerhard

[Beta-User]

MQTT2_(SERVER|DEVICE) machen mAn. an der Stelle alles richtig. Das Reading "online" wird passend gefüllt, wenn die Zeit für keepalive um ist, ohne dass eine ordentliche Abmeldung erfolgt ist (und der Server das meldet, was uU. etwas länger dauert als nur keepalive zu beachten). Darauf kann man dann z.B. auch einen Eventhandler ansetzen.

Ansonsten bin ich durchaus froh, dass zwischenzeitlich einige Leute den "Vorsicht vor zu viel WLAN-Gedöns mit Consumer-Routern"-Zwischenruf kennen... Dass das durchaus seltsame Blüten treiben kann, wenn es nicht 100% funktioniert, haben wir schon an einigen Stellen geschildert bekommen, es scheint sich halt immer wieder (geringfügig) anders bemerkbar zu machen, wenn der Router "wackelt". Leider kann ich auf die Schnelle auch nicht behaupten, dass es eine stressfreie Alternative geben würde.

FYI: Zwischenzeitlich gibt es eine ganze Reihe an ZigBee-Zeug, bei dem nur der Basischip anders zu sein scheint (auf der Packung gibt es Kleber zum ankreuzen...), also statt des WLAN-TYWE3S dann eben (vermutlich) ein TYZS3 oder TYZS4 verbaut ist - die kosten in China dann grade mal 1-2€ mehr wie die WLAN-Varianten. Kann aber noch nicht wirklich sagen, ob das Zeug zuverlässig läuft. deconz erkennt die jedenfalls in der Regel völlig stressfrei...

[gestein]

D.h., der Server merkt sich intern, welche Geräte über das keepalive zu beobachten sind.
Wenn keine LWT-Meldung vom Gerät zum Server kommt, dann tut der Server auch nichts. Richtig?

ZigBee scheint wirklich eine interessante Alternative zu werden.
Bisher hatte ich "nur" die Bewegungsmelder über deConz eingebunden.
Als ich dann einen Bewegungsmelder weiter weg in der Wohnung platzieren wollte, kam keine stabile Verbindung mehr zu stande.
Daraufhin habe ich mir mal schnell einen Zwischenstecker gekauft, denn "angeblich" sollen ja alle ZigBee-Geräte, die ständig am Stromnetz hängen, auch als "Repeater" funktionieren.
Also einfach eingesteckt, bei deConz angelernt und schon war der Bewegungsmelder erreichbar.
Scheint wirklich vielversprechend zu sein.

lg, Gerhard

[Beta-User]

D.h., der Server merkt sich intern, welche Geräte über das keepalive zu beobachten sind.
Wenn keine LWT-Meldung vom Gerät zum Server kommt, dann tut der Server auch nichts. Richtig?

Jein. Der Client meldet seine diesbezüglichen "Wünsche" am Server an. Der Server merkt sich das und sendet ggf. dann entsprechende Infos an die weiteren Clients, wenn die Bedingungen passen...
Insgesamt eine m.E. empfehlenswerte Darstellung, hier zu "LWT":
https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/ (ggf. einen Übersetzer bemühen).

ZigBee scheint wirklich eine interessante Alternative zu werden.

...wenn es günstig sein soll...
Ich meine, es sei eine brauchbare Alternative, habe aber auch an einigen Stellen schon "seltsame" Erfahrungen gemacht, und nicht alles Material ist empfehlenswert... Die Bandbreite geht von "Schrott bei Auslieferung" bis "Wow", und das läßt sich leider nicht immer nur ausschließlich am Preis und/oder der Marke festmachen. Was ich in letzter Zeit feststelle ist eine gewisse Standardisierung auf die "Tuya"-Chipsätze, und die scheinen (zunehmend) tauglich zu sein. (die sind aber mWn. auch in Sonoff-Bewegungsmeldern drin: die, die ich unter dieser Bezeichnung in der Hand hatte gehören zur Kategorie "Schrott bei Auslieferung"...)

Für Rollladenaktoren würde ich z.B. immer die ZWave-Variante nehmen, obwohl es die zwischenzeitlich zu einem Bruchteil auch in ZigBee gibt...