KNX/EIB - √ - PM unzuverlässig, WAF gefährdet!

[Chris M.]

Ganz im Sinne der Automatisierung habe ich ausreichend PMs verbaut, und in Räumen wie der Diele auch auf "Angst-Schalter" verzichtet.

Nun ist es aber so, dass der PM in der Diele zu ca. 90% richtig funktioniert - aber halt in 10% der Fälle nicht oder deutlich verzögert reagiert. Reproduzierbar ist leider nichts, auch Bewegungsmuster die immer perfekt funktionieren, mögen manchmal gar nicht. Der anfangs zumindest skeptische WAF ist inzwischen stark am Sinken (meine Ausrede, dass die einfach noch nicht "richtig abgestimmt" sind, werde ich wohl nicht mehr lange aufrecht erhalten können...)

Technischer Hintergrund:
PM ist der Merten Argus Präsenzmelder 6308xx, der über das ABB DALI-GW in die Decke eingebaute (d.h. für den PM vermutlich unsichtbare) Spots mit Soft-Start und Soft-Stop ansteuert, d.h. ich verwende zur Zeit nur Ein/Aus, kein Dimmen oder gar Konstantlichtregelung.

Bisher hatte ich brav auf das Rückmeldeobjekt/Sicherheitspause das Schalten/Status des entsprechenden DALI-Kanals gelegt. Ist das richtig?
Ein Test mit entfernter Rückmeldung sah anfangs vielversprechend aus, hatte jetzt aber wieder den Fall, dass eine Präsenz nicht gemeldet wurde Wenigstens schaltet sich das Licht (wg. optischer Rückkopplung) zumindest nicht wieder von selbst ein.

Gibt es bekannte Fallen, die ich noch umschiffen müsste? Sagt die Glaskugel, was falsch läuft? Mit welchen Infos würde die Glaskugel etwas klarer erscheinen?

[MarkusS]

Was sagt denn der Busmonitor? Liegt der Fehler am PM oder weiter hinten (DALI, ...)?

[Chris M.]

Da der Busmonitor schweigt, liegt der Fehler am PM.

Der PM ist auch so parametriert, dass auf einem Kanal eine Überwachung läuft (d.h. unabhängig von allem werden alle 60s je nach Erfassung 0 oder 1 gesendet) und auf dem anderen im Normalbetrieb das Licht-Schalten. Beide Kanäle reagieren aber nicht...

[makki]

Sehr komisch..
Ich kenne das mit 15 Merten PM in 2J gefühlte 1-2x und das nur aus zwei Gründen, die bei dir nicht zutreffen dürften:
- HS lahmt
- uralter PM und falsche Appl

Was noch einfällt:
- Helligkeitsschwelle evtl. zu hoch; mal im Melderbetrieb testen.
- Telegrammratenbegrenzung (weiss grad nicht ob vorh.)
- Zonen-Schnickschnack erstmal lassen, die Appl ist sehr mächtig, teilw. wirds dadurch aber auch unübersichtlich und der PM tut evtl. nicht mehr das was man wollte..

Makki

[Chris M.]

Sehr komisch..
Ich kenne das mit 15 Merten PM in 2J gefühlte 1-2x und das nur aus zwei Gründen, die bei dir nicht zutreffen dürften:

Schon mal gut zu wissen, dass es kein prinzipielles Problem ist

- HS lahmt
- uralter PM und falsche Appl

Da die alle direkt schalten ist ein lahmender HS (ok, hab ich nicht, und das WireGate darf nicht lahmen ) auszuschließen. Und die PMs sind auch hoffentlich nicht uralt (hoffe ich mal, das der Großhändler meinem Elektriker nicht so etwas angedreht hat...)

- Helligkeitsschwelle evtl. zu hoch; mal im Melderbetrieb testen.
- Telegrammratenbegrenzung (weiss grad nicht ob vorh.)

Helligkeitsschwelle sollte gar nicht aktiv sein. Telegrammratenbegrenzung (keine Ahnung ob aktiv oder gar vorhanden, kann gerade nicht nachsehen...) kann eigentlich auch nicht zuschlagen, zu den fraglichen Zeiten schickt der keine bis kaum Telegramme...

- Zonen-Schnickschnack erstmal lassen, die Appl ist sehr mächtig, teilw. wirds dadurch aber auch unübersichtlich und der PM tut evtl. nicht mehr das was man wollte..

OK, könnte ich mal ausprobieren. Wobei ich Zonen bisher kaum einsetze, nur Kanäle - und da gehe ich momentan davon aus, dass die einfach getrennt sind. Meine Vorstellung ist, dass der erste Kanal auf allen Sektoren einfach Überwachung macht (Alarmanlage, Logik, keine Ahnung was, ...). Der zweite Kanal sorgt (auch bei allen Sektoren aktiv) für's Licht schalten. Die Auswertung von Zonen/Sektoren hätte ich auf die weiteren Kanäle gelegt (z.B. Treppenlicht bei genau der passenden Zone des Dielen-PMs...)

Könnte das Verhalten durch ein "Blenden" durch die Fußbodenheizung hervorgerufen sein? Die hat in den entsprechenden Räumen ca. 24°C (mit Schwankung um ca. 1 K)

[makki]

Ich hatte mich selbst anfangs mit den Zonen/Kanälen teils "intuitiv" verhaspelt, daher der Hinweis..
FBH würde ich ausschliessen, ich hab hier zwei Stück auf 30° Aquarien gucken (das ist ein Problem, aber auch lösbar) und die Melden/Schalten trotzdem.
Aber Du hast ja ein Bus-Log, wenn das letzte (lange) vor dem gewollten und nicht erfolgten schalten eine 1 war: Empfindlichkeit runterdrehen..

Einzig mit zweien (auch uralt!) habe ich bei starkem Sonneneintrag auf den Boden das Problem, die werden aber einfach nicht für Meldezwecke genutzt und dann ist es so hell, das man sicher kein Licht braucht

Makki

P.S.: Auch wenn ich kein 100%-Anhänger der reinen, dezentralen Lehre bin: Direkt schalten ist da IMHO das richtige, ich sende bei den meisten auch nur vom HS einen geringeren Dimmwert (Nachtlicht) "hinterher", bei ausreichender Dimmzeit perfekt&failsafe..
Ich merks nur trotzdem, wenn der HS das Multiroom manchmal (selten!) nicht einschaltet, das ist aber definitiv ein "hausgemachtes" Problem

[Chris M.]

Bisschen besser ist's mit dem Basis-Setup. Aber: gerade im Flur ist's immer noch nicht optimal:

Am schlimmsten ist der Übergang Wohnzimmer-Flur (die Tür ist genau 3m vom PM entfernt, der Weg geht leider genau drauf zu). Hier ist das Licht oft erst an, wenn man schon umter'm PM steht...
Beim Test mit Winken habe ich gemerkt, dass dabei das Hauptproblem eher ein verzögertes Ansprechen als eine zu schlechte Empfindlichkeit ist.

Gibt es da bekannte Tricks den PM etwas schneller ansprechend zu machen? (Z.B. bei Reduzierung der Reichweite, oder der Empfindlichkeit)

Und da ich vom Basis-Setup in Zukunft wieder etwas weg will: ist bekannt ob diese PMs intern eine Telegrammraten-Begrenzung o.ä. haben, die stören könnte, wenn ich parallel zur Lichtsteuerung einen Überwachungsblock aktiviere der je nach Anwesendheit jede Minute eine 1 bzw. 0 schreibt?

(Und da wir hier schon quasi beim Thema sind, wie Löst ihr dieses Thema: gegeben 1x BMW der nur eine GA schreiben kann, so wie zu schaltendes Licht und Anwesendheitüberwachung. Wie heißt dann die beschriebene GA? "Bewegung" und das Licht liegt da auch drauf, oder "Licht An/Aus" und die Anwesendheitüberwachung hört da mit?)

[ThorstenGehrig]

Und da ich vom Basis-Setup in Zukunft wieder etwas weg will: ist bekannt ob diese PMs intern eine Telegrammraten-Begrenzung o.ä. haben, die stören könnte, wenn ich parallel zur Lichtsteuerung einen Überwachungsblock aktiviere der je nach Anwesendheit jede Minute eine 1 bzw. 0 schreibt?

So ganz habe ich nicht verstanden was du mit Überwachungsblock meinst.
Was ein Thema sein könnte: ein PM hat eine Sperrzeit nachdem er das Licht ausgeschaltet hat, bevor er wieder einschaltet (damit er nicht die ausgehenden Leuchtmittel als Bewegung wahrnimmt). Die kann man wahrscheinlich parametrisieren.
Ich habe Gira-PMs die 2 Ausgänge haben - einen verwende ich als helligkeitsabhängigen Lichtschalter - den anderen als unabhängigen Bewegungserkenner....

Gruß
Thorsten

[Chris M.]

So ganz habe ich nicht verstanden was du mit Überwachungsblock meinst.
[...]
Ich habe Gira-PMs die 2 Ausgänge haben

Ich meine genau das. Die Merten Argus 6308 haben die Möglichkeit 5 Blöcke und in jedem der Blöcke 4 Ausgangsobjekte zu beschreiben (d.h. in Summe max. 20 GAs "gleichzeitig"). Das zusammen mit den 4 Zonen, die getrennt ausgewertet werden können, ist das ein wunderbar mächtiges Teil...

[rb84]

Könnte das Verhalten durch ein "Blenden" durch die Fußbodenheizung hervorgerufen sein? Die hat in den entsprechenden Räumen ca. 24°C (mit Schwankung um ca. 1 K)

Aus einem anderen Projekt mit Infrarotsensoren: JA das kann durchaus sein!

Die Elektronik ist meistens so aufgebaut bzw. programmiert, dass er einen gewissen Schwellenwert zum Auslösen braucht um False Positive zu vermeiden. Durch Störeinflüsse kann das massiv eingeschränkt werden. Dein Körper hat dann keine saubere Kante mehr.
Er braucht im Endeffekt länger um "sich sicher zu sein"...

[makki]

ich hab jetzt nochmal nachgeschaut, es gibt nur "zeit zwischen telegrammen" pro Kanal in der Appl, das da vielleicht was falsches drinsteht.. Kann ja aber auch nicht sein, meine senden auch zyklisch das bewegungsobjekt..

Kann mir das, wenn alle Parameter stimmen, ansonsten nicht vorstellen, ich hab im Keller auch einen auf den man gerade 4m zuläuft und der hupft schon wenn ich um die Ecke biege
Vielleicht hat das Ding im Flur auch nen Hau ?
(ich habe eher das umgekehrte Problem, hab die empfindlichkeit teilw drastisch runterdrehen müssen und einen auch einfach abgeklebt)

Makki

P.S.: @chris BWM ausnahmsweise nicht BMW

[SebastianFey]

evlt ist das teil auch einfach defekt?
oder verschmutzt. hatte mal nen fussel vor/im dem detektor (im gehäuse), das hat auch zu lustigen effekten geführt

[Micha]

der Weg geht leider genau drauf zu)

IF-Melder sind wie ein Insektenauge aufgebaut, sehr viele kleine Linsen, die in unterschiedliche Richtungen "schauen". Gemeldet wird das Verlassen einer Linse und das Ansprechen einer benachbarten Linse. Wenn Du genau darauf zugehst, kann es sein, dass Du die eine Linse erst spät verläßt und ebenso erfolgt das BUS-Telegramm.

Versuch mal schräg zu laufen, dh. Du schneidest mehr Linsengebiete. Geht es dann eher?

Gruß Micha

[Chris M.]

Leider bin ich mit den PMs noch nicht wirklich weiter gekommen. Da fast alle PMs bei mir betroffen sind, möchte ich gerne ausschließen, dass der Fehler hier vor der Tastatur sitzt...

Unten ist das Beispiel des Wohnzimmer-PMs. Ziel ist, zum einen einen regelmäßigen Status zu bekommen, ob jemand da ist (GA 6/0/50), z.B. zur Überwachung. Zum anderen möchte ich über GA 1/0/69 die Visu an und aus schalten, d.h. eine klassische Licht-An/Aus-Anwendung.

Parametriert ist der wie in den Bildern erkennbar. Ein Ausschnitt des Logs aller Pakete von der PA 1.1.55 (d.h. dem PM) ist:

2011-05-01 11:08:59.203,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:09:59.128,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:10:59.546,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:11:59.635,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:12:58.870,A_GroupValue_Write,1.1.55,4/1/50,25 7E,224.96,DPT_Value_Lux,9.004,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:12:59.323,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:13:58.942,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:14:58.892,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:15:59.434,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:16:58.801,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:17:57.903,A_GroupValue_Write,1.1.55,4/1/50,25 D6,239.04,DPT_Value_Lux,9.004,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:17:58.781,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:18:58.701,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:19:58.692,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:20:58.630,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:21:58.605,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:22:57.658,A_GroupValue_Write,1.1.55,4/1/50,25 EF,243.04,DPT_Value_Lux,9.004,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:22:58.558,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:23:58.500,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:24:58.469,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:25:05.390,A_GroupValue_Write,1.1.55,6/0/50,01,1,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:26:58.383,A_GroupValue_Write,1.1.55,6/0/50,01,1,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:27:11.762,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:27:57.427,A_GroupValue_Write,1.1.55,4/1/50,26 C9,277.92,DPT_Value_Lux,9.004,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:28:58.285,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:29:58.238,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:30:58.202,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:30:59.586,A_GroupValue_Write,1.1.55,6/0/50,01,1,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:31:59.680,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:32:57.216,A_GroupValue_Write,1.1.55,4/1/50,25 40,215.04,DPT_Value_Lux,9.004,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:33:58.715,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:34:38.303,A_GroupValue_Write,1.1.55,6/0/50,01,1,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:35:58.249,A_GroupValue_Write,1.1.55,6/0/50,01,1,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:36:31.159,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:37:56.991,A_GroupValue_Write,1.1.55,4/1/50,24 8A,185.92,DPT_Value_Lux,9.004,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:37:58.183,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:38:57.953,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:39:57.914,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:40:57.869,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:41:57.830,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:42:56.783,A_GroupValue_Write,1.1.55,4/1/50,25 97,228.96,DPT_Value_Lux,9.004,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:42:57.800,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:43:57.742,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:44:57.683,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:45:57.668,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:46:20.939,A_GroupValue_Write,1.1.55,6/0/50,01,1,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:47:19.882,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:47:25.446,A_GroupValue_Write,1.1.55,6/0/50,01,1,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:47:56.573,A_GroupValue_Write,1.1.55,4/1/50,25 07,205.92,DPT_Value_Lux,9.004,0,low,5,T_DATA_XXX_REQ,0
2011-05-01 11:48:24.557,A_GroupValue_Write,1.1.55,6/0/50,00,0,DPT_Switch,1.001,0,low,5,T_DATA_XXX_REQ,0

Wie man sehen kann, an die GA 1/0/69 wird kein Paket gesendet!
(Und die andere GA ist auch nicht 100% richtig, wird aber zumindest gesendet)

Was mache ich hier falsch? Oder ist das doch eher ein HW Defekt?

[makki]

evtl. mal irgendwann aus versehen an den Flags des KO gedreht?
Mit der lernbaren Treppenlichtzeit hatte ich irgendwann verzweifelt aufgegeben, das machte irgendwie nie das was ich mochte.. Stell die doch mal testweise fix ein.

Makki