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

[Beleuchtfix]

Mir kommt es vor, dass du schon die Gebrauchsanweisung deines neuen Autos, dass nächstes Jahr geliefert wird, auswendig lernst und versuchst, schon alles im Vorfeld perfekt zu beherrschen. Grundsätzlich finde ich es schon gut, wenn sich jemand mit den Geräten beschäftigt, aber gerade die MDT Geräte haben so eine komplexe Applikation, dass du einiges erst richtig verstehen wirst, wenn du mit dem Gerät arbeiten kannst.

Ich gehe davon aus, dass für LK1 das KO8 (bei Konfiguration als Sperrobjekt) dass richtige ist, um diesen Lichtkanal zu sperren, aber was macht dann das KO7 anderes und wofür ist es gedacht? Ich denke es wäre auf jeden Fall gut, da noch eine Beschreibung/Erklärung ins THB aufzunehmen.

Du musst die Tabelle aber auch genau lesen, da steht beo KO 8 sende, bei KO7 empfangen, KO 8 ist das Statusobjekt der Sperre.

, da wird in der Spalte "Verwendung" immer von "Lichtkanal" gesprochen auch wenn es sich um KOs des HLK-Kanal handelt,

MDT scheint die Kanäle immer weiter anzugleichen. HLK und Alarmkanäle benötigen eigentlich keine Helligkeitsauswertung, man will ja auch Tagsüber Heizen. Dann gibt es aber wieder genügend Leute, die lieber einen 3. Lichtkanal hätten, und es unlogisch finden, dass man etwas bei Heizung nicht kann, was bei Licht möglich ist. Das wird immer universeller, und bei der Aktualisierung der Handbücher geht das schon mal unter.

Sorry hatte den Beitrag von hjk nicht wahrgenommen.

Viel Erfolg
Florian

[martiko]

Du hast natürlich recht, alles geht nicht in der Theorie, darum habe ich mir ja auch einige Geräte fürs Testbrett besorgt um die wichtigsten Grundfunktionen testen zu können (da konnte ich mich zum Glück mit dem Elektriker einigen, dass er diese von mir übernimmt und dann einbaut), als PM habe ich da den Steinel-TP den ich im Bad einsetzen werde (weil es den in der Aktion damals günstig gab). Aber der verhält sich eben doch völlig anders als die MDTs, vermutlich wäre es gut gewesen, wenn ich zumindest einen MDT-PM/BM genommen hätte, kann ich aber jetzt nicht mehr ohne große Diskussionen und Aufwand ändern (fragt nicht, wie viele Iterationen mit Bauträger / Elektriker es gedauert hat, bis ich mit dem Angebot inhaltlich zufrieden war, über das finanzielle rede ich lieber gar nicht...).

Von daher dachte ich schon, dass ich die Programmierung zum allergrößten Teil anhand der Anleitungen (und der praktischen Tests auf meinem Testbrett) durchführen kann. Und ich sehe das schon etwas anders als beim Autofahren, es geht ja jetzt nicht um die Benutzung der Geräte, sondern die Konfiguration. Und um bei dem Beispiele zu bleiben, da überlege ich mir vorher eben beim Auto auch, was ich wie bestellle damit es zusammenpasst.
Aber ich merke schon, an der ein oder anderen Stelle geht es definitiv nicht (im Detail) ohne die Geräte... trotzdem möchte ich es soviel wie möglich und so gut wie möglich vorkonfigurieren um möglichst wenig "Nachbessern" zu müssen, vor allem muss ich mir zumindest über die Struktur und Funktionalität sicher sein, ich habe keine Lust am Ende noch mal an der GA-Struktur korrigieren zu müssen.

Du musst die Tabelle aber auch genau lesen, da steht beo KO 8 sende, bei KO7 empfangen, KO 8 ist das Statusobjekt der Sperre.

Ich denke, da hast Du Dich verlesen... KO7 ist definitiv etwas anderes, wie ja auch von hjk bestätigt.

[mumpf]

Hi,

Da aber der PM kein Rückmeldeobjekt für die Sperre hat, wird der Tastenstatus der gerade nicht betätigten Taster nicht aktualisiert.

Wie löst Ihr eine solche Situation?

Einen Status brauchst Du nur, wenn die Objekte selbst ihren Zustand verändern können. Und selbst dann kann (und darf) man es in KNX so lösen, dass die Status-Information über das gleiche KO gesendet werden kann. So viel zur Theorie.

In der Praxis geht es ganz einfach: Du nimmst die selbe GA für alle Taster und deren Tastenstatus. Sinnvollerweise setzt Du dann auch noch das L-Flag am Statusobjekt.

Allerdings sperre ich die PMs auch häufig, da mir das ewige "an/aus" auf den Keks geht. Dies geschieht mit einer weiteren Taste auf dem Tastsensor.

Bei der Aussage würde ich mir nochmal ein Gesamtkonzept überlegen... Das Ziel einer Automatisierung sollte nicht sein, dass diese einem "auf den Keks" geht (außer man will es so).

Gruß, Waldemar

[mumpf]

Hi,

Aber ich merke schon, an der ein oder anderen Stelle geht es definitiv nicht (im Detail) ohne die Geräte... trotzdem möchte ich es soviel wie möglich und so gut wie möglich vorkonfigurieren um möglichst wenig "Nachbessern" zu müssen, vor allem muss ich mir zumindest über die Struktur und Funktionalität sicher sein, ich habe keine Lust am Ende noch mal an der GA-Struktur korrigieren zu müssen.

Diese Einstellung würde ich mir überlegen. Vor allem, weil es Dein erstes größeres Projekt ist und du somit noch gar keine Erfahrung hast. Ich hatte vorhin gerade in meinem ETS-Projekt gesehen, dass ich am 27.12.2013 das Projekt für mein aktuelles Haus begonnen habe (ich feiere sozusagen das siebenjährige Jubiläum), und ich hatte immerhin bereits vorher ein kleineres KNX-Projekt am laufen (nur ein Stockwerk mit Licht/PM/Heizung/Fensterkontakten), aus dem ich gelernt habe.
Ich habe mit der Einführung meiner Visu (ca. 2015) nochmal die gesamte GA-Struktur überarbeitet und dann nochmal gegen 2018, damit ich alle bis dahin aufgelaufenen "Ausnahmen" wieder begradigen konnte und alle neuen Ideen, neue technische Möglichkeiten und alle neuen Erfahrungen integrieren konnte.

Ich glaube, mit der inneren Einstellung "ich muss da sowieso nochmal ran, wenn ich genau weiß, was ich brauche" sparst Du dir viel Stress und Ängste bei der Vorbereitung. Es gleich auf Anhieb richtig zu bekommen und hinterher nicht mehr ran zu müssen ist der Ansatz eines Service-Dienstleisters. Die haben den Vorteil der Erfahrung, werden aber möglichst das Ziel verfolgen, eine mehr oder minder gute Standard-Installation zu machen (soll nicht abwertend sein, ich schätze die Arbeit von Dienstleistern sehr, diese hat einfach nur gewisse Grenzen).

Wenn Du schon selber programmierst, dann solltest Du gerade die Möglichkeiten nutzen, die Dir das bietet. Und das sind vor allem Anpassungen, die sich dadurch ergeben, dass man in dem Objekt wohnt und versucht, alltägliche Kleinigkeiten zu optimieren.

Um die Brücke zum Beitrag oben zu schlagen: Eine Aussage "... xyz ... geht mir auf den Keks" würde es bei mir nicht geben, denn sobald mir etwas auffällt, was mir nicht gefällt, ändere ich es so lange, bis es mir gefällt. Und das passt nicht zu der Einstellung

möglichst wenig "Nachbessern" zu müssen

.

Nur meine Meinung,
Gruß, Waldemar

[martiko]

Hi Waldemar,

danke für die Rückmeldung. Also ich habe (hatte) tatsächlich die Hoffnung, dann später "im laufenden Betrieb" keine gravierenden Anpassungen mehr an der Struktur machen zu müssen. Aber danke für die Warnung, dass das sogar bei Dir (den ich für sehr fit halte) der Fall war...

Dass ich an vielen Stellen in jedem Fall nachjustieren muss ist klar, das war auch der Grund, warum ich es selbst mache. Da dachte ich aber eher an funktionale Dinge, von denen man eben erst im Alltag feststellt, wie man es gerne hätte. Oder so primitive Dinge wie Schwellwerte von Bewegungsmeldern etc.. Und dann eben natürlich Logiken (über die wir schon bzgl. Zustandsautomaten geschrieben haben, das kann man theoretisch kaum bis gar nicht vorplanen).

Na mal sehen, ich mache einfach was geht vorher... und lasse mich überraschen, wie viel ich im Nachhinein noch ändern muss (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...)

Gruß
Martin

[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

[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

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

[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

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

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]

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.

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

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

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.