Steinel True Presence – Präsenzmelder

[gbglace]

Ja der BWM 55 passt so nicht an die Wand der sieht ja die Ecke im Wozi nicht mehr wo man am Rand vom TP ist. Dann mittiger den BJ mit den Zonen, da dann aber auch nicht den Mini auch wenn das dann schon nen größere Box an der Decke ist. Aber das relativiert sich, wenn man nicht auch alles in einem Lochraster in der Lichtgestaltung geplant hat.

[livingpure]

Gefühlt ist das für eine sichere True Presence Erkennung auf den Sofa zu weit weg.

Dann sind die Steinel Angaben also auch in Bezug auf die Reichweite viel zu optimistisch?

Danke für die Anregungen!


Küche sehe ich den TP nicht nötig, da ist doch mit dem BJ (nicht Mini) genug Bewegung.
Wäre es dann nicht ein Kompromiss nur den BJ + TP über der Couch zu verbauen, u.U. reicht der BJ für den Esstisch und wenn nicht, dann ergänze ich da später den TP?
Ich sehe es zwar auch so, dass man Installationen an der Decke nur wenig wahrnimmt, schön finde ich es trotzdem, wenn da möglichst wenig ist.
Spotraster gibt es keines, die Spots (roten Kreise) im Plan sind auch nicht mehr aktuell, so viele werden es nicht.

Den 55 BWM könnte ich prinzipiell vorsehen, da ist mir der BJ Mini P an der Decke aber lieber, da der an der Decke weniger auffällt als an der Wand. Eine Option wäre noch den sehr tief, auf Steckdosenhöhe, zu verbauen. Da fällt er nicht auf, allerdings ist das eine der wenigen Stellen, an der die KNX Leitung nicht direkt greifbar ist und wenn da eine Ablage (im Plan oberhalb) steht, dann schaut der BWM nicht in den Bereich weiter oben. Der BJ Mini hat sicher die bessere Erkennung.

Also den großen BJ unten an der Küche sehe ich sinnvoll, für mich ist die Frage nur noch, ob die TP Dose da daneben oder über die Couch kommt. Nach euren Erfahrungen wohl besser über die Couch.

[willisurf]

Wir sind froh den TP am Esstisch zu haben. Aber wenn Du ihn einfach nachrüsten kannst, warum nicht.

[livingpure]

Ja, Leitung liegt dort, wäre nur eine Bohrung und dann kann er montiert werden. Wie unwahrscheinlich ist denn, dass er in der mittigen Position nicht Couch und Esstisch erfasst? Wenn das halbwegs realistisch ist, dann könnte ich mir die Dosenbohrungen jetzt sparen und den mal nur testweise montieren. Wenn es so gut wie ausgeschlossen ist, wäre es deutlich leichter die Dose über der Couch direkt jetzt zu setzen.

[willisurf]

Ich halte es für deutlich unwahrscheinlich, das die Erkennungsleistung für wirklich ruhende Personen von der mittigen Position klappt.
Außerdem hättest Du dann kaum noch Spielraum in der Empfindlichkeitseinstellung.

[H3rbst]

Also wir haben es hier ziemlich genauso, auch vom Grundriss. TP über der Couch und dann BJ Premium zum schönen Trennen der Zonen. Haben aber kein TP über dem Esstisch wie hier vorgeschlagen und vermissen ihn definitiv. Eine Leitung in der Decke haben wir vorgesehen und wir kommen mit der Szene Essen gut klar, aber nochmal besser wäre es sicher mit einem TP

[Darrol]

Hallo allerseits,

mir ist in den letzten Monaten bzgl. der Ausfälle der TP-Sensoren eine These in den Sinn gekommen, die das Problem evtl. reproduzierbar machen könnte.

Zunächst mal zu meinem Setup und meinen Beobachtungen:
Ich habe 5 TP-Multisensoren und einen normalen TP-Sensor im Einsatz
Davon befinden sich 3 im EG und fallen deutlich häufiger aus als die 3 Geräte im OG.
Im EG werden die Fenster mit Raffstoren verschattet im OG haben wir Rollos im Einsatz.

In den letzten Wochen haben sie die Ausfälle wieder auffällig gehäuft nachdem alle Sensoren eigentlich die meiste Zeit des letzten Jahres stabil gearbeitet haben.
Was in den letzten Wochen anders war, war dass es relativ windiges bis stürmisches Wetter gab. Das hat bei geschlossener Verschattung oft wackelnde/zappelnde Raffstoren mit sich gebracht, die ja dafinitiv auch im physikalischen Erfassungsbereich der Sensoren liegen.

Nun zu meiner These: Die Firmware nimmt alle Bewegungen innerhalb des physikalischen Erfassungsbereiches auf und errechnet ob die Bewegung innerhalb des softwaredefinierten Bereiches liegt und meldet dementsprechend Präsenz oder eben nicht.
Wenn nun diese Operation aufgrund eines Singaldauerfeuers von zappelnden Raffstoren in einer Dauerschleife läuft, kommt es irgendwann zu einem Speicherüberlauf und damit dem Absturz des Geräts.

Was denkt ihr, ist davon zu halten?

[gbglace]

Raffstoren mit sich gebracht, die ja dafinitiv auch im physikalischen Erfassungsbereich der Sensoren liegen.

Was sich aber doch durch Reichweiteneinstellung verhindern lassen sollte.

[willisurf]

Wenn nun diese Operation aufgrund eines Singaldauerfeuers von zappelnden Raffstoren in einer Dauerschleife läuft, kommt es irgendwann zu einem Speicherüberlauf und damit dem Absturz des Geräts.

Was denkt ihr, ist davon zu halten?

Ist meines Erachtens durchaus eine valide These. Memory Leak oder Overflow ist immer einen Bug wert.
Würde auch damit zusammenpassen, das Steinel in den letzten Softwareversionen vermehrt an solchen Algorithmen (tracking, fast mode,…) gearbeitet hat und die Software damit tendenziell instabiler geworden ist. Da ist offensichtlich ein grundlegender Bug oder eine Konzeptschwäche in der Software die immer noch nicht behoben ist.

[jcd]

Bei unseren (klappernden) Alu-Rollläden habe ich auch einen Einfluss auf das Erfassungsverhalten des TP festgestellt. Am schlimmsten ist, wenn ein Watchdog-Reset stattfindet während die Rollläden unten sind und im Wind klappern. Dann ist im Nachgang die Empfindlichkeit extrem reduziert.

Reichweite reduzieren ist bei uns nicht möglich. Der TP hängt mittig, sodass eine Reduktion der Reichweite die Tür aus dem Erfassungsbereich nimmt. Ich teste derzeit aber Bürstendichtungen um das Klappern der Rollläden zu beseitigen. Seit Montage ersten Testmustern gibts bei uns jetzt jedoch keinen Wind mehr.^^

Der Theorie des Speicherüberlaufs war ich zu zunächst abgeneigt, aber jetzt muss auch sagen, dass ich einen Zusammenhang zwischen „Detektionsaktivität“ und Ausfallhäufigkeit/Reset für Möglich halte.

[willisurf]

„Reichweite reduzieren ist bei uns nicht möglich. Der TP hängt mittig, sodass eine Reduktion der Reichweite die Tür aus dem Erfassungsbereich nimmt. Ich teste derzeit aber Bürstendichtungen um das Klappern der Rollläden zu beseitigen“

livingpure das ist u.a. der Grund für eine kleinteilige (und möglichst quadratische) Aufteilung der TPs (und natürlich die Kombination mit PIRs, aber das hast Du ja).

[f10]

Hallo,

also die Theorie mit Raffstoren hatte ich auch scho. Bei mir sind die "schlechten" TPs auch in Reichweite eines Raffstores. Die Reichweite lässte sich dort aber ebenfalls schlecht reduzieren, ohne die Erkennung am Randbereich nicht zu beeinflussen.
Evtl. könnte die SW aber die typischen Klapperfrequenzen ausfiltern.


Gruß, Florian

[Marino]

Ich habe mich heute mal wieder gefragt, warum ich so lange im dunkeln stand, bevor das Licht angeschaltet worden ist.

Habs auch rausgefunden... da hilft das beste Logikmodul nichts. Ich nutzte momentan einen VPM mit meinen Steinel. Daran angebunden sind KO 80 & 81 für Presence und TruePresence. Eigentlich toll. Wäre da nicht manchmal das lange warten, bis das Licht angeht.

Ich nutze die "normale" Präsenz einfach, um meine Taster zu wecken bei Präsenz.

Als ich vorhin suchte, viel mir auf, dass der Präsenzausgang 69 schon schaltete, also auch Licht anschalten würde, das erste Signal bei 80/81, aber erst 7s später auf true gesetzt wurde.

Während also der Tastsensor schon lange leuchtete, musste das Licht noch 7s warten, bis es geschaltet wurde, da erst dann TruePresence gesendet. Beim Betreten der Küche hätte ich natürlich Presence erwartet, aber das wurde anscheinend verschluckt und da ich mich wenig bewegte, kam dann als nächstes TruePresence.

Also:
17:52:10 - Küche betreten und sofort KO 69=1 (weckte Tastsensor)
17:52:17 - KO 81=1 (TruePresence) und der VPM schaltete sofort die Lichtszene
17:52:19 - KO 80=1 (Presence), KO 81=0 (TruePresence)... usw.

Da nutzt man extra die "nativen" Ausgaben, damit man direkt Presence und TruePresence abgreifen kann und der VPM dann schalten kann und dann schickt der Steinel da erstmal 7s nichts drauf, obwohl er eine Bewegung erkannt hat und mit seiner eigenen Logik das Licht geschaltet hätte.

Vielleicht hilft es ja jemandem. Zum triggern KO 69 abgreifen ist halt schwierig, da der ja auch mal an bleiben kann, wie ich aus der Vergangenheit weiß. Maximal steigende Flanke und nur als Impuls, ohne Betrachtung des Zustandes. Das stört beim Tastsensor nicht, grätscht dann aber ja bei Lichtsteuerung wieder mit rein
So etwas nervt echt.

Mir ist in einigen Zimmern nämlich schon aufgefallen, dass das Licht immer öfter 6-8s braucht, bis es geschaltet wird. Immer, wenn ich schnell die Visu öffne, geht es an, wenn ich gerade den Status sehe.


Viele Grüße
Nils

[gbglace]

da erst dann TruePresence gesendet.

Das ist aber gut so und gewollt und per Design.

[willisurf]

Zum triggern KO 69 abgreifen ist halt schwierig

Die Erfahrung habe ich nicht. Wie Göran sagt, die beiden Rohausgänge sind nett, aber es ist für eine einwandfreie Funktion notwendig das KO69 für die Präsenz mit zu benutzen. Bei mir bleibt es zwar auch mal etwas länger an, aber das bewegt sich im Bereich <2min. Aber natürlich kannst Du mit der Logik auch die Flanke ausfiltern und diese dann auf das ODER geben.
Ich verODERe das KO69 direkt mit KO81 für Präsenz, im VPM ganz normal schaltend