FHEM aufteilen wegen blockierenden Modulen

[Ranseyer]

Hi,

das FHEM wird ja häufig wegen seinem Admin immer fetter, da man regelmäßg neues probieren und hinzufügen "muss"... (Busfahrplan integriert owohl 36x Tage im Jahr keiner Bus fährt, ...)
Nun kommt es vor, dass das Drücken eines Schalters schon mal eine Sekunde dauern kann. => inakzeptabel !

Welche der Module nun FHEM blockieren kann man vermutlich nur einzeln herausfinden. (Aber wenn man es dann trotzdem haben will: )

Also dachte ich FHEM2FHEM würde das ganze lösen:
-Einfach den Linux Container von FHEM duplizieren und jeweils einen Teil der Devices löschen und die beiden mit FHEM2FHEM / "Typ: Log" miteinander verbinden
  -Schon bekommt man den bereits vorverdauten Busfahrplan vom Sklaven-FHEM beigeliefert...
-Alle USB-Devices (soweit nötig) hängen künftig am Remote-FHEM (Ich will nicht über Devices nachdenken und habe diese daher generell alle in genau einem Container [FHEM+Heizungs Daemon, ...]sichtbar gemacht)

=> Geht nicht so wirklich weil es dann in der Zukunft kein Autocreate mehr geben wird beim Haupt-FHEM

Frage: Macht so eine Splittung aus Performancegründen generell Sinn, und wäre die Kopplung per MQTT evtl sinnvoller (MQTT-Generic läuft sowieso) ?

Grüße

[herrmannj]

ich mache da aktuell sehr gute Erfahrungen indem ich via mqtt mehrere FHEM verbinde. Meistens landen Dinge die noch nicht fertig entwickelt sind auf einer extra Instanz und das funktioniert aus meiner Sicht sehr gut.

[FHEM-User22]

Hallo,
klingt auch für mich interessant...
Gibts da dafür irgendwo eine Anleitung (für Daus) für das Verbinden der Fhem per MQTT?

Dankeschön

[Eistee]

Ich spiele auch mit dem Gedanken. Ich überlege nur ob man FHEM nicht mehrmals mit jeweils einer anderen config starten kann dazu.

[Wernieman]

Das geht .. in dem Du für jede FHEM-Instanz eine andere Config angibst .... am besten auch getrennte Logfiles

[rudolfkoenig]

Ob man FHEM2FHEM oder MQTT fuer die Nachrichtenuebermittlung waehlt, ist Geschmacksfrage, bzw. haengt davon ab, was man verbinden will.
- FHEM2FHEM ist Punkt-zu-Punkt Architektur, MQTT ist HUB
- mit FHEM2FHEM:LOG kriegt man die Readings eines dummys mit dem gleichen Namen automatisch aktualisiert, bei :RAW kriegt man autocreate.
- mit MQTT kann man Nachrichten auch an nicht-FHEM Systeme schicken.

Beide Verfahren haben das Problem, dass die Systeme nur lose gekoppelt sind, d.h. man kann nicht von ueberall einfach auf alle Readings/Variablen/etc aller Systeme zugreifen, d.h. sie sind nicht mit eiem Multithreaded Loesung equivalent.
Dass das nicht nur ein Nachteil ist, ist mir schon bewusst.

[FHEM-User22]

Hallo,

Ich überlege nur ob man FHEM nicht mehrmals mit jeweils einer anderen config starten kann dazu.

löst das das Performance-Problem, wenn doch alles wieder auf einer Maschine läuft?

[CoolTux]

Hallo,
löst das das Performance-Problem, wenn doch alles wieder auf einer Maschine läuft?

Das Problem ist ja nicht das die Maschine ausgelastet oder blockiert ist sondern die FHEM Instanz.

[Wernieman]

Also das FHEM blockiert ist, während die Maschine "Däumchen dreht"

[Otto123]

Die separaten Instanzen habe ich in drei Möglichkeiten mal beschrieben.

@Joerg hast Du mal ein Beispiel für die Kopplung von zwei FHEM Instanzen per mqtt? Ich probiere da auch gerade rum und mir fehlt es noch ein bisschen an Ideen.

Gruß Otto

[Wuppi68]

tacker mich auch dran

[herrmannj]

Die separaten Instanzen habe ich in drei Möglichkeiten mal beschrieben.

@Joerg hast Du mal ein Beispiel für die Kopplung von zwei FHEM Instanzen per mqtt? Ich probiere da auch gerade rum und mir fehlt es noch ein bisschen an Ideen.

Gruß Otto

ja klar, das ist wenig "sophisticated"

Auf 'A' läuft der MQTT2_SERVER auf 'B' der MQTT2_CLIENT (angebunden an 'A').

Alles was von extern via MQTT kommt ist dann schon auf beiden Maschinen verfügbar.
Wenn ich darüber hinaus etwas von dem einen auf den anderen bekommen möchte, dann mache ich das via 'publish'

Beispiel: Helligkeit kommt auf 'A' an (Homematic). Dort ein notify und schon ist es auf auch auf 'B' verfügbar.

Code Auswählen Erweitern

motion_front:brightness.* set mqtt publish -r home/states/outdoor/front/bightness $EVTPART1

Nix wahnsinnig Ausgefeiltes, eher kurz und effizient

[Beta-User]

@hexenmeister hatte das für MQTT_GENERIC_BRIDGE hier mal beschrieben, wie man Sensordaten damit publisht, einen Aktor schaltet usw.. Das sollte - abgesehen von der Vorbereitung des IO's, die dort (entsprechend dem damaligen Stand) nur für 00_MQTT.pm dargestellt ist - auch mit MQTT2_(SERVER|CLIENT) gehen; dann ist aber Vorsicht bei autocreate angesagt, da MQTT2_DEVICE nichts von den dahinterliegenden "Abnehmern" weiß und daher zusätzliche Devices anlegt, die man eigentlich nicht braucht, (dafür aber eventuell die Events abgreift und nicht weitergibt)!

Da wird zwar an den Enden gerne ein dummy verwendet, das sollte aber 1:1 auch mit MQTT2_DEVICE gehen (wenn ich ihn richtig verstanden habe, arbeitet er (was MQTT betrifft) praktisch nur mit dummy-TPYE, wohl, weil das einfacher zu konfigurieren sei als MQTT_DEVICE; da MQTT2_DEVICE und dummy in der Hinsicht "gleichwertig" sind, würde ich für Client-Devices zu MQTT2_DEVICE tendieren, das ist aber wohl eine Geschmacksfrage, ich z.B. vermeide dummy, wo es geht...).

(Und bevor jemand ausdrücklich danach fragt: MQTT_BRIDGE geht zwar evtl. auch, aber das ist mMn. nicht mehr "state of the art").

Wenn jemand da eine aktualisierte Fassung mit je einem MQTT2-IO (und MQTT2_DEVICE) hat: her damit, dann kann ich gerne versuchen, das für's Wiki aufzubereiten...

[herrmannj]

Bei mir hängen dahinter MQTT2_DEVICE. Finde ich(!) viel flexibler. Insbesondere die Möglichkeit bei der ReadingList anstelle von JSON2VALUE eigene Funktionen zu hinterlegen machen das Ding super flexibel. Das mag (wird) nicht jedermanns Sache sein, aus meiner Sicht top!

[Beta-User]

Wie bereits gesagt, ich tendiere auch stark zu MQTT2_DEVICE als Device-TYPE für alles, was via MQTT reinkommt und der reinen Informationsdarstellung dient. Aber zur Ehrenrettung von MQTT_DEVICE sei angemerkt, das auch das erlaubt, beliebigen Perl-Code anzuflanschen und dasselbe scheint auch für MQTT_GENERIC_BRIDGE zu gelten (habe aber nicht nach vielen Beispielen gesucht, da ich das nicht brauche bzw. lieber den MQTT2_DEVICE-Pfad nutze; es wundert mich aber ein wenig, dass noch keiner auf die Idee gekommen ist, json2nameValue() in MQTT_DEVICE aufzurufen; vom Gefühl her sollte das jedenfalls auch funktionieren...).

Die Stärke von MQTT_GENERIC_BRIDGE sehe ich eher darin, dass man _alle anderen_ Devices recht leicht mit einer Sende-Funktion ausrüsten und auch direkte set-Befehle entgegennehmen kann. Da hat man alles "an einer Stelle" ohne separaten Eventhandler, es reichen also z.B. bei dem EnOcean-Beispiel von Hexenmeister diese zwei Zeilen:

Code Auswählen Erweitern

attr <actor-device-name> mqttPublish state:topic=haus/wohnzimmer/licht/top/state
attr <actor-device-name> mqttSubscribe state:stopic=haus/wohnzimmer/licht/top/setDas hält mMn. die Konfiguration etwas übersichtlicher wie separate notify.