ich weiß nicht so recht, wo meine Fragen thematisch am besten passen. Da EnOcean der Auslöser für die Fragen ist, bringe ich sie mal hier unter.
In EnOcean gibt es die wunderbare Funktion „Status emulieren“, mit der man wählen kann, ob die Statusvariable der Instanz bei einer Schaltaktion immer geändert wird oder nur dann, wenn man eine Rückmeldung erhalten hat und auch wirklich geschaltet wurde.
Nun zu den Fragen:
Sowas hätte ich mir auch für andere Hardware wie z.B. KNX gewünscht, dass ich wählen kann, ob die Statusvariable immer geändert wird oder nur dann wenn über eine der eingetragenen Rückmeldeadressen die Bestätigung erfolgt.
Gerade wenn man Aktoren z.B. systemseitig sperrt wäre das sehr nützlich. Wäre sowas realisierbar?
Nach jedem Schaltvorgang den Status per Script abzufragen halte ich nicht für praktikabel.
Wenn ich den Status nicht emuliere, also die Variable nur nach erfolgreicher Rückmeldung gesetzt wird, ändert diese sich ja nicht, wenn aus irgendeinem Grund nicht geschaltet werden konnte oder die Rückmeldung ausbleibt. Soweit so gut.
Nicht so schön ist, dass wenn ich in der App / WebFront schalte, die Variable direkt mit dem neuen Status angezeigt wird, selbst wenn sie nicht geändert wurde. Um den realen Status zu sehen, muss man einmal die Seite mit der Variablen wechseln und wieder zurück, dann zeigt sie wieder den korrekten Status an. Lässt sich das ändern? Ist vermutlich eher eine Unzulänglichkeit von App / WebFront und hat nicht direkt etwas mit der Funktion zu tun.
Was passiert bei der Status GA wenn man auf der Schalt GA eine „EIN“ schickt, aber dieses aufgrund der Sperrung nicht ungesetzt wird? Sendet die Status GA dann den aktuellen Wert? Das hätte ich jetzt eigentlich so erwartet.
Der Hintergrund ist folgender. Sofern es keine Fehlermeldung gibt, geben wir davon aus, dass das Gerät geschaltet hat. Ansonsten hast du sehr unschöne Verzögerungen und die Leute klicken mehrfach auf die An/Aus Elemente. Da diese nur „Toggle“ sind, würde ggf. das Licht sofort wieder aus gehen. Die aktuelle Variante ist somit nicht perfekt (für unidirektionale System oder bidirektionale System ohne direktes ACK) aber das geringere „übel“ im Vergleich zum viel zu späten Feedback.
Nein, die Aktoren senden dann gar nichts auf der Status GA. In IPS geht die Variable auf „EIN“, in Wirklichkeit passiert aber nichts. Würde ich manuell einen Request hinterher schicken, ginge sie wieder auf „AUS“.
Ich kenne jetzt sicherlich nicht alle KNX-Hersteller und will nicht ausschließen, dass es welche gibt, die ein Telegramm immer mit einem Status-Telegramm beantworten. Die Hersteller und Aktoren, die ich kenne, bieten aber in der Regel nur folgende Möglichkeiten:
[ul]
[li]Status zyklisch senden (Intervall in der Regel einstellbar)
[/li][li]Status bei Änderung senden
[/li][/ul]
Im Prinzip ist das bei den meisten Aktoren so (Schalter, Rolladen etc.)
Ich habe mir schon so etwas gedacht und kann die Implementierung daher nachvollziehen. Mir würde auf Anhieb auch keine bessere Alternative einfallen.
Habe gerade getestet. Wenn ein Aktorkanal gesperrt ist und man auf die GA für Schalten eine 1 sendet, dann meldet der Aktor nichts zurück. In IPS steht dann „an“.
Ich verstehe das Problem - bisher hast du Recht, dass dies mit IP-Symcon nicht sauber lösbar ist. Im Prinzip willst du nur auf die zusätzlichen GAs hören und nicht auf die Schaltende GA.
Ich habe das folgendermaßen gelöst, das ich eine andere Variable selber gebaut habe, diese Schalte ich (sofort) und gebe den Schaltbefehl an den echten Aktor weiter… dann zieht meine Variable automatisch einen Timer mit dem Timeout auf (bei mir 14 Sekunden, weil Dimmer recht träge sind) und vergleicht dann nochmal die Variable mit dem Gerätezustand.
Wenn die abweichen kann man unterschiedlich reagieren, ich wiederhole das Senden ein 2. mal automatisch, wenn das auch nicht klappt gebe ich per Push-Nachricht einen Fehler aus und stelle die Variable zurück… so zeige ich immer den richtigen Zustand an (von der Laufzeit bis Timeout mal abgesehen) und habe trotzdem sofortige Reaktion.
Allerdings hoffe ich mir das alles sparen zu können, wenn ich den FGW-14-USB als Gateway benutze, da dort regelmäßig der aktuelle Schaltzustand zurückgemeldet wird und damit immer der aktuelle Stand im IPS steht (ob mir das schnell genug geht weiß ich noch nicht).
Im übrigen mache ich das alles, was ich oben beschrieben habe in einem „Virtuellen Gerät“ das ich gerade als Modul schreibe, damit muss man dann nichts programmieren.