HM-Dis-EP-WM55

Begonnen von OliWee, 14 Mai 2016, 16:48:43

Vorheriges Thema - Nächstes Thema

budy

Hmpff... offenbar ist der Sound Transducer hin - der klickt nur leise...
So neu und schon so kaputt...

Gruß,
Stephan
Debian stretch, FHEM 5.9.
HM-CC-RT-DN, HM-ES-PMSw1-Pl, HM-LC-Dim1TPBU-FM, HMUARTLGW, HMLAN, HM-SEC-KEY, HM-SEC-RHS, HM-SEC-SC-2, HM-SEC-SCo, HM-SEC-SD-2, HM-OU-CFM-TW, div. HUEs, Wifilight, Ring Video Pro

zap

Hätte mich auch gewundert. Ich benutze zwar HMCCU statt CUL, aber das Prinzip ist identisch.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

budy

Sag mal... piept das Device nicht auch, wenn es das erste mal gestartet wird oder man den Anlernbutton drückt? Mein Händler will von mri ein Skript, welches das Problem zeigt und da kann ich ihm natürlich sagen, dass er das in FHEM einbinden soll... aber ob das hilft... ;)

Gruß,
Stephan
Debian stretch, FHEM 5.9.
HM-CC-RT-DN, HM-ES-PMSw1-Pl, HM-LC-Dim1TPBU-FM, HMUARTLGW, HMLAN, HM-SEC-KEY, HM-SEC-RHS, HM-SEC-SC-2, HM-SEC-SCo, HM-SEC-SD-2, HM-OU-CFM-TW, div. HUEs, Wifilight, Ring Video Pro

MadMax-FHEM

Hi Stephan,

kann zwar grad nicht testen aber ich glaube ja, beim Einlegen der Batterien hat es immer einen Selbsttest inkl. "Pieptest" gemacht.

Beim Anlernen bin ich mir da nicht sicher (glaube nicht, da eher "nur" Blinken)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

budy

Moin Joachim,

danke - das reicht ja auch - da kann der Händler das ja selber mal testen... ;)

Gruß,
Stephan
Debian stretch, FHEM 5.9.
HM-CC-RT-DN, HM-ES-PMSw1-Pl, HM-LC-Dim1TPBU-FM, HMUARTLGW, HMLAN, HM-SEC-KEY, HM-SEC-RHS, HM-SEC-SC-2, HM-SEC-SCo, HM-SEC-SD-2, HM-OU-CFM-TW, div. HUEs, Wifilight, Ring Video Pro

_Lars_

Hallo zusammen,

vorab, vielen Dank an Martin für seine Mühe und die Spender, die das Teil hier deutlich nach vorne gebracht haben !!!

Ich habe Fhem auf einem RaspberryPi laufen mit hmusb als Funkmodul. Im Moment habe ich 9 threeState Sensoren und 3 Rauchmelder am System angeschlossen. Damit eine kleine Alarmanlage umgesetzt. Jetzt soll das WM55 Statusanzeige für meine Kontakte und den Alarmanlagen Zustand sein. Die Tasten möchte ich zum EIN und AUS Schalten nehmen.

Durch eure Beschreibungen, habe ich das Ding jetzt halbwegs verstanden und die Textausgabe auch einigermaßen im Griff.

Meine Ausgaben für das Display schreibe ich in die Texte text0,text2,text4 und gebe das im Falle, dass ich was ändern muss aus.

Mein Schaltertext ist statisch und wird nicht verändert.

Das sieht exemplarisch zum Beispiel so aus...
auf text0 habe ich den status der Fenster liegen. Also, falls eins auf ist soll da offen stehen, ansonsten zu.

([Kontakt_Arbeitszimmer_1] eq "open" ) ( set ep_Key_01 text Offen; define T_DIS_SWITCH at +00:00:20 set ep_Dis displayEP text0:text2:text4: )
DOELSEIF
([Kontakt_Kueche_1] eq "open") ( set ep_Key_01 text Offen; define T_DIS_SWITCH at +00:00:20 set ep_Dis displayEP text0:text2:text4:)
...
DOELSE
(set ep_Key_01 text Zu; define T_DIS_SWITCH at +00:00:20 set ep_Dis displayEP text0:text2:text4:)

Die Wartezeit von 20Sek habe ich deshalb drin, da ich einen Konflikt zwischen umschreiben des Text und Kommando zum Darstellen vermeiden will. 20Sek, vielleicht etwas zu viel, ist aber im Moment OK.
Mir ist auch klar, dass im Moment der Text auch neu gesendet wird, wenn ein Fenster geöffnet wird und schon ein anderes auf war, das ist alles Optimierungspotential, wenn ich das komplette Ding im Griff habe :-)

Das Umschalten des Display bei Tastendruck habe ich auf eure Empfehlung durch
attr EG_DisplaySW_Dis param reWriteDisplay03 abgefangen.

Das mit dem flackern beim Umschalten ist nicht so toll, aber akzeptabel.

Nun zu meinem aktuellen Problem. Ich kriege die beiden Taster nicht sauber eingelesen. Für den ersten Versuch habe ich nur eine Dummy Variable umschalten wollen. Also bei Taster oben (Taster2) soll die auf EIN gehen und bei dem Taster unten (Taster1) auf AUS.
define ep_SW_ON DOIF ([ep_Btn_02]=~ "Short") (set Test EIN)
define ep_SW_OFF DOIF ([ep_Btn_01] =~ "Short") (set Test AUS)


Irgendwie funktioniert das nicht :-(. Wenn ich daran rumprobiere, komme ich total schnell in den hmusb:ERROR-Overload status. Das kenn ich schon von früheren Phasen, wo ich meine Fensterkontakte in Betrieb genommen habe. Aber da hat das recht lange und gedauert und etliche Schaltversuche benötigt in diesen Zustand zu kommen.
Hier erreiche ich das schon nach ein paar betätigungen.

Deshalb glaube ich, dass ich etwas grundsätliches falsch eingestellt oder umgesetzt habe.

Hat einer von euch eine Idee, woran es liegen könnte? Was muss ich euch für Informationen geben, die das Problem eingrenzen könnten?

Bin gespannt, ob jemanden was dazu einfällt

Gruß
Lars

A.Harrenberg

Hi,
Zitat von: MadMax-FHEM am 02 September 2016, 09:02:19
kann zwar grad nicht testen aber ich glaube ja, beim Einlegen der Batterien hat es immer einen Selbsttest inkl. "Pieptest" gemacht.
ich kann bestätigen das der beim Einlegen der Batterie einmal kurz piepst. Hatte das Ding gerade vor mir liegen und habe es ausprobiert.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

martinp876

mir nciht klar, was da gesendet werden sollte. kannst du die Messages einmal aufzeichnen?

_Lars_

#128
Da ich mich noch nicht so besonders gut auskenne im Problem Debugging, muss ich etwas dusselig nachfragen  :-[

Soll ich ich das im LogFile aufzeichnen oder im EventMonitor ?

EventMonitor sieht so aus ...
2016-09-03 15:43:08.638 CUL_HM Display battery: ok
2016-09-03 15:43:08.638 CUL_HM Display CMDs_done
2016-09-03 15:43:08.638 CUL_HM Display ep_Btn_01 Short
2016-09-03 15:43:08.644 CUL_HM ep_Btn_01 Short (to VCCU)
2016-09-03 15:43:08.644 CUL_HM ep_Btn_01 trigger: Short_32
2016-09-03 15:43:08.644 CUL_HM ep_Btn_01 trigger_cnt: 32
2016-09-03 15:43:11.644 CUL_HM Display CMDs_pending
2016-09-03 15:43:11.653 CUL_HM Display CMDs_pending
2016-09-03 15:43:11.661 CUL_HM ep_Dis displayEP
2016-09-03 15:43:13.731 CUL_HM Display CMDs_done


_Lars_

Das erste Problem habe ich schon mal entdeckt.
Das DOIF auf den Tastern wird nur ausgelöst, wenn ich wirklich einen Wechsel zum vorherigen State mache.
Also zum Beispiel erst Short drücke und dann Long. Zweimal Short hintereinander wird nicht erfaßt. Nun ja ist wohl
ein grundsätzliches Verständnisproblem bei mir gewesen. Hab das jetzt gehen Notify getauscht
define ep_BtnEIN notify a|ep_Btn_02:.* set Test EIN
define ep_BtnAUS notify a|ep_Btn_01:.* set Test AUS

und jetzt kann ich schon mal wie erwartet über die Taster meine Dummy Var umschalten.

Das Problem mit dem Overload bleibt. Kriege wieder keine Antworten von meinem HMUSB weil State Overload :-(

martinp876

das mit dem Overload interessiert mich mehr.
dazu musst du einmal messages sniffen. Zudem brauche ich dann eine Aussage wie oft du das machst, was du sniffen wirst.

_Lars_

So, ich hoffe ich hab das richtig gemacht.

Habe
attr global verbose 1
attr global mseclog 1
attr <hmlan> logIDs all,sys
in die Config eingetragen und dann zwei mal Taster2 und zwei mal Taster 1 betätigt.
Ich denke das EIN, bzw AUS-Schalten der Alarmanlage wird so ca. 2-3 mal am Tag passieren.


2016.09.03 17:13:06.527 0: HMLAN_Send:  hmusb S:SF09C3F35 stat:  00 t:00000000 d:01 r:F09C3F35 m:02 B001 424242 44EA03 010E
2016.09.03 17:13:08.052 0: HMLAN_Delay: hmusb 44EA03
2016.09.03 17:13:08.653 0: HMLAN_Parse: hmusb R:RF09C3B8C stat:0008 t:00000000 d:FF r:7FFF     m:02 B001 424242 44E9F1 010E
2016.09.03 17:13:08.654 0: HMLAN_Parse: hmusb no ACK from 44E9F1
2016.09.03 17:13:08.781 0: HMLAN_Parse: hmusb R:E44EA03   stat:0000 t:0046F367 d:FF r:FFB8     m:02 A010 44EA03 424242 0601010045
2016.09.03 17:13:08.909 0: HMLAN_Parse: hmusb R:RF09C3F35 stat:0001 t:0046F36C d:FF r:FFB8     m:02 A010 44EA03 424242 0601010045
2016.09.03 17:13:08.910 0: HMLAN_SdDly: hmusb 44EA03
2016.09.03 17:13:09.010 0: HMLAN_Send:  hmusb S:SF09C452A stat:  00 t:00000000 d:01 r:F09C452A m:02 B001 424242 44EA03 010E
2016.09.03 17:13:09.678 0: HMLAN_Parse: hmusb R:E44EA03   stat:0000 t:0046F6DB d:FF r:FFB9     m:02 A010 44EA03 424242 0601010046
2016.09.03 17:13:09.774 0: HMLAN_Parse: hmusb R:RF09C452A stat:0001 t:0046F6E0 d:FF r:FFB9     m:02 A010 44EA03 424242 0601010046
2016.09.03 17:13:09.949 0: HMLAN_Send:  hmusb S:SF09C4C92 stat:  00 t:00000000 d:01 r:F09C4C92 m:02 B001 424242 44E9F1 010E
2016.09.03 17:13:10.478 0: HMLAN_Parse: hmusb R:E44E9F1   stat:0000 t:0046FA10 d:FF r:FFCF     m:02 A010 44E9F1 424242 060101002F
2016.09.03 17:13:10.606 0: HMLAN_Parse: hmusb R:RF09C4C92 stat:0001 t:0046FA15 d:FF r:FFCF     m:02 A010 44E9F1 424242 060101002F
2016.09.03 17:13:11.886 0: HMLAN_Parse: hmusb R:E2E8DB7   stat:0000 t:0046FF86 d:FF r:FF9E     m:B1 8610 2E8DB7 000000 0AA8F2880000
2016.09.03 17:13:22.697 0: HMLAN_Send:  hmusb I:K
2016.09.03 17:13:22.704 0: HMLAN_Parse: hmusb V:03C4 sNo:NEQ0369437 d:49ADBD O:424242 t:004729DA IDcnt:000E L:0 %
2016.09.03 17:13:34.387 0: HMLAN_Parse: hmusb R:E4BD5FF   stat:0000 t:0047575B d:FF r:FFD7     m:C2 A640 4BD5FF 424242 0268
2016.09.03 17:13:37.416 0: HMLAN_Send:  hmusb S:SF09CB7DD stat:  00 t:00000000 d:01 r:F09CB7DD m:C3 B011 424242 4BD5FF 8003020A12800A12820A12840A14C01C
2016.09.03 17:13:38.740 0: HMLAN_Delay: hmusb 4BD5FF
2016.09.03 17:13:39.091 0: HMLAN_Parse: hmusb R:RF09CB7DD stat:0001 t:004769D7 d:FF r:FFE0     m:C3 8002 4BD5FF 424242 00
2016.09.03 17:13:39.092 0: HMLAN_SdDly: hmusb 4BD5FF
2016.09.03 17:13:39.193 0: HMLAN_Send:  hmusb S:SF09CBD09 stat:  00 t:00000000 d:01 r:F09CBD09 m:C3 B011 424242 4BD5FF 8003020A12800A12820A12840A14C01C
2016.09.03 17:13:39.795 0: HMLAN_Parse: hmusb R:RF09CBD09 stat:0001 t:00476C9B d:FF r:FFE0     m:C3 8002 4BD5FF 424242 00
2016.09.03 17:13:39.897 0: HMLAN_Send:  hmusb S:SF09CC12D stat:  00 t:00000000 d:01 r:F09CC12D m:C4 A011 424242 4BD5FF 8003D01DE016F003
2016.09.03 17:13:40.180 0: HMLAN_Parse: hmusb R:RF09CC12D stat:0001 t:00476DFC d:FF r:FFE0     m:C4 8002 4BD5FF 424242 00
2016.09.03 17:13:47.702 0: HMLAN_Send:  hmusb I:K
2016.09.03 17:13:47.733 0: HMLAN_Parse: hmusb V:03C4 sNo:NEQ0369437 d:49ADBD O:424242 t:00478B87 IDcnt:000E L:0 %
2016.09.03 17:13:49.461 0: HMLAN_Parse: hmusb R:E4BD5FF   stat:0000 t:0047924D d:FF r:FFDC     m:C5 A640 4BD5FF 424242 4269
2016.09.03 17:13:52.489 0: HMLAN_Send:  hmusb S:SF09CF2BF stat:  00 t:00000000 d:01 r:F09CF2BF m:C6 B011 424242 4BD5FF 8003020A12800A12820A12840A14C01C
2016.09.03 17:13:54.166 0: HMLAN_Parse: hmusb R:RF09CF2BF stat:0001 t:0047A4B6 d:FF r:FFE1     m:C6 8002 4BD5FF 424242 00
2016.09.03 17:13:54.267 0: HMLAN_Send:  hmusb S:SF09CF950 stat:  00 t:00000000 d:01 r:F09CF950 m:C7 A011 424242 4BD5FF 8003D01DE016F003
2016.09.03 17:13:54.268 0: HMLAN_Send:  hmusb I:K
2016.09.03 17:13:54.422 0: HMLAN_Parse: hmusb V:03C4 sNo:NEQ0369437 d:49ADBD O:424242 t:0047A5AF IDcnt:000E L:0 %
2016.09.03 17:13:54.518 0: HMLAN_Parse: hmusb R:RF09CF950 stat:0001 t:0047A616 d:FF r:FFE1     m:C7 8002 4BD5FF 424242 00
2016.09.03 17:14:02.936 0: HMLAN_Parse: hmusb R:E4BD5FF   stat:0000 t:0047C6DA d:FF r:FFDE     m:C8 A640 4BD5FF 424242 413B
2016.09.03 17:14:05.964 0: HMLAN_Send:  hmusb S:SF09D2761 stat:  00 t:00000000 d:01 r:F09D2761 m:C9 B011 424242 4BD5FF 8003020A12800A12820A12840A14C01C
2016.09.03 17:14:07.641 0: HMLAN_Parse: hmusb R:RF09D2761 stat:0001 t:0047D959 d:FF r:FFE1     m:C9 8002 4BD5FF 424242 00
2016.09.03 17:14:07.742 0: HMLAN_Send:  hmusb S:SF09D2DF2 stat:  00 t:00000000 d:01 r:F09D2DF2 m:CA A011 424242 4BD5FF 8003D01DE016F003
2016.09.03 17:14:07.993 0: HMLAN_Parse: hmusb R:RF09D2DF2 stat:0001 t:0047DABA d:FF r:FFE1     m:CA 8002 4BD5FF 424242 00
2016.09.03 17:14:14.074 0: HMLAN_Parse: hmusb R:E4BD5FF   stat:0000 t:0047F26F d:FF r:FFDD     m:CB A640 4BD5FF 424242 413C
2016.09.03 17:14:17.103 0: HMLAN_Send:  hmusb S:SF09D52E4 stat:  00 t:00000000 d:01 r:F09D52E4 m:CC B011 424242 4BD5FF 8003020A12800A12820A12840A14C01C
2016.09.03 17:14:18.779 0: HMLAN_Parse: hmusb R:RF09D52E4 stat:0001 t:004804DB d:FF r:FFD8     m:CC 8002 4BD5FF 424242 00
2016.09.03 17:14:18.880 0: HMLAN_Send:  hmusb S:SF09D5974 stat:  00 t:00000000 d:01 r:F09D5974 m:CD A011 424242 4BD5FF 8003D01DE016F003
2016.09.03 17:14:19.131 0: HMLAN_Parse: hmusb R:RF09D5974 stat:0001 t:0048063B d:FF r:FFD8     m:CD 8002 4BD5FF 424242 00
2016.09.03 17:14:19.269 0: HMLAN_Send:  hmusb I:K
2016.09.03 17:14:19.291 0: HMLAN_Parse: hmusb V:03C4 sNo:NEQ0369437 d:49ADBD O:424242 t:004806D3 IDcnt:000E L:0 %


Ich hoffe du kannst aus der Zahlenkollone was rauslesen :-) Für mich im Moment die Matrix :-)

LuckyDay

mal so nebenbei, er hat noch die 0.964 Firmware auf dem hmusb, und nicht die 0.967

martinp876

so weit alles ok. Viele Bursts => viel Funklast.

erst sehe ich 2 Statusrequest für 44EA03  und 44E9F1. Beide müssen wiederholt werden von FHEM => mindestens 8 Burst messages wurden gesendet.
- Mit dem EP hat das nichts zu tun, der hat kein Statusrequest
- du kannst (solltest) mit hmInfo protoEvents prüfen was so funkseitig stattfindet. da stehen auch Widerholungen. Bei Burst unangenehm.

Beim EP wird mit jedem Tastendruck ein Burst gesendet um den Text zu übertragen. Beim ersten mal musste es wiederholt werden, sonst hat es auf Anhieb funktioniert.

Du kannst in 1h 100* burst senden - oder 1600 messages - der eine Mischung. Ein fehlgeschlagener Burst zählt 3-fach. Also nur 30 Burst fehlversuche.



pc1246

Zitat von: fhem-hm-knecht am 03 September 2016, 17:23:32
mal so nebenbei, er hat noch die 0.964 Firmware auf dem hmusb, und nicht die 0.967
Hallo Lars
Was fhem-hm-knecht geschrieben hat, ist nicht ganz unwichtig! Du solltest dringend ein Firmwareupdate machen! Ansonsten ist Dein hmusb auf kurz oder lang hin! Und Ersatz gibt es keinen mehr!
Gruss und schoenen Sonntag noch
Christoph
HP T610
Onkyo_AVR;Enigma2; SB_Server; SB_Player; HM-USB; PhilipsTV; harmony hub; Jeelink mit PCA301; Somfy; S7-300; LGW; HUE; HM-IP auf Charly; div