Verzögerung mit Schaltern/Sensoren

Begonnen von Icebear, 02 November 2013, 10:39:55

Vorheriges Thema - Nächstes Thema

Icebear

Hallo,

ich hoffe wer hat eine Idee.

Ich habe im Flur einen Bewegungsmelder (Intertechno) und einen Switch (HomeEasy) wobei ich vorher auch HomeEasy melder hatte und dabei das selbe problem.

Der Melder sendet ein On .. darauf reagier ich im notify und sende ein On-for-timer an den HomeEasy switch.

Es dauert teilweise EWIG bis das senden ausgeführt wird.

Jetzt habe ich getestet worans liegt. Vermutung 1 logfiles usw .. das wars nicht
Vermutung 2 WEB und longpoll .. das wars auch nicht
Nachdem ich jetzt einen 3 kanal switch habe von Intertechno habe ich da Problem mal weiter eingegrenzt und musste feststellen das es offensichtlich am RFXTrx liegt.

also Versuch 1: notify geändert das der IT Switch gesteuert wird über RFXTrx (also sender ARC empfänger IT) > gleiches verhalten wie sender ARC empfänger HE (verzögerung von mehreren sekunden) ... und jetz
Versuch 2 : IT Switch als IT device am Cul angelegt
Sender ARC über RFXTrx empfänger (switch) über CUL und IT Modul und siehe da .. praktisch keine verzögerung mehr beim senden..

Resultat: der RFXTrx schaltet das senden für eine gewisse zeit ab wenn protokolle empfangen werden. Sobald da nichts mehr kommt wird das senden wieder freigegeben und das Einschalten des Lichts erfolgt.

Willi: könnte diese beobachtung richtig sein und wenn ja wie "umschifft" man das prob ??
gibts sowas wie ein "force send" oder so ?

Grüße aus Friedrichsfeld
Raspberry PI mod B (Wheezy), Fhem 5.4, CUL868, CUL433 , RfxTrx, HM-USB-CFG2, Wlan, HomeEasy, IT, FS20, TFA, HomeMatic, Oregon Scientific, HMLand auf Fritzbox
Raspberry PI mod B (RaspBMC)

Willi

Hallo Icebear,

ich habe bei mir noch keinerlei Verzögerungen feststellen können, obwohl ich eine Menge Sensoren habe, die häufig senden.

Ich kann mir nicht vorstellen, das bei Dir so viel Funkverkehr ist, dass der RFXtrx433 nicht mehr senden kann. Wie RFXCOM das Abarbeiten des Sendens genau implementiert hat, weiss ich nicht. Es sollten allerdings zwischen den einzelnen empfangenen Datagrammen immer genug Lücken sein. Oder hast Du generell Funkprobleme im 433 Mhz Bereich?
Generell gibt der RFXtrx433 zurück, ob er senden kann. Es gibt dabei auch eine Statusmeldung, die angibt, dass das Senden um 3 Sekunden verzögert wird.

Um das auszuschließen, kannst Du die Zeilen 123ff in 46_RFX_ELSE.pm von bisher
        if (($msg != 0x00) && ($msg != 0x01)) {
                Log3 $hash, 1, "TRX_ELSE_Parse() error transmit NACK=".sprintf("%02x",$msg);
        }

wie folgt abändern:
        if ($msg != 0x00) {
                Log3 $hash, 1, "TRX_ELSE_Parse() error transmit NACK=".sprintf("%02x",$msg);
        }


Wenn nach dieser Änderung eine Menge Meldungen
Zitat... TRX_ELSE_Parse() error transmit NACK=...
kommen diese bitte mitteilen.

Ich vermute eher, dass FHEM selbst irgendwo herumhängt und der Sendebefehl nicht an RFXtrx433 gesendet wird. Problem ist bei FHEM, dass es kein richtiges Multitasking gibt. Ein einiges Skript kann die komplette Verarbeitung bei FHEM verzögern.
Deine Änderung per CUL zu senden, könnte das Problem auf andere Weise gelöst haben.

Gibt es die Verzögerungen auch, wenn Du den Switch per RFXtrx über die GUI oder per "set GERÄT on" schaltest?

Schalte mal für Deinen Switch (nachfolgend im Beispiel LICHT_INNENHOF) verbose ein, damit Du im fhem-2013-11.log entsprechendes Logging bekommst, wenn Du schaltest:
attr LICHT_INNENHOF verbose 5 verzögern.

Du solltest jetzt beim Schalten über set LICHT_INNENHOF off folgenden Eintrag im Log haben:
Zitat2013.11.02 18:49:33 5: TRX_LIGHT_Set() name=LICHT_INNENHOF device_type=ARC, deviceid=P12 house=80, unit=12 command=off
2013.11.02 18:49:33 5: TRX_LIGHT_Set hexline=07100100500c0000
Beim Einschalten über set LICHT_INNENHOF off sollte folgenden Eintrag im Log kommen:
Zitat2013.11.02 18:50:11 5: TRX_LIGHT_Set() name=LICHT_INNENHOF device_type=ARC, deviceid=P12 house=80, unit=12 command=on
2013.11.02 18:50:11 5: TRX_LIGHT_Set hexline=07100100500c0100

Dadurch siehst Du genau, wann das Kommando zum Aus-/Einschalten an RFXtrx433 gesendet wird.
Teste, ob es hier eine Verzögerung zwischen dem Timestamp im Log und den eigentlichen Schalten gibt.

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Icebear

#2
Hallo,

ich stelle fest seit ich HOMEEASY Receive am RFXTRX aus habe scheint es besser geworden zu sein.. Da die Bewegungsmelder ja lustigerweise alles aussenden ist das nicht so schlimm.

Die Bewegungsmelder senden ARC,AC und HE nacheinander aus..

Ich checks mal weiter nach größeren verzögerungen (habe die zugehörigen Devices und notifys weiterlaufen mit verbose 5)
aber ich sehe jetz schon ...
2013.11.02 20:17:11 1: TRX_ELSE_Parse() error transmit NACK=01

mehrmals schon .. wenn ich HE noch receive habe duerfte das noch mehr sein ..
das schonmal zur info

Raspberry PI mod B (Wheezy), Fhem 5.4, CUL868, CUL433 , RfxTrx, HM-USB-CFG2, Wlan, HomeEasy, IT, FS20, TFA, HomeMatic, Oregon Scientific, HMLand auf Fritzbox
Raspberry PI mod B (RaspBMC)

Willi

Hmm.

ZitatDa die Bewegungsmelder ja lustigerweise alles aussenden
Das ist ja nicht so gut. Deine Bewegungsmelder scheinen die 433er-Frequenz ziemlich vollzumachen.

Welche Bewegungsmelder verwendest Du?

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Icebear

Die HomeEasy (Die Alten sowie die Neueren) .. Ich nehme an das genau ist das Problem.. Da ich 2 stück in dem Flur verbaut habe und beide alle protokolle senden sind das je nachdem wo man in den flur läuft schon 6 transmits .. muss mir da was anderes überlegen ..

Raspberry PI mod B (Wheezy), Fhem 5.4, CUL868, CUL433 , RfxTrx, HM-USB-CFG2, Wlan, HomeEasy, IT, FS20, TFA, HomeMatic, Oregon Scientific, HMLand auf Fritzbox
Raspberry PI mod B (RaspBMC)

Icebear

Hallo,

auch als Info für dich willi... RFXCom hat den Thread hier gelesen und mir eine EMail geschrieben ...

DANKE auch dafür ..

Zitat
it is not the RFXtrx433 which is the trouble but it is normal that the RFXtrx433 does not start sending while another RF device is transmitting.

It is not a good idea to start transmitting if another RF device is active because both RF message will collide and disturb each other. For that reason the RFXtrx433 will wait until the other RF device has stopped transmitting.



Do not use motions sensors that transmit for a long period!

Ok das erklärt wahrscheinlich warum es besser funzt über den CUL...

Grüße
Raspberry PI mod B (Wheezy), Fhem 5.4, CUL868, CUL433 , RfxTrx, HM-USB-CFG2, Wlan, HomeEasy, IT, FS20, TFA, HomeMatic, Oregon Scientific, HMLand auf Fritzbox
Raspberry PI mod B (RaspBMC)

Willi

Aber das würde ja bedeuten, dass bei Dir über längere Zeit der Funkbereich 433 MHz komplett zu ist, ohne Lücke.
Kann ich mir irgendwie kaum vorstellen. Ist bei Dir die Empfangs-LED dauernd an?

Du hast noch nicht mitgeteilt, ob Du die langen Verzögerungen auch beim Schalten über die Weboberfläche hast. Wenn nicht, würde ich eher eine andere Ursache suchen.
Grüße Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Willi

Was ich mich noch frage: Wie lang ist EWIG als Verzögerung?

Schön wäre zu wissen, ob der Timestamp im Log beim Senden angibt, dass der Sendebefehl schnell an den RFXtrx übergeben wird, dieser dann aber EWIG verzögert.

Grüße Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Icebear

Hi,
beim Schalten über einen Schalter passiert das nicht allerdings senden Schalter wohl auch nur wärend gedrückt wird..
Die Bewegungssensoren (auch mal nach gesucht machen die wohl alle) senden sehr viele Pakete in kurzer Zeit und ballern alles dicht ...
Allerdings wird das vom RFXTrx wohl gefiltert so das man das so garnicht mitbekommt.. Werde das mal in ruhe testen sobald ich dazu komme .. Ich werde dir selbstverständlich berichten ...

Grüsse aus Friedrichsfeld
Icebear
Raspberry PI mod B (Wheezy), Fhem 5.4, CUL868, CUL433 , RfxTrx, HM-USB-CFG2, Wlan, HomeEasy, IT, FS20, TFA, HomeMatic, Oregon Scientific, HMLand auf Fritzbox
Raspberry PI mod B (RaspBMC)

Willi

Hmm.  Habe ich das vorher nicht richtig verstanden? Ich dachte die Verzögerungen treten immer auf.

Wenn Du sagst, dass die Bewegungsmelder das Problem sind, dann sollten die Verzögerungen nur dann auftreten, wenn die Bewegungsmelder eine Bewegung feststellen, oder? Korreliert dies?

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Icebear

Hi Willi,

die leute von RFXCom haben offensichtlich recht und die Bewegungsmelder machen den funk sowas von dicht ..

Nachdem ich nun die ersten HomeMatic switche verbaut habe ist das problem weitestgehends verschwunden.

Jetzt gibt es nur noch verzoegerungen wenn ich an 2 bewegungsmelder langlaufe (da scheint der eine den anderen beim senden zu blocken und der zweite reagiert verzoegert).

Ist aber wesendlich angenehmer als vorher wo ich verzoegerungen bis 5 sekunden hatte weil der befehl an die HomeEasy bzw. IT devices nicht rausgingen. Test mit einem CUL488 (den hab ich mitlerweile auch) brachten nur eine minimale verbesserung. Die Lösung im moment ist das ganze über Homematic zu schalten mit den Homeeasy bewegungsmeldern und fhem dazwischen aber die bewegungsmelder werden auch noch getauscht.

Das ganze geraffel hat mich nu genug nerven gekostet.. (homeeasy switche die einfach mal so einschalten usw...)
Danke dir für die unterstützung .

Grüsse
Icebear
Raspberry PI mod B (Wheezy), Fhem 5.4, CUL868, CUL433 , RfxTrx, HM-USB-CFG2, Wlan, HomeEasy, IT, FS20, TFA, HomeMatic, Oregon Scientific, HMLand auf Fritzbox
Raspberry PI mod B (RaspBMC)