FHEM2FHEM - Umsetzung

[Puschel74]

Wozu hier alle mit Dummys um sich werfen bleibt mir ein Rätsel 

Ein UserReading erstellt und das Regexp entsprechend angepasst und der Kuchen ist im Ofen.
Mit etwas Phantasie bei den Readingsnamen lassen sich auch die Schleifen wunderbar vermeiden.

Hautp-FHEM: Hier läuft ALLES drüber und auch nur hier stehen die Codes.
Slave-FHEM: Dieser horcht nur per F2F und dem passenden Regexp auf "seine " Befehle die er von der Hauptinstanz bekommt und führt diese dann aus.
Haupt-FHEM: Mit dem passenden Regexp im F2F weiß die Haupt-Instanz immer was die Slaves grad machen und reagiert entsprechend.

[franky08]

Dann frag mal Andre 

VG
Frank

[joshi04]

Ich habe den Eindruck, dass ein "alter Raspberry B+" mit kontinuirlichem Messen und loggen (5 Minuten Takt) von 20 Temperaturen schon genug zu tun hat.

Wenn es nur damit schon zu Verzögerungen kommt, kann es nicht das einzige sein, was er macht. Ganz so schwachbrüstig sollte der Rpi dann doch nicht sein. Da würde ich noch mal nach Optimierungen schauen. Ich wäre überrascht, wenn ihn das bereits zu 100% auslasten würde. Aber das ist ein anderes Thema.

Ich habe momentan 4 FHEM-Instanzen laufen, 1x DS415+ / 2xRaspberry Pi2 / 2xRaspberry Pi B+.

Für einen Newbie, wie Du Dich bezeichnest, Respekt!

Wozu hier alle mit Dummys um sich werfen bleibt mir ein Rätsel 

Eigentlich braucht man die doch, wenn man den Status des GPIOs vom Slave auf dem Master darstellen möchte, oder wie würdest Du das umsetzen?

Hautp-FHEM: Hier läuft ALLES drüber und auch nur hier stehen die Codes.
Slave-FHEM: Dieser horcht nur per F2F und dem passenden Regexp auf "seine " Befehle die er von der Hauptinstanz bekommt und führt diese dann aus.
Haupt-FHEM: Mit dem passenden Regexp im F2F weiß die Haupt-Instanz immer was die Slaves grad machen und reagiert entsprechend.

Besser hätte ich das nicht auf den Punkt bringen können.

Frohe Ostern...

Das wünsche ich ebenso.

[kvo1]

Hallo Zusammen,
bitte nicht wundern, ich das nur per Zufall grade gelesen und habe so etwas auf meine todo-Liste, also trage
ich mich nur kurz hier ein um mitzulesen.

gruss
kvo1

[Pf@nne]

Moin Puschel,

• Hautp-FHEM: Hier läuft ALLES drüber und auch nur hier stehen die Codes.
• Slave-FHEM: Dieser horcht nur per F2F und dem passenden Regexp auf "seine " Befehle die er von der Hauptinstanz bekommt und führt diese dann aus.
• Haupt-FHEM: Mit dem passenden Regexp im F2F weiß die Haupt-Instanz immer was die Slaves grad machen und reagiert entsprechend.

Treffer und versenkt, das ist doch genau das was wir hier suchen!!!
Könntest du dazu mein Beispiel abändern, ich habe nicht wirklich verstanden was es mit dem UserReading auf sich hat.
Nebenbei mache ich einen Crashcurs in RegExp....

[Prof. Dr. Peter Henning]

Ich kann von diesem Aufbau nur abraten.

Die Vorstellung, FHEM als ein verteiltes System mit einem Master und mehreren Slaves zu betreiben, führt in die Irre. Weder wird das System dadurch schneller, noch stabiler.

LG

pah

[Puschel74]

Eigentlich braucht man die doch, wenn man den Status des GPIOs vom Slave auf dem Master darstellen möchte, oder wie würdest Du das umsetzen?

Äh ja - guter Einwand.
cloneDummy dürfte die bessere Wahl sein ich muss mic haber erst nochmal durch die commandref zu cloneDummy lesen.
Ich hab zwar 2 im Einsatz aber vielleicht hat sich ja in der Zwischenzeit was geändert.

Beispiel:
Internetradio mit FHEM über F2F (auf die detailierten Angaben verzichte ich mal da diese variabel sind).
Die Lautsprecher sind auf meiner Hauptinstanz angelegt - Namensgebung: Lautsprecher_Keller_Buero etc.
Auf meinem Slave läuft StreamRadio mit einem notify auf die Lautsprecher (.*_Radio_|Lautsprecher_).* {
(Der Teil mit .*_Radio_ ist vorbereitet um SRadio auf der Hauptinstanz abzubilden aber auf dem Slave zu steuern).
SRadio auf dem Slave hat ein UserReading Lautsprecher das bei jedem einschalten eines Lautsprechers erhöht und beim ausschalten verringert wird.
Zur Zeit sind 4 Lautsprecher im Einsatz.
Wenn das UserReading == 0 ist wird SRadio abgeschaltet anderfalls eingeschaltet.

Wenn ich also auf der Hauptinstanz einen Lautsprecher einschalte wird das UserReading um 1 erhöht und SRadio beginnt zu düddeln.
cloneDummy muss ich mir nochmal anschauen wie gesagt aber damit würde ich versuchen SRadio auf der Hauptinstanz abzubilden.
Eine F2F-Verbindung von der Hauptinstanz zum Slave mit Regexp SRadio:.* und der clone sollte mir den Sender anzeigen.
Muss ich gleich mal ausprobieren - immer alles aufschieben hat auch keinen Sinn 

Edith: @pah
Ich stimme dir zu aber einen HiFiBerry kann man nun mal nur auf einem RasPi (ohne Aufwand) betreiben und der Spieltrieb wird auch gestillt dabei 
Und mit meinen Somfy-Rollläden auf einem anderen RasPi per F2F angebunden bin ich sehr zufrieden und es klappt einwandfrei.
Wie gesagt - ich hab auf den Slaves keine "Intelligenz" sondern rein nur die Devices.
Der Rest liegt bei mir auf meiner Haupt-FHEM-Instanz.

[Prof. Dr. Peter Henning]

Oh, in dem Umfang mache ich das auch. Sowohl meine Schallpegelmessung läuft auf einem eigenen Raspberry, als auch meine EBUS-Heizungsanbindung.

Das ist aber etwas ganz Anderes, als als das von "pfanne" vertretene System.

LG

pah

[joshi04]

Ich kann von diesem Aufbau nur abraten.

Die Vorstellung, FHEM als ein verteiltes System mit einem Master und mehreren Slaves zu betreiben, führt in die Irre. Weder wird das System dadurch schneller, noch stabiler.

Ganz so allgemein und uneingeschränkt würde ich dem nicht zustimmen wollen. Es gibt Anwendungsfälle, bei denen die Herausforderungen (geringere Stabilität und steigende Komplexität) von den Vorteilen einer Lösung überwogen werden, bzw. bestimmte Lösungen erst möglich machen. Ich kann mir vorstellen, dass die Entfernung zwischen Master und GPIO-Device/Rpi eine Rolle für die Entscheidung spielt.

Grundsätzlich würde ich Dir zustimmen, dass man wissen sollte, wann, warum und wie man F2F einsetzt. Die Übersichtlichkeit steigt dadurch definitiv nicht. Bei mir sind der Spritpreismonitor, ein Wettermodul und ein paar Sensoren "ausgelagert", die nur empfangen. Ich hatte durch Erstere Verzögerungen auf dem Master, die dazu geführt haben, dass der HMLan-keep-alive manchmal zu spät kam -> reconnects im Log.

cloneDummy dürfte die bessere Wahl sein ich muss mic haber erst nochmal durch die commandref zu cloneDummy lesen.

Die hatte ich noch gar nicht auf dem Zettel. Vielleicht hat man damit auch nicht das Problem mit dem doppelten Doppelpunkt in den Readings. Man lernt nie aus. Ich packe das bei mir mal auf die ToDo-Liste. Das wäre dann wieder ein Notify gespart.

Schöne Grüße,
John

[Prof. Dr. Peter Henning]

Leute, bitte genauer lesen.

Mein Post bezieht sich nicht auf "ganz allgemein und uneingeschränkt" - und "Slave" bedeutet eben nicht, dass der Raspberry nur Sensordaten empfängt.

Ebenfalls nicht darauf, dass andere Serversysteme (sei es nun HifiBerry, OWServer oder EBUS) auf einen separaten Raspberry ausgelagert werden - das ist sogar sehr sinnvoll.

Sondern präzise darauf (und das ist hier die Bedeutung von "Slave"), dass ein FHEM-System in größerem Umfang von einem anderem FHEM-System Befehle empfangen soll und diese dann auszuführen hat. DAS ist, dabei bleibe ich, nicht sinnvoll.

LG

pah

[joshi04]

Das ging wohl in meine Richtung. Ich denke, ich habe es richtig verstanden und bleibe bei der Meinung, dass man keine absoluten (präzisen) Aussagen treffen kann, solange man nicht alle Randbedingungen eines Anwendungsfalls kennt. Zum Glück gibt es immer mehrere Meinungen. Aber vielleicht möchtest Du mich auch nicht verstehen.
Eine Alternativlösung hast Du leider noch nicht vorgeschlagen, vielleicht kannst Du Pfanne mit einer besseren Lösung weiterhelfen anstatt nur zu sagen, wie es Deiner Meinung nach nicht umgesetzt werden sollte. Daher übergebe ich an dieser Stelle (Anfängerbereich) gerne an Dich.

OT: Hier im Forum habe ich den Eindruck, wird man häufig missverstanden und bekommt dann verbal einen drüber gebraten.  Ich wollte Dir nicht zu nahe treten, was mir anscheinend nicht gelungen ist. Aber weil dem so ist, werde ich mich für nähere Zukunft bis auf weiteres wieder aufs Lesen beschränken.

@ Pf@anne,
bitte lass Dich nicht beirren. Mich würde interessieren, wie Du Deine Anwendung nun gelöst hast.

In diesem Sinne, frohe Ostern,
John

[Pf@nne]

Hier ist ja richtig was los....

Ich komme leider erst heute Abend zum Lesen.

Jetzt erstmal Frohe Ostern.....

[Puschel74]

pah hat schon recht und es ist auch gut das sich jemand findet der auf einige "Stolperfallen" hinweist.
Natürlich macht es keinen Sinn x RasPi mit F2F anzubinden und dann noch auf jedem die Intelligenz zu betreuen da das sehr schnell unübersichtlich wird und später die Suche losgeht wo welches Device warum geschaltet wird.

Wenn man auf seinen F2F-Instanzen aber nur die Geräte anlegt und darauf achtet das die Intelligenz auf einer! Instanz bleibt lassen sich schon eine Menge Fehlerquellen eliminieren.
Auch wird die Wartbarkeit der Codes dadurch nicht unnötig erschwert.

[Pf@nne]

Ohne jetzt die oberen Beiträge nachvollzogen zu haben....

Wie schaut es denn mit der späteren Bedienung aus?
Ich möchte z.B. meine Haustechnik sowohl über Wandtaster als auch über ein Tablet-Frontend steuern.
Wenn ich jetzt die "Intelligenz" auf mehrere autarke Pi´s verteile, dann müsste ich ja auch mehrere Frontends benutzen.

Oder sollen die autarken Pi´s autark bleiben und nur einen Kanal für externe Signale bereitstellen?
Das ginge natürlich auch.....

Allerdings bin ich auch der Meinung, dass eine zentrale Intelligenz einfacher zu administrieren ist und somit weniger Fehlerpotenzial birgt.

Ich fummel mal ein wenig....
@Puschel, kannst du mal ein einfaches Code-Beispiel mit userReading auf Basis meiner Error_LED machen?

[Puschel74]

@Puschel, kannst du mal ein einfaches Code-Beispiel mit userReading auf Basis meiner Error_LED machen?

Klar.
Welches UserReading hättest du den gerne?