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.
Ist aus meiner Sicht ein Übersteuern des Melders (manueller Eingriff), hier sollte mein Wunsch Vorrang haben. Das habt ihr auch so beschrieben, hier macht es auch Sinn, das helligkeitsabhängige Ausschalten zu unterdrücken. Nur fehlen hier einige Fälle:
Da sich die Fälle quasi analog verhalten zu dem Fall wenn Präsenz da ist, hatte ich das mal unter den Tisch fallen lassen.
KO1 hörend sehe ich wie crewo als Rückmeldeobjekt vom Aktor oder von einem anderen Automatismus (Zeitschaltuhr, Treppenlicht, Logikengine). Hier sollte weniger geschehen als an KO9, denn in den meisten Fällen wird hier nur das gleiche Signal kommen, dass der Melder selber gesendet hat.
Hier haben wir aus Projekten zum Teil ganz andere Rückmeldungen. Dort wird sehr gern mit dem Taster direkt der Aktor geschaltet ohne über den Melder zu gehen. Argumentation unter anderem, dass bei defekt zumindest ein manuelles Einschalten immer noch möglich ist. Auch wenn der Melder bzw. Lichtausgang gesperrt ist, wäre zumindest das Licht schalten über den Taster noch möglich. Hier haben wir tatsächlich unterschiedliche Anforderungen.
AUS Signal mit Präsenz --> Licht AUS solange Präsenz + Nachlaufzeit und sofort Rückfall in Standardbetrieb (Licht geht sofort wider an)
Das wäre im dem geschilderten Fall dann fatal, denn dann würde der manuelle Wunsch per Taster sofort vom Melder übersteuert. Aber natürlich sind beide Anforderungen nachvollziehbar.
Zitat von Steinel Technical Support Beitrag anzeigen
- Wenn ein Schaltbefehl auf dem hörenden Ausgang kommt ohne anwesende Präsenz, was passiert wenn Präsenz auftritt? Standardbetrieb des Melders? Würde der Melder zB Einschalten wenn kurz zuvor ein AUS ohne Präsenz kam? --> Tendenz Steinel: Einschalten bei Präsenz
JA! Damit bestätigt ihr meine beiden grünen Punkte! Also auch hiermit kann ich mich nur der "Tendenz Steinel" anschließen.
Wir würden den Fall in Zukunft differenziert betrachten.
Auf dem hörenden Ausgang kommt ein AUS und es ist niemand da mit Nachlaufzeit 5 Minuten ---> AUS und Standardbetrieb --> kommt jemand nach 1 Minute rein, dann würde eingeschaltet.
Auf dem hörenden Ausgang kommt ein AUS und es ist jemand da mit Nachlaufzeit 5 Minuten ---> AUS für Präsenz und Nachlaufzeit danach Standardbetrieb.
Das ist sicherlich eine Philosophiefrage, wie man die Hierarchie der Kommandos sieht. Ganz ohne Grund sind die weiteren Ansteuerungen des Aktors ja auch nicht.
Zitat von Steinel Technical Support Beitrag anzeigen
Automatisches Einschalten temporär gesperrt (melderintern)
richtig, dass ihr das in Zukunft das getrennt behandeln wollt (also melderinterne Sperren unabhängig von externen Sperren)? Würde ich sehr begrüßen.
Prinzipiell sollte es so sein, dass aktuell schon beim Sperren über das Sperrobjekt sämtliche Ausgänge gesperrt sind (Ausnahme Teach Input). Die melderinterne Sperre die sich durch das KO9 ergibt lässt hingegen weiteren Input von außen zu, das heisst er sperrt nur melderintern Funktionen (zB helligkeitsabhängiges Ausschalten).
An dieser Stelle schon mal Dank allen für den bisherigen Input.
Momentan habe ich eher das Gefühl das sie träger in der Reaktion geworden sind, werd es die Tage aber noch weiter beobachten.
Habe jetzt ein paar Tage Zeit gehabt, nachdem ich meine Entfernungen wieder angepasst, läuft es wie gewohnt, das sie jetzt flinker sind, kann ich aber nicht bestätigen. Für mich ist das die gewohnte leicht verzögerte Auslösung, welche für mich aber von Anfang an in Ordnung war. Dieses größere Delay konnte ich jetzt noch nicht wieder beobachten, kam bei mir aber auch sehr selten vor.
Gruß Andreas
bin im Urlaub, hab jetzt erst Zeit, was längeres zu schreiben.
Vieles passt schon, so wie ich das sehen würde, bei KO1 hörend würde ich mich crewo anschließen wollen, ich beschreibe aber mal das Szenario aus meiner Sicht in der obigen Form:
Ist aus meiner Sicht ein Übersteuern des Melders (manueller Eingriff), hier sollte mein Wunsch Vorrang haben. Das habt ihr auch so beschrieben, hier macht es auch Sinn, das helligkeitsabhängige Ausschalten zu unterdrücken. Nur fehlen hier einige Fälle:
EIN Signal ohne Präsenz --> Licht EIN solange Nachlaufzeit, tritt währenddessen Präsenz auf, wird nach Präsenz + Nachlaufzeit ausgeschaltet --> helligkeitsabhängiges Ausschalten temporär gesperrt (melderintern)
EIN Signal mit Präsenz --> Licht EIN solange Präsenz + Nachlaufzeit --> helligkeitsabhängiges Ausschalten temporär gesperrt (melderintern)
AUS Signal ohne Präsenz --> Licht AUS für Nachlaufzeit, tritt währenddessen Präsenz auf, bleibt es solange Präsenz + Nachlaufzeit ausgeschaltet --> Automatisches Einschalten temporär gesperrt (melderintern)
AUS Signal mit Präsenz --> Licht AUS solange Präsenz + Nachlaufzeit --> Automatisches Einschalten temporär gesperrt (melderintern)
KO1 hörend sehe ich wie crewo als Rückmeldeobjekt vom Aktor oder von einem anderen Automatismus (Zeitschaltuhr, Treppenlicht, Logikengine). Hier sollte weniger geschehen als an KO9, denn in den meisten Fällen wird hier nur das gleiche Signal kommen, dass der Melder selber gesendet hat. Hauptsächlich geht es also um die Fälle, die sich unterscheiden, also wenn nicht vom Melder eingeschaltet wurde und ein EIN kommt oder wenn nicht vom Melder ausgeschaltet wurde und ein AUS kommt. Aber hier trotzdem nochmal alle Fälle:
EIN Signal ohne Präsenz --> Licht EIN solange Nachlaufzeit, tritt währenddessen Präsenz wir nach Präsenz + Nachlaufzeit ausgeschaltet --> helligkeitsabhängiges Ausschalten bleibt aktiv
EIN Signal mit Präsenz --> Licht EIN solange Präsenz + Nachlaufzeit --> helligkeitsabhängiges Ausschalten bleibt aktiv (normaler Melderbetrieb)
AUS Signal ohne Präsenz --> Licht AUS für Nachlaufzeit und sofort Rückfall in Standardbetrieb (Licht geht bei nächster Bewegung an)
AUS Signal mit Präsenz --> Licht AUS solange Präsenz + Nachlaufzeit und sofort Rückfall in Standardbetrieb (Licht geht sofort wider an)
Bei den beiden "AUS" hier ist wichtig, dass sie NICHT für die Nachlaufzeit ausmachen! Man braucht eine Möglichkeit, dem Melder ein externes "AUS" zu melden, ohne dass er für die Nachlaufzeit AUS bleibt. Das Beispiel hier ist: Irgendeine Automatik hat mir das Licht ausgemacht (per Szene oder sonst was). Der Aktor meldet das dem PM über KO1. Ich will dann winken können (oder noch besser, der TP weiß ja selber, dass gerade Präsenz im Raum ist) und so das Licht SOFORT wieder anmachen können. Wenn ich für die Nachlaufzeit ein AUS haben will, gehe ich auf KO9.
Meine obigen Fälle sollen auch die Fragen am Ende beantworten, aber hier nochmal explizit:
- Nachdem manuell ein- oder ausgeschaltet wurde (KO9), kommt auf dem hörenden Ausgang ein Schaltbefehl. Überschreiben wir den Schaltbefehl der dort kam? Was hat höhere Priorität? Der Schaltereingang oder der zeitlich aktuellere Schaltbefehl auf dem hörenden Ausgang? --> Tendenz Steinel: der letzte Schaltbefehl gewinnt
Natürlich gewinnt der aktuellste Befehl. In 99% der Fälle wird das nur die Bestätigung des KO9 sein (KO9 geht auf EIN, PM sendet EIN, Aktor meldet EIN auf KO1 - gleiches mit AUS).
Wenn der Aktor was anderes meldet, dann hat das seinen Grund und dann sollte der PM das wissen und sich passend danach richten.
- Wenn ein Schaltbefehl auf dem hörenden Ausgang kommt ohne anwesende Präsenz, was passiert wenn Präsenz auftritt? Standardbetrieb des Melders? Würde der Melder zB Einschalten wenn kurz zuvor ein AUS ohne Präsenz kam? --> Tendenz Steinel: Einschalten bei Präsenz
JA! Damit bestätigt ihr meine beiden grünen Punkte! Also auch hiermit kann ich mich nur der "Tendenz Steinel" anschließen.
Noch eine Anmerkung zu den Sperren (wie gesagt, bin im Urlaub und kann derzeit nicht testen):
Soweit ich mich erinnere, hat ein Schreiben auf KO9 immer auch die externe Sperre des Kanals beeinflusst, zumindest wurde über das Sperr-Status-KO immer was ausgegeben - und die Sperre nach der Nachlaufzeit auch automatisch zurückgenommen. Damit war eine externe Sperre nicht zusammen mit KO9 nutzbar. Verstehe ich den Passus
richtig, dass ihr das in Zukunft das getrennt behandeln wollt (also melderinterne Sperren unabhängig von externen Sperren)? Würde ich sehr begrüßen.
Bei Fragen oder unklaren Formulierungen meinerseits bin ich gerne bereit, einzelne Aspekte detaillierter zu beleuchten. Testen kann ich aber erst wieder in einer Woche...
Diskussionswürdig und ohne finalen Soll-Zustand sind aus unserer Sicht folgende Dinge:
- Nachdem manuell ein- oder ausgeschaltet wurde (KO9), kommt auf dem hörenden Ausgang ein Schaltbefehl. Überschreiben wir den Schaltbefehl der dort kam? Was hat höhere Priorität? Der Schaltereingang oder der zeitlich aktuellere Schaltbefehl auf dem hörenden Ausgang? --> Tendenz Steinel: der letzte Schaltbefehl gewinnt
- Wenn ein Schaltbefehl auf dem hörenden Ausgang kommt ohne anwesende Präsenz, was passiert wenn Präsenz auftritt? Standardbetrieb des Melders? Würde der Melder zB Einschalten wenn kurz zuvor ein AUS ohne Präsenz kam? --> Tendenz Steinel: Einschalten bei Präsenz
Auch hier, wäre das für mich das zu erwartende Verhalten. Weil: Jemand klickt irgendwo auf Szene "Abwesend" und diese schaltet alle Lichter aus, läuft danach aber schnell noch ins Bad, würde dort gerne trotzdem das Licht wieder anhaben.
ABER:
Der hörende ist doch nur für den Aktor-Status, oder? Ich würde dort gar nichts machen ausser bei "EIN" die Nachlaufzeit starten und Licht wieder aus. Keine Veränderung von irgendwas bei AUS, diese Meldung auf dem höhrenden wäre mir total egal als PM ausser, dass ich nun weiß, das Licht ist aus. Oder?
crewomumpf und gerne auch weiterer Input von allen weiteren Interessierten
Hallo,
wir haben in interner Runde das Thema externer Input (hörende Adresse und/oder Tastereingang) diskutiert und sind zu folgendem Soll-Verhalten gekommen:
Schalten über Schalten Eingang (KO9)
EIN Signal bei Präsenz --> Licht EIN solange Präsenz + Nachlaufzeit, danach Rückfall in Standardbetrieb --> helligkeitsabhängiges Ausschalten temporär gesperrt (melderintern)
AUS Signal ohne & bei Präsenz --> Licht AUS solange Präsenz + Nachlaufzeit, danach Rückfall in Standardbetrieb --> Automatisches Einschalten temporär gesperrt (melderintern)
Schalten über hörenden Ausgang (KO1)
EIN Signal ohne Präsenz --> Licht EIN solange Nachlaufzeit, tritt währenddessen Präsenz wir nach Präsenz + Nachlaufzeit ausgeschaltet --> helligkeitsabhängiges Ausschalten bleibt aktiv
EIN Signal mit Präsenz --> Licht EIN solange Präsenz + Nachlaufzeit --> helligkeitsabhängiges Ausschalten bleibt aktiv (normaler Melderbetrieb)
AUS Signal mit Präsenz --> Licht AUS solange Präsenz + Nachlaufzeit
EIN Signal ohne Präsenz --> Licht EIN für Nachlaufzeit
AUS Signal ohne Präsenz --> Licht AUS für Nachlaufzeit
Diskussionswürdig und ohne finalen Soll-Zustand sind aus unserer Sicht folgende Dinge:
- Nachdem manuell ein- oder ausgeschaltet wurde (KO9), kommt auf dem hörenden Ausgang ein Schaltbefehl. Überschreiben wir den Schaltbefehl der dort kam? Was hat höhere Priorität? Der Schaltereingang oder der zeitlich aktuellere Schaltbefehl auf dem hörenden Ausgang? --> Tendenz Steinel: der letzte Schaltbefehl gewinnt
- Wenn ein Schaltbefehl auf dem hörenden Ausgang kommt ohne anwesende Präsenz, was passiert wenn Präsenz auftritt? Standardbetrieb des Melders? Würde der Melder zB Einschalten wenn kurz zuvor ein AUS ohne Präsenz kam? --> Tendenz Steinel: Einschalten bei Präsenz
mumpf
Die unterschiedlichen Lichtszenen steuere ich glaube ich jetzt erstmal mit edomi (also externer Logik) und schicke hier Steuerbefehle für Dimmen und an/aus einzelner Lichtquellen nach den Steuerbefehlen des TP nach. So funktioniert das Grundlicht durch den PM immer und ich bin nicht mehr von mehreren Kanälen abhängig. Aber ich wäre froh, wenn das doch alles nativ abzubilden wäre, habe vermutlich die gleiche Anforderung wie du.
die offizielle Konfigurationsempfehlung von euch, gerade wenn wir hier von hörender Adresse sprechen wegen Aktor-Status bei Fremdbedienung,
dem kann ich mich nur anschließen, und es erweitern durch "Nutzung von mehreren Kanälen, die sich gegenseitig sperren können". Typisches Beispiel hier sind PM für Lichtautomatisierung, die aber auch durch Taster und andere Automatiken (Zeitschaltuhren, Treppenlicht) bedient werden können, aber 2 oder 3 Lichtkänäle nutzen, um zu unterschiedlichen Tageszeiten unterschiedliche Lichteffekte zu erhalten (bei uns ist es Tag-/Nacht-/Morgenlicht).
Wenn ihr die Szenarien, an die ihr denkt, vorher hier beschreibt, könntet ihr sicherlich Feedback bekommen, ob das so passt und was ihr vergessen habt - und das noch bevor ihr das implementiert. Erspart Frust auf beiden Seiten.
Steinel Technical Support Trotzdem interessiert mich mal die offizielle Konfigurationsempfehlung von euch, gerade wenn wir hier von hörender Adresse sprechen wegen Aktor-Status bei Fremdbedienung, wäre toll hier eure professionelle Ansage zu bekommen.
Das funktioniert aber doch eigentlich jetzt schon, bzw. hat von Anfang an funktioniert.
Ich hatte da meine Probleme, evtl. liegt das auch an der Nutzung der Sperren um ein unterschiedliches Verhalten Tag/Nacht zu realisieren (Nachts nur Halbautomat und Tagsüber Vollautomat). Muss ich mal ansehen, ich sag ja, vermutlich ist das mein Fehler, ich habe einiges unkonventionell gemacht nachdem mein gewünschtes Verhalten nicht mit einfachen Mitteln funktionierte. Werde das jetzt erstmal wieder auf "einfach" umbauen.
könntet ihr mal bitte eure "Idealkonfiguration" beschreiben, wie der TP in Verbindung mit einem Taster zu betreiben ist? Ziel ist: Manuell Aus -> Licht bleibt aus bis Präsenz weg, dann wieder Automatik. Manuell An: Licht bleibt an bis Präsenz weg ODER wenn keine Präsenz erkannt wird bis Nachlaufzeit Ende.
Das funktioniert aber doch eigentlich jetzt schon, bzw. hat von Anfang an funktioniert.
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.
- habt ihr eine absehbare Planung dafür?
Einen Kommentar schreiben: