Steinel True Presence – Präsenzmelder

[mumpf]

Hi Steinel Technical Support,

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.

Gruß, Waldemar

[crewo]

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.

[Steinel Technical Support]

crewo mumpf 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


Wir sind gespannt auf das Feedback

Grüße

[crewo]

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

Die Tendenz würde ich unterstreichen!

- 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?

[mumpf]

Hi,

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:

Schalten über Schalten Eingang (KO9)

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)

Schalten über hörenden Ausgang (KO1)

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

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.

Bei Fragen oder unklaren Formulierungen meinerseits bin ich gerne bereit, einzelne Aspekte detaillierter zu beleuchten. Testen kann ich aber erst wieder in einer Woche...

Gruß, Waldemar

[andreasrentz]

So wie Waldemar es ergänzt hat, wäre es perfekt.

[andreasrentz]

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

[crewo]

Ich kann das nur positiv zurückgeben, nach dem Update läuft das auf gutem Niveau was die Erkennung angeht! Kein Vergleich zu vorher.

[Steinel Technical Support]

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.

[crewo]

Steinel Technical Support Egal, alles ist besser als das Verhalten aktuell - habt ihr eine absehbare Planung dafür?

[Steinel Technical Support]

Steinel Technical Support Egal, alles ist besser als das Verhalten aktuell - habt ihr eine absehbare Planung dafür?

Ich kann aktuell da keine Termine nennen. Wir würden noch einige Feedbacks abwarten und in der letzten August Woche in die Umsetzung gehen.

[fudi6489]

Hallo, bei mir ist es bei 2 von 14 Meldern seit dem Update vorgekommen dass die Beleuchtung vor der eingestellten Nachlaufzeit versucht abzuschalten.

Ich arbeite mit einer Nachlaufzeit von 30sek, teilweise auch 2min.
In diesen Fällen dimmte die Beleuchtung allerdings nach etwa 10sek Anwesenheit im Raum runter und danach wieder hoch, um 10sek später wieder runter zu dimmen.

Runter dimmen ist in diesen Fällen nur das Soft-Aus vom Aktor und wird ziemlich sicher ein Aus Signal des Melders sein, ist aber nach dem Verlassen des Raumes nicht mehr reproduzierbar da ich schon 3 mal die ETS angeworfen habe um den Busverkehr aufzuzeichnen.

Ist dieses Phänomen bei sonst jemanden auch schon aufgetreten, wenn nicht muss ich mal schauen ob ich den Busverkehr dauerhaft loggen kann um dem Problem auf die Schliche zu kommen?

Ansonsten funktionieren die Melder von der Erkennung absolut zufriedenstellend, und ich kann hier definitiv eine Kaufempfehlung abgeben, was vor dem Update absolut nicht der Fall war, und ich mich echt schon über den Kauf in den A... gebissen habe.

Freut mich dass Steinel nach doch längerer Zeit, wie es aussieht intensiv an der Verbesserung des Melders arbeitet.

LG Jürgen

[fudi6489]

Ich kann aktuell da keine Termine nennen. Wir würden noch einige Feedbacks abwarten und in der letzten August Woche in die Umsetzung gehen.

Bitte lasst euch Zeit und testet auch viel.

Die Updateprozedur ist jetzt nicht unbedingt das was ich mir nach Feierabend vorstellen und doch eher zeitaufreibend.
Somit sollte es nicht zu oft nötig sein, beim letzten Mal hat sie sich ja im Gegensatz zum ersten Update definitiv ausgezahlt und ich denke die ein oder ander Woche mehr können wir mit den bestehenden Problemen sicher noch leben.

Wenn ich jetzt aber an Firmen denke die diese Updates durchführen müssen da der Melder nicht zuverlässig arbeitet gehts hier ja auch gleich um ein paar Euros wenn diese nochmals anrücken muss.

LG Jürgen

[mumpf]

Hi,

jetzt fängt die Diskussion an (finde ich sehr positiv):

Dort wird sehr gern mit dem Taster direkt der Aktor geschaltet ohne über den Melder zu gehen.

Hier reden wir scheinbar aneinander vorbei, was die Bedeutung von KO9 ist. Natürlich kann man den Aktor mit dem Taster schalten, nur muss diese GA eben auch auf KO9 gehen. Es gibt 2 Szenarien:

1. Ich schalte mit dem Taster->der geht nur an KO9->damit schaltet KO1 den Aktor. In diesem Falle will ich alles, was der PM macht, ich will vor allem nicht, dass das Licht angeht, wenn der PM gesperrt ist. Das ist glaube ich der Fall, den ihr im Kopf habt (zumindest so lese ich die Argumentation)
2. Ich schalte mit dem Taster->der geht direkt an den Aktor UND an KO9 (die selbe GA). Damit schaltet der PM dann zwar "nochmal" ein, aber das ist unkritisch, da ja schon eingeschaltet ist. Falls der PM gesperrt/gestört/kaputt ist, habe ich immer noch Licht. Aber wenn der PM korrekt funktioniert, kann KO1 (hörend) genau so bleiben, wie ich das beschrieben habe.

Hier haben wir tatsächlich unterschiedliche Anforderungen.

Ehrlich gesagt sehe ich das nicht so, beide Fälle lassen sich perfekt abbilden.

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.

Wie gesagt, Fall 2 bildet das genau ab. Deswegen schrieb ich immer, KO9 ist der Tastereingang. Wenn man den Melder nicht über KO9 benachrichtigt, dass manuell bedient wurde, ist es vollkommen OK, dass der Melder den (für ihn nicht vorhandenen) manuellen Wunsch ignoriert.

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.

Genau das ist falsch! Ich wiederhole mich gerne hier: Wenn jemand ein AUS mit Nachlaufzeit haben will, dann soll er KO9 benutzen. Da ist ja die Funktion da! Wenn ihr das so macht, wie oben beschrieben, dann gibt es keine Möglichkeit mehr, ein AUS ohne Nachlaufzeit zu bekommen (also den von mir beschriebenen Fall abzubilden):

AUS Signal mit Präsenz --> Licht AUS und sofort Rückfall in Standardbetrieb (Licht geht sofort wider an)

Ich bin ehrlich gesagt verwundert, warum ihr eine Funktion, die es sowieso bei KO9 gibt, unbedingt auch bei KO1 implementieren wollt und das sogar noch

differenziert betrachten

wollt? Es ist absolut unnötig.

Um das nochmal etwas abstrakter zu behandeln:
Mir ist beim schreiben der Antwort aufgefallen, dass ihr versucht, KO1 hörend sehr an KO9 anzugleichen. Wenn die aber gleich sein sollen, würde man KO9 nicht benötigen. Man braucht aber bei einem PM einen Eingang für den "Status des Aktors", und dieser Eingang sollten nicht gleich sein mit den Eingang für manuelle Aktionen.

Könnte es sein, dass der Feedback aus aktuellen Projekten zu KO1 daher kommt, dass die Elektriker nicht zwischen manuellen und automatischen Aktionen unterscheiden und einfach KO1 hörend für manuelle Aktionen verwenden, weil sie das so kennen? Weil die einfach KO9 nicht beachten?
Wäre dann nicht die Lösung für alle, einfach die Funktionen KO1 hörend und KO9 zu tauschen? Also:

• KO1 hörend macht exakt die Sachen, die ich oben bei KO9 beschrieben habe
• KO9 wird zum "Status vom Aktor" umbenannt und macht genau die Sachen, die ich bei KO1 hörend beschrieben habe?

Ihr hättet die, die sich nicht wirklich viel Gedanken über Unterschiede zwischen Automatik/Manuell machen wollen, mit KO1 "abgefrühstückt" und in vielen (einfachen) Fällen würde das Ergebnis rauskommen, dass die Leute wollen. Vor allem die Elektriker, die den Status des Aktors auf KO1 legen und dann mit dem Taster direkt den Aktor schalten, würden auch das bekommen, was sie erwarten.

Für die Leute, die sich ernsthaft mit Automatisierung beschäftigen und anspruchsvolle manuelle Eingriffe realisieren wollen, würde dann KO9 für den Aktorstatus und weitere Automatismen zur Verfügung stehen, vor allem ein "AUS ohne Nachlaufzeit".

Wäre das vielleicht eine bessere Lösung?

Gruß, Waldemar

P.S.:

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

Das mit den Sperren muss ich einfach nochmal testen, wenn ich wieder aus dem Urlaub zurück bin, mag sein, dass ich da was falsch in Erinnerung hatte, sorry.

[mumpf]

Hi,

Egal, alles ist besser als das Verhalten aktuell

dem kann ich nur bedingt zustimmen. es würde besser werden, aber nicht wirklich gut, wenn ein AUS-Status von meinem Aktor mich dazu zwingt, aufzustehen und zum Taster zu laufen. Ist noch der Punkt, dem mich stört, sonst sieht das schon besser aus...

Gruß, Waldemar