Bewegungsmelder schaltet Funksteckdose - Schaltverzögerung

[Wetterhexe]

Hallo allerseits,

bin gerade dabei mit FHEM ins Abenteuer smarthome zu starten. Einiges meiner vorhandenen Gerätschaften läuft schon sehr zufriedenstellend (Harmony FB, Oregon WMR200, Kameras, Satreceiver).

Aktuell möchte ich einen Bewegungsmelder dazu bringen eine Funksteckdose mit Stehleuchte zu schalten. Grundsätzlich funktioniert das auch, allerdings ist das schalten der Dose nach Bewegungsalarm um ziemlich genau 2 Sekunden verzögert. Hört sich nicht viel an, wenn man aber drauf wartet daß beim Betreten eines Raums 2 Sekunden vergehen bis das Licht angeht kann das schon nerven

Meine bisherigen debug Versuche:

• Taster in fhem gebaut und damit geschaltet: geht nahezu verzögerungslos (< 0.5 sec.)
• apptime aktiviert, keine nennenswerten Verzögerungen erkennbar
• im rfxtrx log sieht man um 10:10:15 die drei transmits (da repeat=3, war vorher auf 0, ändert aber nichts). Um 10:10:17 machts dann "klack" in der Dose und es wird hell

Mein environment:

• fhem auf einem debian/core2duo Rechner
• Rfxtrx433E USB, Protokolle nur Oregon und ByronSX aktiviert
• Funksteckdosen: Brennenstuhl RCS-1000N (=ELRO AB440D)
• Bewegungsmelder: 1byone (von autocreate als TRX_SELECTPLUS erkannt)

log Auszug:

Code Auswählen Erweitern


2017.01.04 10:10:15 5: TRX/RAW: /^G^V^B
2017.01.04 10:10:15 5: TRX: TRX_Read '071602'
2017.01.04 10:10:15 5: TRX_Read END
2017.01.04 10:10:15 5: TRX/RAW: ^G^V^B/¼^@£
2017.01.04 10:10:15 5: TRX: TRX_Read '071602bc00a3'
2017.01.04 10:10:15 5: TRX_Read END
2017.01.04 10:10:15 5: TRX/RAW: ^G^V^B¼^@£/^Q`
2017.01.04 10:10:15 5: TRX: TRX_Read '071602bc00a31160'
2017.01.04 10:10:15 5: TRX_Read rmsg '071602bc00a31160'
2017.01.04 10:10:15 5: TRX_Read TRX_data '071602bc00a31160'
2017.01.04 10:10:15 5: TRX_Parse() '071602bc00a31160'
2017.01.04 10:10:15 5: RFXTRX: dispatch 071602bc00a31160
2017.01.04 10:10:15 5: TRX_LIGHT_Parse() decoding delay=18 hex=071602bc00a31160
2017.01.04 10:10:15 5: TRX_LIGHT_Parse() X10 num_bytes=7 hex=071602bc00a31160
2017.01.04 10:10:15 5: TRX_LIGHT: device_name=TRX_SELECTPLUS_00 data=00
2017.01.04 10:10:15 5: RFXTRX sending 071002004c030100
2017.01.04 10:10:15 5: SW: 071002004c030100
2017.01.04 10:10:15 5: RFXTRX sending 071002004c030100
2017.01.04 10:10:15 5: SW: 071002004c030100
2017.01.04 10:10:15 5: RFXTRX sending 071002004c030100
2017.01.04 10:10:15 5: SW: 071002004c030100
2017.01.04 10:10:15 5: TRX_Read END

2017.01.04 10:10:17 5: TRX/RAW: /^D^B^A
2017.01.04 10:10:17 5: TRX: TRX_Read '040201'
2017.01.04 10:10:17 5: TRX_Read END
2017.01.04 10:10:17 5: TRX/RAW: ^D^B^A/^@^@
2017.01.04 10:10:17 5: TRX: TRX_Read '0402010000'
2017.01.04 10:10:17 5: TRX_Read rmsg '0402010000'
2017.01.04 10:10:17 5: TRX_Read TRX_data '0402010000'
2017.01.04 10:10:17 5: TRX_Parse() '0402010000'
2017.01.04 10:10:17 5: RFXTRX: dispatch 0402010000
2017.01.04 10:10:17 5: TRX_ELSE_Parse() decoding delay=10 hex=0402010000
2017.01.04 10:10:17 5: TRX_ELSE_Parse() 2 hex=0402010000
2017.01.04 10:10:17 5: TRX_ELSE_Parse() num_bytes=4 hex=0402010000 type=2
2017.01.04 10:10:17 5: TRX_Read END
2017.01.04 10:10:17 5: TRX/RAW: /^D^B^A^@
2017.01.04 10:10:17 5: TRX: TRX_Read '04020100'
2017.01.04 10:10:17 5: TRX_Read END
2017.01.04 10:10:17 5: TRX/RAW: ^D^B^A^@/^@
2017.01.04 10:10:17 5: TRX: TRX_Read '0402010000'
2017.01.04 10:10:17 5: TRX_Read rmsg '0402010000'
2017.01.04 10:10:17 5: TRX_Read TRX_data '0402010000'
2017.01.04 10:10:17 5: TRX_Parse() '0402010000' dup
2017.01.04 10:10:17 5: TRX_Read END
2017.01.04 10:10:17 5: TRX/RAW: /^D^B^A
2017.01.04 10:10:17 5: TRX: TRX_Read '040201'
2017.01.04 10:10:17 5: TRX_Read END
2017.01.04 10:10:17 5: TRX/RAW: ^D^B^A/^@^@
2017.01.04 10:10:17 5: TRX: TRX_Read '0402010000'
2017.01.04 10:10:17 5: TRX_Read rmsg '0402010000'
2017.01.04 10:10:17 5: TRX_Read TRX_data '0402010000'
2017.01.04 10:10:17 5: TRX_Parse() '0402010000' dup
2017.01.04 10:10:17 5: TRX_Read END


Ich bin im Moment etwas ideenlos wo ich noch ansetzen könnte. Das Verhalten ist 100% reproduzierbar, somit würde ich fremdes "Funkfeuer" mal ausschließen. Ist natürlich nicht undenkbar daß der Bewegungsmelder eines erzeugt sobald er auslöst, und der rfxtrx deshalb solange schweigt. Hat jemand von Euch einen Ansatz wo ich noch suchen könnte? Oder soll ich die Bewegungsmelder einfach schrotten und was "gscheites" kaufen?

Bin für jeden Hinweis dankbar
LG aus Wien, die Wetterhexe

[KölnSolar]

Du hast die beiden devices aber doch nicht direkt gekoppelt, oder ? schau Dir das Ganze mal im event-monitor an und berichte.
Grüße Markus

[Wetterhexe]

nein die sind nicht direkt gekoppelt. Im event-monitor sieht das so aus (da läßt sich die Verzögerung nicht erkennen):

Code Auswählen Erweitern


2017-01-04 12:49:47 at Steckdose2_timer Next: 12:49:57
2017-01-04 12:49:47 Global global DEFINED Steckdose2_timer
2017-01-04 12:49:47 TRX_LIGHT Steckdose2 on
2017-01-04 12:49:47 TRX_LIGHT TRX_SELECTPLUS_00 chime: ring
2017-01-04 12:49:47 TRX_LIGHT TRX_SELECTPLUS_00 ring
2017-01-04 12:49:57 TRX_LIGHT Steckdose2 off
2017-01-04 12:49:57 Global global DELETED Steckdose2_timer


[KölnSolar]

So ganz hab ich es noch nicht verstanden. Ich sehe das define eines at, das Einschalten der Dose. Vermutlich beides aus einem Einschalten mit on-for-timer 10. Aber erst dann kommt das event des Bewegungsmelders ? Womit wurde dann das on-for-timer ausgelöst ?

Der Bewegungsmelder wird ja "nur" als Klingel(-taster) erkannt. Bewegungsmelder haben üblicherweise 2 events gegenüber nur einem eines Klingeltasters. Wird vielleicht ein event in fhem "verschluckt" ? Du könntest Dir mal das Verhalten und die events des Bewegungsmelder im rfxmgr angucken.

[Wetterhexe]

ja genau, das ist ein on-for-timer 10 (testweise). Im Echteinsatz solls mal eine Treppenhausbeleuchtung, evtl. auch Licht für die Garageneinfahrt werden.

Der on-for-timer wird durch den Bewegungsmelder ausgelöst, der liefert die events chime: ring, und ring. Warum die im log erst dahinter kommen? Keine Ahnung, find ich auch unlogisch. Aber funktionieren tuts jedenfalls soweit 

rfxmgr kann ich auf die Schnelle nicht anwerfen, der rfxtrx hängt an einem Linux Server. Oder gibts sowas ähnliches auch für Linux?

Was man im eventlog nicht sieht ist die Verzögerung bis die Dose schaltet. Um 12:49:47 wird das event ausgelöst, das deckt sich mit der Bewegung, danach ist 2 Sek. Pause und erst danach schaltet die Dose. Im log aus dem ersten post kommt das besser raus, da sieht man daß nach 2 Sekunden irgendwas(?) antwortet, zeitgleich schaltet da auch die Dose (die hat aber keine Rückmeldung )

[KölnSolar]

Oder gibts sowas ähnliches auch für Linux?

Leider nein.
Mein Gedanke war halt, dass Du das auslösende event "unterschlagen" hast und das gepostete event bereits das 2. event ist. 
Ich muss mir mal in Ruhe meine Klingel angucken. Die verzögert auch leicht  Poste doch mal Dein notify,DOIF.

[Wetterhexe]

bezüglich Linux rfxmgr bin ich fündig geworden .... falls es jemand brauchen kann, hier der Link: https://github.com/ssjoholm/rfxcmd_GC.
Werd ich mir am Abend mal genauer anschauen.

mein notify ist eher unspektakulär DOIF hab ich keins:
define n_modect1_Stehlampe notify TRX_SELECTPLUS_00:ring set Steckdose2 on-for-timer 00:00:10

Ich hab das gleiche auch in fhem mit einem Taster (dummy) gemacht:
define n_Taster_Stehlampe notify myTaster1.* set Steckdose2 on-for-timer 00:00:10

Beim "Taster" gehts ohne Verzögerung 

Vielen Dank fürs drüberschauen und mitleiden! 

[Wetterhexe]

Ich habe diesen rfxmgr für Linux zum laufen gebracht, und mir die events vom Bewegungsmelder angesehen. Es kommt meist nur ein einziges event, selten zwei.
Und so schaut der output aus:

Code Auswählen Erweitern


Received                = 07 16 02 00 00 A3 11 70
Date/Time               = 2017-01-04 18:33:36
Packet Length           = 07
Packettype              = Chime
Subtype                 = SelectPlus
Seqnbr                  = 00
ID                      = 00A3
Signal level            = 7


[KölnSolar]

Und jetzt erhoffst Du Dir eine Lösung 
Leider Fehlanzeige 

mitleiden

tu ich. Denn ich hab selber die Verzögerung. Ich seh halt nur nicht, wenn jemand den Klingeltaster drückt und sich wundert, wenn der Gong etwas später ertönt
Aber halten wir das Positive fest: Zumindest die firmware gibt nicht mehr als ein "ring(Bewegung)" her. Ein "Bewegung Ende" gibt es nicht 
Am Bewegungsmelder liegt es nicht 
Du hast mich Lügen gestraft und es gibt eine "Form" des rfxmgr, die unter Linux läuft.  Leider scheinbar nicht mehr gepflegt Ist aber trotzdem sehr aufschlussreich !!!

Ich werde  bei mir mal näher nach der Ursache der Verzögerung forschen. fhem, die 2-Stufigkeit der TRX-Module ? Ich kann auch mit einem 433CUL vergleichen. Das wird aber dauern...

Zurück zu Deiner Installation, was ist das Protokoll Deiner Dose und womit schaltest Du sie ?

[Wetterhexe]

Und jetzt erhoffst Du Dir eine Lösung 
Leider Fehlanzeige 

sagen wir mal, Jein

Ich bin lange genug in der IT um zu wissen daß es nicht für alles eine Lösung gibt. Und ich bin gerade dabei zu erforschen, was alles mit FHEM "geht", oder halt auch nicht. Das macht die Sache ja auch spannend  Eigentlich habe ich sowieso als "Hauptproduktlinie" ein Auge auf die homematic Schiene geworfen, also werde ich mir dort mal einen Aktor und motion Sensor zum spielen besorgen. Das low-cost Gedöns wird schon irgendwo anders Verwendung finden 

Die Dosen sind von Brennenstuhl (RCS 1000 N) und scheinbar baugleich mit den ELRO AB400D, somit also Lightning1 Protokoll wenn ich mich richtig erinnere.
Ein CUL868 ist schon auf dem Weg zu mir, scheint aber fast so als müßte ich auch einen 433er ordern ...

Solltest du noch etwas herausfinden würde ich mich natürlich über erhellende news freuen. In diesem Sinne, LG von der Hexe 

[RaspiCOC]

Ich habe hin und wieder nicht reproduzierbar ein ähnliches Problem, was aber in aller Regel nur am frühen Morgen auftritt. Bewegungsmelder löst aus (Bedingung Twilight: ja, es ist dunkel), dann wird eine Kaskade von Funksteckdosen geschaltet. Die schalten dann mitunter eine nach der anderen aber mit 20 Sekunden Verzögerung. Eine halbe Stunde später ist der Spuk vorbei und alles läuft reibungslos.

Das Log lieferte mir bisland auch keinerlei Erkenntnisse. Die Systemlast wir immer im unteren Bereich. Keine besondere Funklast am Morgen, also eigentlich alles wie immer.

[Wetterhexe]

Danke für die Info!

Ich habe das Problem mittlerweile gelöst, verwende einen HM Bewegungsmelder, damit ist die Verzögerung weg.

Am Bewegungsmelder liegts aber vermutlich nicht, ich tippe eher auf eine Sendeverzögerung im TRX. Ich werde das noch weiter verfolgen, der Postmann hat gerade zwei neue CULs gebracht, damit kann ich am TRX empfangen und mit dem CUL senden (oder umgekehrt) ... mal schauen ob das neue Erkenntnisse bringt 

[Wetterhexe]

Heute hatte ich mal Zeit um ein paar Tests zum Problem zu machen. An Hardware war am Start:

Bewegungsmelder:
1byOne (433), erkannt als TRX_SELECT
Intertechno PIR-1000 (433)
Homematic HM-SEC-MDIR-2 (868)

Schaltaktoren:
Brennenstuhl RCS 1000N Funksteckdosen (433)
Intertecho ITLM-1000 (433)
Homematic HM-LC-SW1-FM (868)

RF Interfaces:
CUL-433 (SlowRF)
CUL-868 (HM)
RFXtrx433E

Damit habe ich einige Tests durchgeführt:

Code Auswählen Erweitern

Sensor RF-IF Aktor RF-IF Verzögerung
===========================================================================================
1byOne TRX RCS1000 TRX 2 sec.
HM-SEC CUL-868 HM-SW1 CUL-868 keine
PIR-1000 CUL-433 HM-SW1 CUL-868 keine
PIR-1000 CUL-433 ITLM-1000 CUL-433 2 sec. (sleep!)
PIR-1000 TRX ITLM-1000 CUL-433 2 sec. (sleep!)
1byOne TRX ITLM-1000 CUL-433 2 sec. (sleep!)
1byOne TRX HM-SW1 CUL-868 keine


Sobald sowohl Sensor als auch Aktor auf 433 MHZ funken, gibts eine Verzögerung, egal über welches RF ich sende. Interessant waren vor allem die Tests dem CUL als Empfänger. Hier mußte ich vor dem Senden manuell ein 2 Sek. sleep einbauen, ansonsten wurde der Schaltbefehl einfach ignoriert. Der TRX als Empfänger scheint das selbst zu berücksichtigen (collision avoidance?), der hat die Pause von selbst eingelegt (was ja mein ursprüngliches Problem war).

Mal schauen wie ich das in meinem "eierlegenden Wollmilchsau home" Szenario unterbringe.
Anregungen, Testwünsche etc. sind natürlich herzlich willkommen!

[KölnSolar]

Hier mußte ich vor dem Senden manuell ein 2 Sek. sleep einbauen, ansonsten wurde der Schaltbefehl einfach ignoriert. Der TRX als Empfänger scheint das selbst zu berücksichtigen (collision avoidance?), der hat die Pause von selbst eingelegt (was ja mein ursprüngliches Problem war).

Da ist was wahres dran. Beim CUL ist das Problem bekannt(2 sec erscheinen mir aber viel).
Zum RFXTRX gibt es seitens des Herstellers folgenden Kommentar "CSMA-CA technology to avoid RF collisions." Bin aber auch noch nicht dazu gekommen das detailliert auszutesten (und zu verstehen). Ist mir im Moment noch zu kalt, um mich vor die Tür an meinen Sender zu stellen 

[derchrome]

Kurze Off-Topic Frage: der Bewegungsmelder, ist das dieser hier?

https://www.amazon.de/gp/aw/d/B01HB9RCGW/ref=pd_aw_sim_107_3?ie=UTF8&psc=1&refRID=KXN5GTBSW7GS4ZAGZEF7&dpPl=1&dpID=51ebWGYzZiL

Liest du den über den CUL ein? Funkt der auf 433 MHz?