FHEM aufteilen wegen blockierenden Modulen

[Ranseyer]

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!

[Prof. Dr. Peter Henning]

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

Code Auswählen Erweitern

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

20.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

Code Auswählen Erweitern

{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

[Ranseyer]

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)