Server-Umzug und Shelly-Aktoren

[Superposchi]

Hallo, beim meinem serverumzug bin ich auf das nächste Problem gestoßen.
Nach den Homematic-Devices geht es nun um meine Shelly-Devices

Ich habe alle Shelly-Devices per RAW-Definition auf den neuen Server übertragen und dann in der Shelly-Bedienoberfläche die IP-Adresse des MQTT2-Servers (also die IP des neuen Fhem-Servers). Komischerweise werden nur 2 der 7 Devices als verbunden angezeigt. Ich kann auch nicht sehen welche zwei es sind, somit fällt es mir schwer explizit ein List zu liefern wenn ich nicht von allen 7 Devices plus MQTT-Server-Device ein List einstellen will.

Gibt es hier etwas zu beachten oder eine Idee wie und wonach ich suchen muss?
Wenn ich die verbundenen und die nicht verbundenen Devices identifizieren könnte wäre ich wahrscheinlich auch schon ein Stück weiter.

[MadMax-FHEM]

Mit online/verbunden meinst du das LWT?
Oder wie/an was machst du "verbunden" fest?

Bin nicht sicher aber ich denke das LWT wird nicht (so oft) zyklisch übertragen...

Evtl. mal die Shelly "durchbooten"...

Aber vielleicht hat Beta-User eine andere/bessere/richtigere Idee...

Gruß, Joachim

[Beta-User]

Aber vielleicht hat Beta-User eine andere/bessere/richtigere Idee...

Habe keine bessere Idee, eigentlich sollte das stressfrei funktionieren.

Sicher, dass alle Eingaben in den Web-Interfaces der ESP's auch gespeichert worden sind und die Dinger einen reboot gemacht haben?

An sich sollte auch in den MQTT2_DEVICE-Instanzen zu sehen sein, ob die "online" sind (falls du via "raw" nur die Attribute und nicht auch die setstate-Zeilen übernommen hattest). Notfalls einfach mal versuchen zu schalten, dann siehst du ja, was passiert...

[rudolfkoenig]

Wenn ich die verbundenen und die nicht verbundenen Devices identifizieren könnte wäre ich wahrscheinlich auch schon ein Stück weiter.

Beim MQTT2_SERVER reicht ein list.

[Superposchi]

Ich mache es an dem Reading "nrclients" im MQTT-Server-Device fest. Dort stand ursprünglich 5, 3 weitere (2 H&T und ein Gassensor) senden nur sporadisch.
Nach dem Umzug steht im alten Server dort nun eine 3 und im neuen Server eine 2.
Habe den kompletten Raw-Code kopiert und übertragen und auch noch mal probiert direkt über die config.cfg die Devices zu kopieren.
Beide Wege mit gleichem Ergebnis. Die Devices (3 Shelly2.5, 1 Shelly1PM und ein Wassersensor [Hat natürlich keine aktiven Schaltvorgänge]) reagieren nicht auf Schaltvorgänge

Die IP des neuen Servers sind definitiv übernommen worden - bis auf die drei sporadisch sendenden Devices. Für einen Tip wie man die Weboberfläche trotzdem aufrufen kann wäre ich dankbar.
Habe auch den Server bereits mehrfach neu gestartet.

Wenn ich alleine schon sehen könnte welche zwei Devices er richtig übernommen hat, dann könnte ich zumindest nach Unterschieden suchen.

Hier das List des MQTT-Server-Devices:

Code Auswählen Erweitern

Internals:
   .FhemMetaInternals 1
   CONNECTS   2
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        1883 global
   FD         8
   FUUID      5fc0f832-f33f-793a-6c0e-c6d750e7d6474e84
   FVERSION   00_MQTT2_SERVER.pm:0.246390/2021-06-15
   NAME       MQTT2_Server
   NR         20
   PORT       1883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .attrtocr:
     .*
   .clientArray:
     MQTT2_DEVICE
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2021-08-25 12:01:57   nrclients       2
     2021-08-25 12:01:48   state           Initialized
   clients:
     MQTT2_Server_192.168.178.153_7329 1
     MQTT2_Server_192.168.178.154_25957 1
   retain:
Attributes:
   autocreate simple
   event-on-change-reading .*
   group      Bridges
   icon       mqtt_bridge_2
   room       MQTT2_DEVICE,System
   timestamp-on-change-reading .*
   verbose    1

[Beta-User]

MQTT2_Server_192.168.178.153_7329 1
     MQTT2_Server_192.168.178.154_25957 1

...wie wäre es, das als Info zu den IP's zu verstehen...?

Dass nur sporadisch sendende Geräte erst dann registriert werden, wenn sie sich verbunden haben, ist eigentlich logisch, für das "Aufwecken zur Konfiguration" meine ich was mit einer "Knopfdruck"-Anweisung im Hinterkopf zu haben (will sagen: Doku des Herstellers lesen...)

[Superposchi]

...wie wäre es, das als Info zu den IP's zu verstehen...?

Ehrlich, ich versteh nicht was du damit sagen willst.

Das sporadisch sendende Devices nicht inbegriffen sind habe ich doch eigentlich deutlich geschrieben.
Ich habe 8 Shelly-Devices, 3 senden davon nur sporadisch.
Darum stand im alten Server in dem genannten Reading auch nur eine 5 und keine 8.

Problem ist halt, dass sich die 5 jetzt auf beide Server verteilen - 3 auf den alten, 2 auf den neuen. Obwohl alle gleich umgezogen sind.

[Beta-User]

Ehrlich, ich versteh nicht was du damit sagen willst.

Du siehst die IP-Adressen von zwei verbundenen Geräten:
192.168.178.153 bzw. ...154. Die könntest du z.B. dann über das WEB-Interface unter dieser Adresse aufrufen, oder?

Das sporadisch sendende Devices nicht inbegriffen sind habe ich doch eigentlich deutlich geschrieben.
Ich habe 8 Shelly-Devices, 3 senden davon nur sporadisch.
Darum stand im alten Server in dem genannten Reading auch nur eine 5 und keine 8.

Problem ist halt, dass sich die 5 jetzt auf beide Server verteilen - 3 auf den alten, 2 auf den neuen. Obwohl alle gleich umgezogen sind.

Sorry für's "verzählen", aber die "fehlenden drei" "siehst" du anscheinend (noch?) auf dem alten Server - ergo hatten die die Änderung der Ziel-IP nicht mitbekommen...

=> zumindest über den alten Server kannst du die IP's der "fehlenden drei" über ein list am alten MQTT2-Server ermitteln und dann eben die Übung (Aufruf des Web-Interfaces via IP, Änderung der MQTT-Server-IP) nochmal machen, bis es passt...

Klarer jetzt?

[Superposchi]

Du siehst die IP-Adressen von zwei verbundenen Geräten:

Du meinst um die verbundenen Geräte zu erkennen, soweit hatte ich nicht gedacht. Stimmt, dass wären dann zwei der Shelly2.5-Devices.

Sorry für's "verzählen", aber die "fehlenden drei" "siehst" du anscheinend (noch?) auf dem alten Server - ergo hatten die die Änderung der Ziel-IP nicht mitbekommen...

Ich denke hier reden wie aneinander vorbei.
Ich kenne alle IP's. und ich sehe alle Devices auf beiden Fhem-Servern. Auf dem neuen reagieren sie nur nicht und es werden wie geschrieben die veränderten Mengenangaben im reading angezeigt.
Im web-Interface aller Devices ist der neue Fhem-Server eingetragen.

Das ist ja das komische.

[TomLee]

Es steht zwar nirgends das eines vergeben wurde aber im Falle das doch der MQTT2-Server mit Username/Passwort abgesichert ist, würde man mit default verbose 3 wenigstens eine Meldung im Log sehen (so in der Art: Login denied for user >bla< via MQTT2_Server_IP_52750), hätte man sich beim Usernamen/Passwort eingeben vertippt.

[Beta-User]

...in teilen doppelt, aber schon fertig...

Im web-Interface aller Devices ist der neue Fhem-Server eingetragen.

Wenn es dann nach einem harten reboot (stromlos machen) nicht klappt und die weiter über den alten Server schaltbar bleiben, sind die Dinger defekt. Zum Glück habe ich nicht viele ESP's im Einsatz, aber bisher war es bei keinem nach einem Serverwechsel ein größeres Problem, die IP zu ändern. Ist aber schon eine Weile her, dass ich das "durchexerziert" habe, und es war kein Shelly dabei.
Bin ziemlich sicher, dass es hier schon Berichte gegeben hätte, wenn die Shelly da grundsätzlich "zickig" wären.

Nur zur Sicherheit: es ist keine User/Password-Eingabe für den neuen MQTT-Server erforderlich (allowed) oder die Daten passen weiterhin bzw. wurden auch geändert?

[Superposchi]

Also nach einem erneuten Device-Reboot kamen der Shelly1PM und der Gassensor jetzt rüber zum neuen Fhem-Server, dort wird jetzt im Reading auch eine 4 angezeigt.
Der dritte Shelly2.5 wird nach einem Device-Reboot jetzt von keinem Server geschaltet, nur angezeigt wird das Device auf beiden Servern. Werde gleich im Anschluss noch mal den Fhem-Server neu starten, vielleicht bewirkt das ja was.

Gibt es denn irgendeine Option die drei Shelly-Sensoren zu triggern damit das Web-Interface aufgerufen werden kann auch wenn sie gerade "stumm" sind? Ansonsten müsste ich die Drei aus ihren versteckten Ecken rauskramen und über den Knopf am Gerät wecken, was mit einigem Aufwand verbunden wäre.

[TomLee]

Ich hab mal bei einem Shelly1 ein update gemacht und in den Einstellungen ganz unten kann man ein Debug Log aktivieren (weiß nicht wie lange das schon gibt oder schon immer, hab mich bisher kaum mit dem Shelly näher beschäftigt).

Das würd ich mal einschalten den Shelly neu starten und anschliessend das Log runterladen .
Ich weiß nicht was da drin steht/stehen könnte, noch nie ausprobiert und ob es vlt. sogar sowas wie Debug-Level gibt.

[Beta-User]

Der dritte Shelly2.5 wird nach einem Device-Reboot jetzt von keinem Server geschaltet, nur angezeigt wird das Device auf beiden Servern. Werde gleich im Anschluss noch mal den Fhem-Server neu starten, vielleicht bewirkt das ja was.

FHEM-Server neu starten ist m.E. nutzlos, der funktioniert doch erwiesenermaßen!
(Grummel, immer diese *denkdirwas* Wind.*-Methoden...)

Gibt es denn irgendeine Option die drei Shelly-Sensoren zu triggern damit das Web-Interface aufgerufen werden kann auch wenn sie gerade "stumm" sind? Ansonsten müsste ich die Drei aus ihren versteckten Ecken rauskramen und über den Knopf am Gerät wecken, was mit einigem Aufwand verbunden wäre.

Die Frage hatten wir ihn ähnlicher Form (update anschubsen?) schonmal, wenn ich mich recht entsinne. Der Betreffende hatte dann am Ende ein notify auf LWT (?) gelegt (wäre auf dem Altsystem). Allerdings habe ich keine Erinnerung mehr, ob das geklappt hat, und auch keinen Link (=>selber suchen...).

EDIT: Der hier war es: https://forum.fhem.de/index.php/topic,106986.0.html

(Falls du einen funktionierenden Code für das Anschubsen des Server-Wechsels hast (vermute: in dem notify dann ein curl-Aufruf oder sonst eine HTTP-post-Methode): Sowas wäre ggf. für das Wiki interessant...)

[Superposchi]

@TomLee
Hab ich gesehen, werde ich falls nötig auch noch probieren.

@Beta-User
Genau selber denken soll ja gesund sein. Nein, ganz einfach hatte ich gehofft, dass beim neuen einlesen der config.cfg das Problem vielleicht gelöst wird. War aber nicht.
Hab dafür im Web-Interface die MQTT-Einstellungen noch mal auf den alten Fhem-Server gesetzt und der Aktor war dort wieder schaltbar. Danach dann wieder auf den neuen Server eingetragen und ein Device-Reboot und siehe da, jetzt ist er sogar doppelt im MQTT-Server des neuen Fhem drin. Mit zwei verschiedenen Portnummer so wie es aussieht, siehe List des Device.

Was die drei Aktoren angeht, danke für den Link. LWT sagt mir nämlich nichts. Schaue mir den Link erst mal an und dann die Shelly-Doku. Irgendeine Möglichkeit muss es ja geben.

Edit: gerade als ich das List erstellen wollte ist der Doppeleintrag verschwunden. Ist jetzt also erstmal alles soweit sauber und so wie es soll. Es fehlen nur die drei sporadisch sendenden Sensoren.

Code Auswählen Erweitern

Internals:
   .FhemMetaInternals 1
   CONNECTS   6
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        1883 global
   FD         8
   FUUID      5fc0f832-f33f-793a-6c0e-c6d750e7d6474e84
   FVERSION   00_MQTT2_SERVER.pm:0.246390/2021-06-15
   NAME       MQTT2_Server
   NR         20
   PORT       1883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .attrtocr:
     .*
   .clientArray:
     MQTT2_DEVICE
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2021-08-25 17:26:13   nrclients       5
     2021-08-25 17:14:26   state           Initialized
   clients:
     MQTT2_Server_192.168.178.151_3860 1
     MQTT2_Server_192.168.178.153_11298 1
     MQTT2_Server_192.168.178.154_18652 1
     MQTT2_Server_192.168.178.162_21565 1
     MQTT2_Server_192.168.178.164_14174 1
   retain:
Attributes:
   autocreate simple
   event-on-change-reading .*
   group      Bridges
   icon       mqtt_bridge_2
   room       MQTT2_DEVICE,System
   timestamp-on-change-reading .*
   verbose    1

[Beta-User]

"LWT" ist eine MQTT-Spezialität (Langform: last will testament), aber nachdem ich den Thread wiedergefunden habe, ist auch klar, wie ein tauliches "ich bin wieder erreichbar"-Event aussieht:

Code Auswählen Erweitern

2021-04-18_04:23:22 MQTT2_shellyflood_B08543 online: trueDarauf kannst du (angepaßt an deine Devices!) dann reagieren und den "ändere die MQTT-Server-Adresse" HTTP-post abgeben. Wie der (prinzipiell) aussieht, müßte der (guten) Shelly-Doku zu entnehmen sein, that's all...