Aufteilen eines Fhem auf zwei durch fhem2fhem verbundene: Name der MQTT Devices

[matze1999]

Hallo,

ich hab mal eine Frage zu den Namen der MQTT Devices in Fhem, wer legt deren Struktur fest? Fhem oder (in meinem Fall) Tasmota?

bis vor einigen Wochen (?), haben neue MQTT Devices immer im Namen ein

Code Auswählen Erweitern

MQTT_ vorangestellt bekommen, Z.B.

Code Auswählen Erweitern

MQTT2_DVES_8FBDC0
wenn ich aktuell neue MQTT Devices anbinde erhalten sie nur noch Namen ohne das vorangestellte MQTT, z.B.

Code Auswählen Erweitern

DVES_8FBDC0
Ich möchte gern einen zweiten FHEM Server per Fhem2Fhem anbinden und dort einige Devices "umziehen". Dazu lasse ich die betreffenden Devices sich nur am neuen Fhem Server anmelden, allerdings bekommen sie hier die o.g. neuen Namen, ich kann sie zwar umbennen und meine vorhandenen Routinen laufen wieder, aber schneller gibnge es, wenn sie sich mit ihrem alten Namen am neuen Fhem anmelden würden.

matze1999

[juergen012]

Moin,
guckst du:
https://forum.fhem.de/index.php?topic=139923.0

[matze1999]

Hallo,

habe jetzt in dem verlinkten thread keine Lösung gefunden.

Wenn ich auf beiden Seiten FhemA und FhemB das autocreate abschalte, kann ich identische (?) Devices anlegen (ich kopiere einfach den Raw Inhalt):

FhemB hier ist das MQTT2 Device neu angeschlossen (von FhemA umgezogen)
FhemA soll per fhem2fhem auf fhemB Devices zugreifen und deren Daten in vorhandenen Routinen (deshalb der Bedarf an gleichen Namen) verwenden

Wenn ich nun das Device direkt oder über fhemB schalte, dann wird der Zustand in FhemA richtig angezeigt, nur Schhalten von FhemA funktioniert nicht.

Ist das evtl. richtig bei Fhem2Fhem?



, wenn ich in FhemB schalte wird das auch in FhemA angezeigt

[matze1999]

oder anders gefragt, wie kann ich ein Fhem in zwei durch fhem2fhem verbundene Fhem teilen, und die Devices einfach aufteilen ohne DOIF,at, notify usw anpassen zu müssen?

Ich dachte, wenn ich die Devices einfach an den zweiten Fhemserver anbinde und diese den gleichen Namen behalten, werden sie im ersten fhem wieder unter diesem Namen erkannt und genutzt.

[Beta-User]

- warum f2f bei Devices, die sowieso via MQTT kommunizieren? MQTT2_CLIENT, und du kannst die Benennung nachziehen, wann du magst.
- wie viel Aufwand wäre es, "sinnvolle" Namen zu vergeben? Das, was autocreate geliefert hatte, ist doch so oder so nicht intuitiv zu gebrauchen....?!?

[matze1999]

Warum?

ich hab zwei weit entfernte Standorte und wollte so den einen Standort "autarker" machen, und auch bedienbar, wenn der andere Standort mal ausfällt oder nicht erreichbar ist. Weiterhin habe ich den zweiten Standort (B) mobil angebunden, und z.Zt. sehr viel Traffic zwischen den Standorten, u.a. wahrscheinlich durch zigbee2mqtt, welches ich an jedem Standort separat laufen lasse. Da aber alle Routinen und Abhängigkeiten vom derzeitig einzigen Fhem Server (A) ausgehen, scheint mir das den Traffic zu bringen. Deshalb die Idee, beide Standorte zu trennen, und nur das notwendigste auf den jeweils anderne Standort zu verteilen.

Ja, das mit den Namen..., nachher ist man immer schlauer, aber ich löse das Erkennungsproblem über alias Namen.

Wahscheinlich würde es schon reichen, die zigbee2mqtt Devices nur lokal an jeweiligen fhem anzubinden.

Das möchte ich aber mit so wenig aufwand wie möglich machen.

 

[Gisbert]

Hallo matze1999,

ich weiß nicht, ob es nur mir so geht, aber so ganz hab ich den Sinn noch nicht verstanden.

Du hast zwei verschiedene Standorte, die aber miteinander kommunizieren sollen oder gar müssen. Warum?
Was muss denn der eine Standort vom anderen wissen? Wäre es nicht einfacher zwei getrennte Installation zu haben, deren Informationen bei dir zusammenlaufen?
Oder geht es dir um Ausfallsicherheit? Was wäre denn der GAU, falls dein Server abraucht? Keine Daten loggen, keine Lichter, Heizung etc. steuern? Oder um was elementar Überlebendsnotwendiges, wohl kaum?
Wenn es um Ausfallsicherheit geht, dann wäre Proxmox mit lokalen Backups sowie zusätzlich in der Cloud sinnvoll. Wenn dein Rechner abraucht, dann besorgst du dir einen neuen und spielst die Backups ein. Vorher alles Dokumentieren und einen Leitfaden erstellen. Wenn du es übertreiben willst, dann stellst du dir jetzt schon einen betriebsbereiten Rechner als Ersatzteil hin oder kaufst gleich etwas Leistungstärkeres und nimmst deine ältere Hardware als Ersatzteil.

Wenn das alles in die falsche Richtung gedacht war, dann bitte ich schon jetzt mal um Entschuldigung.

Viele Grüße Gisbert

Änderung 17.3.2025: Da meine Vermutung falsch war, ziehe ich den obigen Text (kursiv, durchgestrichen und klein) zurück.

[matze1999]

Hallo,

es sind zwei Standorte, die z.Zt. in eiunem VPN, mit einem Fhem Server am Standort A, im Gunde sind beide Standorte autark, ein paar Sensoren werden vom jeweils anderen Standort ausgelesen und verarbeitet. aber es sind auch von jedem Standort Aktoren vom jeweils anderen Standort zu schalten.
Für beide Standorte separat läuft jeweils ein zigbee2mqtt Server.


Ich habe in letzter Zeit sehr viel Traffic vom Standort B, dieser ist Mobil angebunden. Ich vermute zigbee2mqtt als Verursacher, es gab auch zwischendurch immer mal zigbee2mqtt Versionen, bei denen das wieder weniger war, jetzt aktuell mit der 2.x Version ist es wieder mehr. Dort kann man mir aber nicht helfen, bzw. Anfragen dazu liefen ins Leere.

Meine Vorstellung ist/war, dass, wenn ich für jeden Standort eine eigene Fhem Instanz mache, ich den Traffic reduziere, da die Auswertung nur örtlich erfolgt.

Ich lasse mich da gern verbessern, wenn das keine Lösung für das Problem ist.

[rudolfkoenig]

...aber schneller ginge es, wenn sie sich mit ihrem alten Namen am neuen Fhem anmelden würden.

Ich wuerde in 10_MQTT2_DEVICE die Zeile 290 in den alten Zustand versetzen:
Jetzt:

Code Auswählen Erweitern

      $devName = makeDeviceName($devName);
Alt:

Code Auswählen Erweitern

      $devName = makeDeviceName("MQTT2_$devName");
Danach FHEM neu starten und darauf achten, dass kein FHEM update ausgefuehrt wird, oder die Datei per exclude_from_update eine Weile aus dem update ausschliessen.

[TomLee]

Ich vermute zigbee2mqtt als Verursacher, es gab auch zwischendurch immer mal zigbee2mqtt Versionen, bei denen das wieder weniger war, jetzt aktuell mit der 2.x Version ist es wieder mehr.

Hallo,

wsl. nicht der Grund, erwähns aber mal. Mit der "ersten" Version 2.0.0 wurden bei mir alle Topics doppelt gesendet. Zu der Zeit war nach Update auf 2.1.1 wieder alles normal.
Welche Version nutzt Du auf der "Mobil" angebundenen Installation?

Gruß Thomas

[matze1999]

Hallo,

ja, das war auch mein Eindruck, dass die 2.1.1 weniger Datenverkehr hatte als die jetzige 2.1.3, die ich aktuell nutze.

matze1999