Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Option 2: könnte man ggf. eine zweite Sperre (analog E13) einführen
Wäre es in dem Fall nicht besser anstatt einer weiteren Sperre die Option zu haben dass bei Sperren nichts passiert?
So wie man diese Möglichkeit bei manchen KNX Geräten hat.
z.B. Aktivirbar mit einem Wert außerhalb des Bereichs bei "Position bei Sperre", z.B. mit -1
Das Thema mit den Ausgängen habe ich auch noch, da ich den Baustein nach händischer Behangfahrt ausschalte und nach (zeitgesteuerter) Reaktivierung oft erstmal Times abwarten muss, bis wieder der neue Wert kommt.
Das mit der Sperre geht leider nicht, da wie Du schon geschrieben hast nach Sperre aufheben der letzte Wert nicht gesendet wird.
Das könnte man zumindest mit zusätzlicher Logik lösen: Der berechnete Wert am Ausgang vom Beschattungsbaustein wird zusätzlich in ein iKO geschrieben. Sobald die Sperre entsperrt wird (iKO 326 im Beispiel oben geht auf "1"), triggert das auch eine Logik, die die Werte aus den iKOs auf die tatsächlichen (KNX)-GAs setzt.
Option 1: warum wird bei Aktivierung des LBS über E12 nicht einmal der Baustein komplett getriggert und neue Werte ohne irgendwelche Timer direkt ausgegeben?
Tatsächlich fände ich diese Lösung am besten. Wenn ich den Baustein wieder anschalte fände ich es toll, wenn gleich eine Wertberechnung mit -ausgabe stattfinden würde.
Was ich mir auch vorstellen könnte: E9 und E10 sind ja dafür da, dass sich der Baustein abschaltet, sofern die Ist-Werte von den berechneten Werten um x % abweichen. Evtl. wäre es auch denkbar, dass man über ein Flag einstellen kann, dass diese Abweichung den Baustein nur sperrt aber nicht abschaltet, dann hätte man ja das sofortige senden der berechneten Werte nach Aufheben der Sperre.
Wäre es in dem Fall nicht besser anstatt einer weiteren Sperre die Option zu haben dass bei Sperren nichts passiert?
Nachteil davon wäre daß ich für meinen Fall den Türkontakt (der eine Position anfahren soll) und den Automatikstatus (der keine Veränderung triggern soll) per ODER Baustein auf den Sperreingang legen müsste und dann noch eine Logik den Eingang Positionsänderung ja/nein zusätzlich berechnen müsste. Mit meinem Vorschlag könnte ich beide KO direkt ohne irgendein LBS auf die beiden unterschiedlichen Sperreingänge legen und auch die Position direkt auf die Eingänge legen ohne weitere Logik.
Oder man ändert das Verhalten bein Erkennen von manuellem Verfahren. Der LBS schaltet sich dann nicht mehr aus, sondern sperrt nur die Ausgänge, rechnet aber wie bei Sperre = 1 intern weiter. Dafür würde aber ein Reseteingang notwendig werden, um den LBS dann wieder in den „Automatikmodus“ zu bringen. Ein Ausgang für „Auto-Aus“ Wäre dann auch eine feine Sache. Dann kann mit einem Verzögerer nach Auto-Aus der Reset in den Automatikmodus gemacht werden.
Mfg Micha
Qualifizierte und richtige Antworten gibts nur von Leuten, die während des Neustarts des HS Zeit für einen Post haben!
Oder man ändert das Verhalten bein Erkennen von manuellem Verfahren. Der LBS schaltet sich dann nicht mehr aus, sondern sperrt nur die Ausgänge, rechnet aber wie bei Sperre = 1 intern weiter.
Jepp, hatte ich oben in #737auch schon mal vorgeschlagen. Wobei man fürs Entsperren ja keinen neuen Eingang bräuchte, das geht ja bereits mit E13. Aber eine Status-Ausgabe, die über die Sperre informiert wäre sinnvoll (um ggfls. einen Resktivierungs-Timer zu starten). Z.B. als eigenen Statuswert an A10 oder einen dedizierten Sperrstatus-Ausgang.
Das Ausschalten des LBS ist ja so quasi auf meinem Mist gewachsen. Das hatte mir im Ur-LBS gefehlt. In der nächsten Version wurde die Funktion dann eingebaut. Damals war der LBS auch noch sehr übersichtlich, und ich hatte noch nicht das Bedürfniss, das der LBS intern weiterrechnet. An dem Zopf festzuhalten, das sich der LBS ausschaltet, sehe ich keine Notwendigkeit mehr. Wenn es wirklich mit einer internen Sperre getan ist, dann umso besser.
Mfg Micha
Qualifizierte und richtige Antworten gibts nur von Leuten, die während des Neustarts des HS Zeit für einen Post haben!
wenn ich mich nicht schwer täusche, dann habe ich in der aktuellen Version einen Bug eingebaut.
Würdet ihr bitte prüfen, ob sich der Baustein wirklich so wie gewünscht verhält, wenn die Sperre aufgehoben wird? Ich habe bzgl. der neuen Variante der Sperre ein wenig experimentiert und dabei ist mir aufgefallen, dass das mit der Positionsberechnung während aktiver Sperre nicht wirklich funktioniert bzw. nach der aktuellen Implementierung nicht funktionieren kann.
Bisher habe ich keine Detailtests gemacht, sondern nur bei Dämmerung Sperre an und wieder aus. Da wurde zumindest dann immer die Dämmerungsposition wieder nach der Sperre angefahren... Mit aktiver Beschattung habe ich bisher aufgrund des schlechten Wetters noch keine Erfahrung sammeln können
Morgen werde ich mir dann eine Logik für die 1 und 2 Generierung an E13 ausdenken... Und was ggf. jetzt auch noch ein "Problem" ist, ist das man die Bausteindeaktivierung durch manuelles Verfahren an E12 und E13 rückgängig machen muss, da ja der Baustein nicht gesperrt sondern wirklich deaktiviert wird, oder?
Aber da denke ich morgen weiter draufrum wieviel Logik da nun nötig ist und experimentiere mal etwas...
danke für die neuen Features. Werde ich gleich testen.
Wäre es möglich, dass bei manueller Änderung des Behangs der Baustein weiterhin aktiv bleibt und der Baustein nur gesperrt (2) wird?
Dadurch müsste man nur den Status überprüfen (wenn es auch als Ausgang zur Verfügung steht) und ggf. darauf reagieren.
irgendwie bekomme ich keine wirklich sinnige und einfache Logikidee für die neue Struktur der Sperre im Zusammenspiel mit der Abschaltung des LBS bei manuellem Verfahren hin.
Daher nochmal die Frage an alle User des LBS hier (einige wie Hardy und Micha haben ja schon signalisiert den E12 bzw. das wirkliche AN/AUS des LBS nicht (mehr) zu brauchen):
Wer braucht eine komplette Abschaltung des LBS über E12? Ich kann mir da grad kaum einen Anwendungsfall vorstellen...
Nach längerem Überlegen wäre für mich sinnig:
E12 (0|1) wird Sperre ohne Verfahren
E13 (0|1) wird Sperre mit Position anfahren über E14+15
A8 signalisiert ob Baustein gesperrt ist (0|1) wobei Sperre entweder über E12 oder E13 aktiv sein kann. Das würde jedoch die Logik an A8 invertieren, wäre also nicht abwärtskompatibel...
Zum Entsperren müssten dann halt an E12 und E13 eine "0" anliegen dann würde A8 auf "0" gehen. Solange einer der Eingänge mit "1" belegt ist bleibt Sperre an A8 "1".
für bessere Abwärtskompatibilität könnte man auch einen neuen Ex und Ax anlegen für Sperrstatus und Sperre ohne verfahren. Ich bin aber der Meinung Baustein AN/AUS könnte eigentlich entfallen.
Hätte da jemand Einwände?
und die wichtigste Frage an Yves: Wäre das einigermaßen einfach im LBS umsetzbar?
Zuletzt geändert von tger977; 11.03.2018, 18:03.
Grund: Abwärtskompatibilität geändert und weiter detailiert
Wer braucht eine komplette Abschaltung des LBS über E12? Ich kann mir da grad kaum einen Anwendungsfall vorstellen...
Der Usecase den ich an dieser Stelle durchaus habe ist, dass eine Abschaltung der Bausteine die CPU-Last auf Edomi verringern kann, je nachdem wieviele Instanzen des LBS man laufen hat und wie häufig diese getriggert werden. Unterm Strich also dann von Interesse, wenn man eher schächere Hardware für Edomi verwendet...
Nach längerem Überlegen wäre für mich sinnig:
E12 (0|1) wird Sperre ohne Verfahren
E13 (0|1) wird Sperre mit Position anfahren über E14+15
A8 signalisiert ob Baustein gesperrt ist (0|1) wobei Sperre entweder über E12 oder E13 aktiv sein kann. Das würde jedoch die Logik an A8 invertieren, wäre also nicht abwärtskompatibel...
Zum Entsperren müssten dann halt an E12 und E13 eine "0" anliegen dann würde A8 auf "0" gehen. Solange einer der Eingänge mit "1" belegt ist bleibt Sperre an A8 "1".
Grundsätzlich einverstanden. Allerdings würde ich den Inhalt von A8 mit den beiden Sperr-Eingängen verUNDen, also
E12 = 0, E13 = 0 > A8 = 0
E12 = 1, E13 = 0 > A8 = 1
E12 = 0, E13 = 1 > A8 = 2
E12 = 1, E13 = 1 > A8 = 3
Damit wäre auch am Ausgang klar, welche Sperre aktiv ist.
für bessere Abwärtskompatibilität könnte man auch einen neuen Ex und Ax anlegen für Sperrstatus und Sperre ohne verfahren. Ich bin aber der Meinung Baustein AN/AUS könnte eigentlich entfallen.
und die wichtigste Frage an Yves: Wäre das einigermaßen einfach im LBS umsetzbar?
Nunja, einfach ist alles und nichts, die Tücke liegt bekanntlich immer im Detail.
Bis jetzt haben wir noch immer eine Lösung gefunden, auch wenn es in den meisten Fällen nicht trivial ist, die Abläufe im LBS anzufassen. Allerdings kann ich schon sagen, dass es mit dem NG-Baustein viel einfacher ist, überhaupt Umbauten zu machen, da die State-Machine für das eigentliche Handling der Behangpositionen völlig separat von den Trigger-Bedingungen des LBS abgearbeitet wird.
Der Usecase den ich an dieser Stelle durchaus habe ist, dass eine Abschaltung der Bausteine die CPU-Last auf Edomi verringern kann, je nachdem wieviele Instanzen des LBS man laufen hat und wie häufig diese getriggert werden. Unterm Strich also dann von Interesse, wenn man eher schächere Hardware für Edomi verwendet...
grundsätzlich dachte ich das auch erst, aber beim zweiten Überlegen kam ich zu dem Schluss daß das kaum etwas bringt, da der WorstCase bzgl. CPU ja der Fall ist in dem alle Bausteine tatsächlich aktiv sind und das wird wohl bei sehr sonnigen Tagen immer der Fall sein. Und macht wirklich wer eine Logik um über E12 abhängig von hoher CPU Last einige Bausteine abzuschalten?!
Allerdings würde ich den Inhalt von A8 mit den beiden Sperr-Eingängen verUNDen, also
E12 = 0, E13 = 0 > A8 = 0
E12 = 1, E13 = 0 > A8 = 1
E12 = 0, E13 = 1 > A8 = 2
E12 = 1, E13 = 1 > A8 = 3
Damit wäre auch am Ausgang klar, welche Sperre aktiv ist.
das sehe ich wieder aus Anwendersicht kritisch, da
a) man dann wieder Logik braucht um Stati 1-3 aufzulösen.
b) frage ich mich auch was ich mit der Detailierung machen soll. Gesperrt ist gesperrt, da ist es mir eigentlich egal über welchen Eingang.
c) man in der Visu vermutlich auch keine zwei verschiedenen Stati darstellen würde sondern nur gesperrt oder freigegeben.
Wenn's wirklich gebraucht wird: ganz konsequent wäre zwei Ausgänge anzulegen, jeweils passend und mit gleichen Wertebelegungen (0 und 1). Dann könnte man diese auch leichter mit (Binär)Logiken weiterverarbeiten. Ich halte Stati mit 2 oder 3 immer für schwierig(er) in der Weiterverarbeitung...
Nochmal meine Idee im Detail:
ich würde an den (einen!) Ausgang der Sperre das KO Automatikmodus hängen und beschreiben. Parallel kann dieses KO auch über die Visu oder Taster direkt beschrieben werden. Damit würde ich dann auch das Sperren über ein manuelles Verfahren sofort mitbekommen und kann dies auch in der Visu darstellen und auch z.B. über einen Timer ein automatisches Wiederaktivieren des LBS machen (so wie ich es heute schon über den E12 mache)
KO Automatikmodus kommt auch direkt an den Ex für Sperre ohne Verfahren. Damit wirkt hier auch z.B. das Wiederaktiveren über Timer nach manuellem Verfahren.
Der Tür- oder Fensterkontakt kommt an den Ex für Sperre mit Verfahren auf Sperrposition. Damit kann ich dann die Jalousie öffnen wenn die Tür aufgeht.
Zusätzlich wäre sichergestellt daß der Tür/Fensterkontakt auch immer "Master" ist, sprich solange dieser gesetzt ist kann auch ein manuelles Triggern über Visu oder Taster nicht zu einer Entsperrung führen (will ja nicht daß mich meine Kinder versehentlich aussperren wenn ich im Garten bin...). Dazu müssen im LBS aber beide Sperreingänge verUNDet werden, sprich nur im Fall beider Eingänge =0 darf der LBS entsperren.
Das Ganze würde so meiner Meinung nach komplett ohne weitere externe Logik (bis auf die heute schon gebaute Timerlogik zum Wiederaktivieren nach manuellem Fahren) funktionieren und sollte auch leicht verständlich sein.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar