Liebe Fachleute,
habe mir vor etwa 14 Tagen zwei HM-Dis-WM55 bestellt und bin erst heute dazu gekommen Nr. 2 zusammen zu bauen.
Während Nr. 1 seit 14 Tagen problemlos funktioniert, weigert sich Nr. 2 komplett zu pairen und bleibt auf set_0xD8814F stehen.
Ein getConfig wird mit einem RESPONSE TIMEOUT:RegisterRead quittiert.
Ich habe bereits mehrfach(!):
- das Display auf Werkseinstellungen zurück gesetzt
- das Device aus FHEM entfernt und erneut versucht zu pairen
- FHEM aktualisiert
- den RasPi neu gestartet
Sämtliche anderen Aktoren, Schalter, Sensoren sind voll funktionstüchtig.
Wie kann ich ermitteln, ob das HM-Dis-WM55 selbst das Problem ist?
Freue mich über jeden Tipp!
Internals:
CFGFN
CUL_0_MSGCNT 8
CUL_0_RAWMSG A1A0284004656F0D8814F1000D34E45513031303338333212110000::-57:CUL_0
CUL_0_RSSI -57
CUL_0_TIME 2016-08-20 13:42:49
DEF 4656F0
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 8
NAME HM_4656F0
NOTIFYDEV global
NR 249
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
channel_01 HM_4656F0_Dis_01
channel_02 HM_4656F0_Dis_02
channel_03 HM_4656F0_Dis_03
channel_04 HM_4656F0_Dis_04
channel_05 HM_4656F0_Dis_05
channel_06 HM_4656F0_Dis_06
channel_07 HM_4656F0_Dis_07
channel_08 HM_4656F0_Dis_08
channel_09 HM_4656F0_Dis_09
channel_0A HM_4656F0_Dis_10
lastMsg No:02 - t:00 s:4656F0 d:D8814F 1000D34E45513031303338333212110000
protCmdDel 21
protLastRcv 2016-08-20 13:42:49
protResndFail 1 last_at:2016-08-20 13:42:53
protSnd 7 last_at:2016-08-20 13:42:49
protState CMDs_done_Errors:1
rssi_at_CUL_0 avg:-58.37 cnt:8 min:-64 lst:-57 max:-54.5
Readings:
2016-08-20 13:41:34 CommandAccepted yes
2016-08-20 13:42:49 D-firmware 1.0
2016-08-20 13:42:49 D-serialNr NEQ0103832
2016-08-20 13:41:33 R-pairCentral set_0xD8814F
2016-08-20 13:41:35 aesCommToDev ok
2016-08-20 13:41:34 aesKeyNbr 00
2016-08-20 13:42:53 state RESPONSE TIMEOUT:RegisterRead
Regl_00.:
VAL
Helper:
HM_CMDNR 23
cSnd 01D8814F4656F00006,01D8814F4656F000040000000000
mId 00D3
rxType 4
Dispi:
L:
L1:
d 1
L2:
d 1
L3:
d 1
L4:
d 1
L5:
d 1
L6:
d 1
S:
L1:
d 1
L2:
d 1
L3:
d 1
L4:
d 1
L5:
d 1
L6:
d 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +4656F0,00,00,00
nextSend 1471693369.69051
prefIO
rxt 0
vccu
p:
4656F0
00
00
00
Mrssi:
mNo 02
Io:
CUL_0 -55
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_cul_0:
avg -58.375
cnt 8
lst -57
max -54.5
min -64
Shadowreg:
RegL_00. 02:01 0A:D8 0B:81 0C:4F
Attributes:
IODev CUL_0
IOgrp VCCU:CUL_0
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-Dis-WM55
room CUL_HM
serialNr NEQ0103832
subType pushButton
webCmd getConfig:clear msgEvents
Hi,
welches IODev hast du?
CUL??
Ich weiß zwar nicht, warum einer ging und der andere nicht geht (gleicher Typ) aber es gibt hin und wieder wohl Timing-Probleme mit CUL und Homematic.
https://forum.fhem.de/index.php/topic,56690.msg482089.html#msg482089 (https://forum.fhem.de/index.php/topic,56690.msg482089.html#msg482089)
Vielleicht hilft das...
...da ja (wie bei mir) mehrfaches Zurücksetzen und neu Pairen nicht klappt...
Gruß, Joachim
Ja, ist ein CUL.
Das Thema mit der neuen Firmware habe ich schon gesehen.
Bin jedoch skeptisch, ob die experimentelle(?) FW hier Besserung bringt.
Zumal ein Display problemlos funktioniert.
Ich bin erst einmal auf der Suche nach der Ursache und möchte verstehen was da eigentlich schief läuft.
Ein erster Versuch die Kommunikation mit zu schneiden hat bei mir mehr Fragezeichen hinterlassen als mögliche Hinweise...
Dann am besten mal den Mitschnitt hier (in code Tags '#') posten...
Dann besteht die Chance, dass jemand drüber kuckt der sieht wo der Fehler liegt und (vielleicht) auch ne Lösung hat...
Gruß, Joachim
Ich bin mir bei der Menge an der für mich nur schwer identifizierbarer Informationen noch nicht einmal sicher was ich jetzt hier zeigen sollte.
Ich versuch's mit folgendem Ausschnitt einer getConfig Kommunikation:
(Vielleicht kann jemand fachkundige Interpretationshilfe leisten...)
2016.08.20 13:18:02 4: CUL_Parse: CUL_0 A 0C 4E 8670 3F7B5E 000000 00D3432A -53
2016.08.20 13:18:37.052 4: CUL_Parse: CUL_0 A 0F 3B 8610 21DC66 000000 0A890C080018BF -106.5
2016.08.20 13:18:55.458 4: CUL_Parse: CUL_0 A 0F 78 8610 3F65A2 000000 0A910A0E0000C8 -102
2016.08.20 13:19:55.501 4: CUL_Parse: CUL_0 A 0C 7C 8670 207080 000000 00DC3ECC -100
2016.08.20 13:20:07.752 4: CUL_Parse: CUL_0 A 0B 06 A240 4656F0 D8814F 01021E -59
2016.08.20 13:20:07.852 4: CUL_send: CUL_0As 0A 06 8002 D8814F 4656F0 00
2016.08.20 13:20:07.965 4: CUL_send: CUL_0As 13 07 A011 D8814F 4656F0 8001020A0A0A0A0A0A03
2016.08.20 13:20:08.119 4: CUL_Parse: CUL_0 A 0A 07 8002 4656F0 D8814F 001E -59
2016.08.20 13:20:30.414 4: CUL_Parse: CUL_0 A 1A 07 8400 4656F0 D8814F 1000D34E4551303130333833321211000025 -55.5
2016.08.20 13:20:30.417 1: General --------- start me
2016.08.20 13:20:30.514 4: CUL_send: CUL_0As 10 1C A001 D8814F 4656F0 00040000000000
2016.08.20 13:20:40.595 4: CUL_Parse: CUL_0 A 0C 4F 8670 3F7B5E 000000 00D3432B -52.5
2016.08.20 13:20:56.166 4: CUL_Parse: CUL_0 A 1A 08 8400 4656F0 D8814F 1000D34E455130313033383332121100000F -66.5
2016.08.20 13:20:56.169 1: General --------- start me
2016.08.20 13:20:56.169 1: General --------- stop me###########
2016.08.20 13:21:02.833 4: CUL_Parse: CUL_0 A 1A 09 8400 4656F0 D8814F 1000D34E4551303130333833321211000011 -65.5
2016.08.20 13:21:02.836 1: General --------- start me
2016.08.20 13:21:02.837 1: General --------- stop me###########
2016.08.20 13:21:32.953 4: CUL_Parse: CUL_0 A 0F 79 8610 3F65A2 000000 0A91090E0000C8 -102
2016.08.20 13:21:46.410 4: CUL_Parse: CUL_0 A 1A 0A 8400 4656F0 D8814F 1000D34E455130313033383332121100001F -58.5
2016.08.20 13:21:46.414 1: General --------- start me
2016.08.20 13:21:46.414 1: General --------- stop me###########
2016.08.20 13:22:23.307 4: CUL_Parse: CUL_0 A 0C 34 A641 404D00 D8814F 0126C8EC -84
2016.08.20 13:22:23.409 4: CUL_send: CUL_0As 0D 34 8002 D8814F 404D00 0101C800
2016.08.20 13:22:52.810 4: CUL_Parse: CUL_0 A 0C 35 A641 404D00 D8814F 012700EF -82.5
2016.08.20 13:22:52.911 4: CUL_send: CUL_0As 0D 35 8002 D8814F 404D00 0101C800
2016.08.20 13:22:56.508 4: CUL_Parse: CUL_0 A 0C 7D 8670 207080 000000 00DC3FCC -100
2016.08.20 13:23:03.849 4: CUL_Parse: CUL_0 A 0C 50 8670 3F7B5E 000000 00D3432A -53
2016.08.20 13:23:31.530 4: CUL_Parse: CUL_0 A 0B 0B A240 4656F0 D8814F 01031E -59
2016.08.20 13:23:31.632 4: CUL_send: CUL_0As 0A 0B 8002 D8814F 4656F0 00
2016.08.20 13:23:31.745 4: CUL_send: CUL_0As 13 0C A011 D8814F 4656F0 8001020A0A0A0A0A0A03
2016.08.20 13:23:31.899 4: CUL_Parse: CUL_0 A 0A 0C 8002 4656F0 D8814F 001D -59.5
2016.08.20 13:23:36.691 4: CUL_Parse: CUL_0 A 1A 0C 8400 4656F0 D8814F 1000D34E455130313033383332121100001B -60.5
scheint schon gepairt. logge einmal ein getConfig.
Zumindest behauptet das Display das, in FHEM bleibt das set_0xD8814F stehen...
Hier ein getConfig mitschnitt mit erneutem RESPONSE TIMEOUT:RegisterRead:
2016.08.20 17:37:21.099 4: CUL_Parse: CUL_0 A 0B 09 A240 4656F0 D8814F 020214 -64
2016.08.20 17:37:21.199 4: CUL_send: CUL_0As 0A 09 8002 D8814F 4656F0 00
2016.08.20 17:37:21.311 4: CUL_send: CUL_0As 13 0A A011 D8814F 4656F0 8001020A0A0A0A0A0A03
2016.08.20 17:37:21.464 4: CUL_Parse: CUL_0 A 0A 0A 8002 4656F0 D8814F 0016 -63
2016.08.20 17:38:18.050 4: CUL_Parse: CUL_0 A 1A 0A 8400 4656F0 D8814F 1000D34E4551303130333833321211000021 -57.5
2016.08.20 17:38:18.054 1: General --------- start me
2016.08.20 17:38:18.151 4: CUL_send: CUL_0As 10 1F A001 D8814F 4656F0 00040000000000
2016.08.20 17:38:28.678 4: CUL_Parse: CUL_0 A 0D 1D A610 3F6BC9 1F8727 0601C800C8 -102
2016.08.20 17:38:28.940 4: CUL_Parse: CUL_0 A 19 1D A603 3F6BC9 1F8727 78EA587E0F8E35CC15754360454E36BFC7 -102.5
ZitatHier ein getConfig mitschnitt mit erneutem RESPONSE TIMEOUT:RegisterRead:
drückst du auch aufs knöpfchen?
Ja, bin doch geübt durch Nr. 1.
Nr. 2 verhält sich auch optisch anders.
Während Nr.1 mit "Übernehmen" schnell orange/grün blinkt, startet Nr. 2 kurz und blinkt dan nur noch weiss/grün.
Gibt der letze Mitschnitt irgendeine Erkenntnis preis?
er gibt kein mucks von sich. deshalb ja meine frage.
fehler beim zusammenbauen?
Hmmm, ausschliessen kann man das ja nie.
Dennoch möchte ich mich als geübten Löter bezeichnen.
Und kontrolliert habe ich das (optisch) natürlich schon.
Wirklich schwierig und/oder umfangreich war der Zusammenbau ja eigentlich nicht.
Ich werd's jedenfalls morgen nochmals kontrollieren...
Es ist ja nicht so, dass gar nichts am CUL ankommt.
Das Pairing startet und die Signalstärke ist der Position angemessen.
die anlernmessage vom knöpfchen drücken war ja doch zu sehen, aber der schalter reagiert halt nicht mehr auf die getconfig message. könnte also ein timingproblem sein.
wiederhole bis es klappt (cmds_done), sonst die optimierte fw.
ZitatDas Thema mit der neuen Firmware habe ich schon gesehen.
Bin jedoch skeptisch, ob die experimentelle(?) FW hier Besserung bringt.
Moin Moin!
Habe soeben nochmals meinen Zusammenbau unter der grossen Lupe überprüft: sieht wirklich absolut einwandfrei aus.
Alles wieder zusammengesteckt, auf Werkseinstellungen zurückgesetzt und in FHEM das alte Device entfernt.
Dann ein "set VCCU hmPairForSec 60", den Taster auf der Rückseite gedrückt, Anlernen per unteren Fronttaster gestartet, "Starten" blinkt einige Sekunden weiss/orange.
In FHEM wurde das Device unter CUL_HM hinzugefügt, allerdings noch mit "R-pairCentral: set_0xD8814F".
Ein getConfig und einmal dann den unteren Taster "Übernehmen": kurzes orange/grünes Blinken "Übernehmen", dann weiss/grünes Blinken "Übernehmen" für mehrere Sekunden.
In FHEM wieder ein "RESPONSE TIMEOUT:RegisterRead"...
Hier nochmals ein aktueller Mitschnitt:
2016.08.21 11:30:30.462 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 3018.
2016.08.21 11:30:30.644 4: CUL_send: CUL_0As 10 16 A001 D8814F 4656F0 00050000000000
2016.08.21 11:30:30.803 4: CUL_Parse: CUL_0 A 11 16 A002 4656F0 D8814F 04194E1A2C194E0029 -53.5
2016.08.21 11:30:30.904 4: CUL_send: CUL_0As 19 16 A003 D8814F 4656F0 8fa47595f8890fb40419b4e7601ff8b3
2016.08.21 11:30:31.061 4: CUL_Parse: CUL_0 A 0E 16 8002 4656F0 D8814F 0034042C6329 -53.5
2016.08.21 11:30:31.161 4: CUL_send: CUL_0As 13 17 A001 D8814F 4656F0 000802010AD80B810C4F
2016.08.21 11:30:31.322 4: CUL_Parse: CUL_0 A 11 17 A002 4656F0 D8814F 042DB02E8E2DB00029 -53.5
2016.08.21 11:30:31.423 4: CUL_send: CUL_0As 19 17 A003 D8814F 4656F0 a42e19eccfc193b3073ef7fd73c056d0
2016.08.21 11:30:31.586 4: CUL_Parse: CUL_0 A 0E 17 8002 4656F0 D8814F 007D23FCC929 -53.5
2016.08.21 11:30:31.687 4: CUL_send: CUL_0As 0B 18 A001 D8814F 4656F0 0006
2016.08.21 11:30:31.845 4: CUL_Parse: CUL_0 A 11 18 A002 4656F0 D8814F 04811767F581170028 -54
2016.08.21 11:30:31.945 4: CUL_send: CUL_0As 19 18 A003 D8814F 4656F0 fcdc6a3bda3a230587f5b5982270d6d3
2016.08.21 11:30:32.144 4: CUL_Parse: CUL_0 A 0E 18 8002 4656F0 D8814F 007D1306E029 -53.5
2016.08.21 11:30:41.875 4: CUL_Parse: CUL_0 A 0C 88 8670 207080 000000 009255D3 -96.5
2016.08.21 11:31:07.829 4: CUL_Parse: CUL_0 A 1A 02 8400 4656F0 D8814F 1000D34E4551303130333833321211000028 -54
2016.08.21 11:31:07.832 1: General --------- start me
2016.08.21 11:31:07.930 4: CUL_send: CUL_0As 10 17 A001 D8814F 4656F0 00040000000000
2016.08.21 11:31:19.957 4: CUL_Parse: CUL_0 A 1A 03 8400 4656F0 D8814F 1000D34E4551303130333833321211000028 -54
2016.08.21 11:31:19.960 1: General --------- start me
2016.08.21 11:31:19.960 1: General --------- stop me###########
2016.08.21 11:31:21.776 4: CUL_Parse: CUL_0 A 1A 04 8400 4656F0 D8814F 1000D34E4551303130333833321211000028 -54
2016.08.21 11:31:21.779 1: General --------- start me
2016.08.21 11:31:21.779 1: General --------- stop me###########
2016.08.21 11:31:28.439 4: CUL_Parse: CUL_0 A 1A 05 8400 4656F0 D8814F 1000D34E4551303130333833321211000028 -54
2016.08.21 11:31:28.442 1: General --------- start me
2016.08.21 11:31:28.443 1: General --------- stop me###########
2016.08.21 11:31:58.799 4: CUL_Parse: CUL_0 A 0C 5C 8670 3F7B5E 000000 00CA402B -52.5
2016.08.21 11:32:20.073 4: CUL_Parse: CUL_0 A 1A 06 8400 4656F0 D8814F 1000D34E4551303130333833321211000029 -53.5
2016.08.21 11:32:20.077 1: General --------- start me
2016.08.21 11:32:20.077 1: General --------- stop me###########
2016.08.21 11:32:57.881 4: CUL_Parse: CUL_0 A 0C 89 8670 207080 000000 009155D3 -96.5
2016.08.21 11:34:26.553 4: CUL_Parse: CUL_0 A 0C 5D 8670 3F7B5E 000000 00CA402A -53
2016.08.21 11:34:46.158 4: CUL_Parse: CUL_0 A 0D C3 A610 434249 1F8727 06010000D0 -98
2016.08.21 11:36:39.807 4: CUL_Parse: CUL_0 A 0C 5E 8670 3F7B5E 000000 00CA402A -53
2016.08.21 11:37:53.045 4: CUL_Parse: CUL_0 A 0D BE A610 4349F5 D8814F 06010000FA -77
2016.08.21 11:37:53.146 4: CUL_send: CUL_0As 0A BE 8002 D8814F 4349F5 00
2016.08.21 11:39:42.813 4: CUL_Parse: CUL_0 A 0C 5F 8670 3F7B5E 000000 00CA402B -52.5
2016.08.21 11:40:05.576 4: CUL_Parse: CUL_0 A 0D 00 A610 43431D 1F8727 06010000D2 -97
2016.08.21 11:40:05.839 4: CUL_Parse: CUL_0 A 19 00 A603 43431D 1F8727 463A46F5197FFBCE8769436EDB7D019DD0 -98
2016.08.21 11:40:27.147 4: CUL_Parse: CUL_0 A 0C 8C 8670 207080 000000 008F56D0 -98
2016.08.21 11:42:19.736 4: CUL_Parse: CUL_0 A 0C 01 A641 43431D 1F8727 01F1C8D3 -96.5
2016.08.21 11:42:20.000 4: CUL_Parse: CUL_0 A 19 01 A603 43431D 1F8727 449AEA01F3D1FE3B78F4E67521646EBED5 -95.5
2016.08.21 11:42:20.532 4: CUL_Parse: CUL_0 A 0C 02 A241 43431D 1F8727 01F1C8CF -98.5
2016.08.21 11:42:20.795 4: CUL_Parse: CUL_0 A 19 02 A203 43431D 1F8727 5DE821FCA3E81F0B0E9180B24010968BCE -99
2016.08.21 11:42:31.317 4: CUL_Parse: CUL_0 A 0C 60 8670 3F7B5E 000000 00CA402B -52.5
2016.08.21 11:42:39.178 4: CUL_Parse: CUL_0 A 0B 07 A240 4656F0 D8814F 010129 -53.5
2016.08.21 11:42:39.279 4: CUL_send: CUL_0As 0A 07 8002 D8814F 4656F0 00
2016.08.21 11:42:39.392 4: CUL_send: CUL_0As 13 08 A011 D8814F 4656F0 8001020A0A0A0A0A0A03
2016.08.21 11:42:39.546 4: CUL_Parse: CUL_0 A 0A 08 8002 4656F0 D8814F 0029 -53.5
2016.08.21 11:42:55.259 4: CUL_Parse: CUL_0 A 0C 03 A641 43431D 1F8727 01F200D1 -97.5
2016.08.21 11:42:55.523 4: CUL_Parse: CUL_0 A 19 03 A603 43431D 1F8727 788F0308C860BEFD13AFB4E65C8052B6CF -98.5
2016.08.21 11:42:55.799 4: CUL_Parse: CUL_0 A 12 28 8002 394A0E 1F8727 010502002E0002AAAAC3 -104.5
2016.08.21 11:42:56.084 4: CUL_Parse: CUL_0 A 0C 04 A241 43431D 1F8727 01F200D1 -97.5
2016.08.21 11:42:56.349 4: CUL_Parse: CUL_0 A 19 04 A203 43431D 1F8727 618B7E979133BB38CD27240208A316C7D0 -98
2016.08.21 11:44:57.157 4: CUL_Parse: CUL_0 A 0C 8E 8670 207080 000000 008E56CC -100
2016.08.21 11:45:05.321 4: CUL_Parse: CUL_0 A 0C 61 8670 3F7B5E 000000 00CA402B -52.5
2016.08.21 11:45:24.344 4: CUL_Parse: CUL_0 A 1A 08 8400 4656F0 D8814F 1000D34E4551303130333833321211000028 -54
2016.08.21 11:45:24.348 1: General --------- start me
2016.08.21 11:45:35.397 4: CUL_Parse: CUL_0 A 1A 09 8400 4656F0 D8814F 1000D34E4551303130333833321211000028 -54
2016.08.21 11:45:35.401 1: General --------- start me
2016.08.21 11:45:35.401 1: General --------- stop me###########
2016.08.21 11:45:51.527 4: CUL_Parse: CUL_0 A 1A 0A 8400 4656F0 D8814F 1000D34E4551303130333833321211000029 -53.5
2016.08.21 11:45:51.530 1: General --------- start me
2016.08.21 11:45:51.531 1: General --------- stop me###########
2016.08.21 11:45:58.793 4: CUL_Parse: CUL_0 A 0F 8C 8610 3F65A2 000000 0A90F80E0000BE -107
Ich habe mich gegen die optimierte FW entschieden und werde das Display erst einmal reklamieren - das erste hat schliesslich auch ohne funktioniert.
Ohne eine offizielle Übernahme dieser Firmware und der angepassten Module wäre das für mich eine Sackgasse bzgl. zukünftiger Updates.
das pairen funktioniert prima, obwohl du sogar aes angeschaltet hast.
er antwortet nur nicht auf das getconfig.
aes macht das schlechte timing der cul geräte nicht einfacher. ist das beim anderen schalter ebenfalls eingeschaltet? vielleicht liegt es daran.
ZitatOhne eine offizielle Übernahme dieser Firmware und der angepassten Module wäre das für mich eine Sackgasse bzgl. zukünftiger Updates.
entweder timingoptimierte homematic io's nutzen, oder beim "chef" den wunsch der übernahme der timing verbesserungen äussern.
AES ist bei einigen Kontakten und auch beim anderen Display eingeschaltet.
(Weniger weil ICH das eingeschaltet habe, sondern weil's default war - wenn's funktioniert: Finger weg lassen.)
Den Wunsch beim Chef äussere ich gern. Wer isses denn?
Chef de Mission und zusätzlich owner der 00_cul ist Rudi.
Mittlerweile ist 00_cul für hm schon weit fortgeschritten so dass Rudi tatsächlich Probleme haben wird, die Änderungen abzusehen. Die Versuche ihn bereits auf dem Weg mitzunehmen sind gescheitert.
Somit sehe ich keine Chance dass es über Rudi noch etwas wird. Dein Problem verstehe ich ebenfalls.
Aktuell hast du die beschriebene Wahl. Ich denke einmal über eine gütliche Einigung zwischen den beiden Entwicklern nach ;)
Ahaa: "Moderator" und "Hero Member"
;)
Viel Erfolg!
Ich kann Rudi nach Deiner Beschreibung aber ebenfalls gut verstehen...
Mei Vorschlag ist ein io cul-hm bereitzustellen. Das kann man in fhem einbinden. Rudi hat weiterhin sei universal culio was hm nicht sauber unterstützt und für welches ich keinen Support liefere.
Der User kann die cul für hm nutzen ODER fuer eine andere Familie.
Er muss das Perl Modul (also den Typ bei der Definition) wählen. Auch der fwupdate sollte entsprechend implementiert werden.
Damit sollte Rudi, Ansgar, ich, du und alle anderen Leben koennen.
Das hört sich für mich praktikabel an.
Vielleicht habt Ihr eine Möglichkeit das so um zu setzen.
8)
Kurze Rückmeldung zum reklamierten Display:
Der neue Bausatz erreichte mich eben - habe also einen Kompletttausch bekommen.
Leider KEINE Besserung, auch das neue Display kann nicht vollständig gepaired werden.
Dieselbe Firmware 1.0 und derselbe Bausatz.
Nach Überprüfung des ersten funktionstüchtigen Displays und einem erneuten getConfig bekomme ich auch dort einen RESPONSE TIMEOUT.
Ich nehme an, dass zwischen dem Anlernen des ersten und des zweiten Displays eine Änderung des Code zu diesem Verhalten führte.
Ich muss mir jetzt überlegen wie ich weiter machen werde, so kann das nicht bleiben...
:(
Im Log einige Zeit zurück sehe ich ein Pairen und AES gesendet von einer CUL ohne "HW-FW".
Es ist immer noch sehr kritisch eine CUL mit der "standart-FW" mit HM zu nutzen - insbesondere bei Kommunikation mit Timing Anforderungen wie AES und aktionen die mehrere Message austauschen.
Ein Debuggen lohnt sich nicht - haben wir vor ~2 Jahren aufgegeben.
Es git eine FW die Timing korrekturen ermöglicht. Wer die nicht nutzt muss seine (selbst verschuldeten) Probleme selbst lösen - es geht halt nicht.
Es liegt nicht am HM device.
Zitat von: martinp876 am 03 September 2016, 15:05:38
Es git eine FW die Timing korrekturen ermöglicht. Wer die nicht nutzt muss seine (selbst verschuldeten) Probleme selbst lösen - es geht halt nicht.
Ich würde ja gerne, wenn's denn funktionierte.
Ich teste gerade mit Ansgars FW und bekomme nur Probleme: Cannot init /dev/ttyACM0, ignoring it (CUL_0)
Da kann ICH doch eigentlich nicht viel verbocken - das Flashen der FW und der anschliessende Verify liefen problemlos durch.
Die 00_CUL.pm ersetzen fertig - ODER?
so ist es.
da meine CUL verstorben ist kann ich es nicht mehr probieren. Also sie noch lief ging es ohne Probleme.
Ansgar wird sicher antworten.
Ansgar hat mir den entscheidenden Tipp gegeben!
Nach dem Flashen haben meine beiden USB Devices mal eben die /dev/ttyAMA* getauscht.
Da konnte nicht mehr viel kommen.
Lustigerweise haben sie nach Flashen der ursprünglichen Version wieder zurück getauscht.
Dann funktionierte wieder alles und ich dachte natürlich es läge an der FW...
Hi,
wenn die beim/nach dem Booten mal tauschen, dann besser einbinden per /dev/serial/by-id bzw. (wie ich, da selbe ID) /dev/serial/by-path (dann halt nicht unstecken, eh klar)...
Mit der alternativen/optimierten FW und den angepassten Modulen habe ich jetzt auch keine Probleme mehr.
Gebe dir Recht: blöd, dass es nicht im Standard ist...
Aber bei mir tragbar, da es "nur" ein Testsystem ist...
Bei meinen "richtigen" Systemen habe ich HM-CFG-USB bzw. neuerdings HM-UART...
Gruß, Joachim
Hallo Joachim,
kannst Du bitte mal ein Pairing und getConfig mit HM-CFG-USB mit
attr global mseclog 1 und verbose 4 mit loggen, falls Su so ein Display hast. Oder jemand anderes?
Es könnte sein, dass Martins letzte Änderung bezüglich Pairing in 10_CUL_HM.pm wegen des Klingelsensors bei dem Display jetzt Probleme bereitet, da nun auf wiederholtes Request nicht mehr neu gesendet wird (wie auch im Log zu getConfig zu sehen).
ZitatOhne eine offizielle Übernahme dieser Firmware und der angepassten Module wäre das für mich eine Sackgasse bzgl. zukünftiger Updates.
ZitatIch denke einmal über eine gütliche Einigung zwischen den beiden Entwicklern nach
Rudi hat leider nicht genügend Zeit und Energie, um alle aufgelaufenen Änderungen meinerseits zu prüfen und zu testen. Dazu habe ich zu weit ausgeholt und teilweise ausholen müssen.
ZitatMein Vorschlag ist ein io cul-hm bereitzustellen.
Die Sackgasse hat zu weiteren unabhängigen Entwicklungen meinerseits geführt, die ich nicht mehr missen möchte und vom "Standard" 00_CUL.pm usw. nicht unterstützt werden.
Ich arbeite derzeit an einem 00_TSCUL.pm, 16_TSSTACKED.pm, plus weiterer Sondermodule. Damit kann man dann die Timestamp Firmware für HM nutzen und 00_CUL.pm etc. kann Updates erfahren ohne dass es zu Konflikten kommen sollte.
Da auch meine Zeit und Energie sehr begrenzt ist, ist das auch erst mal der schnellste Weg.
Ein jeweils "geringer" Eingriff seitens Rudi und Martin wird aber nicht zu vermeiden sein, da z.B. der {TYPE} an einigen Code Stellen abgefragt/benötigt wird und ein (ggf. suboptimaler) Mischbetrieb mit mehrenen CUL Devices, insbesondere bei STACKABLE_CC möglich bleiben muss.
Gruß, Ansgar.
Hi Ansgar,
gerne.
Habe beide Displays...
Bin allerdings grad nicht zuhause bis Mitte der Woche...
Wenn sich bis dahin niemand gefunden hat reiche ich es nach... ;-)
Kann ja auch mal mit dem "Spezial-CUL" am Testsystem testen...
Und auch mal HM-UART...
Gruß, Joachim
P.S.: ist auch eine gute Gelegenheit die "aufgeräumten" Module einzuspielen... Hatte dazu bislang keine Zeit/Anlass...
Hi Ansgar,
also ich hab mal mein Hauptsystem (HM-CFG-USB) auf den neuesten Stand gebracht und die Einstellungen vorgenommen.
Allerdings verbose 4 bei global spuckt sehr viel (unnützes) Zeugs raus...
...und mit verbose 4 nur beim hmusb steht nicht wirklich viel im Log...
2016.09.09 11:51:04.897 3: CUL_HM set vccu hmPairForSec 60
2016.09.09 11:51:13.858 2: CUL_HM Unknown device HM_3515DA is now defined
2016.09.09 11:51:13.877 2: autocreate: define HM_3515DA CUL_HM 3515DA
2016.09.09 11:51:13.882 2: autocreate: define FileLog_HM_3515DA FileLog ./log/HM_3515DA-%Y.log HM_3515DA
2016.09.09 11:51:14.518 3: CUL_HM pair: HM_3515DA pushButton, model HM-Dis-WM55 serialNr
2016.09.09 11:51:25.621 4: HMLAN_ack: timeout - clear queue
2016.09.09 11:51:39.542 3: CUL_HM set HM_3515DA getConfig
2016.09.09 11:51:48.578 1: my_StoreBatteryStatus ignoring Device: HM_3515DA
2016.09.09 11:51:58.659 4: HMLAN_ack: timeout - clear queue
Was würde dir helfen?
Gruß, Joachim
Hi Ansgar,
hab nun doch noch mal mit global verbose 4 versucht möglichst wenig "Schrott" zu loggen...
2016.09.09 12:20:01.876 3: CUL_HM set vccu hmPairForSec 60
2016.09.09 12:20:01.909 4: WEB_192.168.1.72_43588 GET /fhem?detail=vccu&fw_id=; BUFLEN:0
2016.09.09 12:20:01.962 4: name: /fhem?detail=vccu&fw_id= / RL:5326 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:02.645 4: WEB_192.168.1.72_43588 GET /fhem?cmd={ReadingsVal(%22vccu%22,%22virtual%22,%22%22)}&XHR=1; BUFLEN:0
2016.09.09 12:20:02.652 4: name: /fhem?cmd={ReadingsVal(%22vccu%22,%22virtual%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:02.662 4: WEB_192.168.1.72_43588 GET /fhem?cmd={AttrVal(%22vccu%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.09.09 12:20:02.668 4: name: /fhem?cmd={AttrVal(%22vccu%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:02.789 4: WEB_192.168.1.72_43588 GET /fhem?XHR=1&inform=type=status;filter=vccu;since=1473416400;fmt=JSON&fw_id=976×tamp=1473416402754; BUFLEN:0
2016.09.09 12:20:08.287 2: CUL_HM Unknown device HM_3515DA is now defined
2016.09.09 12:20:08.325 2: autocreate: define HM_3515DA CUL_HM 3515DA
2016.09.09 12:20:08.329 2: autocreate: define FileLog_HM_3515DA FileLog ./log/HM_3515DA-%Y.log HM_3515DA
2016.09.09 12:20:08.963 3: CUL_HM pair: HM_3515DA pushButton, model HM-Dis-WM55 serialNr
2016.09.09 12:20:20.755 4: HMLAN_ack: timeout - clear queue
2016.09.09 12:20:22.311 4: WEB_192.168.1.72_43592 POST /fhem?cmd=save&XHR=1&fw_id=976; BUFLEN:0
2016.09.09 12:20:22.347 4: WriteStatefile HM_3515DA_Dis_01 peerList: Missing TIME, using current time
2016.09.09 12:20:22.456 4: name: /fhem?cmd=save&XHR=1&fw_id=976 / RL:52 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:30.192 4: Connection closed for WEB_192.168.1.72_43588: EOF
2016.09.09 12:20:30.206 4: WEB_192.168.1.72_43592 GET /fhem?room=CUL%5fHM; BUFLEN:0
2016.09.09 12:20:30.268 4: name: /fhem?room=CUL%5fHM / RL:1644 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:30.977 4: WEB_192.168.1.72_43592 GET /fhem?XHR=1&inform=type=status;filter=room=CUL%5fHM;since=1473416429;fmt=JSON&fw_id=978×tamp=1473416430941; BUFLEN:0
2016.09.09 12:20:31.552 4: SetSavedDesTemp exec {my_StoreDesTemp($NAME, $EVENT)}
2016.09.09 12:20:35.049 4: WEB_192.168.1.72_43590 POST /fhem?cmd.HM_3515DA=set%20HM_3515DA%20getConfig&room=CUL_HM&XHR=1&fw_id=978; BUFLEN:0
2016.09.09 12:20:35.490 3: CUL_HM set HM_3515DA getConfig
2016.09.09 12:20:35.495 4: name: /fhem?cmd.HM_3515DA=set%20HM_3515DA%20getConfig&room=CUL_HM&XHR=1&fw_id=978 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.09 12:20:36.821 4: SetBatteryStatus exec {my_StoreBatteryStatus($NAME, $EVENT)}
2016.09.09 12:20:36.822 1: my_StoreBatteryStatus ignoring Device: HM_3515DA
2016.09.09 12:20:37.206 4: SetBatteryStatus exec {my_StoreBatteryStatus($NAME, $EVENT)}
2016.09.09 12:20:37.208 4: SetBatteryStatus exec {my_StoreBatteryStatus($NAME, $EVENT)}
2016.09.09 12:20:42.856 4: WEB_192.168.1.72_43590 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-09.log; BUFLEN:0
Wenn du noch was brauchst einfach melden...
Macht es Sinn das Display bei mir auf meinem Testsystem ("Spezial-CUL") anzumelden?
Oder auf dem HMUART-System?
Gruß, Joachim
Hallo Dog_Martin,
ich habe ein ähnliches/gleiches? Problem.
https://forum.fhem.de/index.php/topic,43022.0.html
Woran lag es jetzt bei dir?
Leider habe ich deine Aussage jetzt nicht so genau verstanden. Das tauschen der /dev/ttyAMA* kam ja erst durchs flashen oder?
Dank & Gruß Marcus
Hallo Joachim,
in Deinen Logs sehe ich nicht die Rohdaten von HM CFGUSB. Beim dem fehlt der passende verbose.
Aber mir wäre es hilfreich, wenn Du parallel auf Deinem Testsystem mit verbose 4 beim "Spezial CUL" den ganzen Vorgang vom scharfen System loggen/mitlauschen könntest. Dann habe ich auch gleich alle Timing Infos.
Danke!
@Marcus: Ja, nach dem Flashen hat sich die /dev/ttyAMA* Schnittstelle geändert. Das kann sich ggf. auch nach einem Reboot des Systems nochmal ändern. Mit
dmesg
auf einer Linux Konsole/Terminal kannst Du herraus lesen, auf welcher Schnittstelle das device landet.
Gruß, Ansgar.
Hi Ansgar,
hab ich mir schon gedacht, war mir auch zu wenig...
Hatte aber verbose 4 bei global und dem hmusb...
Soll ich auf 5 gehen?
Oder fehlt noch wo was?
Pairing stosse ich von der vccu aus an...
Hab heute Nachmitrag/Abend noch mal Zeit was zu testen...
Werde dann auch mal auf meinem Testsystem (spezial-CUL) pairen...
Wichtig für mich: welche Einstellungen wo, damit du die notwendigen Infos bekommst...
Gruß, Joachim
Hallo Ansgar,
danke für deine Nachricht. Mein device stimmt.
Ich wollte insbesondere wissen, ob du sonst etwas verändert hast. Du hast je geflashed um das Problem zu lösen nehme ich an. Das Problem bestand also schon vorher.
Bei dir ging es also einfach mit neuem flashen des CUL und danach anpassen des device?
Dank & Gruß Marcus
Hallo Joachim,
ja, versuch es mal mit verbose 5 auf dem scharfen System. Ich sehe nicht, was gesendet/empfangen wird.
Auf dem Testsystem kannst Du natürlich auch mal pairen und loggen, das würde das Fehlverhalten aufzeichnen.
Aber eigentlich interessiert mich, wie es mt hmusb "richtig" abläuft und nur wenn Du auf dem Testsystem mit verbose 4 bei CUL mitloggst, was auf dem scharfen System im Äther passiert sehe ich was vernünftiges.
@Marcus: In der Timestamp Firmware habe ich eine USB Seriennummer implementiert. Die kann man bei Bedarf beim Kompilieren auch je CUL individuell einstellen. Damit ist eine eindeutige Zuordnung mehrer CULs anhand der Seriennummer möglich.
Offenbar führt das ggf. zu einer Änderung der automatischen Schnittstellenzuordnung. Damit musst Du also ggf. die Schnittstelle in der fhem.cfg für den CUL anpassen, um CUL wieder nutzen zu können. Nach einen Systemneustart kann die Zuordnung auch wieder anders sein.
Mit der "/etc/udev/rules.d/99-usb-serial.rules" kannst Du die USB Seriennummer nutzen, um einen eindeutigen Schnittstellen link zu erzeugen.
#/etc/udev/rules.d/99-usb-serial.rules
#CUL 868MHz
SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="868000", SYMLINK+="CUL868_0"
damit in fhem.cfg
define CUL_HM868 CUL /dev/CUL868_0@12000000 1034
Auf diese Art habe ich 2 CULs an meinem RasPi zu eindeutigen Schnittstellen bringen können.
Dein eigentliches Problem mit dem Display ist dann der nächste Akt. Und das scheint noch nicht gelöst.
Gruß, Ansgar.
Hi Ansgar,
so ich hab mein Hauptsystem mit dem hmusb mal "leer geräumt", damit nicht so viel unnützes Zeugs drin steht...
Hier das Log von Pairing und getConfig:
2016.09.11 01:22:03.536 5: Cmd: >set vccu hmPairForSec 60<
2016.09.11 01:22:03.538 3: CUL_HM set vccu hmPairForSec 60
2016.09.11 01:22:03.575 4: WEB_192.168.1.72_48234 GET /fhem?detail=vccu&fw_id=; BUFLEN:0
2016.09.11 01:22:03.611 4: name: /fhem?detail=vccu&fw_id= / RL:5333 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.11 01:22:04.229 4: WEB_192.168.1.72_48234 GET /fhem?cmd={ReadingsVal(%22vccu%22,%22virtual%22,%22%22)}&XHR=1; BUFLEN:0
2016.09.11 01:22:04.230 5: Cmd: >{ReadingsVal("vccu","virtual","")}<
2016.09.11 01:22:04.238 4: name: /fhem?cmd={ReadingsVal(%22vccu%22,%22virtual%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.11 01:22:04.245 4: WEB_192.168.1.72_48234 GET /fhem?cmd={AttrVal(%22vccu%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.09.11 01:22:04.246 5: Cmd: >{AttrVal("vccu","room","")}<
2016.09.11 01:22:04.254 4: name: /fhem?cmd={AttrVal(%22vccu%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.11 01:22:04.364 4: WEB_192.168.1.72_48234 GET /fhem?XHR=1&inform=type=status;filter=vccu;since=1473549722;fmt=JSON&fw_id=62×tamp=1473549724271; BUFLEN:0
2016.09.11 01:22:04.940 5: HMLAN/RAW: /E3227F4,0000,0001D28F,FF,FFBE,F3865A3227F4000000910139
2016.09.11 01:22:04.941 5: HMLAN_Parse: hmusb R:E3227F4 stat:0000 t:0001D28F d:FF r:FFBE m:F3 865A 3227F4 000000 910139
2016.09.11 01:22:04.942 5: hmusb dispatch A0CF3865A3227F4000000910139::-66:hmusb
2016.09.11 01:22:05.644 5: HMLAN/RAW: /E2B8E86,0000,0001D532,FF,FFBD,2886102B8E860000000A99020B0040
2016.09.11 01:22:05.645 5: HMLAN_Parse: hmusb R:E2B8E86 stat:0000 t:0001D532 d:FF r:FFBD m:28 8610 2B8E86 000000 0A99020B0040
2016.09.11 01:22:05.646 5: hmusb dispatch A0F2886102B8E860000000A99020B0040::-67:hmusb
2016.09.11 01:22:09.036 5: HMLAN/RAW: /E3515DA,0000,0001E27F,FF,FFDA,0184003515DA0000001000D34D45513030323237363812110000
2016.09.11 01:22:09.042 5: HMLAN_Parse: hmusb R:E3515DA stat:0000 t:0001E27F d:FF r:FFDA m:01 8400 3515DA 000000 1000D34D45513030323237363812110000
2016.09.11 01:22:09.043 5: hmusb dispatch A1A0184003515DA0000001000D34D45513030323237363812110000::-38:hmusb
2016.09.11 01:22:09.044 2: CUL_HM Unknown device HM_3515DA is now defined
2016.09.11 01:22:09.044 5: Triggering global (1 changes)
2016.09.11 01:22:09.045 5: Starting notify loop for global, first event UNDEFINED HM_3515DA CUL_HM 3515DA
2016.09.11 01:22:09.047 2: autocreate: define HM_3515DA CUL_HM 3515DA
2016.09.11 01:22:09.048 5: Triggering global (2 changes)
2016.09.11 01:22:09.050 2: autocreate: define FileLog_HM_3515DA FileLog ./log/HM_3515DA-%Y.log HM_3515DA
2016.09.11 01:22:09.052 5: Triggering global (3 changes)
2016.09.11 01:22:09.059 5: Triggering global (1 changes)
2016.09.11 01:22:09.060 5: Starting notify loop for global, first event DEFINED HM_3515DA_Dis_01
2016.09.11 01:22:09.063 5: Triggering global (1 changes)
2016.09.11 01:22:09.063 5: Starting notify loop for global, first event DEFINED HM_3515DA_Dis_02
2016.09.11 01:22:09.066 5: Triggering global (1 changes)
2016.09.11 01:22:09.067 5: Starting notify loop for global, first event DEFINED HM_3515DA_Dis_03
2016.09.11 01:22:09.070 5: Triggering global (1 changes)
2016.09.11 01:22:09.070 5: Starting notify loop for global, first event DEFINED HM_3515DA_Dis_04
2016.09.11 01:22:09.073 5: Triggering global (1 changes)
2016.09.11 01:22:09.074 5: Starting notify loop for global, first event DEFINED HM_3515DA_Dis_05
2016.09.11 01:22:09.077 5: Triggering global (1 changes)
2016.09.11 01:22:09.077 5: Starting notify loop for global, first event DEFINED HM_3515DA_Dis_06
2016.09.11 01:22:09.080 5: Triggering global (1 changes)
2016.09.11 01:22:09.081 5: Starting notify loop for global, first event DEFINED HM_3515DA_Dis_07
2016.09.11 01:22:09.084 5: Triggering global (1 changes)
2016.09.11 01:22:09.084 5: Starting notify loop for global, first event DEFINED HM_3515DA_Dis_08
2016.09.11 01:22:09.087 5: Triggering global (1 changes)
2016.09.11 01:22:09.088 5: Starting notify loop for global, first event DEFINED HM_3515DA_Dis_09
2016.09.11 01:22:09.091 5: Triggering global (1 changes)
2016.09.11 01:22:09.092 5: Starting notify loop for global, first event DEFINED HM_3515DA_Dis_10
2016.09.11 01:22:09.094 3: CUL_HM pair: HM_3515DA pushButton, model HM-Dis-WM55 serialNr
2016.09.11 01:22:09.099 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:1
2016.09.11 01:22:09.100 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:2
2016.09.11 01:22:09.100 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:3
2016.09.11 01:22:09.144 5: HMLAN_Send: hmusb S:S16687EA5 stat: 00 t:00000000 d:01 r:16687EA5 m:16 A001 AFFE11 3515DA 00050000000000
2016.09.11 01:22:09.146 5: CUL_HM HM_3515DA protEvent:CMDs_processing... pending:2
2016.09.11 01:22:09.148 5: Triggering HM_3515DA (3 changes)
2016.09.11 01:22:09.149 5: Starting notify loop for HM_3515DA, first event D-firmware: 1.0
2016.09.11 01:22:09.324 5: HMLAN/RAW: /E3515DA,0100,0001E39F,FF,FFDA,16A0023515DAAFFE11042C3A18182C3A00
2016.09.11 01:22:09.326 5: HMLAN_Parse: hmusb R:E3515DA stat:0100 t:0001E39F d:FF r:FFDA m:16 A002 3515DA AFFE11 042C3A18182C3A00
2016.09.11 01:22:09.326 5: hmusb dispatch A1116A0023515DAAFFE11042C3A18182C3A00:AESpending:-38:hmusb
2016.09.11 01:22:09.329 5: Triggering HM_3515DA (2 changes)
2016.09.11 01:22:09.330 5: Starting notify loop for HM_3515DA, first event aesCommToDev: pending
2016.09.11 01:22:09.580 5: HMLAN/RAW: /R16687EA5,0021,0001E3A4,00,FFDA,1680023515DAAFFE1100E87EED8E
2016.09.11 01:22:09.581 5: HMLAN_Parse: hmusb R:R16687EA5 stat:0021 t:0001E3A4 d:00 r:FFDA m:16 8002 3515DA AFFE11 00E87EED8E
2016.09.11 01:22:09.582 5: hmusb dispatch A0E1680023515DAAFFE1100E87EED8E:AESCom-ok:-38:hmusb
2016.09.11 01:22:09.587 5: HMLAN_Send: hmusb S:S1668808A stat: 00 t:00000000 d:01 r:1668808A m:17 A001 AFFE11 3515DA 000802010AAF0BFE0C11
2016.09.11 01:22:09.590 5: CUL_HM HM_3515DA protEvent:CMDs_processing... pending:1
2016.09.11 01:22:09.593 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:09.593 5: Starting notify loop for HM_3515DA, first event aesCommToDev: ok
2016.09.11 01:22:09.996 5: HMLAN/RAW: /E3515DA,0100,0001E637,FF,FFD8,17A0023515DAAFFE11046CB898966CB800
2016.09.11 01:22:09.997 5: HMLAN_Parse: hmusb R:E3515DA stat:0100 t:0001E637 d:FF r:FFD8 m:17 A002 3515DA AFFE11 046CB898966CB800
2016.09.11 01:22:09.998 5: hmusb dispatch A1117A0023515DAAFFE11046CB898966CB800:AESpending:-40:hmusb
2016.09.11 01:22:10.001 5: Triggering HM_3515DA (2 changes)
2016.09.11 01:22:10.002 5: Starting notify loop for HM_3515DA, first event aesCommToDev: pending
2016.09.11 01:22:10.252 5: HMLAN/RAW: /R1668808A,0021,0001E63C,00,FFCE,1780023515DAAFFE11000C7FE718
2016.09.11 01:22:10.253 5: HMLAN_Parse: hmusb R:R1668808A stat:0021 t:0001E63C d:00 r:FFCE m:17 8002 3515DA AFFE11 000C7FE718
2016.09.11 01:22:10.254 5: hmusb dispatch A0E1780023515DAAFFE11000C7FE718:AESCom-ok:-50:hmusb
2016.09.11 01:22:10.259 5: HMLAN_Send: hmusb S:S16688329 stat: 00 t:00000000 d:01 r:16688329 m:18 A001 AFFE11 3515DA 0006
2016.09.11 01:22:10.262 5: CUL_HM HM_3515DA protEvent:CMDs_processing... pending:0
2016.09.11 01:22:10.265 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:10.265 5: Starting notify loop for HM_3515DA, first event aesCommToDev: ok
2016.09.11 01:22:10.669 5: HMLAN/RAW: /E3515DA,0100,0001E8C6,FF,FFCC,18A0023515DAAFFE1104DA3A2119DA3A00
2016.09.11 01:22:10.670 5: HMLAN_Parse: hmusb R:E3515DA stat:0100 t:0001E8C6 d:FF r:FFCC m:18 A002 3515DA AFFE11 04DA3A2119DA3A00
2016.09.11 01:22:10.670 5: hmusb dispatch A1118A0023515DAAFFE1104DA3A2119DA3A00:AESpending:-52:hmusb
2016.09.11 01:22:10.673 5: Triggering HM_3515DA (2 changes)
2016.09.11 01:22:10.674 5: Starting notify loop for HM_3515DA, first event aesCommToDev: pending
2016.09.11 01:22:10.925 5: HMLAN/RAW: /R16688329,0021,0001E8CB,00,FFCB,1880023515DAAFFE1100053E3505
2016.09.11 01:22:10.925 5: HMLAN_Parse: hmusb R:R16688329 stat:0021 t:0001E8CB d:00 r:FFCB m:18 8002 3515DA AFFE11 00053E3505
2016.09.11 01:22:10.926 5: hmusb dispatch A0E1880023515DAAFFE1100053E3505:AESCom-ok:-53:hmusb
2016.09.11 01:22:10.930 5: CUL_HM HM_3515DA protEvent:CMDs_done
2016.09.11 01:22:10.933 5: Triggering HM_3515DA (2 changes)
2016.09.11 01:22:10.934 5: Starting notify loop for HM_3515DA, first event aesCommToDev: ok
2016.09.11 01:22:11.795 5: HMLAN_Send: hmusb I:K
2016.09.11 01:22:12.365 5: HMLAN/RAW: /HHM-LAN-IF,03C7,LEQ0659122,2CC6D3,AFFE11,0001EF86,0000
2016.09.11 01:22:12.366 5: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0659122 d:2CC6D3 O:AFFE11 t:0001EF86 IDcnt:0000 L:0 %
2016.09.11 01:22:12.367 5: Triggering hmusb (1 changes)
2016.09.11 01:22:12.367 5: Starting notify loop for hmusb, first event loadLvl: low
2016.09.11 01:22:14.096 5: HMLAN_Send: hmusb I:+3515DA,00,00,00
2016.09.11 01:22:16.845 5: HMLAN/RAW: /E3229B5,0000,00020101,FF,FFD0,0F84703229B500000000FE39
2016.09.11 01:22:16.846 5: HMLAN_Parse: hmusb R:E3229B5 stat:0000 t:00020101 d:FF r:FFD0 m:0F 8470 3229B5 000000 00FE39
2016.09.11 01:22:16.847 5: hmusb dispatch A0C0F84703229B500000000FE39::-48:hmusb
2016.09.11 01:22:17.261 5: HMLAN/RAW: /E32185B,0000,0002029A,FF,FFE2,47865A32185B000000910837
2016.09.11 01:22:17.262 5: HMLAN_Parse: hmusb R:E32185B stat:0000 t:0002029A d:FF r:FFE2 m:47 865A 32185B 000000 910837
2016.09.11 01:22:17.263 5: hmusb dispatch A0C47865A32185B000000910837::-30:hmusb
2016.09.11 01:22:19.735 4: Connection accepted from WEB_192.168.1.72_48236
2016.09.11 01:22:19.738 4: WEB_192.168.1.72_48236 POST /fhem?cmd=save&XHR=1&fw_id=62; BUFLEN:0
2016.09.11 01:22:19.739 5: Cmd: >save<
2016.09.11 01:22:19.739 5: Triggering global (1 changes)
2016.09.11 01:22:19.740 5: Starting notify loop for global, first event SAVE
2016.09.11 01:22:19.743 4: WriteStatefile HM_3515DA_Dis_01 peerList: Missing TIME, using current time
2016.09.11 01:22:19.778 4: name: /fhem?cmd=save&XHR=1&fw_id=62 / RL:52 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.11 01:22:20.260 4: HMLAN_ack: timeout - clear queue
2016.09.11 01:22:24.942 5: HMLAN/RAW: /E3227F4,0000,000220B0,FF,FFBF,F384703227F4000000010139
2016.09.11 01:22:24.949 5: HMLAN_Parse: hmusb R:E3227F4 stat:0000 t:000220B0 d:FF r:FFBF m:F3 8470 3227F4 000000 010139
2016.09.11 01:22:24.950 5: hmusb dispatch A0CF384703227F4000000010139::-65:hmusb
2016.09.11 01:22:27.503 5: HMLAN/RAW: /E2BBF72,0000,00022AAF,FF,FFBA,0386702BBF7200000000D33E
2016.09.11 01:22:27.504 5: HMLAN_Parse: hmusb R:E2BBF72 stat:0000 t:00022AAF d:FF r:FFBA m:03 8670 2BBF72 000000 00D33E
2016.09.11 01:22:27.504 5: hmusb dispatch A0C0386702BBF7200000000D33E::-70:hmusb
2016.09.11 01:22:27.855 5: HMLAN/RAW: /E322927,0000,00022BF8,FF,FFCB,A5865A32292700000060FF3A
2016.09.11 01:22:27.856 5: HMLAN_Parse: hmusb R:E322927 stat:0000 t:00022BF8 d:FF r:FFCB m:A5 865A 322927 000000 60FF3A
2016.09.11 01:22:27.857 5: hmusb dispatch A0CA5865A32292700000060FF3A::-53:hmusb
2016.09.11 01:22:29.471 4: Connection closed for WEB_192.168.1.72_48234: EOF
2016.09.11 01:22:35.948 4: WEB_192.168.1.72_48236 GET /fhem; BUFLEN:0
2016.09.11 01:22:35.967 4: name: /fhem / RL:1134 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.11 01:22:36.653 4: WEB_192.168.1.72_48236 GET /fhem?XHR=1&inform=type=status;filter=room=Overview;since=1473549754;fmt=JSON&fw_id=75×tamp=1473549756558; BUFLEN:0
2016.09.11 01:22:36.795 5: HMLAN_Send: hmusb I:K
2016.09.11 01:22:36.816 5: HMLAN/RAW: /HHM-LAN-IF,03C7,LEQ0659122,2CC6D3,AFFE11,00024F0D,0001
2016.09.11 01:22:36.817 5: HMLAN_Parse: hmusb V:03C7 sNo:LEQ0659122 d:2CC6D3 O:AFFE11 t:00024F0D IDcnt:0001 L:0 %
2016.09.11 01:22:36.818 5: Triggering hmusb (1 changes)
2016.09.11 01:22:36.818 5: Starting notify loop for hmusb, first event loadLvl: low
2016.09.11 01:22:37.264 5: HMLAN/RAW: /E32185B,0000,000250BB,FF,FFE2,47847032185B000000010837
2016.09.11 01:22:37.265 5: HMLAN_Parse: hmusb R:E32185B stat:0000 t:000250BB d:FF r:FFE2 m:47 8470 32185B 000000 010837
2016.09.11 01:22:37.266 5: hmusb dispatch A0C47847032185B000000010837::-30:hmusb
2016.09.11 01:22:38.371 4: Connection closed for WEB_192.168.1.72_48236: EOF
2016.09.11 01:22:38.388 4: Connection accepted from WEB_192.168.1.72_48248
2016.09.11 01:22:38.392 4: WEB_192.168.1.72_48248 GET /fhem?room=CUL%5fHM; BUFLEN:0
2016.09.11 01:22:38.419 4: name: /fhem?room=CUL%5fHM / RL:1470 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.11 01:22:39.033 4: WEB_192.168.1.72_48248 GET /fhem?XHR=1&inform=type=status;filter=room=CUL%5fHM;since=1473549757;fmt=JSON&fw_id=76×tamp=1473549758940; BUFLEN:0
2016.09.11 01:22:42.242 4: Connection accepted from WEB_192.168.1.72_48250
2016.09.11 01:22:42.245 4: WEB_192.168.1.72_48250 POST /fhem?cmd.HM_3515DA=set%20HM_3515DA%20getConfig&room=CUL_HM&XHR=1&fw_id=76; BUFLEN:0
2016.09.11 01:22:42.247 5: Cmd: >set HM_3515DA getConfig<
2016.09.11 01:22:42.250 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.250 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.259 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:1
2016.09.11 01:22:42.261 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.262 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.268 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:2
2016.09.11 01:22:42.269 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.269 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.275 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:3
2016.09.11 01:22:42.276 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.277 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.282 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:4
2016.09.11 01:22:42.283 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.284 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.289 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:5
2016.09.11 01:22:42.290 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.291 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.297 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:6
2016.09.11 01:22:42.298 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.298 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.304 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:7
2016.09.11 01:22:42.305 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.306 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.310 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:8
2016.09.11 01:22:42.311 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.311 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.315 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:9
2016.09.11 01:22:42.316 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.317 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.321 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:10
2016.09.11 01:22:42.321 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.322 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.326 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:11
2016.09.11 01:22:42.327 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.327 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.331 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:12
2016.09.11 01:22:42.332 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.332 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.336 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:13
2016.09.11 01:22:42.337 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.337 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.341 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:14
2016.09.11 01:22:42.342 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.343 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.347 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:15
2016.09.11 01:22:42.347 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.348 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.352 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:16
2016.09.11 01:22:42.353 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.353 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.357 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:17
2016.09.11 01:22:42.358 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.358 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.362 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:18
2016.09.11 01:22:42.363 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.363 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.367 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:19
2016.09.11 01:22:42.368 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.369 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.373 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:20
2016.09.11 01:22:42.373 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:42.374 5: Starting notify loop for HM_3515DA, first event CMDs_pending
2016.09.11 01:22:42.378 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:21
2016.09.11 01:22:42.378 3: CUL_HM set HM_3515DA getConfig
2016.09.11 01:22:42.384 4: name: /fhem?cmd.HM_3515DA=set%20HM_3515DA%20getConfig&room=CUL_HM&XHR=1&fw_id=76 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.09.11 01:22:45.009 5: HMLAN/RAW: /E31D1FE,0000,00026EFB,FF,FFD8,EB865A31D1FE000000910633
2016.09.11 01:22:45.010 5: HMLAN_Parse: hmusb R:E31D1FE stat:0000 t:00026EFB d:FF r:FFD8 m:EB 865A 31D1FE 000000 910633
2016.09.11 01:22:45.011 5: hmusb dispatch A0CEB865A31D1FE000000910633::-40:hmusb
2016.09.11 01:22:47.857 5: HMLAN/RAW: /E322927,0000,00027A18,FF,FFCB,A5847032292700000000FF3A
2016.09.11 01:22:47.862 5: HMLAN_Parse: hmusb R:E322927 stat:0000 t:00027A18 d:FF r:FFCB m:A5 8470 322927 000000 00FF3A
2016.09.11 01:22:47.863 5: hmusb dispatch A0CA5847032292700000000FF3A::-53:hmusb
2016.09.11 01:22:48.561 5: HMLAN/RAW: /E3515DA,0000,00027CE2,FF,FFCC,02A2403515DAAFFE110201
2016.09.11 01:22:48.562 5: HMLAN_Parse: hmusb R:E3515DA stat:0000 t:00027CE2 d:FF r:FFCC m:02 A240 3515DA AFFE11 0201
2016.09.11 01:22:48.563 5: hmusb dispatch A0B02A2403515DAAFFE110201::-52:hmusb
2016.09.11 01:22:48.568 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:1
2016.09.11 01:22:48.568 5: CUL_HM HM_3515DA prep ACK for 02
2016.09.11 01:22:48.569 5: HMLAN: Skip ACK
2016.09.11 01:22:48.570 5: CUL_HM HM_3515DA protEvent:CMDs_processing... pending:1
2016.09.11 01:22:48.571 5: CUL_HM HM_3515DA sent ACK:2
2016.09.11 01:22:48.574 5: Triggering HM_3515DA (3 changes)
2016.09.11 01:22:48.575 5: Starting notify loop for HM_3515DA, first event battery: ok
2016.09.11 01:22:48.581 5: Triggering HM_3515DA_Dis_02 (3 changes)
2016.09.11 01:22:48.582 5: Starting notify loop for HM_3515DA_Dis_02, first event Short (to vccu)
2016.09.11 01:22:48.673 5: HMLAN_Send: hmusb S:S16691937 stat: 00 t:00000000 d:01 r:16691937 m:03 A011 AFFE11 3515DA 8001020A0A0A0A0A0A03
2016.09.11 01:22:48.675 5: CUL_HM HM_3515DA protEvent:CMDs_processing... pending:0
2016.09.11 01:22:49.201 5: HMLAN/RAW: /R16691937,0001,00027F5F,FF,FFCC,0380023515DAAFFE1100
2016.09.11 01:22:49.202 5: HMLAN_Parse: hmusb R:R16691937 stat:0001 t:00027F5F d:FF r:FFCC m:03 8002 3515DA AFFE11 00
2016.09.11 01:22:49.203 5: hmusb dispatch A0A0380023515DAAFFE1100::-52:hmusb
2016.09.11 01:22:49.207 5: CUL_HM HM_3515DA protEvent:CMDs_done
2016.09.11 01:22:49.210 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:49.210 5: Starting notify loop for HM_3515DA, first event CMDs_done
2016.09.11 01:22:54.482 5: HMLAN/RAW: /E2D9B77,0000,00029405,FF,FFC5,CF86102D9B770000000A98FE0B0040
2016.09.11 01:22:54.483 5: HMLAN_Parse: hmusb R:E2D9B77 stat:0000 t:00029405 d:FF r:FFC5 m:CF 8610 2D9B77 000000 0A98FE0B0040
2016.09.11 01:22:54.484 5: hmusb dispatch A0FCF86102D9B770000000A98FE0B0040::-59:hmusb
2016.09.11 01:22:55.282 5: HMLAN/RAW: /E3515DA,0000,00029730,FF,FFCC,03A2403515DAAFFE110202
2016.09.11 01:22:55.283 5: HMLAN_Parse: hmusb R:E3515DA stat:0000 t:00029730 d:FF r:FFCC m:03 A240 3515DA AFFE11 0202
2016.09.11 01:22:55.284 5: hmusb dispatch A0B03A2403515DAAFFE110202::-52:hmusb
2016.09.11 01:22:55.288 5: CUL_HM HM_3515DA protEvent:CMDs_pending pending:1
2016.09.11 01:22:55.289 5: CUL_HM HM_3515DA prep ACK for 02
2016.09.11 01:22:55.290 5: HMLAN: Skip ACK
2016.09.11 01:22:55.291 5: CUL_HM HM_3515DA protEvent:CMDs_processing... pending:1
2016.09.11 01:22:55.292 5: CUL_HM HM_3515DA sent ACK:2
2016.09.11 01:22:55.295 5: Triggering HM_3515DA (3 changes)
2016.09.11 01:22:55.296 5: Starting notify loop for HM_3515DA, first event battery: ok
2016.09.11 01:22:55.302 5: Triggering HM_3515DA_Dis_02 (3 changes)
2016.09.11 01:22:55.302 5: Starting notify loop for HM_3515DA_Dis_02, first event Short (to vccu)
2016.09.11 01:22:55.394 5: HMLAN_Send: hmusb S:S16693378 stat: 00 t:00000000 d:01 r:16693378 m:04 A011 AFFE11 3515DA 8001020A0A0A0A0A0A03
2016.09.11 01:22:55.396 5: CUL_HM HM_3515DA protEvent:CMDs_processing... pending:0
2016.09.11 01:22:56.370 5: HMLAN/RAW: /R16693378,0001,00029B5E,FF,FFC7,0480023515DAAFFE1100
2016.09.11 01:22:56.371 5: HMLAN_Parse: hmusb R:R16693378 stat:0001 t:00029B5E d:FF r:FFC7 m:04 8002 3515DA AFFE11 00
2016.09.11 01:22:56.372 5: hmusb dispatch A0A0480023515DAAFFE1100::-57:hmusb
2016.09.11 01:22:56.376 5: CUL_HM HM_3515DA protEvent:CMDs_done
2016.09.11 01:22:56.379 5: Triggering HM_3515DA (1 changes)
2016.09.11 01:22:56.379 5: Starting notify loop for HM_3515DA, first event CMDs_done
2016.09.11 01:22:57.879 4: Connection closed for WEB_192.168.1.72_48248: EOF
2016.09.11 01:22:57.896 4: WEB_192.168.1.72_48250 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-09.log; BUFLEN:0
Ich hoffe das hilft...
Falls ich noch mal Zeit hab schicke ich noch ein Log von meinem Testsystem mit dem "spezial-CUL"...
Gruß, Joachim
Hallo Joachim,
danke für das Log.
Ich vermisse allerdings das vollständige getConfig in der Ausführung darin.
Hast Du beim Device autoReadReg auf 5 und expert auf 2 gestellt, damit auch die Register gelesen werden?
Das mitloggen des Vorgangs auf dem Testsystem mit Spezial CUL auf verbose 4 würde mir dann auch alle eigenständigen Wiederholungen seitens HM_USB aufzeigen.
Gruß, Ansgar.
Hi Ansgar,
gerne.
Hmmm, ich stell die Werte ein (bzw. kontrolliere mal) und wiederhole...
Mache dann auch das selbe auf dem Testsystem/spezial-CUL...
Wird aber noch etwas dauern...
Gruß, Joachim
Hallo Joachim,
bitte auf dem Testsystem mitlauschen und loggen, wenn Du auf dem Hauptsystem loggst!
Hier https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979 (https://forum.fhem.de/index.php/topic,24436.msg489979.html#msg489979) habe ich auch was neues zum Testen. In meiner FHEM 5.7 Testumgebung läuft diese neue Version. :)
Gruß, Ansgar.
Hi Ansgar,
ah, ok.
Irgendwelche Einstellungen beim Testsystem (außer wie bisher beim Loggen)?
Autocreate nur auf einem System?
(Hauptsystem)
Gruß, Joachim
Hallo Joachim,
auf dem Testsystem nur verbose 4 beim spezial CUL zum mitlauschen, sonst nichts.
Gruß, Ansgar.
Hallo Ansgar,
danke für deine Nachricht.
Ich glaube nach wie vor nicht, dass das Device bei mir für Probleme sorgt. Ich habe ja nur Probleme beim Register lesen und pairen. Gewöhnliches Schalten von Autoren geht ja schon seit einem Jahr gut.
Danke für weitere Hinweise.
dmesg:
[ 4088.329540] usb 1-1.5: USB disconnect, device number 5
[ 4088.329770] cdc_acm 1-1.5:1.0: failed to set dtr/rts
[ 4088.610037] usb 1-1.5: new full-speed USB device number 6 using dwc_otg
[ 4088.730983] usb 1-1.5: New USB device found, idVendor=03eb, idProduct=2ff4
[ 4088.731003] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4088.731014] usb 1-1.5: Product: ATm32U4DFU
[ 4088.731024] usb 1-1.5: Manufacturer: ATMEL
[ 4088.731048] usb 1-1.5: SerialNumber: 1.0.0
[ 4204.825067] usb 1-1.5: USB disconnect, device number 6
[ 5487.789585] usb 1-1.5: new full-speed USB device number 7 using dwc_otg
[ 5487.906388] usb 1-1.5: New USB device found, idVendor=03eb, idProduct=204b
[ 5487.906414] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5487.906430] usb 1-1.5: Product: CUL868
[ 5487.906445] usb 1-1.5: Manufacturer: busware.de
[ 5487.906460] usb 1-1.5: SerialNumber: 868000
[b][ 5487.909066] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device[/b]
fhem log:
2016.09.14 13:44:18 0: Server shutdown
2016.09.14 13:44:20 1: Including fhem.cfg
2016.09.14 13:44:21 3: WEB: port 8083 opened
2016.09.14 13:44:21 3: WEBphone: port 8084 opened
2016.09.14 13:44:21 3: WEBtablet: port 8085 opened
2016.09.14 13:44:21 2: eventTypes: loaded 560 events from ./log/eventTypes.txt
[b]2016.09.14 13:44:21 3: Opening CUL1 device /dev/ttyACM0[/b]
2016.09.14 13:44:21 3: Setting CUL1 serial parameters to 9600,8,N,1
2016.09.14 13:44:22 1: CUL1 is VERSION_TS, V 99.75 CUL868, CUL_V3.4
2016.09.14 13:44:22 3: CUL1: Possible commands: BbCFiAZEGMKJUYRTVWXefmltux
2016.09.14 13:44:22 3: CUL1 device opened
2016.09.14 13:44:22 2: Switched CUL1 rfmode to HomeMatic
2016.09.14 13:44:24 1: Including ./log/fhem.save
2016.09.14 13:44:24 3: Device HM_2FDB94 added to ActionDetector with 000:10 time
2016.09.14 13:44:24 3: Device HM_38D85C added to ActionDetector with 000:10 time
2016.09.14 13:44:24 3: Device HM_4BE69C added to ActionDetector with 000:10 time
2016.09.14 13:44:24 3: Device Schaltsteckdose1 added to ActionDetector with 000:10 time
2016.09.14 13:44:24 2: SecurityCheck: WEB,WEBtablet has no associated allowed device with basicAuth. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.09.14 13:44:24 0: Featurelevel: 5.7
2016.09.14 13:44:24 0: Server started with 58 defined entities (fhem.pl:12095/2016-08-30 perl:5.014002 os:linux user:fhem pid:11029)
Hallo Marcus,
ZitatIch habe ja nur Probleme beim Register lesen und pairen
Gerade dabei kommt es auf das Timing an und auf die Einhaltung des Protokolls, dass aus mehreren Abfragen besteht.
Schalten ist meist nur ein Befehl an das device, auf den ein ACK vom device kommen muss. Von Sensoren kommen meißt nur "Broafcasts" aud die nicht geantwortet werden muss.
Beim Klingelsensor har das device ein abweichendes Verhalten bezüglich des Protokolls gehabt, washalb Martin eine Änderung eingebaut hat, die das beheben sollte.
Die Änderung besteht darin, wiederholte Requests, die Du mit dem Drücken der Pairing Taste auslöst, zu ignorieren.
D.h., wenn es beim ersten Drücken nicht klappt (Request wird nicht empfangen oder die Antwort auf den Request scheitert etc.), dann kannst Du lange weiter drücken, aber es passiert nichts mehr, bis vom device mal was anderes, als der Request kommt oder FHEM neu gestartet wird.
Ich habe in meinem Klingelsensorworkaroundversuch in meiner 10_CUL_HM.pm ein einmaliges Ignorieren eingebaut, so dass sich das bei nicht Klingelsensor devices beim zweiten Driuck der Pairing Taste wieder erholen sollte. Außerdem in meiner 00_CUL.pm ein einmaliges Wiederholen einer Anforderung an ein device auf die eine Ack Antwort angefordert wird, wenn das ACK nach Timeout ausbleibt. HMLAN macht diese Wiederholung wohl sogar 3-mal in der Firmware automatisch, ohne dass FHEM das mitbekommt, was wohl eigentlich auch nur für Empfangsprobleme aud device Seite gedacht gewesen ist.
Daher würde ich gerne ein Pairing und getConfig eines HMLAN hier mitgelauscht sehen, um zu sehen, ob es genau daran nun klemmen kann, weil wiederum dass device ggf. vom Protokoll abweicht und diese Wiederholung ggf. auch mehr als einmal braucht. Das würde Martin die Hinweise geben, was er ggf. korrigieren müßte.
Ggf. auch mir, wenn es devices gibt, die mehr als eine Wiederholung zwingend benötigen. Dann müßte die Wiederholung in die CUL Firmware rein, da Timeout-Timing über FHEM dann zu kritisch wird.
Gruß,
Ansgar.
Zitat von: noansi am 14 September 2016, 23:14:59
Daher würde ich gerne ein Pairing und getConfig eines HMLAN hier mitgelauscht sehen, um zu sehen, ob es genau daran nun klemmen kann, weil wiederum dass device ggf. vom Protokoll abweicht und diese Wiederholung ggf. auch mehr als einmal braucht. Das würde Martin die Hinweise geben, was er ggf. korrigieren müßte.
Ggf. auch mir, wenn es devices gibt, die mehr als eine Wiederholung zwingend benötigen. Dann müßte die Wiederholung in die CUL Firmware rein, da Timeout-Timing über FHEM dann zu kritisch wird.
Hallo Ansgar,
sorry. Bin grad bissi im Stress... ;-)
Evtl. morgen, auf jeden Fall am Freitag.
Muss erst noch in Ruhe durchgehen was ich auf meinem Testsystem einspielen muss etc.
Und da ich mein Hauptsystem mit dem HM-CFG-USB wieder leer räumen will (damit nicht zu viel unbrauchbares Zeugs dazwischen kommt), will ich das mal lieber in Ruhe machen. ;-)
Soll ich das System mit dem HM-UART auch mitlauschen lassen?
Oder auch mal mit diesem Pairen und auch das Testsystem mitlauschen lassen??
Gruß, Joachim
Hallo Ansgar,
so habe mal getestet.
Hoffe es war richtig so und du kannst was damit anfangen...
Angehangen dann mal diverse Logs (für den Fall, dass sie zu groß zum Posten sind).
Ich hoffe die Namen sind sprechend genug.
Leider hatte ich beim ersten (manuellen) getConfig expert auf 1 stehen, daher habe ich noch ein getConfig nachgereicht mit expert 2.
Falls ich noch was tun kann bzw. was anderes einstellen (hätte sollen) einfach Bescheid geben.
Gruß, Joachim
P.S.: die Anpassungen/Änderungen etc. beim Testsystem sind im Asksin-Thread dokumentiert. Alle Systeme (hmusb, HMUART) auf aktuellem Stand, update kurz vor den Tests.
Hallo Joachim,
danke für das Logging.
Ich habe damit mal zufällig die automatische Wiederholung eines HMUART im Timing sehen können. :) Zwei Wiederholungen und etwa 354ms bei fehlender Antwort vom device.
Das hat aber mit dem vorliegenden Display Problem nichts zu tun. Merkwürdige Wiederholungen sehe ich nicht. Bei dog_martin vermute ich mal Timing, also dass CUL für das device etwas zu früh sendet. Dann ist er wohl in die schon beschriebene Wiederholungsignoranzfalle geraten, so dass drücken der Taste nichts mehr gebracht hat.
Dein Log mit HMUART (hmId AFFE22 ?) ist etwas unglücklich gelaufen, da auch HMUSB (hmId AFFE11 ?) beim Pairing mitgemischt hat und einen Register read parallel auf das display mitgemacht hat.
War das nicht mal so gedacht, dass nur eine hmId im System sein sollte und über die VCCU das jeweilige IO-Device gewählt werden sollte?
Gruß, Ansgar.
Hi Ansgar,
hmmm wenn das problematisch ist, müsste ich mal die anderen (oder eins der anderen) Systeme ausschalten.
Ich habe 3 Systeme mit unterschiedlichen HMIDs:
Hauptsystem hmusb: AFFE11
Demnächst neues Hauptsystem bzw. Evaluierung HMUART: AFFE22 (kann schon sein, kann grad nicht kucken)
Und mein Testsystem mit dem Spezial-CUL: AFFE01 (oder so)
Alle haben eine vccu damit sie sich gegenseitig nicht "stören" so ala unkown message help me!
Funktioniert soweit.
Die jeweiligen Geräte sind natürlich nur in jeweils einem System.
Daher mache ich mein Hauptsystem auch immer "leer" für die Tests, damit nicht ganz so viel "Müll" mit drin steht.
Denn dort sind natürlich die meisten Geräte: 5 Thermostate, 8 Wandthermostate, 4 Fensterkontakte und noch so einiges...
Bei den beiden anderen Systemen sind nur wenige Komponenten, zum Testen halt...
Falls ich nochmal was testen soll/kann einfach Bescheid geben...
...und auch, ob ich eins (oder zwei) der jeweils anderen Systeme abschalten soll während der Tests...
Gruß, Joachim