FHEM Forum

Moin,

ich habe eine Frage zur "fachgerechten" Umsetzung von folgendem:

• Ich habe einen FHEM MASTER auf meiner DS415+ laufen. Hier sollen alle Verküpungen / Ereignisse / Messwerte ausgewertet und verschaltet werden.
• Ich habe mehrere SLAVES zum Messen und Steuern im Haus verteilt, z.B. für die Heizung.
• Ich möchte jetzt einen Output im SLAVE vom MASTER aus steuern.
• Im SLAVE gibt es ein GPIO-Device Zirkulation.
• Im MASTER gibt es einen Dummy Zirkulation
• Der Slave bekommt über FHEM2FHEM alle LOGs des MASTERS und soll den GPIO-Device Zirkulation über ein notify vom MASTER Zirkulation ableiten. Das klappt auch alles ganz gut.

Ist das der "fachgerechte" Weg oder macht man das anders?

Probleme gibt es jetzt mit dem MASTER Dummy und on-for-timer.
Ich habe jetzt schon gelesen und bemerkt, dass sich dummys nicht zurücksetzen.

Wie bekomme ich jetzt das on-for-timer vom MASTER zum SLAVE?


Gruß
Pf@nne

Moin,

fehlen hier noch weitere Infos...
oder habe ich mich zu unklar ausgedrückt.

Über ein wenig Unterstützung würde ich mich als Newbie wirklich freuen.
Ohne Hilfe wird es für mich sehr schwer FHEM unter Kontrolle zu bringen.


Gruß
Pf@nne

Hallo, du solltest deine Frage laut Maintainer.txt vlt. besser hier stellen:
FHEM/93_FHEM2FHEM.pm         rudolfkoenig         http://forum.fhem.de Automatisierung

also in Automatisierung. Da das ein ziemlich komplexes Thema ist, wird dir da bestimmt ehr geholfen.

P.S Wenn ich F2F im Log Modus auf dem Slave laufen habe und gleichzeitig F2F auf dem Master, dann muss ich über regex filtern da man sich sonst eine "schöne" Schleife baut. Ich habe bei mir auf 2 Slaves F2F (Raspi´s) laufen und logge damit die Daten auf dem Master, gleichzeitig läuft auf dem Master eine F2F Instanz um auf einem Slave Raspi lirc ansteuern zu können. Das funktioniert einwandfrei wenn mann die "Schleife" vermeidet.

VG
Frank

Auf dem Slave habe ich dann:

define F2F FHEM2FHEM 192.168.2.66:7072 LOG:pifhem.*
attr F2F room System
define n_pifhem notify pifhem.* {Log 3, "$NAME: $EVENT";;fhem("$EVENT")}
attr n_pifhem disable 0
attr n_pifhem room Infrarot

Dadurch werden die vom Master gesetzten Befehle auf dem Slave umgesetzt. Auf dem Master :
define pifhem dummy
attr pifhem DbLogExclude .*
attr pifhem room RASPI
#

ein dummy.

VG
Frank

OK, das habe ich soweit.... das mit der Schleife habe ich auch schon live ausprobiert!
Gibt ne Menge Daten beim Loggen....  ::)

Wie kann ich nach rooms bzw. groups filtern....

Wie kann ich denn den Dummy im Master mit on-for-timer schalten, der Dummy im Master setzt sich ja nicht selber wieder zurück?
Ein on-for-timer im SLAVE auf den GPIO des PI geht.

Vielen Dank für deine Unterstützung.....
Wenn wir hier nicht weiterkommen würde ich diesen Beitrag verschieben lassen...

Gute Frage, hab ich selber noch nicht probiert. Obwohl ein on-for-timer der abgelaufen ist ja fertig ist oder mit clone dummy. Da kann ich dir aber nichts dazu sagen, da ich mich damit noch nicht beschäftigt habe.

VG
Frank

OK,

ZitatWie kann ich nach rooms bzw. groups filtern....

Kannst du mir hierzu etwas unter die Arme greifen?

Hallo, mir ist nicht ganz klar was du nach rooms bzw. groups filtern möchtest.

VG
Frank

Hallo Pf@anne,

nur eine sehr allgemeine Hilfestellung:
Zum Verständnis und der Verwendung von FHEM2FHEM hast Du Dir sicherlich dieses hier schon gelesen:
http://www.fhemwiki.de/wiki/FHEM2FHEM

FHEM2FHEM funktioniert unidirektional. D.h. für Events, die auf einem Slave anfallen, benötigst Du ein FHEM2FHEM auf dem Master, das die Events vom Slave einsammelt. Wenn der Master die Events verarbeitet und einen Aktuator steuern soll, der aber auf dem Slave über ein Interface angeschlossen ist, benötigst Du einen zweites FHEM2FHEM auf dem Slave, dass die Kommandos vom Master einsammelt.

Darüber hinaus würde ich Dir empfehlen, zunächst auf dem Host, auf dem die Events eintreffen (mit dem Interface) (Du nennst sie glaube ich Slaves), die Events auf das nötigste zusammenzukürzen mit den Attributen event-on-xxx und darüber hinaus auch nur die Events zuzulassen, die Du wirklich verwenden möchtest. Das hält die Loggs/DB schlank. Erst dann würde ich darüber nachdenken, welche Events ich per FHEM2FHEM einsammeln würde.

Ich gebe zu, ich habe Deine Problemstellung nur oberflächlich überflogen, hoffe aber, es hilft Dir trotzdem weiter, viel Erfolg.

Schöne Grüße,
John

ps: FHEM2FHEM wäre für mich schon nicht mehr "für Anfänger"...

Hi,

@John,
die Grundfunktion von F2F habe ich im Ansatzt verstanden, jetzt geht es um die "fachgerechte" nutzung.
Das mit den Filtern habe ich mir auch so gedacht, nur das durchlassen, was auch benötigt wird, das verringer den Datenverkehr und die Überraschungen.

@Frank,
die Frage war ob man mit F2F auch nach room bzw. groups filtern kann.
Damit könnte ich alle Events die für den SLAVE bestimmt sind in eine Gruppe bzw. in einen Raum packen.


Ich möchte nur vermeiden etwas unnötig doppelt zu machen oder zu merken, dass das so nicht geht... :-)


Gruß
Pf@nne

Das wird dir bestimmt nur jemand beantworten können der etwas tiefer in Perl steckt. Ich denke das es über eine etwas "kompliziertere" regex bestimmt möglich sein könnte aber sooo tief stecke ich nicht in Perl drinne. Da könnte vlt. Andre (justme) weiterhelfen.

VG
Frank

Soweit ich es verstehe, bestimmen die Attribute room und group eines Moduls nur, wo und wie die Dinge in FHEMWeb auf dem entsprechenden Host dargestellt werden. d.h. die Inhalte der Readings bzw. Events bleiben davon unbehelligt und werden damit auch nicht über FHEM2FHEM übertragen.

Die Information, zu welchem Raum ein Event gehört, lässt sich meines Wissens höchstens durch eine entsprechende Nomenklatur des Namens vom Modul "transportieren". Daher beginnen die Namen meiner Komponenten jeweils mit zwei Buchstaben, die den Raum bezeichnen gefolgt von einem Unterstrich. So kann später danach gefiltert/sortiert werden. Als weiteres habe ich an Komponenten, die irgendwo remote an einem Interface hängen, ein "_r" an den Namen gehängt, um mir das in Erinnerung zu rufen. Die Namensgebung im Frontend ist darüber hinaus Leserfreundlich über das Attribut alias definiert. Da gibt es aber sicherlich auch andere Möglichkeiten der Benennung.

Aber vermutlich habe ich auch noch nicht verstanden, was Du genau vorhast.

Das mit dem on-for-timer habe ich tatsächlich nicht verstanden, was Du vorhast. Soweit mir bekannt, hat zumindest ein Dummy nicht diese "Intelligenz", da universell. Tut das denn ein GPIO-Device?
So richtig verstanden, muss ich zugeben, habe ich die Problemstellung noch nicht.

Schöne Grüße,
John

ZitatDie Information, zu welchem Raum ein Event gehört, lässt sich meines Wissens höchstens durch eine entsprechende Nomenklatur des Namens vom Modul "transportieren". Daher beginnen die Namen meiner Komponenten jeweils mit zwei Buchstaben, die den Raum bezeichnen gefolgt von einem Unterstrich. So kann später danach gefiltert/sortiert werden. Als weiteres habe ich an Komponenten, die irgendwo remote an einem Interface hängen, ein "_r" an den Namen gehängt, um mir das in Erinnerung zu rufen. Die Namensgebung im Frontend ist darüber hinaus Leserfreundlich über das Attribut alias definiert. Da gibt es aber sicherlich auch andere Möglichkeiten der Benennung.

Jiip, diese Möglichkeit habe ich auch schon in betracht gezogen. Ich wollte nur vermeiden mir wieder etwas auszudenken, was FHEM viel einfacher beherscht. Es wäre nicht das erste mal, dass ich mir einen recht umständlichen "work arround" bastel, der nicht notwendig gewesen wäre.

ZitatDas mit dem on-for-timer habe ich tatsächlich nicht verstanden, was Du vorhast. Soweit mir bekannt, hat zumindest ein Dummy nicht diese "Intelligenz", da universell. Tut das denn ein GPIO-Device?

Einen GPIO oder einen I²C-MCP23017 Portexpander kann ich prima über on-for-timer steuern.
Diese steuern sich wieder ab.

Was ich möchte:
Ich habe an meinem SLAVE (Raspberry GPIO) eine Zirkulationspumpe. Diese möchte ich alle 30 Minuten für 5 Minuten laufen lassen.
Allerdings möchte ich im SLAVE keine "Intelligenz" integrieren. Der GPIO im SLAVE soll nur über das FHEM2FHEM on / off gesetzt werden.

Die "Intelligenz" soll im MASTER (DS415+) integriert werden, hierzu habe ich einen Dummy Zirkulation im MASTER angelegt.
Diesert soll über ein "at" on-for-timer gesteuert werden, nur dass das so nicht geht.

Wie würdest du das lösen?

Sinnvol wäre es natürlich wenn der Dummy im MASTER über eine FHEM2FHEM-Instanz im Master quasi als Rückmeldung gesteuert wird.


EDIT:

Ich habe jetzt mal folgendes gemacht:

Master:
#--------------------------------------------------------------
# Overheat
#--------------------------------------------------------------
define Error_LED dummy
attr Error_LED alias Error LED
attr Error_LED room Overheat
attr Error_LED setList on off

define Blink_Error_LED at +*00:00:05 set Error_LED on-for-timer 1
attr Blink_Error_LED room Overheat


Slave:

define Master FHEM2FHEM 192.168.1.3:7072 LOG:.*
attr Master alias Master Control
attr Master room SystemBUS

#-----------------------------------
# Overheat
#-----------------------------------

define Error_LED RPI_GPIO 5
attr Error_LED alias Error LED
attr Error_LED direction output
attr Error_LED room Overheat

define Set_EXT_Error_LED notify Error_LED set Error_LED $EVENT
attr Set_EXT_Error_LED alias Error LED - MasterControl
attr Set_EXT_Error_LED room Overheat



So sieht das EvenLOG im SLAVE aus:

2015-04-03 23:58:42 RPI_GPIO Error_LED on-for-timer 1
2015-04-03 23:58:42 RPI_GPIO Error_LED on
2015-04-03 23:58:42 at Blink_Error_LED Next: 23:58:47
2015-04-03 23:58:44 RPI_GPIO Error_LED off
2015-04-03 23:58:44 RPI_GPIO Error_LED off
2015-04-03 23:58:47 RPI_GPIO Error_LED on-for-timer 1
2015-04-03 23:58:47 RPI_GPIO Error_LED on
2015-04-03 23:58:47 at Blink_Error_LED Next: 23:58:52
2015-04-03 23:58:49 RPI_GPIO Error_LED off
2015-04-03 23:58:49 RPI_GPIO Error_LED off
2015-04-03 23:58:52 RPI_GPIO Error_LED on-for-timer 1
2015-04-03 23:58:52 RPI_GPIO Error_LED on
2015-04-03 23:58:52 at Blink_Error_LED Next: 23:58:57
2015-04-03 23:58:54 RPI_GPIO Error_LED off
2015-04-03 23:58:54 RPI_GPIO Error_LED off

Die LED im SLAVE blinkt ganz prima! Allerdings bleibt der Dummy im WEB-IF des Masters dauerhaft on.
Diesen könnte ich ja jetzt über eine weitere FHEM2FHEM-Instanz vom SLAVE in off steuern, quasi als Rückmeldung.

Allerdings wird mir ein wenig mulmig, wenn ich im MASTER und im SLAVE zwei gleiche defines habe, das richt nach Kuddelmuddel....

Jetzt wird ein wenig Clara.

Was steht für Dich hinter Deiner Zielsetzung, alle Intelligenz auf dem Master haben zu wollen? Was verstehst Du unter "Intelligenz"? Zuverlässiger in Bezug auf die Stabilität der Funktionalität wird es dadurch zumindest nicht.
Ich habe die Erfahrung gemacht, dass was ich dachte, das müsste so sein, z.B. alle "Intelligenz" auf dem Master konzentrieren zu wollen, auf anderer Seite zu recht umständlichen Konstruktionen führt, ohne dass am Ende beim Betrieb ein Mehrwert entsteht und es so zusagen nur um einen administrativen Wunsch ging. Aber vielleicht hast Du schwerwiegende Gründe innerhalb Deiner Architektur, die ich noch nicht kenne.

Zitat von: Pf@nne am 03 April 2015, 23:33:14
...
Wie würdest du das lösen?
...

Konzeptionell sehe ich 3 Möglichkeiten:
1. Information "on-for-time" wird übertragen, kein Rückkanal: Der Slave ist "Intelligent" in Bezug auf die Funktionalität on-for-timer und holt sich per F2F den Befehl vom Dummy auf dem Master. Auf dem Master wird der Status des Moduls per notify und at gleicher Zeit automatisch zurückgesetzt, ohne dass eine Bestätigung seitens Slave erfolgt.

2. Information "schalten" wird übertragen, kein Rückkanal: Der Master führt ein "on-for-timer" aus, der Slave erhält allerdings nur die Befehle "on" und "off". In diesem Falle wäre der Slave tatsächlich nur ein Repeater für den Schaltbefehl und "dumm". Auf dem Master wird der Status des Moduls per notify und at zurückgesetzt, ohne dass eine Bestätigung erfolgt.
Da ein Dummy mM die Funktionalität "on-for-timer" nicht unterstützt (im Zweifel schau bitte mal im Forum, ich meine so etwas mal gelesen zu haben), müsste man sich hier etwas eigenes drumherum bauen... Daher ist dieser Ansatz aus meiner Sicht eher theoretisch da zu umständlich. Außerdem hast Du selbst geschrieben "kann ich prima über on-for-timer steuern" auf dem Slave steuern. Bitte vergiss 2.

3. Information "on-for-time" wird übertragen, inkl. Rückkanal: Zusätzlich zum Konstrukt aus 1. benötigst Du auf dem Master, wie Du selbst erkannt hast, ein F2F, was den Status vom Slave abholt.

Wenn jemand noch weitere Möglichkeiten weiß, immer gerne!

Je nach für-und-wieder würde ich zu 1 tendieren. Die Steuerung (das Auslösen) selbst bliebe ja beim Master, nur die Umsetzung des "on-for-timer" würde der Slave übernehmen. Ob ich einen Rückkanal bräuchte, würde ich davon abhängig machen, wie stabil (Funkstrecke) das ganze läuft. Aber wie gesagt, ich kenne nicht alle Deine Beweggründe.

Das mit der Sorge um Kuddelmuddel kann ich nachvollziehen. Gegenmaßnahmen wären,
- Du solltest dafür sorgen, dass die Informationen in eine Richtung (z.B. vom Slave zum Master, Rückkanal) keine Aktion auslöst, bzw. darauf achten, dass keine Schleife entsteht.
- Die Event, die der Slave vom Master einsammelt, würde ich in jedem Falle filtern und nur das abholen, was für den Slave tatsächlich relevant ist. Auch entsprechend Deiner jetzigen Definition würde ich das in jedem Falle tun. Dazu gibts ein Beispiel im Wiki.

Den Zusammenhang zwischen der angegebenen Definition und "ich möchte alle 30 Minuten..." hat mich glaube ich eher etwas verwirrt, da nicht zusammenpassend.
Den Effekt "es geht sicherlich eleganter" kenne ich leider auch. Hier ist Ende zumindest meines Wissens. ;)

Schöne Grüße,
John

Moin,

erstmal vielen Dank, dass du mir unter die Arme greifst und dich mit meiner Problematik auseinander setzt!

ZitatWas steht für Dich hinter Deiner Zielsetzung, alle Intelligenz auf dem Master haben zu wollen? Was verstehst Du unter "Intelligenz"?

Mit "Intelligenz" meine ich die eigentlichen logischen Verknüpfungen der Steuerung. "Der Taster soll die Lampe...."

Zitat.....und es so zusagen nur um einen administrativen Wunsch ging

Das wäre zugegebener maßen einer der Beweggründe, der Andere wäre die Auslastung der Rapberrys möglichst gering zu halten.
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. Zumindest brauchten einige Schalthandlungen manchmal etwas lange.

Ich habe momentan 4 FHEM-Instanzen laufen, 1x DS415+ / 2xRaspberry Pi2 / 2xRaspberry Pi B+.
Wenn ich jetzt die Logik in die "SLAVES" integriere habe ich das Gefühl den Überlick zu verlieren.

Das sind jetzt aber nicht wirklich in Stein gemeißelte Beweggründe, ich bin eben noch am Testen und lernen, bevor ich mein Haus zu 100% auf FHEM umschwenke.


Ich würde mal zum Testen meinen momentanen Stand, zur Variante 3 erweitern. Theoretisch fehlt ja nur der Rückkanal für das Löschen.
Eine "echte" Rückmeldung würde natürlich auch das Einschalten des Dummys im MASTER von der echten Einschaltung des GPIO im SLAVE beinhalten. Dazu bräuchte man aber noch einen weiteren Dummy im MASTER, einen der vom on-for-timer gesteuert wird um dies an den SLAVE weiterzugeben und einen der NUR die Rückmeldungen des SLAVES anzeigt.

Wie du schon sagst, es bleibt eine Frage der Notwendigkeit und macht vieles unübersichtlicher und fehleranfälliger.

Ich bleibe am Ball und würde die Ergebnisse gerne mit dir nochmal durchsprechen.


Frohe Ostern...

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.

Dann frag mal Andre  ;)

VG
Frank

Zitat von: Pf@nne am 04 April 2015, 11:18:11
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.

Zitat von: Pf@nne am 04 April 2015, 11:18:11
Ich habe momentan 4 FHEM-Instanzen laufen, 1x DS415+ / 2xRaspberry Pi2 / 2xRaspberry Pi B+.

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

Zitat von: Puschel74 am 04 April 2015, 12:08:45
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?

Zitat von: Puschel74 am 04 April 2015, 12:08:45
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.

Zitat von: Pf@nne am 04 April 2015, 11:18:11
Frohe Ostern...

Das wünsche ich ebenso.

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

Moin Puschel,

Zitat

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

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

ZitatEigentlich 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  8)

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  ;D
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.

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

Zitat von: Prof. Dr. Peter Henning am 04 April 2015, 19:32:48
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.

Zitat von: Puschel74 am 04 April 2015, 19:38:57
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. :D

Schöne Grüße,
John

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

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

Hier ist ja richtig was los....

Ich komme leider erst heute Abend zum Lesen.

Jetzt erstmal Frohe Ostern.....

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.

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?

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

Klar.
Welches UserReading hättest du den gerne?

ZitatWelches UserReading hättest du den gerne?

Na ja, da fangen die Problme schon an.... Ich habe zwar 4 Raspberrys und eine DS laufen, aber im Grunde weiß ich noch nicht mal genau was ein UserReading ist, bzw. wie man dieses zum Steuern benutzt....
Ich nutze ein UserReading um meine Temperaturmessung zu formatieren...

Du hast geschrieben:

ZitatEin UserReading erstellt und das Regexp entsprechend angepasst und der Kuchen ist im Ofen.

Jetzt fehlt mir das Rezept.... ;D

Gruß
Pf@nne

Zitat..aber im Grunde weiß ich noch nicht mal genau was ein UserReading

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

Pardon, aber irgendwie laufen da Anspruch und Wirklichkeit ein wenig auseinander: Keinen richtigen Durchblick bei FHEM, aber ein System aufbauen, von dem hier mehrere Leute abgeraten haben...

Noch einmal zum Mitschreiben: Es handelt sich bei der Lösung, zwei FHEM-Instanzen über zwei FHEM2FHEM miteinander kommunizieren zu lassen, nicht um eine "fachgerechte" Lösung. Sondern um eine fehleranfällige und langsame Lösung.

Stattdessen sollte auf der zentralen FHEM-Instanz für das gezielte Absetzen von Befehlen an einen Client (nicht "Slave") das ECMD / ECMDDevice verwendet werden, das sich an den Telnetport des anderen FHEM wendet.

pah

P.S.: Auch in diesem Falle handelt es sich bei dem zentralen FHEM nicht um eine Intelligenz...

Guten Morgen Peter,

erstmal möchte ich auch Dir ein fohes (rest) Osterfest wünschen.

Auch vielen Dank für die Beteiligung an diesem Thema.

ZitatPardon, aber irgendwie laufen da Anspruch und Wirklichkeit ein wenig auseinander: Keinen richtigen Durchblick bei FHEM, aber ein System aufbauen, von dem hier mehrere Leute abgeraten haben...

Wieso fühle ich mich jetzt als Trottel?
Natürlich habe ich bisher nur geringe Erfahrungen mit FHEM und stelle dumme Fragen und verstehe nicht alles auf Anhieb. Dazu gibt es doch aber Foren, hier helfen die alten Hasen (wie du einer bist) den Newbies (wie ich einer bin). Nur weil ich noch nicht so tief in der Materie drin stecke heißt das ja noch lange nicht, dass das nicht noch werden kann.
Mir persönlich bereitet die Umstellung auf ein so komplexes  Perl-System wie FHEM es ist ziemliche Probleme. Dennoch halte ich FHEM für das richtige System für meine angestrebte Hausautomatisierung, auch wenn ich viel neues lernen muss. Der Beitrag läuft ja auch im Anfängerbereich unter ,,fachgerechte" Umsetzung.

Vielleicht gelingt es ja den Newbies wie mir unter die Arme zu greifen, ohne dass sie sich wie Dummköpfe fühlen.
Und auch hier nochmal zum mitschreiben: Wir Newbies sind nicht von haus aus störrisch und begriffsstutzig, wir wissen es nur (NOCH) nicht besser. Bitte nicht immer gleich aufgeben, ich verstehe, dass es manchmal schon ein wenig nach ,,Beratungsresistenz" aussieht. Aber bitte nicht aufgeben und auch ein wenig Geduld mit den neuen mitbringen.

Wir sind zwingend auf die Hilfe der alten Hasen angewiesen und nehmen diese auch gerne an UND wir wissen die Hilfe auch zu schätzen.
Wenn das vorgeschlagene nicht sofort umsetzen, dann liegt es meistens daran, dass wir es noch nicht verstanden haben und weiterführende Hilfe vom Profi notwendig ist.

Nur so können Newbies wie ich etwas dazu lernen und später dann, mit ein wenig mehr Erfahrung, den neuen Newbies mit Rat und Tat zu Seite stehen.
Das macht doch ein Forum aus!

Das musste ich auch einfach mal loswerden.....nichts für ungut....
Ich hoffe, dass ich weiterhin mit deiner zielführenden Unterstützung rechnen kann.


Zurück zum Thema....

ZitatStattdessen sollte auf der zentralen FHEM-Instanz für das gezielte Absetzen von Befehlen an einen Client (nicht "Slave") das ECMD / ECMDDevice verwendet werden, das sich an den Telnetport des anderen FHEM wendet.

Wenn das der fachgerechte Weg ist, dann werde ich versuchen mich hier mal einzulesen.
Hast du hierfür ein einfaches Beispiel, z.B. für die Steuerung einer LED?
Vielen Dank wir diesen Tipp.


Gruß
Pf@nne

EDIT:
Ohne, dass ich jetzt schon näher nachgeschlagen habe halte ich die Telnet-Variante auch für sinnvoller, da hier die Anbindung an "nicht FHEM" Geräte erfolgen könnte. So wäre dies doch, so glaube ich jedenfalls, der richtige Weg um z.B. eine Steuerung über eine eigene Anwendung z.B. auf meinem Linux-SAT-Receiver zu ermöglichen oder die Anbindung von AVR Schaltungen über das Netzwerk zu realisieren.

Auch einen guten Morgen.

Ich bitte um Nachsicht, aber nach Beratungsresistenz sah das schon aus. Aber, Schwamm drüber.

In diesem Thread hier: http://forum.fhem.de/index.php/topic,29737.0.html und auf dieser Wiki-Seite http://www.fhemwiki.de/wiki/EBUS wird die Steuerung einer kompletten Heizungsanlage beschrieben. Dabei läuft ein externer (ebusd-)Server auf einem separaten Raspberry Pi und wird von FHEM aus über ECMD/ECDMDevice gesteuert. Weiters dazu in der commandref.

LG

pah

Hi,

ZitatIch bitte um Nachsicht, aber nach Beratungsresistenz sah das schon aus. Aber, Schwamm drüber.

Klar, Schwamm drüber, manchmal muss man nur mal drüber sprechen.....

Sehe ich bisher folgendes richtig?:

• ECMD/ECDMDevice stellt eine definierte Datenverbindung zwischen zwei FHEM Instanzen dar.
• Alternativ kann auch eine Verbindung zu einem "nicht FHEM" TCP-Gerät erstellt werden, hier muss nur festgelegt werden wie was geschrieben bzw. gelesen wird.
• Die "Verbindungskanäle" (was wird wie ausgetauscht) werden in s.g. classes definiert
• Die definierten classes werden in *.cfg-Files abgelegt und dem ECMD-define mitgeteilt.
• Jede class kann dann in einem eigenen ECDMDevice genutzt werden.

Das heißt ich muss die für meine Steuerung benötigte class selber definieren, was wie über das Netzwerk gesendet bzw. geantwortet wird.

Siehst du eine Möglichkeit hierzu ein einfaches Beispiel zu erstellen, da deine links sich im Wesentlichen auf bindung eines FHEM-ECMD an ein "nicht FHEM" Gerät beschreiben.

Es müssten dann ja in beiden FHEM-Instanzen ECMD-Telnet-Verbindungen definiert werden. Was ist mit der stanardmäßig vorhandenen Telnet-Verbindung?

Wie gesagt, am meisten (und schnellsten) lernt man anhand eines Beispiels.

Schalten und rückmelden einer "fernen" LED würde mir hier als "erster Schritt" einfallen.
Vielleicht siehst du eine Möglichkeit hier zu unterstützen....


Gruß
Pf@nne

Dafür würde ich im entsprechenden Thread nachfragen, das hat garantiert schon jemand realisiert.

LG

pah

OK,

---> hier geht es weiter
http://forum.fhem.de/index.php/topic,36060.msg283788.html#msg283788 (http://forum.fhem.de/index.php/topic,36060.msg283788.html#msg283788)

OK, da bin ich wieder...... :)

Nach aussage von Boris Neubert ist ECMD nicht für die Kommunikation zwier FEHM-Instanzen unterienander gedacht.

Zitat

ZitatDem entnehme ich, das ECMD für diese Fälle garnicht konzipiert wurde??
Sonder für die Anbindung von TCP-Server basierter Fremdhardware?

Als klassisches Beispiel wäre hier der Pollin NET-IO zu nennen, der im Grunde ja nur auf Befehle von Außen reagiert,
als da wären....

  sag mit mal wie warm es ist, mach mal Ausgang 3 an, wie steht Eingang 5 gerade.....

Korrekt.

ZitatZitat

Dann wäre ich ja mit ECMD auf der falschen Fährte.....und vielleich doch mit FHEM2FHEM besser beraten?

Am Ende des Tages läuft die Lösung mit ECMD doch nur darauf hinaus, dasselbe zu bewirken wie FHEM2FHEM, nur mit mehr Gewürge.

Viele Grüße
Boris

pah, hast du dazu noch eine weiterführende Idee? Warum würdest du ECMD dafür nutzen und vor allem wie?


Demnach muss ich mir über meine ferne GPIO-Steuerung mit "echter" Rückmeldung hier weiter Gedanken machen.
Ich hoffe (wie bisher auch) auf eure Unterstützung....

Ich werde jetzt mal ein Beispiel fertig machen und dann reinstellen.

Ob es dafür "gedacht" war, ist doch irrelevant - Hauptsache, es funktioniert damit.  Und "Gewürge" kann ich nicht erkennen.

Also nochmal in Kürze meine Argumente

- FHEM2FHEM führt eine lokale Filterung durch. Das bedeutet, dass alle Events der entfernten FHEM-Instanz über das Netz geschickt werden, das ist ggf. eine Menge Traffic. Je nach Auslastung kann das auch Sekunden dauern, bis ein speziell für die lokale Instanz gedachter Befehl dabei ist,ausgefiltert und dann in der lokalen Queue abgearbeitet wurde. Darüber hinaus ist diese Zeit auch vom Zustand des Netzes abhängig. Will die lokale FHEM-Instanz der entfernten etwas mitteilen, geht dies also nicht gezielt. Sondern eher mit der Flaschenpost: Man wirft etwas in den Strom und hofft, dass der Empfänger es herausfieselt.

- ECMD hingegen setzt gezielte write/read-Anweisungen per telnet ab. Das vemeidet Netztraffic, und es ist vollkommen egal, ob am anderen Ende ein FHEM oder ein andere Software mit offenem Port wartet. Sehr viel direkter, mit sehr viel weniger Overhead.

LG

pah

Moin Peter,

ZitatOb es dafür "gedacht" war, ist doch irrelevant - Hauptsache, es funktioniert damit.  Und "Gewürge" kann ich nicht erkennen.

Da hast du recht, auch konnte ich deine Argumente schon vorher nachvollziehen.
Ich teile deine Meinung, eine direkte TCP-Verbindung mit direkten commands und den dazugehörigen responses sind alle mal sinnvoller, so kann auch wesentlich gezielter auf etwailige Störungen reagiert werden.

Ich würde auch lieber mit ECMD weiter "forschen", nur stecke ich ja an dem Punkt wo ich auf der Empfängerinstanz auch das ankommende Telegramm reagieren möchte. Die TCP-Verbindung besteht, nur wie fange ich die SET/GET-CMDs ab?
Im EnventLOG ist nichts zu sehen. Muss eine class mit "Read" od "Wait_for_Data" geschrieben werden?

Vielleicht kannst du mir hier noch ein wenig Starthilfe geben.

Gruß
Pf@nne

In die "class"-Datei für ECMDDevice eintragen:

get state cmd {<hier befehl für die entfernte telnet-Instanz>}
get state expect ".*"
get state postproc { perlauswertefunktion($_) }

Dann in der eigenen myUtils.pm-Datei eine Prozedur anlegen, die

sub perlauswertefunktion($){
<hier diverse perl-Befehle zur Umwandlung der gelesenen Daten>
}

LG

pah

Hallo Peter,

get state cmd {<hier befehl für die entfernte telnet-Instanz>}
get state expect ".*"
get state postproc { perlauswertefunktion($_) }

Das hatte ich glaube ich so weit verstanden...
get cmd = zu sendender TCP-String an das entfernte "Gerät"
get expect = Filtermöglichkeit für die response vom entfernen "Gerät"
get postproc = Verarbeitung der Response z.B. in einer eigenen Perl-Routine

Das ist doch aber wieder die Prozedur zum aktiven einleiten einer Kommunikation.
Mir fehlt jetzt das Gegenstück auf der entfernen FHEM-Instanz.

get state cmd {<hier befehl für die entfernte telnet-Instanz>}
Wie kann ich dieses command auf der entfernten FHEM-Instanz wieder einfangen?

Auf der entfernten FHEM-Instanz muss doch ein TCP-Server laufen der die empfangenen Strings auswertet und weiter verwendet.
Um z.B. einen GPIO zu schalten...

Es mus doch auf der entfernten FHEM-Instanz so etwas wie

ZitatMuss eine class mit "Read" od "Wait_for_Data" geschrieben werden?

geben....

Sorry wenn ich mich immer noch so dusselig anstelle, aber irgendwie hab ich das Gefühl, das wir aneinander vorbei reden..

Und danke für deine Geduld....


Gruß
Pf@nne

Einfach mal direkt auf der externen FHEM.Instanz mit lelnet einloggen (port 7072). Dort kann man jeden FHEM-Befehl absetzen. Und das wird nun eben von ECMDDevice übernommen.


LG

pah

Moin,

ZitatDort kann man jeden FHEM-Befehl absetzen

Jetzt ist der Groschen endlich gefallen, so langsam wird mir klar warum mir keiner so richtig helfen konnte!
Das "set cmd" in der steuernden FHEM-Instanz muss einfach nur einen gültigen FHEM-Befehl enthalten!!! :P
Ich war der Auffassung man könnte "irgendetwas" senden und müsste dies dann im "postproc" des Empfänger wieder zerlegen, auswerten und damit die richtigen Ereignisse Triggern.....dem ist aber nicht so. Die "postproc" ist scheibar nur für Geräte die als response tatsächlich "irgendetwas" antworten, was dann erstmal ausgewertet werden muss.

Ein "Gewürge" würde ich jetzt erstmal auch nicht vermuten wollen. Sieht mir nach dem jetzigen Stand recht strukturiert aus.
Mit den neuen Erkenntnissen werde ich mich heute Abend mal drann setzen und versuchen einen "fernen" GPIO zu steuern und die "echte" Rückmeldung zum Sender zurück zu schicken.

Schönes Wochenende....
Pf@nne

fhem2fhem sendet im LOG modus ab morgen nicht mehr alles über die leitung sondern filtert schon direkt auf dem quell system.

gruss
  andre

@Andre

Hallo Andre, hast du das optional eingebaut, wie angekündigt?

Zitatspricht etwas dagegen die regex (optional ?) im inform für den LOG modus mit an die gegenseite zu schicken und dann vor dem versenden schon zu filtern?

VG
Frank

rudi hat es eingebaut. es wird die regex die es sowieso schon gab und die bis jetzt nur lokal ausgewertet wurde zuerst remote angewendet.

gruss
  andre

Nu ja, dann hatte die Diskussion doch etwas Gutes.

LG

pah

Ich hab das mal hier zusammen gefasst....

http://forum.fhem.de/index.php/topic,36228.0.html (http://forum.fhem.de/index.php/topic,36228.0.html)