Steinel True Presence – Präsenzmelder

[BadSmiley]

Ich biete Anlagen mit 29 Meldern... Aber auch ohne Beschwerden... Darum warte ich mit dem Update so oder so noch.

[Beleuchtfix]

Gibt es eigentlich einen Weg, den Melder schneller zu „updaten“? Ich habe einen Kunden mit 3 TP, da bin ich dan 3 Stunden beschäftigt, muss irgendwo kein Mobilgerät in der Nähe der Melder liegen lassen. Geht das per ETS aus der Ferne irgendwie sinnvoll?
Gruß Florian

[mumpf]

Hi Etienne,

danke für die Blumen! Ich habe natürlich auch ein Eigeninteresse daran...

Ferner bin ich der Meinung, dass es nichts bringt, immer nur hinterher zu "Meckern". Wenn man schon mal die Chance hat, vorher konstruktiv Kritik zu äußern, dann sollte man das Tun. Ich versuche es eben auch mit Beispielen zu belegen, die mir in meinem Haus und auch bei 2 Bekannten, die ich Berate, bereits untergekommen sind. Ist sicherlich nicht mit einem Kundenstamm von mehreren 100 Kunden zu vergleichen, aber hier geht es ja gerade um die nichttrivialen Fälle, also all die, die über "ich verknüpfe mal den Melder mit dem Aktor über eine GA, dann wird das schon" hinausgehen.

Gruß, Waldemar

[Amenophis]

Waldemar, vielen Dank, dass du dich hier so einsetzt und die Sachen gut darstellst. Ich stehe kurz davor den Melder zu kaufen aber die Probleme bisher haben mich abgeschreckt, wenn ich aber deine Vorschläge lese und sehe, dass Steinel Technical Support inzwischen hier gut vertreten ist bzw auch bereit auf unsere Wünsche und Vorschläge einzugehen + endlich Updates für den Melder bringt, werde ich ihn wohl doch kaufen weiter so

[mumpf]

Hi Steinel Technical Support,

Ich hab noch ein weiteres Gegenarguent zu diesem Vorgehen:

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 Problem hier sind die Latenzen der Präsenzerkennung, diese sind auch bei diesem Sensor nicht 0.

Bleiben wir bei der Einstellung 5 Min. Nachlaufzeit und nehmen wir an, ihr könnt Präsenz/Antipräsenz wirklich sicher innerhalb von 10 Sekunden erkennen.

Situation (vereinfacht dargestellt, das Originalszenario ist etwas komplexer): Ich gehe aus einem Raum raus um mache von außen das Licht aus. Intention hier ist "AUS ohne Nachlaufzeit". Ich hab aber was im Raum vergessen und gehe sofort wieder rein. Ich erwarte, dass das Licht angeht.

1. Wenn mein AUS-Signal aber noch zu der Zeit kam, in der der Sensor dachte, es wäre noch Präsenz im Raum (also innerhalb von 10 Sekunden), dann wird das Licht nicht angehen.
2. Sollte er schon "keine Präsenz" festgestellt haben (>10 Sekunden), wird das Licht angemacht.

Ich bekomme somit ein nichtdeterministisches, in den Augen der User (in meinem Falle die Familie, betreibt man es gewerbsmäßig sind es die Kunden) erratisches und zufälliges Verhalten. Das Problem wird um so schlimmer, je länger die Latenz bei der sicheren Präsen-/Antipräsenzerkennung ist. Ich hoffe, ihr seid auch daran interessiert, dass das Verhalten des PM klar und deterministisch ist, und zwar nicht nur aus algorithmischer Sicht betrachtet, sondern auch wie es von Außen betrachtet wirkt.

So, und wenn ich euch bis hierher nicht überzeugt habe, dann werde ich es auch nicht schaffen. Ich diskutiere natürlich gerne weiter und würde mich auch über eine Info freuen, wie ihr euch final entschieden habt.

Gruß, Waldemar

[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

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

[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

[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

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

[crewo]

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

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

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

[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

[andreasrentz]

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