Steinel True Presence – Präsenzmelder

[crewo]

Exun das teste ich jetzt auch mal. Warum man aber bei einem PM, welcher ja zuverlässig als Halbautomat auch alle mit ihm gesteuerten Lichter ausschalten soll kein eigenes KO für Status zur Verfügung stellt, erschließt sich mir nicht. Sowas sollte doch Standard sein mittlerweile, schließlich haben doch auch die allermeisten Aktoren ein Status KO.

[evolution]

Warum man aber bei einem PM, welcher ja zuverlässig als Halbautomat auch alle mit ihm gesteuerten Lichter ausschalten soll kein eigenes KO für Status zur Verfügung stellt, erschließt sich mir nicht.

Weil man keinen weiteren Statuseingang benötigt. Wenn man einen Melder auf diese einfache Weise übersteuern, will reicht es vollkommen aus, dass man lediglich die Schalt-GA für den Aktor auf den PM-Ausgang und den Taster legt. Es besteht keine Notwendigkeit eine weitere Status-GA auf den Ausgang des Melders zu legen. Weniger ist hier mehr!

Deswegen ist das Verhalten unterschiedlich, ob der Melder die Schalt-GA mithört oder ob er manuell einen externen Tastereingang zulässt. Die nachstehende von Waldemar getroffene Aussage haben wir geprüft und sie ist definitiv falsch:

Ich habe es jetzt ausprobiert, der Empfang eines Telegramms auf dem Schaltausgang (KO 1) verhält sich so wie ein Telegramm bei "Eingang schalten" (KO 9). Auch der Sperrstatus wird gesendet und der Melder gesperrt. Somit ist die hörende Adresse auf KO 1 kein Workaround.

Lediglich beim Schalten des Lichts über den externen Eingang (KO #9 für Lichtausgang 1) wird die Sperre gesetzt und gegebenfalls auch wieder aufgehoben. Beim Mithören des Schaltbefehls über die gemeinsame Schalt-GA auf KO #1 wird hingegen keine Sperre gesetzt. Das würde im übrigen auch überhaupt keinen Sinn machen, weil dann bspw. auch keine Halbautomatik umsetzbar ware.
Btw. ist dieses Verhalten beim Mithören der Schalt-GA bei allen mir bekannten Meldern (auch bei MDT) identisch. Die unterschiedlichen Melder der unterschiedlichen Hersteller bieten lediglich unterschiedliche Parametriermöglichkeiten für das separate KO der Tastereingänge. Hier bietet MDT bei seinen Meldern und Tastern zweifelsohne die umfangreichsten Möglichkeiten.

[crewo]

MDT hat explizit eine Lösung für den Status des Lichtkanals, Steinel nicht.

Wenn man einen Melder auf diese einfache Weise übersteuern, will reicht es vollkommen aus, dass man lediglich die Schalt-GA für den Aktor auf den PM-Ausgang und den Taster legt.

Frank nimm es mir nicht übel, aber du liest meine Beiträge nicht oder überfliegst die nur und so muss man sich im Prinzip ständig wiederholen. Ich spreche nicht von Übersteuerung per Taster, das ist in der Tat simpel! Mein Problem ist ein "fremdgesteuertes" Einschalten der Aktorkanäle, z.B. durch eine Szene, trotzdem will ich und so sieht es die Funktion "Halbautomat" ja auch vor, dass diese zuverlässig vom PM wieder ausgeschaltet werden, wenn keine Präsenz mehr erkannt wird.

Grundsätzlich funktioniert das über das mithörend auf KO 1 und wurde von mir auch schon so weiter oben beschrieben, nur eben mit dem Fehler, dass beim mithören noch einmal der Aktor geschaltet wird, das nervt etwas da ich hier wiederum Logiken habe, die ich nun ausnehmen muss, dazu ist das einfach ein nicht sinnvolles Verhalten. Selbst wenn der PM selbst einschaltet jagt er aufgrund mithören des Status nochmal den Ein-Befehl hinterher. Spätestens da fast man sich doch an den Kopf.

[crewo]

Laut Anleitung ist das Verhalten auch so beschrieben, stimmt aber auch nicht ganz:
"Empfängt dieses Objekt ein Telegramm, verhält es sich wie "Lichtausgang X Eingang schalten"." -> Das stimmt in sofern nicht, dass zumindest nicht der Melder gesperrt wird, wie bei "Lichtausgang X Eingang schalten" der Fall. Macht ja auch keinen Sinn, dass bei Status-Meldung vom Aktor der PM gesperrt wird, aber eben macht es auch keinen Sinn, dass er noch einmal einen Ein-Befehl sendet...

PS: Darauf bezog ich mich.

[evolution]

Grundsätzlich funktioniert das über das mithörend auf KO 1 und wurde von mir auch schon so weiter oben beschrieben, nur eben mit dem Fehler, dass beim mithören noch einmal der Aktor geschaltet wird, das nervt etwas da ich hier wiederum Logiken habe, die ich nun ausnehmen muss, dazu ist das einfach ein nicht sinnvolles Verhalten. Selbst wenn der PM selbst einschaltet jagt er aufgrund mithören des Status nochmal den Ein-Befehl hinterher. Spätestens da fast man sich doch an den Kopf.

Genau das tut er bei mir nicht! Die zwei Szenarien habe ich nochmals nachgestellt, mit folgendem Ergebnis:

1. Der TruePresence schickt weder ein EIN-Telegramm auf die Schalt GA, wenn er über eine hörende Adresse das EIN-Signal bereits bekam. Und nach Ablauf der Zeit schaltet der TruePresence dann bei Nichtpräsenz aus.
2. Wenn der TruePresence das Licht eingeschaltet hat und er kommt über die hörende Adresse ein zusätzliches EIN-Signal, dann schreibt er kein weiteres EIN-Telegramm auf die Schalt GA.

Aus meiner Sicht ist dieses Verhalten vollkommen in Ordnung und nachvollziehbar. Da scheinen noch andere an deiner Kommunikation beteiligt.
Hast Du Dir die Telegramme einmal angesehen und ggf. mitprotokolliert? Damit sollte der Urheber doch ausfindig zu machen sein?!

[mumpf]

Hallo Frank,

Beim Mithören des Schaltbefehls über die gemeinsame Schalt-GA auf KO #1 wird hingegen keine Sperre gesetzt

diese Herausforderung nehme ich an:

Soeben ausprobiert, keine Präsenz im Raum, kein Licht an:

#

Zeit

Dienst

Flags

Prio

Quelladresse

Quellname

Zieladresse

Zielname

Rout

Typ

DPT

Info

90

23.10.2019 11:45:19,122

vom Bus

Niedrig

1.0.254

Dummy

19/0/30

19/0/30-Wohnzimmer: Stehlampe schalten

4

GroupValueWrite

1.001 Schalten

$01 | Ein

91

23.10.2019 11:45:19,293

vom Bus

Niedrig

1.0.25

AKS-2016.02 Schaltaktor 20-fach, 12TE, 16A (10mA)

19/0/31

19/0/31-Wohnzimmer: Stehlampe schalten Status

5

GroupValueWrite

1.001 Schalten

$01 | Ein

92

23.10.2019 11:45:19,329

vom Bus

Niedrig

1.0.5

SCN-LOG1.02 Logikmodul

19/0/201

19/0/201-Wohnzimmer: Licht Status

5

GroupValueWrite

1.001 Schalten

$01 | Ein

93

23.10.2019 11:45:19,413

vom Bus

Niedrig

1.0.131

STEINEL True Presence

19/4/34

Wohnzimmer: PM Lichtkanal sperren Status

5

GroupValueWrite

1.001 Schalten

$01 | Ein

Es sind direkt 4 Telegramme hintereinander, Telegramm 90 ist der Schaltbefehl, die 91 die Statusrückmeldung vom Schaltaktor, die 92 das Ergebnis vom ODER über alle Lampenstati, diese GA geht als hörende Adresse auf KO 1 beim Steinel, der antwortet mit Sperre EIN. Und auch nach 10 Minuten (Nachlaufzeit ist nur 2 Minuten) ist die Lampe auch immer noch nicht aus (was für eine Sperre sprechen würde). Nach der Rücknahme der Sperre und 5 Minuten später ist die Lampe immer noch an... hätte ich auch nicht erwartet, aber das ist nochmal ein anderes Thema.

Nach genauer Auswertung des Gruppenmonitors habe ich folgendes gefunden:

#

Zeit

Dienst

Flags

Prio

Quelladresse

Quellname

Zieladresse

Zielname

Rout

Typ

DPT

Info

307

23.10.2019 11:47:18,772

vom Bus

Niedrig

1.0.131

STEINEL True Presence

19/4/30

19/4/30-Wohnzimmer: PM Lichtkanal schalten

5

GroupValueWrite

1.001 Schalten

$00 | Aus

308

23.10.2019 11:47:18,805

vom Bus

Niedrig

1.0.131

STEINEL True Presence

19/4/34

Wohnzimmer: PM Lichtkanal sperren Status

5

GroupValueWrite

1.001 Schalten

$00 | Aus

Die Lampe wurde somit nach der Nachlaufzeit ausgeschaltet und die Sperre zurückgenommen (oben hatte ich gegenteiliges geschrieben, aber da ich nicht in dem Raum war - ich wollte ja den Präsenzmelder nicht beeinflussen - hatte ich den Sonnenschein aus dem Wohnzimmer als "Lampe immer noch an" interpretiert).

crewo: Ich kann nicht bestätigen, dass vom PM nochmal ein Ein-Signal kommt. Bei mir kommt nur die Sperre.

Jetzt ist die Frage, woher das unterschiedliche Verhalten kommt. Ist das von der Parametrierung abhängig? Oder gibt es verschiedene Melder mit verschiedenem Verhalten auf dem Markt? Oder gibt es verschiedene Applikationsversionen?

Ich habe noch ein Ausschnitt der relevanten GA-KO-Zuordnungen als screenshot beigefügt.
SteinelLichtausgang.PNG
Gruß, Waldemar

[evolution]

Danke für die Infos, Waldemar. Hier handelt es sich offensichtlich um ein anderes Verhalten. Und das sollte so nicht sein. Kannst Du mir bitte die Daten aus der SmartRemote App -> Reiter "Info" und die von Dir verwendete Produktdatenbank mit Programmversion und Fingerprint zusenden?

[evolution]

Die Lampe wurde somit nach der Nachlaufzeit ausgeschaltet und die Sperre zurückgenommen (oben hatte ich gegenteiliges geschrieben, aber da ich nicht in dem Raum war - ich wollte ja den Präsenzmelder nicht beeinflussen - hatte ich den Sonnenschein aus dem Wohnzimmer als "Lampe immer noch an" interpretiert).

Passt.

[mumpf]

Hallo Frank,

hier die Infos:
Aus der Steinel-App: Produkt True Presence KNX (7079), Firmware Version 1.0
Aus der ETS: Applikation TruePresence V1.0, Gerätetyp $7079

Danke für Deine Geduld!

Warum crewo da eine zusätzliches EIN auf dem Schaltausgang bekommt und kein EIN auf dem Sperrstatus, kann ich derzeit nicht sagen. Bei mir ist es umgekehrt: Der Sperrstatus "EIN" wird jedesmal gesendet, wenn auf dem Schaltausgang ein Telegramm empfangen wird. Stört mich aber nicht.

Ich möchte noch kurz motivieren, warum mich die Sperre stört. Es geht hierbei nicht um den Einschalt-Fall, da wird ja nach der Nachlaufzeit passend ausgeschaltet, wenn keiner im Raum ist, das klappt auch über KO 9. Relevanter ist hier der Ausschalt-Fall:

Wenn durch irgendeine Automatik (also nicht vom Benutzer über eine Taste) das Licht ungewollt ausgeschaltet wird, dann kann man bei Meldern, die einen Statuseingang ohne Sperre haben, das Licht durch "Winken" wieder einschalten. Mit der Sperre geht das nicht, da die Sperre so lange erhalten bleibt, wie der PM Präsenz erkennt. Und in diesem Fall ist der Riesenvorteil vom TruePresence ein Nachteil: Der Erkennt die Präsenz auch wenn man ganz still während der Nachlaufzeit sitzt/liegt. Und wenn Du jetzt sagst, dass man dann eben die Automatikfunktion korrigieren muss, dass diese nicht das Licht ausschalten, dann gebe ich Dir natürlich recht - nur ist der Alltag nicht in allen Facetten in Regeln zu gießen - sh*t happens...

Durch meine vielen Versuche sehe ich jetzt aber einen Weg, wie ich mein gewünschtes Ausschaltverhalten bei Automatikfunktionen hin bekomme:

• Manuelle und automatische Schaltfunktionen (nicht der Aktorstatus) gehen an "Eingang schalten"
• Die automatischen Schaltfunktionen triggern ein Treppenlicht, dass die Sperre nach kurzer Zeit (1-3 Sekunden) zurücksetzt.
• Falls ich die Sperre noch für was anderes brauche, dann wird das Treppenlicht nur getriggert, wenn der Sperrstatus FALSE ist.

Damit kann ich mit einem Treppenlicht und einem zusätzlichen UND mein Problem lösen.

Exun: Wenn es Dir nur um das Ausschalten nach einem externen Einschalten geht, dann kannst Du das Problem auch mit nur einem Kanal lösen: Du musst vor den "Eingang Schalten" einen Filter setzen, der nur das AN-Signal durchlässt, dann hast Du das, was Du möchtest (ohne die aufwändige Parametrierung des 2. Kanals).

Gruß, Waldemar

[evolution]

Danke Waldemar für den Input. Ich gebe es weiter. Unsere Idealvorstellungen liegen hier imo recht nah beisammen.

[mumpf]

Unsere Idealvorstellungen liegen hier imo recht nah beisammen.

Das denke ich auch. Wenn der Schaltausgang mit hörenden Adressen ohne Sperre funktionieren würde, wäre es das, was man (ich) haben will.

Gruß, Waldemar

[crewo]

Ich schau später mal, aber ich bin mir sicher, dass der zusätzliche "EIN" ohne weitere Kommunikation anderer Bus-Teilnehmer direkt vom Steinel selbst kommt.

[crewo]

Ich habe das eben nicht mehr nachstellen können, dass das "Ein" doppelt kommt - somit Entwarnung. Auch wird keine Sperre gesetzt wenn per KO der Status geliefert wird auf das KO1, das war aber bei mir sowieso noch nie der Fall. Ich habe aber vor dem Test dank der neuen Tabelle von Frank für die Sensoreinstellung die Applikation neu übertragen - evtl. war das eine Art Selbstheilung...

[Beleuchtfix]

Nochmals zurück zur Reichweite, da er technisch bedingt keine Richtung sondern nur Entfernung auswerten kann, muss die Reichweite also eine Halbkugel um den Melder herum sein. Wenn als Entfernung der Wert am Boden angenommen wird, dann müsste bei z.B. 2,5 m Höhe und 2,5 m Bodenreichweite der Erfassungsbereich ca 3,53 m sein (Durchmesser der Halbkugel). Eine stehende Person würde also deutlich weiter entfernt erkannt werden. Hier könnte man jedenfalls beschreiben, wie die Auswertung genau stattfindet.
Gruß Florian
übrigens, die Tabelle zur Auswertung erklärt einiges und erklärt manche Eigenheiten. Irgendwie denkt man immer, das z.B. 7 empfindlicher ist als 6, was so nicht stimmt.

[Delta6400]

Auf das ich vielleicht gelyncht werde
Ich hab das jetzt so verstanden, dass man mit der Reichweite den Radius um den Melder meint.
Also auf dem Boden eine Kreisfläche die als Radius die Reichweite besitzt.
Und das das Volumen (der Bereich den der Sensor dann abdeckt) ein Kegel ist und keine Halbkugel.