Shelly1 verbindet sich nicht wieder mit MQTT2_FHEM_Server Access-Point-Änderung

[hal9000]

Hallo zusammen,

ich bin neu hier im Forum. Ich würde mich ganz und gar nicht als FHEM-Experten bezeichnen, aber ich verwende FHEM schon länger auf einem Raspi um beispielsweise Shelly1-Devices anzusteuern und konnte bisher alle Probleme durch Suchen in Forumsbeiträgen lösen. Jetzt hab ich ein hartnäckiges Problem, bei dem ich nicht weiterkomme.

Das Setup: FHEM auf Raspi. Unter anderem 8 Shelly 1 und Shelly 2.5 Schalter, die mit dem eigenbauten MQTT2_FHEM_Server reden (bei den Shellies ist das MQTT-Protokoll der Orginial-FW aktiviert).

7 Shellies hingen über Wifi an einem Access Point, 1 Shelly wegen Reichweitenproblemen an einem anderen. Hat alles wunderbar geklappt, bis ich die Wifi-Anordnung geändert habe: jetzt hängen alle 8 Shellies an dem einen Access Point. Effekt: der Shelly, der umgezogen wurde, ist weiterhin über sein eigenbautes Web-Interface erreichbar, aber das MQTT2-Device (heißt bei mir MQTT2_Shelly_1_05_EG_Wintergarten) zeigt ihn jetzt als offline an. Man kann zwar im Device schalten und das Lampen-Icon ändert sich - aber das ganze wird wohl nicht weitergereicht - die dazugehörige physikalische Lampe geht nicht an.

Der Effekt ist auch in der Konstellation mit 2 Access-Points sporadisch aufgetreten: in den seltenen Fällen, in denen die Empfangsverhältnise so waren, dass sich MQTT2_Shelly_1_05_EG_Wintergarten mit dem 1. AC verbunden hat, ging das Setup nicht. Als es wieder umgesprungen ist auf den 2. AC ging es (ohne Konfigurationsänderung).

Nach dem Umbau hab ich auch das device MQTT2_Shelly_1_05_EG_Wintergarten gelöscht und per autocreate wieder einbinden lassen. Das ging auch alles, aber es gibt trotzdem keine Kommunikation mit dem Device.

list MQTT2_FHEM_Server liefert:

Code Auswählen Erweitern


Internals:
   CONNECTS   19
   DEF        1883 global
   FD         21
   FUUID      5e1a4392-f33f-a35d-5476-928764d1c54ed5b0
   NAME       MQTT2_FHEM_Server
   NR         132
   PORT       1883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   READINGS:
     2020-07-09 13:48:13   RETAIN          {"tele/DVES_68B3F2/LWT":"Offline","tele/DVES_9188F0/LWT":"Offline","tele/DVES_953FCC/LWT":"Online","tele/DVES_CB2FEE/LWT":"Online","tele/tasmota/LWT":"Online"}
     2020-07-09 14:26:11   nrclients       8
     2020-07-09 13:48:08   state           Initialized
   clients:
     MQTT2_FHEM_Server_192.168.188.57_12744 1
     MQTT2_FHEM_Server_192.168.188.62_23157 1
     MQTT2_FHEM_Server_192.168.188.67_62007 1
     MQTT2_FHEM_Server_192.168.188.68_57449 1
     MQTT2_FHEM_Server_192.168.188.69_13030 1
     MQTT2_FHEM_Server_192.168.188.70_15972 1
     MQTT2_FHEM_Server_192.168.188.72_4281 1
     MQTT2_FHEM_Server_192.168.188.73_54629 1
   retain:
     tele/DVES_68B3F2/LWT:
       ts         1594295288.85184
       val        Offline
     tele/DVES_9188F0/LWT:
       ts         1594295288.85184
       val        Offline
     tele/DVES_953FCC/LWT:
       ts         1594295293.00066
       val        Online
     tele/DVES_CB2FEE/LWT:
       ts         1594295292.93625
       val        Online
     tele/tasmota/LWT:
       ts         1594295288.85184
       val        Online
Attributes:
   autocreate simple
   room       Dummies,MQTT2_DEVICE
   verbose    1


list MQTT2_Shelly_1_05_EG_Wintergarten:

Code Auswählen Erweitern


Internals:
   CFGFN     
   CID        shelly1_76F3A6
   DEF        shelly1_76F3A6
   DEVICETOPIC MQTT2_Shelly_1_05_EG_Wintergarten
   FUUID      5f07064a-f33f-a35d-4ee3-57b5de493c63cf26
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 16
   MQTT2_FHEM_Server_TIME 2020-07-09 14:26:11
   MSGCNT     16
   NAME       MQTT2_Shelly_1_05_EG_Wintergarten
   NR         296
   STATE      off
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2020-07-09 14:00:13   attrTemplateVersion 20200522 or prior
     2020-07-09 14:02:30   event           
     2020-07-09 14:02:30   event_cnt       0
     2020-07-09 14:02:00   fw_ver          20200601-122823/v1.7.0@d7961837
     2020-07-09 14:02:00   id              shelly1-76F3A6
     2020-07-09 14:02:30   input0          0
     2020-07-09 14:02:00   ip              192.168.188.71
     2020-07-09 14:02:00   mac             DC4F2276F3A6
     2020-07-09 14:02:00   new_fw          false
     2020-07-09 14:26:11   online          false
     2020-07-09 14:02:30   relay0          off
     2020-07-09 16:21:53   state           off
Attributes:
   IODev      MQTT2_FHEM_Server
   devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $light = ReadingsVal($name,"state","off");; my $show = '<a href="';;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>" }
   model      shelly1
   readingList shellies/shelly1-76F3A6/relay/0:.* state
  shellies/shelly1-76F3A6/relay/0:.* relay0
  shellies/shelly1-76F3A6/input/0:.* input0
  shellies/shelly1-76F3A6/online:.* online
  shellies/shelly1-76F3A6/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shelly1-76F3A6...mac.*, ? json2nameValue($EVENT) : return }
shelly1_76F3A6:shellies/shelly1-76F3A6/input_event/0:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shelly1-76F3A6/relay/0/command off
  on:noArg shellies/shelly1-76F3A6/relay/0/command on
  x_update:noArg shellies/shelly1-76F3A6/command update_fw
  x_mqttcom shellies/shelly1-76F3A6/command $EVTPART1


Ein funktionierendes Device sieht so aus (list MQTT2_Shelly_1_06_EG_Kueche):

Code Auswählen Erweitern


Internals:
   CID        shelly1_76FCC6
   DEF        shelly1_76FCC6
   DEVICETOPIC MQTT2_Shelly_1_06_EG_Kueche
   FUUID      5e9441e2-f33f-a35d-00f1-f7d2912ed4163e14
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 989
   MQTT2_FHEM_Server_TIME 2020-07-09 16:30:17
   MSGCNT     989
   NAME       MQTT2_Shelly_1_06_EG_Kueche
   NR         161
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2020-07-09 16:30:17   event           S
     2020-07-09 16:30:17   event_cnt       43
     2020-07-09 13:48:16   fw_ver          20200601-122823/v1.7.0@d7961837
     2020-07-09 13:48:16   id              shelly1-76FCC6
     2020-07-09 16:30:17   input0          0
     2020-07-09 13:48:16   ip              192.168.188.72
     2020-06-06 12:03:02   longpush_0      0
     2020-07-09 13:48:16   mac             DC4F2276FCC6
     2020-07-09 13:48:16   new_fw          false
     2020-07-09 13:48:16   online          true
     2020-07-09 16:30:17   relay0          off
     2020-07-09 16:30:17   state           off
Attributes:
   IODev      MQTT2_FHEM_Server
   devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $light = ReadingsVal($name,"state","off");; my $show = '<a href="';;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a>" }
   model      shelly1
   readingList shellies/shelly1-76FCC6/relay/0:.* state
  shellies/shelly1-76FCC6/relay/0:.* relay0
  shellies/shelly1-76FCC6/input/0:.* input0
  shellies/shelly1-76FCC6/online:.* online
  shellies/shelly1-76FCC6/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shelly1-76FCC6...mac.*, ? json2nameValue($EVENT) : undef }
shelly1_76FCC6:shellies/shelly1-76FCC6/longpush/0:.* longpush_0
shelly1_76FCC6:shellies/shelly1-76FCC6/input_event/0:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shelly1-76FCC6/relay/0/command off
  on:noArg shellies/shelly1-76FCC6/relay/0/command on
  x_update:noArg shellies/shelly1-76FCC6/command update_fw
  x_mqttcom shellies/shelly1-76FCC6/command $EVTPART1


Eine Auffälligkeit gibt es: alle funktionierenden Devices haben clients im MQTT2 Server (z.B. MQTT2_FHEM_Server_192.168.188.72_4281 1) - der Problem-Shelly hat das nicht (da wäre die IP 192.168.188.71). Ich weiß nicht, wo die Clients herkommen und was sie machen (sie stehen auch nicht im Config-File), aber offensichtlich enthalten sie ja eine IP und einen Port im Namen und ich nehme an, sie entstehen dynamisch.

Ich frage mich nun, was für FHEM anders ist in Abhängigkeit davon, ob ein Shelly über den einen oder andern Accesspoint angebunden ist (IP-Adresse und Port sind es ja wohl nicht). Auch in den Devices ist mir kein Parameter aufgefallen, der Access-Point abhängig ist. Daher frage ich mich, WAS sich FHEM irgendwo gemerkt hat, dass es es nicht möglich ist, ein Device über einen anderen AC neu anzulegen - offensichtlich funktioniert ja das autocreate nicht korrekt: nach einem delete, sollte doch ein Device wieder neu und frisch angelegt werden können.

Es könnte einen Zusammenhang geben mit diesem Thread: https://forum.fhem.de/index.php?topic=105933.0 - aber da steht leider keine Lösung.

Mir raucht jedenfalls inzwischen der Kopf und es wäre Klasse, wenn ihr mir helfen könntet.

Gruß,

Peter

[Beta-User]

Erst mal herzlich willkommen hier im Forum!

Für mich sieht das wie ein WLAN-Problem aus, mit der Tendenz dazu, dass der ESP auf dem betreffenden Shelly einfach einen Hau hat.

Der Reihe nach: Für jedes Gerät hält MQTT2_SERVER eine Verbindung offen - das sind die temporären Devices, die du siehst (das ist dasselbe wie bei FHEMWEB, da gibt es auch mehrere temporäre Instanzen, wenn man verbunden ist).
Bricht die Verbindung weg, muß sie neu aufgebaut werden, und irgendwas klappt dabei nicht richtig, deswegen geht das device dann - nach Ablauf der "LWT"-Frist - auf "offline", und solange der Client (=der ESP) die Verbindung nicht wieder neu aufmacht, kann der SERVER auch nichts ausliefern...

Vielleicht lieferst du etwas mehr Infos zu Art deiner AP's, und gleich vorneweg: AVM-Geräte (und eine Reihe anderer Consumer-line-Router) sind leider "berüchtigt" für schlechtes WLAN (v.a. iVm. ESP8266) und schlechtes Netzwerkmanagement - teils beträgt die Zahl der "zulässigen" Clients nur 10-20...

[hal9000]

Danke für die schnelle Antwort.

Der AC bei dem alles funktioniert ist eine FritzBox 7390. Manche Shellies adressiert er direkt, manche über einen FritzRepeater 1200. Der zweite AC ist ein Linksys 18154. Der Linksys ist per Kabel mit der FritzBox verbunden.

Der Problem-Shelly hat anstandslos und wochenlang über den Linksys -> FritzRepeater 1200 funktioniert. Die anderen Shellies über die FritzBox mit und ohne FritzRepeater.  Alles stabil über Wochen und Monate.

Nur beim Umhängen des Problem-Shellies zur FritzBox gibt es jetzt Probleme (und zwar nicht sporadisch - sondern es kommt erst gar nicht zum Laufen). Der Shelly hat auch dieselben Einstellungen wie die anderen. Die Einstellungen wurden nie geändert.

Alles Shellies sind immer über ihr Web-IF erreichbar - egal wo sie hängen.

Wenn ich jetzt einen neuen Shelly einbinde, wird er sofort funktionieren. Nur der Shelly, der mal über einen anderen AC eingebunden wurde, lässt sich nicht mehr richtig neu einbinden ...

[Beta-User]

Hmm, wie gesagt: "Fritte" ist gerne mal komisch. Die Verbindung via MQTT ist aber etwas anders gestrickt als HTTP, evtl. ist da auch einfach die Implementierung in dem Shelly ein Problem. (Update+factory-reset hast du schon durch, nehme ich mal an?)

Wie adressierst du den MQTT-Sever? Über die IP oder den hostname?

(Evtl. solltest du das statement "wird sofort funktionieren" mal in der Praxis austesten; evtl. hast du auch einfach einen neuen (W)LAN-Teilnehmer (neues Tablet, Handy, "Smart-TV" oä.), der die Fritte aus dem Tritt bringt (ich habe dieses Modell auch, und das Netzwerkmanagement ist teils auch bei meiner definitiv "komisch"... )).

[hal9000]

Der MQTT2 wird über die IP + Port adressiert.

FHEM ist upgedated, der Shelly ist auf dem neuesten SW-Strand, einen Factory beim Shelly hab ich aber tatsächlich noch nicht gemacht - werde ich dann mal probieren.

Werde auch mal einen frischen Shelly einhängen und den AC wechseln um zu sehen, was dann passiert. Du hast natürlich Recht: von hat mal funktioniert und funktioniert jetzt immer noch kann es einen Unterschied geben ...

[hal9000]

Factory Reset vom Shelly hat schon mal nichts gebracht.

[hal9000]

Inzwischen hab ich einen neuen Shelly-Schalter eingebaut: der funktioniert mit beiden Access Points in FHEM.

Der alte Shelly hat nach wie vor das Problem, dass er an einem AP über MQTT in FHEM eingebunden werden kann, über den anderen AP aber nicht. Wiederholte Factory-Resets haben nichts gebracht. FW-Versionen und MQTT-Einstellungen in beiden Shellies sind gleich (latest). In beiden APs sind beide Shellies sichtbar und über HTTP problemlos ansprechbar.

Also doch die MQTT-FW im alten Shelly geshreddert?

Es bleibt allerdings die Frage, wie sich das Verhalten erklären lässt: das MQTT-Protokoll sollte doch von beiden APs transparent zu FHEM durchgereicht werden. Gibt es irgendeine kritische Einstellung in den APs, die den Unterschied erklärbar macht?

[Nobbynews]

Es stellt sich für mich noch die Frage, wie Du das Umschwitchen auf einen anderen AP angestellt hast.
Unterschiedliche SSIDs?
Grundsätzlich würde ich mal behaupten, dass MQTT und WLan nichts mit einander zu tun haben.

[hal9000]

Der 1. AP ist eine Fritzbox, über Kabel ist ein Syslink AP verbunden. SSIDs sind identisch. Ich nehme mal an, dass es der Wlan-Client im Shelly ist, der sich den stärksten AP raussucht. Das Verbinden mit den APs ist auch kein Problem der Shelly in jedem Fall über das WEB-IF erreichbar.

Über den Syslink klappt's, über die Fritzbox nicht. Und das, obwohl ausgerechnet die Fritzbox ja das ganze Switching macht (über einen weiteren Switch, da hängt zB der Raspi mit FHEM dran).

[MadMax-FHEM]

Wenn die SSIDs identisch sind, wie willst du dann den Shelly/Client "zwingen" wo er hingeht!?

Er sucht sich halt raus was ihm besser gefällt...

Kurzzeitig "erzwingen" kannst du es, wenn du den "ungewollten" AP ausschaltest, wartest bis der Client verbunden ist (sollte ja dann mit dem gewünschten AP "müssen" ) und dann den anderen AP wieder einschalten...

ABER: das wird nicht dauerhaft halten (wenn dem Shelly nunmal der andere AP besser gefällt)

Ich habe ein Unifi mit 3 APs und da sucht sich auch jeder Client was ihm so gefällt...
...ich dachte auch mal ich wüsste wie sich die Clients verteilen müssten

Gut manchmal helfe ich dann schon nach, wenn sich ein Client (meiner Meinung nach) komplett "verlaufen" hat -> disconnect Client -> neue Chance einer "besseren" Verbindung...
(meistens nimmt er dann auch den AP den ich wollte, dass er nimmt  ABER: nicht immer, manchmal bleibt er nach dem "disconnect client" auch stooisch bei dem AP, dann lasse ich es gut sein   )

EDIT: einzig wenn du den Client auf eine bestimmte AP-MAC "nageln" kannst, dann kannst du das auch bei gleicher SSID erzwingen... Sonst denke ich eher: nein.

Gruß, Joachim

[hal9000]

Es geht mir ja gar nicht drum den AP zu erzwingen - soll sich der Shelly doch ruhig den besten AP raussuchen. Das macht FHEM ja auch in der Regel nichts aus.

Zum Testen bin ich jeweils in die Nähe und hab sichergestellt, dass der Shelly mit dem jeweiligen AP verbunden ist - das war auch stabil der Fall.

Das Problem war (jetzt mit einem neuen Shelly geht es): ich hab die Netzwerktopologie gerändert und damit war der eingebaute Shelly mit einem anderen AP (im selben Netzwerk) als vorher verbunden und da konnte FHEM keine Verbindung mehr herstellen (über HTTP aber schon) - das ist auch immer noch reproduzierbar. Das würde ich gerne verstehen und beheben - weil so ist der ausgebaute Shelly ja nicht mehr zu gebrauchen.

Gruß, Peter

[MadMax-FHEM]

Naja dann solltest du vielleicht mal die Topologie vorher/nachher genau erläutern.

Irgendwelche vLANs?
Irgendwelche Switche die irgendwas "sperren"!?

Firewall-Regeln die nur http/https (80/443) durchlassen und andere (ich weiß nicht was mqtt nutzt) blocken!?

Gruß, Joachim

[Nobbynews]

Und das, obwohl ausgerechnet die Fritzbox ja das ganze Switching macht (über einen weiteren Switch, da hängt zB der Raspi mit FHEM dran).

Was für ein Switching macht die Fritzbox?
Evtl. mal in der Fritzbox unter den Netzwerkverbindungen nach alten und ungenutzten Verbindungen zum Problem-Shelly suchen und löschen.
Hast Du mal versucht das Wlan im Shelly von Wifi Mode Client auf Wifi Mode Access Point umzustellen und dann über das aufgespannte Wlan die config noch einmal durchzuführen?

[hal9000]

Die Topologie (alles eine SSID):

- Fritzbox 7390 = AP1 - die hat einen eingebauten 4-fach Switch - daran hängt ein TP-Link Switch - daran hängt der Raspi mit FHEM
- Ein Linksys 18154 im Bridge-Modus = AP2 (hat auch noch einen 4-fach Switch, aber da geht nix drüber) - hängt per Ethernet an der Fritzbox
- Ein Fritz Repeater 12000 verlängert noch die Reichweiter vom AP1

vLans gibt es keine.

Habe jede Menge Shellies:
(1) Manche gehen direkt über AP1
(2) Manche gehen über AP1 und Repeater
(3) Manche gehen über AP2

Alle Shellies (Konfiguration 1 - 3) funktionieren jetzt und werden in FHEM eingebunden. Alle Kommunikation geht immer über den Switch vom AP1 und den TP-Link-Switch zum Raspi und FHEM - die Switches scheiden also als Fehlerquelle aus.

Die Repeater scheiden auch aus, weil einige Shellies mit und andere ohne funktionieren; bei einzelnen Shellies hab ich das auch getestet und das ging.

Der Shelly, den ich rausgeschmissen habe, hing in der Vergangenheit am AP2 (also 3), da war damals auch noch ein Repeater dazwischen - sollte aber keine Rolle spielen. Hat gut funktioniert. Habe aber sporadisch beobachtet, dass die FHEM-Verbindung weg war, wenn die Verbindung mal spontan auf AP1 (also 1) umgesprungen ist, was gelegentlich mal passiert ist. Sobald er wieder über AP2 + Repeater ging, hat er funktioniert.

Da ich den Shelly jetzt eh ausgebaut habe, konnte ich nochmal systematisch testen: Konfig 1 + 2 geht nicht, Konfig 3 geht. Geht nicht heißt: FHEM kann ihn nicht ansprechen, über HTML geht es schon. Über HTML geht immer alles.

FHEM heißt: MQTT (aktiviert in der orginial Shelly FW) + eingebauter MQTT2-Server im FHEM.

Die alte Netzwerkverbingung in der Fritzbox vom alten Shelly hab ich auch mal gelöscht und hab auch den Haken weggemacht, dass DHCT immer wieder dieselbe Adresse zuordnet. Obwohl ich das für ein anderes Gerät auch gemacht habe und das andere Gerät zuerst wieder angemeldet habe - hat er wieder dieselben IP-Adressen zugeordnet (was mich gewundert hat).

Hab beim nicht funktionierenden Shelly auch mehrfach einen Factory-Reset gemacht - was wohl in den Access Point Mode umstellt - und neu konfiguriert - hat nix geholfen.

Es kann natürlich sein, dass der alte Shelly irgendwie eine zerschossene FW hat, so dass zufälligerweise das MQTT-Protokoll nicht mehr sauber gefahren wird (das hat Beta-User von Anfang an vermutet). Werde ihn vlt auch mal irgendwann neu flashen - hoffe momentan aber noch, dass es mal wieder ein Update gibt, dann geht das einfacher Aber was um alles in der Welt kann so zerschossen sein, dass es über AP1 nicht funktioniert, über AP2 aber schon?

Oder verunsaubert AP1 das Protokoll so, dass FHEM/MQTT2 damit nicht mehr gescheit zurecht kommt - und AP2 macht das nicht? Vlt irgendwelche Ports, die nicht klappen? Die werden doch aber dynamisch geöffnet (und sind zufällig gewählt?) und ich wüßte nicht, wo ich da was konfigurieren kann.

Gruß, Peter

[Nobbynews]

Schon ziemlich merkwürdig dieses Verhalten.
Warum verpasst Du dem Shelly nicht im Wifi Client eine feste IP?
Zum Testen könntest Du natürlich noch ein Einbinden über das Shelly-Modul probieren. Das geht auch parallel zu MQTT.
Nur um ggf. Probleme mit MQTT einzugrenzen.