Steinel True Presence – Präsenzmelder

[fudi6489]

Hi Jürgen,

Du gehst immer noch davon aus, dass die Applikationsbeschreibung irgendwas mit der Applikation zu tun hat, die entwickelt wurde .

Teste mal mit ner Taschenlampe und leuchte den Melder an - Licht geht gleich aus. Also nichts mit Nachlaufzeit. Und ich hatte das in der Anfangszeit ausprobiert, ich bin mir ziemlich sicher, dass es auch kein Offset ist, sondern eine Obergrenze. Habe es aber aktuell nicht verifiziert.

Gruß, Waldemar

Servus Waldemar

Soeben dreimal mit der Taschenlampe getestet und das Verhalten ist exakt so wie dies in der Applikationsbeschreibung beschrieben ist.
Das Licht schaltet genau nach der eingestellten Nachlaufzeit von 30 Sekunden ab.

Auszug aus der Applikationsbeschreibung
"Es ist einstellbar, ob der Lichtausgang bei ausreichendem Tageslichtanteil
die Beleuchtung ausschaltet (Präsenzmelderlogik) oder nicht
ausschaltet (Bewegungsmelderlogik). Das Ausschalten bei ausreichendem
Tageslichtanteil wird mit einem Offset parametriert. Steigt
die gemessene Helligkeit über den Wert „Schaltschwelle + Offset
Schaltschwelle AUS“ triggert die Nachlaufzeit bei erfasster Präsenz
nicht nach. Bei Ablauf der Nachlaufzeit schaltet der Ausgang aus."

Das Problem besteht also weiterhin und ist für mich nicht logisch eingrenz - sowie nachvollziehbar.

Liebe Grüße
Jürgen

[BennyM]

Hi Waldemar,

danke für deine Antwort. Sorry war keine Absicht. Dann werde ich mal schauen wo es reinpasst. Falls dennoch jemand zufälligerweise drüber geschaut hat, darf er mir gerne auch direkt schreiben um diesen Thread nicht vollzumüllen. Sorry!!! Grüße Benny

[mumpf]

Hi BennyM,

da dieser Thread eher dazu da ist, die Technik/Funktion/Probleme mit dem TP zu besprechen, hätte ich folgende Bitte: Kannst Du Deine Frage in einem neuen Thread stellen, sowas wie "Erfahrungen zur Positionierung vom True Presence" oder so? Dann bekommst Du auch zu Deinem Grundriss passende Empfehlungen. Sonst wird das hier zu unübersichtlich.

Gruß, Waldemar

[BennyM]

Morgen zusammen,

ich bin gerade dabei die Präsenzmelder für unser Haus zu planen. Ich hatte vor im Wohnzimmer/Esszimmer einen Steinel True Presence zu verwenden. Da ich hier in den letzten Beiträgen jedoch immer davon gelesen habe, dass dieser mittig im Raum platziert werden soll, bin ich nun etwas verunsichert. Ich hatte vor in unserem offenen Wohn- und Esszimmer einen gemeinsamen True Presence zu verwenden und bin von den 9 Meter True Presence Radius ausgegangen, den ich auch in den Plan anbei gezeichnet habe. In der Nähe befindet sich aber auch der Kamin. Könnte man dies, wie im Pan eingezeichnet, umsetzen ? In der Küche sowie im Dusch/Wc plane ich mit dem MDT Glas Präsenzmelder. Da ich leider noch nicht so viel Erfahrung habe, verzeiht mir eventuelle blöde Fragen. Vielleicht kann mir ja jemand der mit dem True Presence bereits Erfahrungen gesammelt hat wertvolle Tipps geben. Besten Dank im Voraus.

[mumpf]

Hi Jürgen,

Du gehst immer noch davon aus, dass die Applikationsbeschreibung irgendwas mit der Applikation zu tun hat, die entwickelt wurde .

Teste mal mit ner Taschenlampe und leuchte den Melder an - Licht geht gleich aus. Also nichts mit Nachlaufzeit. Und ich hatte das in der Anfangszeit ausprobiert, ich bin mir ziemlich sicher, dass es auch kein Offset ist, sondern eine Obergrenze. Habe es aber aktuell nicht verifiziert.

Gruß, Waldemar

[fudi6489]

Hi Jürgen,

ich hab früher auch die beiden KO80+81 verbunden gehabt, hatte damals das Gefühl, dass die vor alles schnell wechseln, wenn man sich in der Nähe vom Melder befindet. Im Ranbereich (also in der Nähe der Grenze des vorgegebenen Radius) ist meist TP aktiv, Bewegung kommt nur noch bei recht starken Bewegungen.

Mit der aktuellen Software hab ich das aber nicht wieder probiert.


Ich hab mir das mal angesehen. Hast Du vielleicht die helligkeitsabhängige Abschaltung aktiv? Licht geht an, der Helligkeitswert ist über dem Schwellwert, also geht Licht wieder aus. Zumindest würde ich das erstmal ausschließen. Wobei ich nicht wirklich verstehe, wieso dann der Präsenzausgang auf 0 geht, ich mag mich also irren.

EDIT: In Deinen Parametern stand "Helligkeitsabhängig abschalten bei 100 Lux", im Word-Dokument gab es eine Zeile
2020-08-18 14:49:33 689208 KNX WRITE 1.0.151 5/1/23 781 Sensoren-Helligkeit-EG-Speis Präsenzmelder 98.96
Das spricht sehr für helligkeitsabhängiges abschalten.

Noch eine Sache: Ich musste bei mir bei der neuen Firmware den Erfassungsradius des Melders um 10 cm erhöhen, um etwas das gleiche verhalten verglichen zu früher zu bekommen. Vor der Anpassung ist auch das Licht ausgegangen (beim sitzen auf dem Sofa). Ich vermute, das ist hier nicht der Fall, oder (zu kleiner Radius)?

Gruß, Waldemar

Servus Waldermar
Danke fürs Ansehen der Logdatei.
Auch ich hatte die Helligkeit im Verdacht weil es für mich das einzige war das schlüssig erschien.
Es wird heller-->Licht geht sofort aus--->Es wird dunkler-->Licht geht sofort wieder an

Ich habe tatsächlich den Parameter "Helligkeitsabhängig abschalten bei 100 Lux"
Allerdings ist dies ein Offset und muss zum Einschaltwert hinzuaddiert werden, wären für den oben geloggten Melder 145 Lux und nicht 100 Lux.
Der Melder darf aber auch beim Überschreiten dieser 145 Lux nicht sofort ausschalten sondern triggert die Nachlaufzeit nicht mehr nach, und dürfte dann erst 30 Sekunden später abschalten.
Es wird aber sofort ausgeschaltet und der maximale gesendete Helligkeitswert waren 106 Lux, Helligkeit senden habe ich bei Änderung von 15 Lux parametriert, also sollte dies auch ausgeschlossen werden können.

Auszug aus der Applikationsbeschreibung
"Es ist einstellbar, ob der Lichtausgang bei ausreichendem Tageslichtanteil
die Beleuchtung ausschaltet (Präsenzmelderlogik) oder nicht
ausschaltet (Bewegungsmelderlogik). Das Ausschalten bei ausreichendem
Tageslichtanteil wird mit einem Offset parametriert. Steigt
die gemessene Helligkeit über den Wert „Schaltschwelle + Offset
Schaltschwelle AUS“ triggert die Nachlaufzeit bei erfasster Präsenz
nicht nach. Bei Ablauf der Nachlaufzeit schaltet der Ausgang aus."

Ich hab jetzt noch einen Auszug von einem anderen Raum gemacht um darzustellen dass es keine einmalige Geschichte ist.
Bei Bedarf kann ich noch weitere liefern.
Ich könnte natürlich jetzt "Helligkeitsabhängig abschalten" deaktivieren und mal schauen was passiert
Es geht aber aktuell hoffentlich darum alle Melderfehler auszumärzen und deswegen möchte ich dem auf die Schliche kommen.

Wäre auch toll wenn sich Steinel Technical Support zu Wort melden würde.

Die Entfernungen habe ich noch nicht neu eingestellt, da ja die eingestellte Nachlaufzeit nicht eingehalten wird und es deswegen nicht an den Reichweiteneinstellungen liegen kann.

Was mir, wie im vorigen Beitrag schon angemerkt, aufgefallen ist: Die beiden KO´s 80+81 welche im Normalbetrieb ständig beschrieben werden, bekommen hier kein einziges Mal einen Status vom Melder.

Link zur Fehlerfassung:
Bitte achtet beim Öffnen vom Link nach dem Klick auf "Download" dass ihr keine Applikation sondern ein Word Dokument runterladet!
Dürfte irgendein Programm von der Gratisuploadseite sein.

Kurzfassung nur mit betreffenden Busverkehr
ProblemLichtkurzEin-AusschaltenSchleuseKurzfassung.docx

Langfassung mit kompletten Busverkehr
ProblemLichtkurzEin-AusschaltenSchleuse.docx

Liebe Grüße
Jürgen

[Beleuchtfix]

ich bin mir nicht sicher, wofür Du plädierst. Heißt das, als SI willst Du nur mit KO1 arbeiten und Dich nicht um KO9 kümmern müssen?

Nein, nicht zwingend. Es ging mir eher um die häufigen Anfragen, mein PM schaltet immer wieder aus, obwohl ich das Licht von Hand eingeschaltet habe. Deshalb ist das eine Logik, mit der ich leben kann.

Was aber stimmen muss, dass ist, dass die Sperren und der passende Status darauf richtig reagieren. Das habe ich jetzt aktuell aber nicht weiter getestet. In der alten Version wurde da inconsistent reagiert. Für mich ist die Logik - keine weitere Aktion des PMs bis zum Ablauf der Präsenz und Ablauf der Nachlaufzeit ok, egal, ob auf KO 1 oder 9, was aber nicht sein darf, dass dann die Sperre als aktiv angezeigt wird. Wenn ich den PM sperre, dann möchte ich, dass das Licht an - oder aus bleibt, bis die Sperre gelöscht wird. Ich will z.B. sicherstellen, dass ich ein Zimmer betreten kann, ohne dass dort das Licht angeht. Und ich muss mich auf die Sperranzeige verlassen.
Gruß
Florian

[crewo]

die Sperre darf somit nur auf den Ausgang wirken und nicht auf die interne Verarbeitung.

Korrekt, das ist vermutlich das Problem.

[mumpf]

Wenn jetzt noch die Kanäle trotz Sperre die Zustände korrekt mitlesen und beachten würden (Tag/Nacht, Helligkeit) und somit nach Entsperren den korrekten Zustand einhalten, wäre das der PM meiner Träume

Das ist ein wichtiger Punkt, gut dass Du das ansprichst. Ich kann zwar derzeit nicht testen (Urlaub) aber ich erinnere mich noch, dass ich mit den Sperren nicht glücklich war .
Was mir fehlt, ist eine weitere Option bei den Sperreinstellungen für Sperre=AUS:

• AUS: beim ausschalten der Sperre wird ein AUS geschickt - das gibt es schon
• EIN: beim ausschalten der Sperre wird ein EIN geschickt - das gibt es schon
• Regelung fortsetzen: beim ausschalten der Sperre wird gar nichts geschickt - auch das gibt es schon
• letzer Zustand: Beim ausschalten der Sperre wird das Signal geschickt, dass geschickt worden wäre, wenn die Sperre nicht aktiv gewesen wäre - das fehlt!

Ich glaube, das ist auch der Fall, der crewo fehlt. Beim einschalten der Sperre macht so eine Einstellung keinen Sinn. Und das positive ist: Um bei dieser Einstellung den Ausgang richtig zu versorgen, muss man sowieso alle Zustände melderintern tracken, die Sperre darf somit nur auf den Ausgang wirken und nicht auf die interne Verarbeitung.

Und ja, dann wäre das auch der Melder meiner Träume

Gruß, Waldemar

[crewo]

Ist eine Möglichkeit, wäre noch einfacher. Ich ging davon aus, dass wenn ein Automatismus das Licht an macht (der Melder das also nur über den Status und nicht über KO9 mitbekommt), es dann wenigstens für die Nachlaufzeit an bleiben sollte, um ein Hin- und Herschalten zu verhindern, nicht das sich hier 2 Automatiken (die im PM und die externe) dauernd gegenseitig triggern. Aber Du hast recht, man kann das Ganze auch komplett symmetrisch betrachten und beide Fälle identisch implementieren.

Das ist der einzige Fall, über den ich auch nachdenken würde als Hersteller. Sonst haben wir tatsächlich das gleiche gemeint aber wohl unterschiedlich ausgedrückt

Ich fände das Verhalten so jedenfalls für den "normalen" Endanwender ideal, da es vorhersehbar und nachvollziehbar ist. Zudem wesentlich weniger komplex in der Einstellung. Wenn jetzt noch die Kanäle trotz Sperre die Zustände korrekt mitlesen und beachten würden (Tag/Nacht, Helligkeit) und somit nach Entsperren den korrekten Zustand einhalten, wäre das der PM meiner Träume

[mumpf]

Hi @crewo,

Mir wäre am liebsten, dass hier gar nichts passiert, es sei denn der Status vom PM passt nicht zum empfangenen Status vom KO1.

Das habe ich hierdurch sagen wollen, war mir nur nicht sicher, ob das in allen Fällen gilt:

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

Inzwischen hab ich weiter drüber nachgedacht und noch keinen Fall gefunden, bei dem das nicht so ist. Ich stimme Dir also vollkommen zu.

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

Das ist der von mir beschriebene Fall "AUS ohne Nachlaufzeit", da sind wir uns also auch einig.

- PM-Kanal auf AUS, Empfängt EIN, dann Licht wieder AUS schalten

Ist eine Möglichkeit, wäre noch einfacher. Ich ging davon aus, dass wenn ein Automatismus das Licht an macht (der Melder das also nur über den Status und nicht über KO9 mitbekommt), es dann wenigstens für die Nachlaufzeit an bleiben sollte, um ein Hin- und Herschalten zu verhindern, nicht das sich hier 2 Automatiken (die im PM und die externe) dauernd gegenseitig triggern. Aber Du hast recht, man kann das Ganze auch komplett symmetrisch betrachten und beide Fälle identisch implementieren.

Gruß, Waldemar

[mumpf]

Hallo Florian,

Grundsätzlich ist die Idee gar nicht so schlecht, einfach nur den Schaltaktor anzusteuern um eine Handschaltung zu aktivieren. Da die Präsenzerkennung ja ziemlich gesichert ist, kann man davon ausgehen, dass man gezielt den PM übersteuern möchte, bis zum Präsenzende.

ich bin mir nicht sicher, wofür Du plädierst. Heißt das, als SI willst Du nur mit KO1 arbeiten und Dich nicht um KO9 kümmern müssen? Einer meiner Vorschläge war ja, dass man KO9 und KO1 hörend vertauscht, dann würde ja der Staus des Aktors, mit KO1 hörend verbunden, genau Dein Verhalten ergeben.

Plädierst Du dafür?

Gruß, Waldemar

[mumpf]

Hi Jürgen,

ich hab früher auch die beiden KO80+81 verbunden gehabt, hatte damals das Gefühl, dass die vor alles schnell wechseln, wenn man sich in der Nähe vom Melder befindet. Im Ranbereich (also in der Nähe der Grenze des vorgegebenen Radius) ist meist TP aktiv, Bewegung kommt nur noch bei recht starken Bewegungen.

Mit der aktuellen Software hab ich das aber nicht wieder probiert.

nur eben im Fehlerfall (blau) wird auf beiden nichts geschrieben und das Licht geht ohne nachvollziehbaren Grund wieder aus.

Ich hab mir das mal angesehen. Hast Du vielleicht die helligkeitsabhängige Abschaltung aktiv? Licht geht an, der Helligkeitswert ist über dem Schwellwert, also geht Licht wieder aus. Zumindest würde ich das erstmal ausschließen. Wobei ich nicht wirklich verstehe, wieso dann der Präsenzausgang auf 0 geht, ich mag mich also irren.

EDIT: In Deinen Parametern stand "Helligkeitsabhängig abschalten bei 100 Lux", im Word-Dokument gab es eine Zeile
2020-08-18 14:49:33 689208 KNX WRITE 1.0.151 5/1/23 781 Sensoren-Helligkeit-EG-Speis Präsenzmelder 98.96
Das spricht sehr für helligkeitsabhängiges abschalten.

Noch eine Sache: Ich musste bei mir bei der neuen Firmware den Erfassungsradius des Melders um 10 cm erhöhen, um etwas das gleiche verhalten verglichen zu früher zu bekommen. Vor der Anpassung ist auch das Licht ausgegangen (beim sitzen auf dem Sofa). Ich vermute, das ist hier nicht der Fall, oder (zu kleiner Radius)?

Gruß, Waldemar

[fudi6489]

Servus Waldemar
Ich habe die beiden KO´s nur mit dem Melder verknüpft und schalte nichts damit.
Mir ist jetzt nur im Log die Häufigkeit aufgefallen.

In der Applikationsbeschreibung steht folgendes:

1.16 Ausgabe Präsenz / True Presence Erfassung *
Die Ausgänge Präsenz und True Presence geben an, ob der Sensor
aktuell eine Erfassung True Presence (Atmungserfassung) oder eine
Präsenzerfassung von Bewegungen die größer als die Mikrobewegungen
beim Atmen vorliegt. Zwischen diesen beiden Kommunikationsobjekten
liegt eine Oder Verknüpfung. Der Sensor kann entweder
Präsenz oder True Presence erfassen. Die Erfassung bezieht
sich immer auf das stärkste Signal. True Presence kann nur angezeigt
werden, wenn keine größeren Bewegungen detektiert werden.

Somit hast du Recht und der Melder macht auf KO 80+81 genau das was er soll, nur eben im Fehlerfall (blau) wird auf beiden nichts geschrieben und das Licht geht ohne nachvollziehbaren Grund wieder aus.

Wenn ich mit der "Fehlersuche" fertig bin werde ich die beiden KO`s wieder trennen da die Häufigkeit der Statusänderung schon hoch ist.
(Hab bei mehreren Einschaltvorgängen nachgesehen und das Szenario mit 4mal in 4sek ist eher die Regel als die Ausnahme)

Liebe Grüße
Jürgen

[mumpf]

Hi Jürgen,

die KO80 und KO81 sind doch rein informativ? Ich hoffe, Du nutzt die nicht für irgendwelche Schaltoperationen, das macht nicht wirklich Sinn. Und wenn der Melder in 4 Sekunden meint, 4 mal abwechselnd Bewegung und Atmung zu erkennen, dann mag das ja so sein, aber warum ist das ein Problem? Deswegen werden ja die eigentlichen Kanäle nicht gleich schalten, oder?

Gruß, Waldemar