"Best Practices" für PM/BM im Zusammenspiel mit Tastern (Sperren/Zwangsführung) etc.

[Wolflay]

Ich gestehe ein: Ich verstehe das Konzept der hörenden Adresse erst sehr langsam (wenn überhaupt ;-) Ist es so, dass der Sensor beim Aktor anfragt, wie dessen Zustand ist (um dann den entsprechenden Befehl zu senden) - oder ist es so, dass der Aktor aktiv auf den Sensor zugeht, um diesen auf dem Laufenden zu halten, welchen Befehl er beim nächsten drücken senden soll?

Also: Ich möchte den Gira PM über mehrere Taster sperren. Die Sperre selbst erfolgt über Umschalten an den Tastern, sodass diese wissen müssen, ob die Sperre gerade aktiv ist.

Bei den Gira Tastsensoren 4 ist mir dies gelungen, indem ich deren Rückmeldeobjekte mit der GA des PM Sperrobjektes verknüpft habe.

Der Gira Tastsensor 3 verfügt aber leider nicht über solche Rückmeldeobjekte - was nun?

@gbglace
Wenn ich in der technischen Formulierung weiter falsch liege, würde ich mich auch hier über einen Hinweis freuen - als Autodidakt kann man sich zwar bei KNX schnell einiges zusammenreimen (immerhin "funktioniert" mein Haus bereits in wesentlichen Zügen ;-) - aber mein Anspruch ist definitiv auch, die Hintergründe korrekt zu verstehen.

Vielen Dank und beste Grüße
Frank

[knxPaul]

Das Schaltobjekt ist in diesem Fall der Gira PM Mini Komfort - der hat aber kein Rückmelde-Objekt

Das verstehe ich wie gbglace auch nicht: Ich kenne das nur so, dass ein oder mehrere Schaltobjekte wie PM und Lichttaster auf eine GA Vorgabe-Telegramme ausgeben, die dann auf einen Aktor wirken. Nur der Aktor kennt den Zustand des Ergebnis aller Vorgaben, ob also beispielsweise das Licht an oder aus ist. Daher nehme ich immer den Zustand des Aktors als Status.

Es sei denn, das Schaltobjekt wirkt auf eine Funktion wie "Tag/Nacht Umschaltung", wo es keinen Aktor gibt. Dann hat die GA für die Funktion "Tag/Nacht Umschaltung" gleichzeitig die Aufgaben Vorgaben und Status in einem. Ich habe gelernt, dass jede Vorgaben ein GroupValueWrite auf dem Bus ist, der mit einem S-Flag in den internen Zustand des KO übernommen wird. In dem Fall, Vorgaben und Status in einer GA und mindestens zwei sendende KOs, braucht jedes KO ein S-Flag, auch die KOs, die Vorgaben ausgeben. Damit wird der Wert im GroupValueWrite des einen KO in den Status des anderen KO übernommen

[gbglace]

Sorry dir ist da nur schwer zu folgen.
einmal gewöhne Dir bitte nicht an davon zu reden KO in GA zu packen, logisch und technisch ergibt das keinen Sinn. Und dann schreibe einfach nochmal was du überhaupt erreichen willst. Welche Information die von wem/was erzeugt wird soll wem warum zur Verfügung gestellt werden.
Wenn du das hast dann nimm die passende GA (=Information) und verbinde das.

Wenn kein Rückmelde/Status Eingangsobjekt vorhanden ist, dann geht die Information als hörende Adresse bei dem Gerät auf das Ausgangs-KO verbunden, welches den Zustand benötigt.

[Wolflay]

Wieso, das funktioniert doch genauso wie bei den "neuen" Tastern. Häng doch die Status GA vom Aktor als hörende GA an das Schaltobjekt. Solche Umschaltungen sind nichts neues, die haben vor 20 Jahren auch schon funktioniert. Beschäftigen muss man sich halt damit.

Das Schaltobjekt ist in diesem Fall der Gira PM Mini Komfort - der hat aber kein Rückmelde-Objekt. Mit den neueren Tastsensoren 4 habe ich es mit der Hilfe hier geschafft: Rückmeldeobjekte der Taster mit in die Schalt-GA und gut. Da aber der Tastsensor 3 kein Rückmeldeobjekt hat, stehe ich jetzt auf dem Schlauch.

Könnt Ihr mir noch einen Hinweis geben?

Beste Grüße
Frank

[Beleuchtfix]

Man kann ja mit solch einer Taste andere Sachen als KNX Geräte steuern. Dann ist es sinnvoll, wenn wenigstens einer auf die Lesenfrage antwortet.

Ich benutze das z.B. als Tag/Nacht Umschaltung, wenn keine Schaltuhr zur Verfügung steht und z.B. Displays in Kinderzimmern abgeschaltet werden müssen. Da hat dann der Taster als einziger den richtigen Status.
Gruß Florian

[vento66]

Wieso, das funktioniert doch genauso wie bei den "neuen" Tastern. Häng doch die Status GA vom Aktor als hörende GA an das Schaltobjekt. Solche Umschaltungen sind nichts neues, die haben vor 20 Jahren auch schon funktioniert. Beschäftigen muss man sich halt damit.

[Wolflay]

Na ja, zum Glück habe ich nur 4 von den alten Tastsensoren (integrieren sich halt so schön ins Schalterprogramm). Aber beim Umschalten kann man die Dinger dann eben kaum gebrauchen?! Ist das Gira Produkt wirklich so aus der Zeit gefallen? Die verkaufen das noch?!

Beste Grüße
Frank

[vento66]

Nur wenn es kein KNX Gerät (Aktor) etc. gibt, was antworten kann. Man kann ja mit solch einer Taste andere Sachen als KNX Geräte steuern. Dann ist es sinnvoll, wenn wenigstens einer auf die Lesenfrage antwortet.

[gbglace]

Das L-Flag bewirkt, das wenn ein Gerät eine aktive Leseanforderung sendet, das dann dieses KO an der ersten angebundenen GA etwas sendet. Ich kann mir halt immer nur schwer vorstellen, dass das an einem Taster irgendwie Sinn ergibt.

[Wolflay]

Sagen wir es mal so früher gab es eh keine Rückmelde-KO an Tastern usw., da wurde alles über hörende Adressen gemacht. Ich finde es aber transparenter mit Rückmeldeadressen und vor allem entsprechende KO

Hilft mir das bei meinem Tastsensor drei - könnte ich auch da etwas über hörende Adressen werden? Bei dem kann ich laut technischer Dokumentation das L-Flag setzen - aber das ist leider auch schon alles...

[gbglace]

man dann ja generell keine Rückmelde-GA mehr?!

Sagen wir es mal so früher gab es eh keine Rückmelde-KO an Tastern usw., da wurde alles über hörende Adressen gemacht. Ich finde es aber transparenter mit Rückmeldeadressen und vor allem entsprechende KO

[Wolflay]

gbglace
mumpf

Vielen Dank für Eure Anmerkungen - das funktioniert nun. Eigentlich bräuchte man dann ja generell keine Rückmelde-GA mehr?!

Noch eine weitere Frage in diesem Zusammenhang: Der zweite beteiligte Taster in dieser Aufgabe ist ein Gira Tastsensor 3. Im Gegensatz zu seinem aktuelleren Bruder hat dieses Bürschchen eine Applikation aus der Steinzeit - ein Rückmeldeobjekt finde ich hier gar nicht. Übersehe ich etwas? Was nun - wisst Ihr einen Kniff?

Beste Grüße
Frank

[martiko]

Ach es ist immer wieder gut, sich hier auszutauschen... Ich hatte meine GA-Struktur (grob) auf der aus dem Beispiel im ETS-Schnellkurs ausgebaut... und irgendwie war ich davon ausgegangen, dass auch die Anzahl der Hauptgruppen auf 7 begrenzt ist...
Dank Waldemars beiläufigem Hinweis habe ich da jetzt noch ein bisschen "entzerrt" und noch 2 neue Haupgruppen hinzugefügt... Dafür schon mal vielen Dank!

Zu dem Thema GA "synchron halten" mit dem X1 mache ich noch mal ein anderes Thema auf. Darauf sind wir hier zwar gestoßen, aber ich denke dass das viele betrifft und vielleicht hat der eine oder andere da ja auch noch Ideen bzw. Tipps.

[mumpf]

weil es ja leider keine sychoronisation zum X1 gibt

Das ist für mich einer der Gründe (wenn nicht der wichtigste), keine der kaufbaren Lösungen einzusetzen. Projektsynchronisation ist äußerst schwer zu realisieren und wird deswegen auch kaum angeboten.

Ich schreibe mir immer wieder kleine Generatoren, die die Synchronisation übernehmen und nutze als Visu/Logikengine Open-Source-Lösungen, die mir erlauben, die Ausgabe vom Generator zu konsumieren. Derzeit stelle ich im laufenden Betrieb auf Home Assistant um, weil meine alte Visu nicht mehr zukunftsfähig ist. Das ist viel Arbeit "am offenen Herzen", ich freue mich tierisch, dass meine GA-Struktur (ist die Version 3 von 2018) prima funktioniert, aber auch da werde ich bei den Fensterkontakten wahrscheinlich nochmal nachbessern.

Im Prinzip arbeite ich nach dem Motto: Es kann sich jederzeit alles ändern und ich möchte sicherstellen, dass das Haus nie "ausfällt". Aber ich gebe ja auch zu, bei mir ist es auch mein Hobby...

Na mal sehen, ich mache einfach was geht vorher...

Natürlich ist eine gute Struktur und Vorbereitung im Vorfeld "nach bestem Wissen und Gewissen" sehr von Vorteil. Nur kann z.B. gar nicht auf zukünftige Technologien vorbereiten. Als ich anfing, waren 16 Hauptgruppen für GA üblich und die "neuen" 32 Hauptgruppen noch von einigen Geräten nicht unterstützt. 2018 hab ich dann auf 32 Hauptgruppen umgestellt, die meisten Geräte können das inzwischen und wenn ich noch eines sehe, dass nur 16 Hauptgruppen kann, dann fliegt das wieder raus.

Ich wollte eigentlich nur sagen, dass man sich mit dem Ansatz "ich mach vorher alles perfekt" auf eine Anspruchsebene begibt, bei der man nur verlieren kann: Man hat viel Stress, vorher an alles zu denken und hat quasi das "Versagen" mit eingebaut, denn es wird beim ersten Versuch ganz sicher nicht perfekt .

Gruß, Waldemar

[Beleuchtfix]

(gerade bei den GAs würde ich sehr ungern strukturell anpassen, weil es ja leider keine sychoronisation zum X1 gibt... Neue GAs sind kein Problem, die hat man ja schnell importiert, aber Änderungen/Verschiebungen... das müsste ich dann alles manuell machen, darauf habe ich echt sehr wenig Lust...)

Das hat Gira schlecht gelöst. Sie gehen einfach davon aus, dass die Visu erstellt wird, wenn ein Projekt auf der KNX Seite fertig ist, das habe ich bis jetzt aber leider noch nicht geschafft
Gruß
Florian