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

[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

[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

[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

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

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

Ja ne Dokulücke ist das eine aber meist hat man halt so ein Gerät am Schreibtisch, probiert es aus und schaut auf das Buslog. Alle Details im Trockenschwimmen programmieren würde ich nicht angehen, viel zu nervig.

Dann bleibt mir wohl nichts anderes übrig als erstmal mit meiner Vermutung ranzugehen und eine Grundkonfiguration zu machen... Korrekturen nach dem Ausprobieren kann ich dann leider erst machen, wenn die Geräte montiert sind, da ich sie wie gesagt vorher nicht zum Testen bekomme.
Kurz gesagt: Ich gehe jetzt einfach mal mit Bewegungsrichtungs-Ausgang BM1 => Enterne Bewegung (Slave) BM2 (und umgekehrt) ins Rennen und werde dann in der Wohnung irgendwann sehen, ob es "passt"... Zwischen Elektroinstallation und Einzug werden sicher einige Wochen liegen, so dass ich da dann hoffentlich genug Zeit habe, es zu "optimieren" ;-)

[gbglace]

Was wird wann gesendet?

Ja ne Dokulücke ist das eine aber meist hat man halt so ein Gerät am Schreibtisch, probiert es aus und schaut auf das Buslog. Alle Details im Trockenschwimmen programmieren würde ich nicht angehen, viel zu nervig.

[martiko]

So etwas testest du leichter, als man es beschreiben kann. Einfach mal per Gruppenmonitor eine 1 und eine 0 senden.

Wie erwähnt habe ich diese Geräte leider nicht auf dem Testbrett und da ich (bis auf einige Ausnahmen) die Geräte und Installation über den Bauträger beim Elektriker beauftragt habe, kann ich sie mir auch nicht vorab kaufen (bzw. hätte ich sie dann doppelt...)

[hjk]

Bewegungserkennung sperren => unterdrückt jede Bewegung, der Kanal verhält sich, als wäre keine Bewegung da. Auch die Nachlaufzeit läuft normal ab.
Das normale Sperrobjekt kann den Ausgang in einen Schaltzustand zwingen.
Der Slave Eingang nimmt eine externe Bewegung an, als wäre es eine selbst erkannte Bewegung.
Er reagiert natürlich nur auf Wert 1, so wie bei allen Meldern am Markt üblich.

[martiko]

wenn es nicht genauer notiert ist dann gibt es zwei Interpretationsmöglichkeiten:

• Der Master reagiert quasi nur auf eine 1, es ist wie als wenn der eigene Sensor etwas registriert, es startet mit eingehender 1 die Nachlaufzeit des Master. Einen Slave dann zyklisch die 1 senden lassen.
• Der Master nimmt 1 und 0 entgegen, die eigene Nachlaufzeit startet aber erst ab eingehender 0.

Sehe ich auch so, da es nicht bschrieben ist, gibt es Interpretationsmöglichkeiten und das ist nicht gut, bzw. sollte eben beschrieben sein, damit man weiß was passiert und nicht erst ausprobieren muss.

Genauso "spannend" ist die Beschreibung der Ausgabe der Bewegungsrichtung, die ich ja für die Einschaltung des Nachbar-BM verwenden möchte (und eben entweder mit dem Slave-Eingang oder Taster-Kurz KO verbinden möchte). Dort steht (umgekehrt das gleiche für die andere Richtung):

Objekt sendet eine 1 wenn erst der rechte Sensor eine Bewegung detektiert hat und dann der linke Sensor

Da frage ich mich nun... (Wann) wird denn auch mal eine 0 gesendet? Wird eine 0 gesendet, wenn nur einer der Sensor aktiviert wird, oder.. nachdem keine Bewegung mehr erkannt wurde (und dem Ende der Nachlaufzeit)? Sollte letzteres der Fall sein wäre das - zumindest für meine geplante Einsatzvariante - ungünstig, denn die Bewegungsrichtungs-Auswerung ist dem Alarm-Kanal zugeordnet, für mich sinnvoll wäre aber die Verwendung der Nachlaufzeiten von LK1...
In jedem Fall ist - meiner Meinung nach - auch diese Funktion nicht ausreichend dokumentiert, sprich: Was wird wann gesendet?

hjk

Vielleicht könntet Ihr ja in einer zukünftigen Version des THB da noch mal ein bisschen mehr ins Details gehen?

[Beleuchtfix]

So etwas testest du leichter, als man es beschreiben kann. Einfach mal per Gruppenmonitor eine 1 und eine 0 senden.

Gruß Florian

[gbglace]

wie der Slave-Eingang verarbeitet wird.

wenn es nicht genauer notiert ist dann gibt es zwei Interpretationsmöglichkeiten:

• Der Master reagiert quasi nur auf eine 1, es ist wie als wenn der eigene Sensor etwas registriert, es startet mit eingehender 1 die Nachlaufzeit des Master. Einen Slave dann zyklisch die 1 senden lassen.
• Der Master nimmt 1 und 0 entgegen, die eigene Nachlaufzeit startet aber erst ab eingehender 0.

[martiko]

Ich habe spezielle Frage zur Parametrierung der MDT-BM (vielleicht ja auch an hjk ):

Was genau sind die KOs 7 und 67 (und vermutlich auch 22); "Bewegungserkennung sperren"? Diese tauchen nur in der Gesamt-Tabelle aller KOs (Seite 10+11) auf, werden aber ansonsten nirgends mehr erwähnt oder erklärt. 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.

Noch eine Frage, auch das ist leider nicht genau im THB erklärt:
Wie genau reagiert der Eingang "Externe Bewegung (Slave"), also gibt es da irgendwelche speziellen Nachlaufzeiten etc. oder wird der LK sofort ausgeschaltet, wenn keine eigenen Bewegung erkannt wurde und dort eine 0 empfangen wird... Konkret bin ich in dem von mir beschrieben Beispiel am Überlegen ob ich die Beweungsrichtungs-Auswertung des "Nachbar-Melder" auf die Taste-Kurz lege oder eben auf Slave, aber dazu müsste ich etwas genauer wissen, wie der Slave-Eingang verarbeitet wird.

Apropos THB, da ist mir noch ein Fehler bzw. zumindest eine Ungenauigkeit in Tabelle 8 auf Seite 23 aufgefallen, da wird in der Spalte "Verwendung" immer von "Lichtkanal" gesprochen auch wenn es sich um KOs des HLK-Kanal handelt, das hat mich im ersten Moment etwas verwirrt...

[gbglace]

Wie löst Ihr eine solche Situation?

Höhrende Adresse, die GA die die Sperre auslöst auch an den Tastern an das Statuseingangsobjekt hängen.

[Wolflay]

Hallo zusammen!

Beim Thema Best practices "PM/ sperren/ Tasterbetrieb" hänge ich momentan auch:

Ich habe den Gira Tastsensor 4 komfort mit den Gira PM mini komfort im Einsatz. Auch bei mir erledigt der PM das Grundgeschäft.

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.

Nun mein Problem: Ich habe z.T. mehrere Sperr-Tasten vergeben, so dass ich das Treppenhaus-Licht z.B. aus dem OG wie aus dem EG sperren kann.

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?

Beste Grüße
Frank