Steinel True Presence – Präsenzmelder

[mumpf]

In Summe bewirkt das Ganze, das der TP nicht allein das Licht einschalten kann. Wenn jedoch jemand den Raum betritt, löst zum einen der PIR sofort aus und öffnet das TOR. Danach genügt es, wenn der TP allein aktiv ist, da auch er das TOR geöffnet hält.

Nur für mich, damit ich das komplett verstehe:

• Der PIR macht das TOR mit einer 1 auf
• Der TP macht mit einer 0 das TOR zu
• Das wäre dann also eine SCHALTER-Logik zum öffnen vom TOR
• Für den TP sind es eignetlich 2 TOR-Logiken (eine für Bewegung und eine für Präsenz)
• Und hinter den TOR-Ausgängen hängt ein VPM

Sehe ich das richtig? Finde ich eine sehr elegante Lösung.

Gruß, Waldemar

[willisurf]

Wie genau hast du das umgesetzt?

Der PIR schaltet über ein Logik-TOR die Präsenzsignale vom TP frei. Wenn TOR geschlossen, ist damit der TP quasi gesperrt, da die Präsenzsignale nicht durchkommen. Das TOR wird von PIR ODER Bewegung TP (muss man nicht mit aufnehmen) ODER vom TP nach dem TOR (quasi Selbsthaltung geöffnet).

In Summe bewirkt das Ganze, das der TP nicht allein das Licht einschalten kann. Wenn jedoch jemand den Raum betritt, löst zum einen der PIR sofort aus und öffnet das TOR. Danach genügt es, wenn der TP allein aktiv ist, da auch er das TOR geöffnet hält.

Klingt kompliziert, ist aber einfach und wirksam.

[FrankMaier]

Wie ich schon etwas davor geschrieben habe, die Sperre hat bei mir nicht funktioniert, da der Steinel TP trotz Sperre nochmals eine Präsenz sendet, und das Licht dann wieder einschaltet. Fällt natürlich nur auf, wenn man manuell das Licht mal ausschalten will.
https://knx-user-forum.de/forum/öffe...93#post1842293

Ich habe es daher so gelöst:
- TP Lichtkanal 1 ist immer an und sendet zyklisch auf die GA "Steinel TP Master"
Er hat eine Nachlaufzeit von 30s und sendet zyklisch alle >60s.
- Von da aus geht es auf eine Logik des MDT PM:
Funktion UND
Sendebedingung: nur 1 senden bei Eingangstelegram
Eingang A: Steinel TP Master
Eingang B: Status des Licht
Ausgang: Slave Eingang des MDT PM

Der MDT PM hat eine Kurzzeitpräsenz von 30s (mit Nachlaufzeit 1min) und eine reguläre Nachlaufzeit von 3min.

Betrete ich den Raum, werde ich vom MDT PM detektiert, das Licht schaltet ein, auf den Eingang vom Slave kommt über den Steinel und der UND Logik ein 1 Signal. Verlasse ich den Raum sofort wieder, so kommt mir der Steinel nicht in die Quere, da er früh genug schon wieder ausgeschalten hat und vor dem Ausschalten nicht nochmal zyklisch etwas gesendet hat.

[gbglace]

PIR Nachlaufzeit auf ca. 60s, etwas höher als TP

Nachlaufzeiten in Sekunden finde ich meist übertrieben und unpassend, klar muss man nicht immer ne viertel Stunde auf Reaktion warten, aber so 1-2 Minuten ist schon OK.

TP Sperre mit An/Aus, darauf einen Lichtausgang des PIR, der wieder rum die Daten des TP mit auswertet, wodurch sich der TP selbst entsperrt hält, auch wenn der PIR keine Bewegung sieht

das ist ein bissel Wirr. Lege ein GA an die vom Ergebnis einer ODER-Logik mit Werten belegt wird und verbinde diese mit dem Sperreingang des Steinel-TP. Eingänge in die Logik sind die zyklische Präsenzmeldung des TP und die Präsenzmeldung des PIR. Die Dinger nennen sich ja Präsenzmelder und nicht Lichtschalter an der Decke, insofern würde ich diese Sperre nicht vom Schaltzustand einer Lampe oder eines Lichtkanals des PIR abhängig machen.

oder nutze sowas wie die Open-KNX VPM Applikation auf 1TE Reg-HW

[amasingh]

Perfekt, danke Verstanden:

- TP als Slave des PIR ( in meinem Fall MDT SCN-P360)
- TP Status zyklisch senden EIN/AUS
- TP Nachlaufzeit geringer als PIR zB 30s
- PIR Nachlaufzeit auf ca. 60s, etwas höher als TP
- TP Sperre mit An/Aus, darauf einen Lichtausgang des PIR, der wieder rum die Daten des TP mit auswertet, wodurch sich der TP selbst entsperrt hält, auch wenn der PIR keine Bewegung sieht
- Keine Bewegung durch TP und PIR erkannt -> Sperre des TP

Korrekt zusammengefasst?

[gbglace]

Weil allein die Applikation des TP so komisch ist wie man da einen Halbautomat baut. Und wenn der TP nur AUS schalten soll, musst ihm beibringen das es eben warum auch immer AN gegangen ist, und schon hängst wieder in seiner Applikation wie die Steinel-Jungs da eine solche Funktion verstehen. Und da deren Ablaufverständnis halt etwas komisch ist will man das so nicht tun.

man nimm dann einen PIR mit gescheiter Applikation und lässt den Steinel als reinen Zuspieler der Information "es ist wer im Raum" agieren. Da der Steinel aber bei diversen Umständen etwas überreagiert (ne Planze im Wind/ nen Geschirrspüler der Läuft ne Waschmaschine die läuft oder das Brathändel am Drehrost im Backofen usw.) Haut man auch noch eine Sperre auf dem TP, damit der nicht einfach mal meldet es ist wer im Raum, wenn vorab aber niemand rein gegangen ist. Also Bewegung vom PIR entsperrt den TP und der Sperrt sich quasi erst wieder selbst wenn er und der PIR keine Bewegung/Anwesenheit mehr registrieren. Kann nur schiefgehen wenn Du rein gehst und ne Wama anschaltest und wieder raus gehst aber die hat man ja eher selten neben dem Sofa stehen.

[amasingh]

Einmal, um ein schnelles Ansprechen zu haben (das war immer der Plan), aber jetzt noch mit dem Tipp den TP darüber erst freizugeben. Das war wirklich ein genialer Hinweis.
Setzt natürlich voraus, das der PIR direkt beim Betreten des Raumes auslöst (aber das war ja auch so geplant), verhindert dann aber ein sporadisches Einschalten, ohne das jemand im Raum ist. Gefällt mir recht gut.

Wie genau hast du das umgesetzt?
Meine Idee war jetzt dass der PIR nur "EINschalten" darf und der TP nur "AUSschalten" darf? Wozu dann noch die Sperre?
Beide senden an die gleiche GA, der PIR ist nicht als SLAVE für den TP verlinkt.

[willisurf]

Falls mehr Details gewünscht sind, zum Prinzip
https://www.mdpi.com/1424-8220/21/10/3529/htm

Der Steinel hat folgenden Sensor
https://laonuri.techyneeti.com/wp-co..._DATASHEET.pdf

[Alloc]

Was macht den TP denn so besonders? Software oder Hardware?

Bis dahin: beides. Die Software ist schon was gaaaaanz besondres

Was du aber hören willst: HW, im Prinzip Radar.

[amasingh]

Was macht den TP denn so besonders? Software oder Hardware? Was führt zu der feinen Abtastung?

[crewo]

Nein

[amasingh]

Wenn der TP nur in Verbindung mit einem PIR ordentlich zu nutzen ist, erhöht das den Preis nochmal um gut 100€.
Gibt es denn wirklich keine brauchbare Alternative (fertig zu kaufen

[willisurf]

Ich habe jetzt einen mehr, als ich benötige und wann immer einer spinnt geht er zurück an Steinel.

Ansonsten habe ich gute Erfahrungen damit gemacht, den TP/TPM mit einem PIR zu kombinieren. Einmal, um ein schnelles Ansprechen zu haben (das war immer der Plan), aber jetzt noch mit dem Tipp den TP darüber erst freizugeben. Das war wirklich ein genialer Hinweis.
Setzt natürlich voraus, das der PIR direkt beim Betreten des Raumes auslöst (aber das war ja auch so geplant), verhindert dann aber ein sporadisches Einschalten, ohne das jemand im Raum ist. Gefällt mir recht gut.

Und für die Applikation natürlich nur der VPM. Nur nichts mit der Steinel Applikation.

[kmk85]

Ich habe 3 TP und 1 TPM

2x TP + der TPM gehen auf einen MDT BWM55, der als Master agiert.

Dann habe ich noch einen TP im Büro, der läuft über Umwege über einen BJ Premium, wegen der Applikation.

Grundsätzlich funktioniert das, von Zeit zu Zeit setzt random schon mal einer aus, kann Monate gutgehen, dann muss man den entweder abstöpseln oder Busreset machen, dann gehts wieder…

Katastrophe.

[pweissen]

22.12 hatte ich ihn zu Steinel geschickt.
Firmware habe ich folgende drauf für meine Multisensor:
[0] Firmware 2.1 | 2
[1] Firmware 1.5
[2] Firmware 2.1.9

Was mir gerade schon auffällt ist, dass VOC NUR zwischen 0-2 ppb schwankt. Aber ich warte mal noch 30 Minuten oder so ab.