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
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.
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
Ich spiele auch mit dem Gedanken. Ich überlege nur ob man FHEM nicht mehrmals mit jeweils einer anderen config starten kann dazu.
Das geht .. in dem Du für jede FHEM-Instanz eine andere Config angibst .... am besten auch getrennte Logfiles
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.
Hallo,
Zitat von: Eistee am 30 Oktober 2019, 12:04:00
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?
Zitat von: FHEM-User22 am 30 Oktober 2019, 13:05:59
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.
Also das FHEM blockiert ist, während die Maschine "Däumchen dreht"
Die separaten Instanzen habe ich in drei Möglichkeiten mal beschrieben (https://heinz-otto.blogspot.com/2019/03/eine-weitere-fhem-instanz-auf-gleicher.html).
@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
tacker mich auch dran
Zitat von: Otto123 am 30 Oktober 2019, 13:23:47
Die separaten Instanzen habe ich in drei Möglichkeiten mal beschrieben (https://heinz-otto.blogspot.com/2019/03/eine-weitere-fhem-instanz-auf-gleicher.html).
@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.
motion_front:brightness.* set mqtt publish -r home/states/outdoor/front/bightness $EVTPART1Nix wahnsinnig Ausgefeiltes, eher kurz und effizient
@hexenmeister hatte das für MQTT_GENERIC_BRIDGE hier mal beschrieben (https://forum.fhem.de/index.php/topic,91642.msg841370.html#msg841370), 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...
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!
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 (https://forum.fhem.de/index.php/topic,91642.msg841370.html#msg841370) von Hexenmeister diese zwei Zeilen:
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.
Hi,
hier gings ja ab... Konnte wegen Partyaktivitäten leider nicht schneller reagieren...
Allerdings habe ich mir die Geschichte inzwischen einfacher vorgestellt... (z.B. auf einen Schlag alle Devices bereitstellen, und man subsribed nur das nötige...)
FHEM2FHEM:RAW macht ja ziemlich genau das was ich mir vorgestellt hatte, aber nicht für z.B. Webservices.
Dass man sich per MQTT (so glaube ich) jeden Wert den man publishen will einzeln kümmern muss finde ich etwas aufwändig...
Als Hausaufgabe werde ich mir mal den Thread von Hexmeister nochmals reinziehen. Gehe aber davon aus, ich werde kein unnötigen Kopplungen vornehmen, außer evtl. die Geschichte mit dem RAW Modul.
Denke mal eher ein sinnvoller Ablauf könnte sein aus dem FHEM-System eine Kopie als Testsystem aufbauen, und beim produktiven FHEM die ganzen unnötigen Sachen löschen... (Die kann man ja jederzeit wieder beim Testsystem nachschauen und auch mal wieder anlegen)
Wenn dann noch etwas zu koppeln ist, kann man ja immer noch...
Danke für euren Input!
Ich habe seit 5 Jahren 3 verschiedene FHEM-Instanzen gekoppelt.
1x Hauptsystem, mit den meisten Interfaces, inzwischen auf einem Mini-PC
1x System mit vielen http-Zugriffen nach außen auf einem Raspberry Pi 3
1x System zur Bedienung von Benutzungsschnittstellen (z.B. Spracherkennung, Sprachsynthese und Tablet-UI) auf einem Raspberry Pi
Nachdem ich drei Jahre lang auf FHEM2FHEM gesetzt habe (und zwar jeweils in beide Richtungen, also insgesamt 6x FHEM2FHEM), bin ich inzwischen auf RFHEM gewechselt. Mit FHEM2FHEM ist die Gefahr sehr groß, dass man man Schleifen einbaut, also ein Event immer im Kreis herumgeht (da geht die Post ab, kann ich sagen ...). In der Performance sehe ich keinen Unterschied.
Auf Perl-Ebene sind die Aufrufe gekapselt, wenn das RFHEM-Device z.B, heißt Task_194n, führe ich das Kommando cmd auf dem anderen FHEM aus durch die Perl-Funktion
sub fhem194Cmd($){
my ($cmd) = @_;
fhem("set Task_194n cmd ".$cmd);
}Die Kopplung von Variablen und Zuständen erreiche ich dadurch, dass bestimmte Werte einfach in längere Strings geschrieben werden (als Werte eines CustomReadings). Beispielsweise ist das Temperaturprofil der Räume meines Hauses derzeit
Zitat20.9 20.0 20.5 21.1 22.7 22.5 19.7 20.3 20.1 21.1 21.1 17.8
Das wird 1x pro Minute auf das entfernte FHEM übertragen, und zwar durch den Aufruf
{fhem194Cmd("{evalProfile('temp','".Value("tempProfile")."')}")}Auf dem entfernten FHEM ruft das die Perl-Funktion evalProfile auf, welche die einzelnen Werte wieder auseinanderfieselt und in separate Readings aufspaltet.
Funktioniert hervorragend,
LG
pah
Danke auch dafür.
Ich hatte zuerst notify per MQTT gepublisht.
Aktuell nutze ich die MQTT Generic-Bridge und publishe "alles".
-Ich habe schon länger die Events drastisch reduziert weil mir viele der Daten egal sind
-Zusätzlich nehme ich immer mal wieder Sachen einzeln aus dem publishen raus, die sinnlos sind, oder ich die gefahr von Schleifen sehe
Hintergrund der anderen Herangehensweise ist dass ich absolut für Standards bin und davon ausgehe, es ist gut alles Wichtige im MQTT-Broker zu haben. (Node-Red lauert schon)