Steinel True Presence – Präsenzmelder

[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

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

[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

[BadSmiley]

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

[mumpf]

Einfach die ganze Familie des Kunden zum Grillen einladen und dann alle Handies einsammeln und fürs Update nutzen.

Gruß, Waldemar

[andreasrentz]

Mit Android gehts echt zügig, alle 3 Updates in 15 Minuten. Mal gut das die das die Kinder eins hatten, bei IOS, beim großen Update hatte ich auch einige Abbrüche und das ist dann noch nerviger.
Trodzdem warte ich mit den weiteren Updates bis die jetzt vorgeschlagen Änderungen eingepflegt werden.

[andreasrentz]

Also ich hoffe ja immer noch, dass ein Aus ohne Nachlaufzeit möglich gemacht wird, Waldemar hat ja alles dazu gesagt. Die Rückmeldungen aus den Projekten kann ich ja verstehen, aber selbst das wäre ja auch noch gegeben , und das der Melder nochmal „Ein“ sendet ist ja nicht tragisch.
Vielleicht ist es ja wirklich so, dass die Rückmeldungen daher rühren weil sie es ja immer so gemacht haben und einfach nicht weiter nachdenken wollen bzw. sich damit zu beschäftigen.

Danke Waldemar für deine ausführliche Schilderung

[andreasrentz]

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

Also ich habe 6 Stück, und nie so massive Probleme gehabt, jedoch habe ich auch immer gehofft das Steinel die Applikation mal verbessert, und hier ist ja jetzt einiges in Bewegung gekommen, bin da sehr zuversichtlich. Ich würde dann auch noch einige Präsensmelder tauschen, TP Erkennung ist perfekt, keine lästigen unnötigen langen Nachlaufzeiten nötig, optisch schick, der TP ist noch kleiner / unauffälliger wie der große Bruder und bringt auch schon allerhand Funktionsumfang mit. Denke den kann man jetzt bedenkenlose weiterempfehlen.

[Amenophis]

Du hast ihn mir ja schon auf dem letzten Treffen in Wiesbaden trotz "Fehler" empfohlen aber ich denke auch, dass ich nun zuschlagen werde, wenn die Komponenten bestellt werden müssen.

[andreasrentz]

Ok, aber denke die Probleme hatte ich nicht unerwähnt gelassen , oder ?

[Amenophis]

Nein nein, alles gut. Wir hatten damals schon gesprochen, dass du mit deinen eigentlich zufrieden bist und die Verzögerung kaum merkst. Aber auch, dass es Probleme gibt, welche hier genannt wurden. Daher alles gut

[mumpf]

Nur als Anmerkung: NOCH sind die Probleme nicht alle behoben... Aber ich hoffe auch, genau so wie ihr.

Gruß, Waldemar

[mumpf]

Hi Steinel Technical Support ,

ich habe mir nochmal anhand eines Sequenzdiagramms veranschaulicht, wie die Signalabfolge bei den KO9 und KO1 (hörend) sein würde, wenn das so verknüpft wäre, wie ich es bisher angenomen habe, also

• Taster schaltet KO9 als manueller Eingang (egal, ob dann auch diese GA auch direkt mit dem Aktor verbunden ist oder nicht)
• KO1 sendend ist mit dem Aktor verbunden
• Status Aktor geht auf KO1 hörend

Sendet der Taster jetzt ein AUS, ist die Intention "AUS mit Nachlaufzeit", da der Taster ja mit KO9 verbunden ist. Was aber genau passiert, ist:

• Taster sendet AUS, KO9 empfängt das (AUS mit Nachlaufzeit)
• PM sendet aus über KO1, Aktor empfängt aus
• Aktor sendet Status AUS, PM empfängt AUS auf KO1 hörend

Wenn in so einem Fall ein AUS auf KO1 die Nachlaufzeit "killen" würde (das Signal auf KO1 kommt ja definitiv später als das auf KO9), wäre das nicht das gewünschte Ergebnis.

Insofern würde ich gerne die beiden "AUS ohne Nachlaufzeit"-Fälle ergänzen:

Schalten über hörenden Ausgang (KO1):

• AUS Signal ohne Präsenz --> Falls das Licht AN ist => Licht AUS und sofort Rückfall in Standardbetrieb (Licht geht bei nächster Bewegung an), sonst im bisherigen Modus bleiben (in der Annahme, dass KO9 schon ausgeschaltet hat, Nachlaufzeit bleibt)
• AUS Signal mit Präsenz --> Falls das Licht AN ist => Licht AUS und sofort Rückfall in Standardbetrieb (Licht geht sofort wider an), sonst im bisherigen Modus bleiben (in der Annahme, dass KO9 schon ausgeschaltet hat, Nachlaufzeit bleibt)

Wahrscheinlich kann man grundsätzlich sagen, dass ein empfangenes Telegramm auf KO1 nur Auswirkung haben sollte, wenn es einen anderen Zustand hat als das KO1 selbst (also nur beim Wechsel von "EIN nach AUS" oder von "AUS nach EIN"). Für "EIN nach EIN" bzw. "AUS nach AUS" ist es ja nur die Bestätigung vom Aktor. Das hab ich aber noch nicht weiter durchdacht bzw. analysiert. Ist nur eine Annahme.

Ich bin auf euer Feedback gespannt und werde auch weiter berichten, wenn mir noch was auffällt. Morgen (Montag) werde ich allerdings kaum online sein können.

Gruß, Waldemar

[crewo]

Warum muss denn das KO1 hörend überhaupt irgendwas steuern? Im Prinzip erwarte ich von einem hörenden KO, an dem der Status eines Aktors hängt, nur einen Soll/Ist-Abgleich. Mir wäre am liebsten, dass hier gar nichts passiert, es sei denn der Status vom PM passt nicht zum empfangenen Status vom KO1.

Beispiel:
- PM-Kanal ist auf EIN, Empfängt plötzlich ein "AUS", dann sollte der PM wieder ein "EIN" senden, solange die Rahmenbedingungen für EIN passen (Präsenz erkannt z.B.)
- PM-Kanal auf AUS, Empfängt EIN, dann Licht wieder AUS schalten

Warum in einem Raum mit dem PM etwas von "extern" über den Status des Aktor-Kanals gesteuert werden muss, verstehe ich gerade nicht, aber evtl. denke ich hier zu einfach. Mir würde jedenfalls genügen, wenn der PM weiß, dass der Aktor "EIN" ist obwohl dieser eigentlich "AUS" seien müsste. Alles andere mache ich doch über das KO9, oder nicht? Klärt mich gern mal auf, warum ihr 2 so komplexe Eingänge fürs Schalten haben möchtet