Damit wiedersprichst du dich zum Teil selbst. Diese Statusvariable wird dann von einem Skript generiert, aber der Schaltaktor selbst liefert dir keinen Status per FHZ. Wenn du den Taster per SWAP schaltest, und die damit verbundene Variable (die in der Instanz mit diesem Taster verknüpft ist) beobachtest, wirst du sehen, dass die nicht reagiert. Die schaltet beim ersten Tastbefehlt auf TRUE und da wird sie bleiben.
Andersrum: Wenn du per Taster ein Licht anmachst, wird die Tastervariable auf TRUE gehen. Wenn du aber nun per SWAP nochmal drückst, wird wohl das Licht ausgehen, aber die Variable vom Taster wird auf TRUE bleiben.
Bei xComfort ist das anders. Da liefert jeder Taster eine Rückmeldung an IPS und dass ist super ! Deshalb meine Wahl von xComfort.
Doch warum sagte ich warum du dich z.T. selbst wiedersprichst ist, du sagst, die Variable schaltet schon richtig, NUR wenn mal ein Befehl nicht ankommt, dann stimmt es nicht mehr. Denk mal darüber nach.
Zuallerest: Es gibt keine ordentliche Möglichkeit das Problem zu lösen.
Es gibt keine Signatur/Zeitstempel oder etwas passendes, wodurch das Telegramm eindeutig erkennbar wird. Deswegen kann IPS nicht einfach dahergehen und Nachrichten filtern, auch wenn es auf den ersten Blick logisch erscheint, dass 2 Nachrichten, die ca. Xms auseinanderliegen zusammengehören müssen. Es kann sein, muss aber nicht.
Solange man auf OnChange triggert, ist es ja auch egal.
Wenn man auf OnUpdate angewiesen ist, ist die Semaphore die beste Lösung.
Das entspricht dann etwas der „Debounce“ Funktion beim Taster.
Könnte man denn nicht die Möglichkeit einbauen, dass jeder Benutzer eine Zeitspanne definieren kann, in der weitere Nachrichten für ein Gerät ignoriert werden?
Das wäre nicht nur für die hilfreich, die mehrere FHZ benutzen möchten, sondern auch für die armen FS20 Fernbedienungsnutzer. Ich habe so ein Teil bei mir am Bett liegen fürs Schlafzimmerlicht. Das Teil ist absolut katastrophal. Die Kontakte prellen, so dass ich oft zwei Anläufe brauche um das Licht auszuschalten.
Ich habe mir meine Programmierung nochmals genau angesehen. Ich habe was total merkwürdiges gemacht. In der Schalterinstanz habe ich ein Bridget FS20TX Device angegeben. Da die Codes für den Taster und den Aktor identisch sind, schaltet der Taster den Aktor direkt, wenn die IPS mal nicht funktioniert.
Läuft die IPS, so sendet die FHZ einen entsprechenden Schaltbefehl entsprechend dem Zustand der Statusvariable für den Taster.
Das ist wohl der Grund, warum bei mir die Statuswerte für Taster und Aktor identisch sind.
Das ist definitiv nicht so. Ich habe gerade bei einem Gerät das Bridged Device gelöscht und per SWAP geschaltet. Die Variable des Tasters schaltet völlig korrekt auf TRUE und auch wieder zurück auf FALSE. Einzig die Statusvariable des Aktors bleibt völlig unverändert (die müsste ich dann per Skript mit dem Taster synchronisieren, aber ich finde das mit dem Bridged Device sehr praktisch).
Kann ich nachvollziehen, so ist die Schaltzuverlässigkeit natürlich höher. Für einige Geräte (Rolladen, Luftentfeuchter, Gartenbewässerung…) werde ich wohl auch einen Rückkanal einbauen.
Mit „nicht ankommt“ meinte ich, der Befehl kommt beim Aktor nicht an, wohl aber bei der FHZ. Die FHZ setzt die Variablen dann so, als wäre der Aktor geschaltet worden. Damit ist der Zustand des Aktors mit der Statusvariable nicht mehr identisch.
So, ich habe jetzt mal eben ausprobiert, was passiert, wenn Variable und Aktorzustand unterschiedlich ist und ich den entsprechenden Taster drücke.
(Die Lampe war eingeschaltet, die Statusvariable des Tasters stand aber auf FALSE)
Der FS20 Tester zeigte mir dann folgendes: Hauscode: 13213334 Adresse: 11 13 Status: SWAP
>FS20TX Instance: #13419
>FS20RX Instance: #15967
Hauscode: 13213334 Adresse: 11 13 Status: ON
>FS20TX Instance: #13419
>FS20RX Instance: #15967
Der Swap-Befehl kam in der FHZ und am Aktor an. Die Lampe wurde korrekt ausgeschaltet.
Da die IPS aber den Wert FALSE für die Lampe gespeichert hatte, wurde ein Einschaltbefehl verschickt und die Statusvariable des Tasters (und auch des Aktors) wurden auf TRUE gesetzt und die Lampe wieder eingeschaltet.
Ich muss gestehen, dass ich ganz begeistert bin von dem Bridged Device. Durch diese Verknüpfung bleiben die Statusvariablen mit dem tatsächlichen Schaltzustand synchron auch ohne dass ich immer zwei Kanäle für jedes Gerät freihalte (Die Kanäle sind noch nicht das Problem, wohl aber die Anzahl der Taster).
Das System arbeitet eben so. Dass es nicht perfekt ist, ist uns allen bewusst.
Das eine Totzeit zum entprellen andere Probleme mit sich bringt ist dir schon klar, oder? Wenn nunzufällig in diesem Moment eine echte Nachricht gesendet wird kommt diese auch nicht an. Und Nachrichten, die nicht ankommen, sind eh schon ein Problem. Das würde sich noch verstärken.
Schau dir die Semaphor-Geschichte an. Die ist für sowas gedacht.
wir sprechen dann irgendwo aneinander vorbei. Bei mir ging es nicht mit dem SWAP Befehl. Alle Variablen blieben auf TRUE stehen, da ein SWAP nicht eindeutig erkannt werden konnte auf welchen Zustand er sich gerade befindet, da eben bei FS20 der Rückmeldekanal fehlt.
Nun könnte es aber sein, dass Paresy in der FS20RX Instanz was geändert hat in der Zwischenzeit und den DATA Kanal irgendwie mit auswertet.
Auf jedenfall war diese Geschichte der Grund, weshalb ich alles auf 2 Kanal taster umbaute. Das war dann ein wenig blöd, da man bei jedem Taster aufpassen musste, wo man gerade drückte. Es gab quasi für jede Lampe 2 Tasten, obwohl nur eine Wippe.
So, wir sind offtopic. Ich glaube das ist nicht so gut.
ja, deshalb hatte ich ja auch geschrieben: „Könnte man denn nicht die Möglichkeit einbauen, dass jeder Benutzer eine Zeitspanne definieren kann, in der weitere Nachrichten für ein Gerät ignoriert werden?“ Wer Probleme hat, kann die Zeit ja auf 0 einstellen. Damit käme dann wieder jede Nachricht an.
Leider lässt sich Semaphor nur auf Skripte anwenden (oder ich habe etwas übersehen). Wenn ich jedes Update einer Variable (ich habe ganz viele davon) erst durch ein Skript bestätigen lassen muss, dann wird die Programmierung dafür sehr umfangreich und später noch wenig verständlich.
Ich denke, dann werde ich eher mehrere IPS starten (halt für jede FHZ eine). Dann kann ich in jedem Skript nachsehen, ob die Variablen in den anderen Programmen die selben Werte aufweisen. Das ist zwar auch nicht wirklich praktisch, aber auf jeden Fall einfacher als jede Variablenänderung zu überwachen.
Wobei ich noch garnicht so genau weiss, was passiert, wenn ich einen Swap-Befehl an die FHZs und den Aktor sende. Die FHZ sendet dann ja einen entsprechenden Ein- oder Ausschaltbefehl. Ich hoffe die zweite FHZ empfängt dann nicht den Schaltbefehl der ersten FHZ.
Wahrscheinlich muss ich mal eine zweite FHZ anschliessen und testen, wie die Geräte sich verhalten.
Wenn du ernsthafte Probleme hast kannst du dir das aber durchaus selbst bauen. Du enpfängst die Variable und lässt ein Script triggern. In dem Script kannst du dann mit dem Semaphore arbeiten und eine zweite Variable kontrolliert setzen.
