fhem2fhem bidirektional und die Schleifen

[holle75]

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

Code Auswählen Erweitern

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.

[eisman]

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

[holle75]

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

[Prof. Dr. Peter Henning]

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"

defmod 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

([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

[holle75]

Haben wir gleichzeitig .....

Was funktioniert:

Code Auswählen Erweitern

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

[holle75]

Wenn 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