FHEM2FHEM - Umsetzung

[Pf@nne]

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

[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

[franky08]

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

[franky08]

Auf dem Slave habe ich dann:

Code Auswählen Erweitern

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 :

Code Auswählen Erweitern

define pifhem dummy
attr pifhem DbLogExclude .*
attr pifhem room RASPI
#

ein dummy.

VG
Frank

[Pf@nne]

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

[franky08]

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

[Pf@nne]

OK,

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

Kannst du mir hierzu etwas unter die Arme greifen?

[franky08]

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

VG
Frank

[joshi04]

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

[Pf@nne]

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

[franky08]

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

[joshi04]

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

[Pf@nne]

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.

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.

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?

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:

Code Auswählen Erweitern

#--------------------------------------------------------------
# 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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[joshi04]

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.

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

[Pf@nne]

Moin,

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

Was 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...."

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