Ich habe einen Wandtaster HM-PB-2-WM55 per CUL mit fhem gepairt und mit einem virtuellen Aktor gepeert. Soweit so gut. Nun ist es aber so, dass ca. 2 jeder zweite Tastendruck mit einer roten LED quittiert wird. Die anderen sind grün, also alles ok.
So siehts aus, wenn die LED grün wird:
2014.03.19 22:14:39 4: CUL_Parse: CUL0 A 0B 56 A440 24F2C2 1C062D 012FDD -91.5
2014.03.19 22:14:40 4: CUL_send: CUL0As 0D 56 8002 1C062D 24F2C2 01010000
2014.03.19 22:14:40 4: eventTypes: CUL_HM CUL_HM_HM_PB_2_WM55_24F2C2 battery: ok -> battery: ok
2014.03.19 22:14:40 4: eventTypes: CUL_HM CUL_HM_HM_PB_2_WM55_24F2C2 CUL_HM_HM_PB_2_WM55_24F2C2_Btn_01 Short (to virtueller_Aktor) -> CUL_HM_HM_PB_2_WM55_24F2C2_Btn_01 Short (to virtueller_Aktor)
2014.03.19 22:14:40 4: eventTypes: CUL_HM CUL_HM_HM_PB_2_WM55_24F2C2_Btn_01 Short (to virtueller_Aktor) -> Short (to virtueller_Aktor)
2014.03.19 22:14:40 4: eventTypes: CUL_HM CUL_HM_HM_PB_2_WM55_24F2C2_Btn_01 trigger: Short_47 -> trigger: Short_47
2014.03.19 22:14:40 4: eventTypes: CUL_HM virtueller_Aktor_Btn1 trig_CUL_HM_HM_PB_2_WM55_24F2C2_Btn_01: short -> trig_CUL_HM_HM_PB_2_WM55_24F2C2_Btn_01: short
2014.03.19 22:14:40 4: eventTypes: CUL_HM virtueller_Aktor_Btn1 trigLast: CUL_HM_HM_PB_2_WM55_24F2C2_Btn_01 :short -> trigLast: CUL_HM_HM_PB_2_WM55_24F2C2_Btn_01 :short
2014.03.19 22:14:40 4: eventTypes: CUL_HM virtueller_Aktor_Btn1 OFF -> OFF
2014.03.19 22:14:40 4: eventTypes: CUL_HM virtueller_Aktor_Btn1 virtActState: OFF -> virtActState: OFF
2014.03.19 22:14:40 4: eventTypes: CUL_HM virtueller_Aktor_Btn1 virtActTrigger: CUL_HM_HM_PB_2_WM55_24F2C2_Btn_01 -> virtActTrigger: CUL_HM_HM_PB_2_WM55_24F2C2_Btn_01
2014.03.19 22:14:40 4: eventTypes: CUL_HM virtueller_Aktor_Btn1 virtActTrigType: short_Release -> virtActTrigType: short_Release
2014.03.19 22:14:40 4: eventTypes: CUL_HM virtueller_Aktor_Btn1 virtActTrigRpt: 1 -> virtActTrigRpt: .*
2014.03.19 22:14:40 4: eventTypes: CUL_HM virtueller_Aktor_Btn1 virtActTrigNo: 47 -> virtActTrigNo: .*
Und so wenns rot wird:
2014.03.19 22:15:50 4: CUL_Parse: CUL0 A 0B 57 A440 24F2C2 1C062D 0228EB -84.5
2014.03.19 22:15:50 4: CUL_send: CUL0As 0D 57 8002 1C062D 24F2C2 0102C800
2014.03.19 22:15:50 4: eventTypes: CUL_HM CUL_HM_HM_PB_2_WM55_24F2C2 battery: ok -> battery: ok
2014.03.19 22:15:50 4: eventTypes: CUL_HM CUL_HM_HM_PB_2_WM55_24F2C2 CUL_HM_HM_PB_2_WM55_24F2C2_Btn_02 Short (to virtueller_Aktor) -> CUL_HM_HM_PB_2_WM55_24F2C2_Btn_02 Short (to virtueller_Aktor)
2014.03.19 22:15:50 4: eventTypes: CUL_HM CUL_HM_HM_PB_2_WM55_24F2C2_Btn_02 Short (to virtueller_Aktor) -> Short (to virtueller_Aktor)
2014.03.19 22:15:50 4: eventTypes: CUL_HM CUL_HM_HM_PB_2_WM55_24F2C2_Btn_02 trigger: Short_40 -> trigger: Short_40
2014.03.19 22:15:50 4: eventTypes: CUL_HM virtueller_Aktor_Btn2 trig_CUL_HM_HM_PB_2_WM55_24F2C2_Btn_02: short -> trig_CUL_HM_HM_PB_2_WM55_24F2C2_Btn_02: short
2014.03.19 22:15:50 4: eventTypes: CUL_HM virtueller_Aktor_Btn2 trigLast: CUL_HM_HM_PB_2_WM55_24F2C2_Btn_02 :short -> trigLast: CUL_HM_HM_PB_2_WM55_24F2C2_Btn_02 :short
2014.03.19 22:15:50 4: eventTypes: CUL_HM virtueller_Aktor_Btn2 ON -> ON
2014.03.19 22:15:50 4: eventTypes: CUL_HM virtueller_Aktor_Btn2 virtActState: ON -> virtActState: ON
2014.03.19 22:15:50 4: eventTypes: CUL_HM virtueller_Aktor_Btn2 virtActTrigger: CUL_HM_HM_PB_2_WM55_24F2C2_Btn_02 -> virtActTrigger: CUL_HM_HM_PB_2_WM55_24F2C2_Btn_02
2014.03.19 22:15:50 4: eventTypes: CUL_HM virtueller_Aktor_Btn2 virtActTrigType: short_Release -> virtActTrigType: short_Release
2014.03.19 22:15:50 4: eventTypes: CUL_HM virtueller_Aktor_Btn2 virtActTrigRpt: 1 -> virtActTrigRpt: .*
2014.03.19 22:15:50 4: eventTypes: CUL_HM virtueller_Aktor_Btn2 virtActTrigNo: 40 -> virtActTrigNo: .*
2014.03.19 22:15:53 4: CUL_Parse: CUL0 A 0B 57 A040 24F2C2 1C062D 0228EE -83
2014.03.19 22:15:53 4: CUL_send: CUL0As 0D 57 8002 1C062D 24F2C2 0102C800
2014.03.19 22:15:53 4: CUL_HM CUL_HM_HM_PB_2_WM55_24F2C2 dupe: repeat 2 ack, dont process
2014.03.19 22:15:53 4: CUL_Parse: CUL0 A 0B 57 A040 24F2C2 1C062D 0228EF -82.5
2014.03.19 22:15:53 4: CUL_HM CUL_HM_HM_PB_2_WM55_24F2C2 dupe: dont process
Also fhem meldet:
2014.03.19 22:15:53 4: CUL_HM CUL_HM_HM_PB_2_WM55_24F2C2 dupe: repeat 2 ack, dont process
Liegt das evtl. am Prellen des Tasters? Warum ist das so bzw. kann man dagegen was machen? Ich habe schon das Entprellen aus dem HMTutotial probiert, aber das scheint nicht zu klappen. Denke mal, da geht es ja auch nur um die Verarbeitung der Trigger in fhem und nicht um diese ACK-LowLevel-Ebene...
Ich würde ja verstehen, wenn fhem den zweiten Tastendruck nicht quittieren würde, aber er scheint gar kein ACK zu schicken. Kann auch Quatsch sein, evtl. weiß ich nicht wovon ich rede :D
PS.
Sehe ich das richtig, dass der Taster nur Befehle von fhem empfangen kann, wenn ich auf der Rückseite den Knopf drücke? Also bei getConfig und beim Peeren und co.?
der WM55 sollte lazyConfig unterstützen. Das heist, dass es antwortet, wenn man einen Button drückt.
Das klappt aber nur mit HMLAN/USB - nicht mir CUL/CUNO (jedenfalls mit der Aktuellen FW)
Mit CUL/CUNO musst du den Config-knopf drücken.
Zeichne einmal rohmessages der Ablaufs auf, kommentiere kurz. Dann werde ich es einmal durchsehen. Millisec auflösung!
Event auf höherer Ebene sind nicht ausreichend
Gruss Martin
Also das hier ist ein Tastendruck, der korrekt mit grün quittiert wird:
2014.03.20 15:20:16.404 4: CUL_Parse: CUL0 A 0B 84 A440 24F2C2 1C062D 013CF2 -81
2014.03.20 15:20:16.505 4: CUL_send: CUL0As 0D 84 8002 1C062D 24F2C2 01010000
So siehts aus, wenn die LED nach dem Drücken rot wird:
2014.03.20 15:23:06.638 4: CUL_Parse: CUL0 A 0B 8E A440 24F2C2 1C062D 0146EC -84
2014.03.20 15:23:06.739 4: CUL_send: CUL0As 0D 8E 8002 1C062D 24F2C2 01010000
2014.03.20 15:23:06.954 4: CUL_Parse: CUL0 A 0B 8E A040 24F2C2 1C062D 0146EF -82.5
2014.03.20 15:23:07.054 4: CUL_send: CUL0As 0D 8E 8002 1C062D 24F2C2 01010000
2014.03.20 15:23:07.166 4: CUL_Parse: CUL0 A 0B 8E A040 24F2C2 1C062D 0146EF -82.5
Danke!
hm...
die messages sind korrekt, das timing auch. Umklar (bei CUL immer) ist der Delay CUL-FHEM. Da gibt es keinen Referenzwert.
Einzig die Zeiten zwischen den empfangenen Messages kann man vergleiche:
15:23:06.638 Parse: CUL0 A 0B 8E A440 24F2C2 1C062D 0146
316ms
15:23:06.954 Parse: CUL0 A 0B 8E A040 24F2C2 1C062D 0146
212ms
15:23:07.166 Parse: CUL0 A 0B 8E A040 24F2C2 1C062D 0146
Das Timing des Device ist meiner Erfahrung nach präzise - der Abstand der Wiederolung sollte identisch sein, 250ms. In deinem System ist eine Schwankung von 100ms zu sehen. Das könnte der Grund sein.
Etwas dagegen zu tun ist nicht einfach... musst du dein System untersuchen....
Gruss Martin
Sorry, aber ich fürchte ich kann dir gerade nicht ganz folgen :-\ Wenn ichs richtig verstehe, dann hängt es mit den Timings zusammen. Also der Schalter schickt das Signal und erwartet innerhalb einer gewissen Zeit ein ACK. Aber aus irgendwelchen Gründen, kommt das vom PC zu spät, richtig? Es wird jedoch korrekt gesendet. Und laut Log wird es auch rechtzeitig gesendet. Also gibt es scheinbar eine Verzögerung nach dem Abschicken der Daten an die serielle Schnittstelle (also auf CUL bzw. OS-Seite)?
Wie hängt das denn mit diesen Mehrfachtriggern zusammen, die ja vermutlich vom Prellen kommen? Das Ganze passiert ja scheinbar nur bei mehrfachen Triggern.
Wenn vom mehrfachen Triggern mehrere Nachrichten reinkommen, müssen die alle ack'd werden oder reicht dann ein ACK für alle?
Last but not least: Gibts irgendwo eine Dokumentation zu dem Homematic-Protokoll (also Ablauf der Kommunikation und Inhalt der Nachrichten)?
Sorry für die Nerverei... :/ Ich lese mich da auch gerne tiefer ein, aber ich verstehe das Problem noch nicht so richtig und weiss nicht so recht, wo ich anfangen soll zu suchen.
ZitatWenn ichs richtig verstehe, dann hängt es mit den Timings zusammen.
ja. Die messages sind korrekt, der WM55 wiederholt, hat also nichts erhalten... dann ist es das Timing.
Zitat
Also der Schalter schickt das Signal und erwartet innerhalb einer gewissen Zeit ein ACK.
ja. Ein ach wird i.a. 100-150ms nach dem Senden erwrtet - nicht früher, nicht später
Zitat
Aber aus irgendwelchen Gründen, kommt das vom PC zu spät, richtig?
ich denke. Den Nachweis kann man mit HMLAN/USB führen, nicht aber mit CUL. Du könntest es mit wireshark "bestätigen".
ZitatAlso gibt es scheinbar eine Verzögerung nach dem Abschicken der Daten an die serielle Schnittstelle (also auf CUL bzw. OS-Seite)?
Es ist eher die Empfangsseite - die ist meist kritischen. Der PC verarbeitet die Daten erst später - holt sie in Blöcken ab, macht erst noch andere Sachen fertig... irgend so etwas. Das senden ist eher weniger ein Problem
ZitatWie hängt das denn mit diesen Mehrfachtriggern zusammen, die ja vermutlich vom Prellen kommen? Das Ganze passiert ja scheinbar nur bei mehrfachen Triggern.
kann ich nicht folgen - ich habe nur einen gesehen. Wo sind die anderen?
ZitatWenn vom mehrfachen Triggern mehrere Nachrichten reinkommen, müssen die alle ack'd werden oder reicht dann ein ACK für alle?
Immer ein Ack je message
ZitatGibts irgendwo eine Dokumentation zu dem Homematic-Protokoll (also Ablauf der Kommunikation und Inhalt der Nachrichten)
nein.
ZitatIch lese mich da auch gerne tiefer ein, aber ich verstehe das Problem noch nicht so richtig und weiss nicht so recht, wo ich anfangen soll zu suchen.
kein Problem. Wenn du einen PC (Windows) mit CUL nutzt wird es schwierig ein stabiles Timing hin zu bekommen. Windows in dieser From ist nicht echtzeit-geeignet. Es erwartet (wie viele higher-level Systeme) einen entsprechenden Support vom IO. CUL/CUNO liefern hier nichts (d.h. kein timng-support)
Gruss Martin
Zitat von: martinp876 am 21 März 2014, 07:14:32
Es ist eher die Empfangsseite - die ist meist kritischen. Der PC verarbeitet die Daten erst später - holt sie in Blöcken ab, macht erst noch andere Sachen fertig... irgend so etwas. Das senden ist eher weniger ein Problem
Ok verstehe. Vielleicht kann ich mal etwas an den COM-Parameter drehen. Im extremsten Fall würde ich mal den FIFO komplett ausschalten, so dass für jedes einzelne empfangene Byte direkt ein Interrupt ausgelöst wird. Aber da es unter Linux genauso ist (s.u.), weiss ich nicht, ob das überhaupt Sinn hat.
Zitat von: martinp876 am 21 März 2014, 07:14:32
kann ich nicht folgen - ich habe nur einen gesehen. Wo sind die anderen?Immer ein Ack je message
Bei dem "Schlechtfall" gehen ja scheinbar zwei Nachrichten ein:
2014.03.20 15:23:06.638 4: CUL_Parse: CUL0 A 0B 8E A440 24F2C2 1C062D 0146EC -84
2014.03.20 15:23:06.739 4: CUL_send: CUL0As 0D 8E 8002 1C062D 24F2C2 01010000
2014.03.20 15:23:06.954 4: CUL_Parse: CUL0 A 0B 8E A040 24F2C2 1C062D 0146EF -82.5
2014.03.20 15:23:07.054 4: CUL_send: CUL0As 0D 8E 8002 1C062D 24F2C2 01010000Ich hatte halt gedacht, dass das vom Prellen kommt. Aber wenn ich dich richtig verstanden habe, dann hat es mit Prellen nix zu tun und es liegt daran, dass der Taster einfach das Signal nochmal sendet, weil das erste nicht korrekt ack'd wurde. Also war einfach Quatsch von mir...
Zitat von: martinp876 am 21 März 2014, 07:14:32kein Problem. Wenn du einen PC (Windows) mit CUL nutzt wird es schwierig ein stabiles Timing hin zu bekommen. Windows in dieser From ist nicht echtzeit-geeignet. Es erwartet (wie viele higher-level Systeme) einen entsprechenden Support vom IO. CUL/CUNO liefern hier nichts (d.h. kein timng-support)
Also ich habe heute mal mein Pandaboard in Betrieb genommen und einfach mal den Taster in ein ansonsten "frisches" fhem installiert. Das Verhalten ist interessanterweise genau dasselbe. Also 50% der Tastendrücke werden mit roter LED quittiert. Scheint also zumindest nicht direkt mit Windows zusammen zu hängen. War jedoch ein Wald und Wiesen Ubuntu. Also kein richtiger Realtime-Kernel o.ä. Benutzt ihr tatsächlich Realtime-Linux für den Betrieb von fhem? Ich glaube aber, dass zumindest einige Teile von dem RT-Kram mittlerweile auch in den Vanilla-Kernel zurück geflossen sind.
Tja, was mach ich nun? Kann dann ja theoretisch nur noch am CUL an sich liegen oder? Ob ich mal spaßeshalber einen HM-LAN besorge und gucke, ob es damit dann spontan besser ist? Oder wie schätzt du da die Chancen ein?
ZitatTja, was mach ich nun? Kann dann ja theoretisch nur noch am CUL an sich liegen oder? Ob ich mal spaßeshalber einen HM-LAN besorge und gucke, ob es damit dann spontan besser ist? Oder wie schätzt du da die Chancen ein?
sieht so aus. Messen kann man nur mit einem weiteren IO.
Du verwendest eine CUL über USB... die sollte eigentlich weitgehend funktionieren.
HMLAN traue ich konzeptbedingt deutlich besseres Timing zu. HMUSB sollte noch weiter vorne liegen, da erfahrungsgemäß LAN mehr Schwankungen erzeugt und langsamer ist als USB. HMLAN ist aber bereits stabil!