Hallo Ihr,
fhem2fhem auf zwei Instanzen bidirektional verbunden. Ich bekomme über LOG:Regex die Schleifen nicht raus. Oder es ist nicht möglich
Instanz 1:
DOIFname DOIF mit 3 Stati cmd_1 cmd_2 cmd_3
state wird in
Instanz 2:
DOIFname Dummy
geschrieben.
Jetzt möchte ich gerne mit dem Dummy von Instanz 2 -> das DOIF state auf Instanz 1 setzen. Das
DOIFname cmd_event: set_cmd_x
generiert dann eine Schleife (vermute ich. Dem Event Monitor kann ich nicht so schnell folgen)
Jetzt viel mit LOG:DOIFname Regex im fhem2fhem Device auf beiden Seiten rumprobiert, aber irgendwie schaffe ich es entweder, dass gar nichts auf der anderen Seite ankommt, oder die Schleife entsteht.
Auch mal den loopThreshold in fhem2fhem auf beiden Seiten auf 2 Sekunden gestellt und das Regex offengelassen (LOG:DOIFname.*). Dann gibts zwar keine Schleifen, aber die Info kommt auch nicht (immer) an.
Das fhem2fhem Device auf beiden Seiten hat die attr:
attr f2fdevice addStateEvent 1
attr f2fdevice keepaliveInterval 10
attr f2fdevice reportConnected 1
Ich hoffe, es gibt ein RegEx im f2fdevice auf der jeweiligen Seite, dass es erlaubt, das DOIF zu setzen ohne dass die Schleife entsteht.
Wie macht ihr das?
Selbstverständlich ist das möglich, das mache ich seit Jahren mit 5 verschiedenen FHEM-Instanzen. Einen entsprechenden Auszug aus dem Buch, dass auf der Homepage von FHEM referenziert ist, gibt es dazu hier auch irgendwo.
In aller Kürze: FHEM2FHEM mit der Option LOG:none, und Daten/Kommando mit "set ... cmd ..." schicken.
LG
pah
Hallo pah, den Auszug aus dem Buch hätte ich gerne gefunden, aber weder die foreninterne noch Google Suche hat etwas mit "fhem2fhem" zutage gefördert.
Dein in aller Kürze verstehe ich nicht. Log:none lässt doch gar nichts mehr durch (das Device wird/soll auf beiden Seiten geschaltet/werden) und set cmd ist eigentlich das was ich mache?
Ich muss nochmal dieses Dummy-mit-selben-Namen-Konzept durchdenken. Dachte, es könnte so einfach sein .... verstehe noch gar nicht so genau, was die Schleife überhaupt auslöst.
Auf Kiste 90
defmod Task_94 FHEM2FHEM 192.168.0.94:7073 LOG:none
sub fhem94Cmd($){
my ($cmd) = @_;
fhem("set Task_94 cmd ".$cmd);
}
Auf Kiste 94
defmod Task_90 FHEM2FHEM 192.168.0.90:7074 LOG:none
sub fhem90Cmd($){
my ($cmd) = @_;
fhem("set Task_90 cmd ".$cmd);
}
Alle Kommandos _explizit_eingeben, z.B auf Kiste 90
{fhem94Cmd("HIER EIN FHEM-KOMMANDO, evtl. mit Daten")}
z.B.
({fhem94Cmd("{evalProfile('climate','".Value("climateProfile")."')}")})
LG
pah
Danke. Sehr komplex. Ich lass das mal sickern.
Als Schubs, bedeutet, durch zB auf der Instanz ohne dem DOIF ein
set DOIFname cmd cmd_3
kommt trotz LOG:none auf der anderen Seite
DOIFname cmd_1
als Event "durch"?!
oder geht ohne die Subs auf der jeweiligen Seite gar nichts? Sorry, das ist für einen Nichtprogrammierer Anschlag.
ein
attr fhem2fhemDevice loopThreshold 3
in beiden f2f Instanzen brachte dann doch die Lösung. Sicherlich ein Workaround (wenn man mit Schaltvorgängen aufeinanderfolgend schneller als die 3 Sekunden ist erfolgt kein update auf der anderen Seite), aber was pah hier gezaubert hat, versteh ich nicht.
Jetzt kann man von beiden Seiten (Instanz 1 das eigentliche Device, Instanz 2 ein Dummy mit selben Namen und umgedreht) schalten und braucht keine zusätzlichen Dummies oder notifies.
Das ist maximal umständlich, das verwende ich nur für echte Duplikate von Devices. Beispielsweise habe ich einen außenliegenden Raspberry Pi Zero mit diversen Wettersensoren, die spiegele ich tatsächlich auf entsprechende Dummies in meinem Haupt-FHEM. Für die Übertragung von Schaltbefehlen ist aber mein unten skizzierter Weg der Bessere.
Wenn ich vom Neben-FHEM 94 aus die Leuchte "WZ.Ecke" auf dem Haupt-FHEM 90 einschalten will, muss ich auf dem 94er nur ein
set Task90 set WZ.Ecke on
absetzen. Oder, auf Perl-Ebene (und _nur dann_ wird das Unterprogramm verwendet)
{fhem90Cmd("set WZ.Ecke on")}
Da ist nichts von "zusätzlichem dummy oder notify" vorhanden.
LG
pah
Ich würde "deinen Weg" gerne probieren, kann aber deinem Code nicht folgen. Ich programmiere kein perl bin also auf vollständig funktionierende snippets angewiesen.... und ein Beispiel-Device welches entsprechende sub aufruft zB. Dann kann ich damit weiterdenken.
Nicht doch. Ich habe doch geschrieben, dass das ganz ohne Perl auskommt.
pah
Um mal dedizierter zu werden. Ohne subs probiert, Eingaben in der FHEM Befehlszeile:
Instanz2 hat es das DOIF
BlueIris_ArmDisarmDOIF
Instanz1 hat es den Dummy (der in ftui als switch den state vom DOIF auf Instanz2 auswertet und auch schalten soll)
BlueIris_ArmDisarmDOIF
Wenn ich auf Instanz1 (Dummy) ein
set BlueIris_ArmDisarmDOIF set cmd_2
absetze, bekomme ich das auch so (set cmd_2) in den state vom DOIF auf Instanz2 geschrieben. Ich verstehe dieses doppelte "set" in deiner Syntax nicht.
Auf dem Standard-Weg (set BlueIris_ArmDisarmDOIF cmd_2) ensteht die Schleife (Instanz2 schreibt dann den gesetzten state von BlueIris_ArmDisarmDOIF wiederum auf Instanz1 und der Dummy schaltet dementsprechend ... und los geht der wilde Ritt).
Ich könnte jetzt noch einen weiteren Dummy auf Instanz1 bemühen der nur von Instanz2 verwertet wird (über LOG: auf Instanz1 ausgenommen) und auf Instanz2 zB über ein Notify das DOIF schalten. Dann hätte ich die Schleife durchbrochen (hätte ich?). Aber in ftui einen switch anzulegen der auf ein Device hört und ein anderes schaltet ist dann auch wieder um drei Ecken. Zusätzlich 2 Dummies und ein notify um letztschlussendlich EIN Device auf einer Seite zu schalten würde ich ungern für mehrere Devices anlegen.
f2f ist neu für mich. Ich hab keine Ahnung, was das richtige Konzept für die Aufgabe ist. Scheint viele Wege zu geben.
Moment: dein "Task90" ist der andere Raspi? Ist das die DNS, Name, oder, oder? Ich steh ganz fest auf dem Schlauch.
Zitatset BlueIris_ArmDisarmDOIF set cmd_2
Vieleicht einfach genau lesen und die richtige Syntax für FHEM-Set-Befehle beachten. Es muss heißen
(Zunächst das Kommando an die fhem2fhem-Instanz) set <HIER DEVICENAME des fhem2fhem> cmd (und jetzt folgt das Kommando an die andere Seite) set BlueIris_ArmDisarm cmd_2.
Zusammen also:
Zitatset <HIER DEVICENAME des fhem2fhem> cmd set BlueIris_ArmDisarm cmd_2
Wetten, dass es geht?
LG
pah
Task90 ist bei mir der Name des fhem2fhem-Device auf der 94er Seite, weil damit Kommandos auf der 90er Kiste ausgeführt werden.
Rate mal, wie das andere fhem2fhem-Device auf dem 90er heißt, mit dem ich Kommandos auf der 94er Kiste ausführen kann. ;)
JETZT, habe ich es kapiert. Dankeschön. Werde ich probieren
Zitat von: Prof. Dr. Peter Henning am 07 März 2025, 15:28:33Task90 ist bei mir der Name des fhem2fhem-Device auf der 94er Seite, weil damit Kommandos auf der 90er Kiste ausgeführt werden.
war der entscheidende Hinweis ... und steht ja auch oben. Da hat mir das folgende Perl gleich Angst gemacht. Augen zu und ... :D
Zitat von: Prof. Dr. Peter Henning am 06 März 2025, 15:57:54defmod Task_94 FHEM2FHEM 192.168.0.94:7073 LOG:none
Edit: das funktioniert tatsächlich ... jetzt muss ich nur noch schauen, ob die Schleife so nicht auftritt :)
... keine Schleifen mehr dank Log:none auf der Instanz2. Danke pah ...
Das gehört zwar nur halb hierher, aber falls noch jemand auf ftui2 unterwegs ist und ein solches Konstrukt sowohl anzeigen als auch schalten möchte
<div data-type="switch"
data-doubleclick="800"
data-device="BlueIris_ArmDisarmDOIF"
data-cmd="set fhem2fhemZH cmd set"
data-states='["initialize","initialized","cmd_1","cmd_2","cmd_3"]'
data-set-states='["cmd_3","cmd_3","cmd_3","cmd_3","cmd_2"]'
data-colors='["#aaa","#aaa","red","SeaGreen","blue"]'
data-background-colors='["#aaa","#aaa","red","SeaGreen","blue"]'
data-icons='["fa-unlock","fa-unlock","fa-lock","fa-unlock","fa-unlock"]'
data-background-icon="fa-circle-thin"
class="small">
</div>
... und es lässt mich nicht los ...
Jetzt habe ich auf Instanz1 den gleichnamigen (wie das DOIF auf Instanz2) Dummy. Den brauche ich Lokal für die Anzeige des DOIF (state) von Instanz2.
f2f auf Instanz2 ist mit LOG:none für alles was von Instanz1 kommt blockiert.
f2f auf Instanz1 ist mit LOG:BlueIris_ArmDisarmDOIF.* offen
Über ftui kann ich das DOIF auf Instanz2 mit
set fhem2fhemZH cmd set BlueIris_ArmDisarmDOIF cmd_x
direkt schalten. Der Dummy auf Instanz1 wird dann über das DOIF von Instanz2 wiederum aktualisiert.
ftui ist sozusagen ein drittes Device, da es den state vom Dummy nur anzeigt, aber nicht ohne Einflussnahme reagiert.
Wie kann ich auch den Dummy auf Instanz1 FHEM-intern schalten, so dass das DOIF auf Instanz2 geschaltet wird ohne wieder eine Schleife zu bauen? Ich kenne keine Möglichkeit direkt "set fhem2fhemZH cmd set BlueIris_ArmDisarmDOIF cmd_x" mit einem Dummy abzusetzen.... aber auch dann würde es zur Schleife kommen.
Habs mal mit einem DOIF auf Instanz1 probiert was auf den Dummy reagiert und das DOIF auf Instanz2 schaltet....
define DummySchaltDevice DOIF ([BlueIris_ArmDisarmDOIF:state]) (set fhem2fhemZH cmd set BlueIris_ArmDisarmDOIF $EVENT)
Aber klar, Schleife über beide Instanzen hinweg
Ich möchte auf zwei Seiten "das selbe Device", welches ich auf beiden Seiten synchronisiert anzeigen und schalten kann, ohne eine Schleife zu bauen.
pah´s Weg funktioniert gut für ftui, aber erfüllt nicht ganz das was ich möchte.
Das muss doch irgendwie gehen ...
hi,
eignet sich dafür MQTT nicht besser, ein device und synchron auf alle Seiten,
ich hatte auch immer wieder fhem2fhem Probleme, beim starten usw.
gruss
Ich denke, über mqtt hast du die selben Probleme. Synchron "das selbe device" auf beiden Seiten schalten und anzeigen sollte eigentlich immer zu einer Schleife führen. Wahrscheinlich möchte ich da etwas, was prinzipiell nicht funktionieren kann.
oder eben der Workaround über attr fhem2fhemDevice loopThreshold x
was dann nur "Halb synchron ist" wenn du zu schnell schaltest.
Aber es will mir einfach nicht in den Kopf, dass die klugen Hirne hier für diese, nicht außergewöhnliche Idee finde ich, noch keine Lösung gefunden haben.
hi,
okay, zeitfaktor hatte ich jetzt nicht gedacht,
da ich an zwei Schaltern an verschiedenen Position nicht schalten kann.
ich glaube es geht nicht wirklich.
Schalter A + A' zum selben Zeitpunkt (ms) schalteten geht nicht.
es wird immer einer schnell sein.
es ist aber ein Gedanke wert.
gruss
geht gar nicht so sehr um wie schnell was schaltet (naja, schon), sondern dass der Event von A bei B ankommt, B reagiert darauf, schaltet und der Event kommt dann wieder bei A an und löst wieder die Schaltung aus, wieder zu B, ..... So entsteht die Schleife. Dabei ist es egal, ob es immer der selbe Befehl ist. Event -> Trigger
Unterbrechen kann man das mit dem attr loopThreshold
pah´s Ansatz schaltet nur B und A wird durch den Event von B synchron. Damit das funktioniert, darf A nicht beim synchronisieren (auf den event reagierend) die selbe Schaltung triggern. Das ist aber die Basis, wenn du auf beiden Seiten das "selbe" synchronisierte und schaltbare Device haben willst. ftui bildet da die Ausnahme, weil du manuell schaltest. Also Zeit vergeht (was auch das attr loopThreshold macht. Das unterbindet für x Sekunden die selben Events).
Da ich aber erst seit 2 Tagen mit f2f rumspiele, weiss ich nicht, ob es nicht doch irgendwie funktioniert. Ich kann dem Ganzen noch gar nicht komplett folgen was wie wo passiert.
Muss nochmal den Weg über notifies/doif und anders benannten Devices nachdenken. Nur erscheint mir das recht aufwendig (und verwirrend bei so vielen Devices für eigentlich nur eins)..... und was passiert wenn du mehrere "gleiche" Devices auf beiden Seiten haben willst. Das führt ja in eine Device-Schlacht....
Wenn man mit einem Dummy kompliziertere Set-Kommandos will, kommt man ohne ein notify, besser noch um ein DOIF nicht herum.
Beispiel: Ich habe einen Dummy "Geschirrspuelen"
Zitatdefmod Geschirrspuelen dummy
attr Geschirrspuelen readingList active event phase
attr Geschirrspuelen setList EndTime:time StartTime:time RelativeTime:time
Das zugehörige DOIF lauscht darauf, was hier für ein "set" abgesetzt wurde - und führt dann eine sehr komplizierte Steuerung mit diversen Schritten durch.
Ich liste jetzt nicht das ganze DOIF auf, der wichtige Auslöser ist ganz einfach
Zitat([Geschirrspuelen:".*EndTime.*"] and [Geschirrspuelen:active] ne "start" and [SN55ZS49CE] =~ /Ready/)
Und es ist wohl sonnenklar, dass damit auch ein "set <FHEM2FHEMDevice> cmd set <Irgendwas auf anderem FHEM>" ausgeführt werden kann.
LG
pah
Haben wir gleichzeitig .....
Was funktioniert:
defmod BlueIris_ArmDisarmDOIF_Trigger DOIF ([BlueIris_ArmDisarmDOIF:state] and [$SELF:LastEvent] ne "$EVENT") (set fhem2fhemZH cmd set BlueIris_ArmDisarmDOIF $EVENT, set $SELF LastEvent $EVENT)
attr BlueIris_ArmDisarmDOIF_Trigger do always
attr BlueIris_ArmDisarmDOIF_Trigger readingList LastEvent
aber das ist ja dann schon sehr mit Kanonen auf Spatzen und überfordert meine Konzentration beim Anlegen von vielen Devices .... und funktioniert nur mit Dummies sonst gibts Probleme mit state (was man dann auch mit tüdelü ausbügeln könnte, aber .....) ..... sehr, sehr unschön.
Ich bin sehr offen für eure Ideen ;) ......
Zitat von: Prof. Dr. Peter Henning am 08 März 2025, 11:56:21Wenn man mit einem Dummy kompliziertere Set-Kommandos will
Kompliziert wirds mir beim Bidirektionalen -> selbes Device/Dummy auf beiden Seiten sowohl synchron als auch schaltbar. In eine Richtung habe ich generell mittlerweile verstanden