HM-CC-RT-DN

Begonnen von Alex85, 13 September 2013, 11:03:07

Vorheriges Thema - Nächstes Thema

CQuadrat

Zitat von: CQuadrat am 17 Oktober 2013, 23:15:54
Nur
winOpnTemp
scheint nicht am Thermostat übernommen zu werden. Dort bleiben immer 12.0 °C stehen, wenn das Fenster geöffnet wird.

Hat das vielleicht mal jemand mit original HomeMatic-Software ausprobiert? Ist es dort genauso?
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue

Stefan M.

Hallo Martin
ich habe nun meine HM Geräte zum testen an einem BeagleBoard mit aktuellem FHEM dran. MISSING ACK kommen immer noch einige aber nicht mehr so viele.
mir ist folgendes aufgefallen

Der Regler im Bad (gilt auch für die anderen Regler) reagiert nicht gleich auf das Fenster öffnen und schließen.
Erst wenn ich den Regler aufwecke (längeres drücken der mittleren Taste) reagiert er kurzzeitig auf den Fensterkontakt bevor er wieder einschläft.

Das konnte ich so nicht in der vorherigen Installation feststellen.
Welche Einstellungen müssen da noch gemacht werden ?


autoReadReg
4_reqStatus

burstAccess
0_off

R-burstRx
on



2013.10.26 23:00:05.707 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6D52F6 d:FF r:FFAE     m:B9 8610 21CEA2 000000 0A88D60F0018
2013.10.26 23:00:05.713 1: RCV L:0F N:B9 F:86 CMD:10 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:broadcast 0A88D60F0018 (INFO_TEMP SET:0x88D6 ACT:0x88D6 ERR:0x0F VALVE:0x0F MODE:0x0F) (,WAKEMEUP,CFG,RPTEN)
2013.10.26 23:00:13.482 1: HMLAN_Parse: HML R:E21CEB3   stat:0000 t:0A6D715A d:FF r:FFCE     m:2B 8610 21CEB3 000000 0A88D30F0018
2013.10.26 23:00:13.485 1: RCV L:0F N:2B F:86 CMD:10 SRC:CUL_HM_HM_CC_RT_DN_21CEB3 DST:broadcast 0A88D30F0018 (INFO_TEMP SET:0x88D3 ACT:0x88D3 ERR:0x0F VALVE:0x0F MODE:0x0F) (,WAKEMEUP,CFG,RPTEN)
2013.10.26 23:00:24.186 1: HMLAN_Send:  HML I:K
2013.10.26 23:00:24.554 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:0A6D9B51 IDcnt:000B
2013.10.26 23:00:49.211 1: HMLAN_Send:  HML I:K
2013.10.26 23:00:49.216 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:0A6DFD0B IDcnt:000B
2013.10.26 23:00:52.512 1: HMLAN_Parse: HML R:E21968B   stat:0000 t:0A6E09E8 d:FF r:FFA4     m:21 A441 21968B 1EA224 011CC8
2013.10.26 23:00:52.517 1: RCV L:0C N:21 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 011CC8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1C NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:00:52.519 1: HMLAN_Send:  HML S:SF691CEE8 stat:  00 t:00000000 d:01 r:F691CEE8 m:21 8002 1EA224 21968B 0101C800
2013.10.26 23:00:52.525 1: SND L:0D N:21 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:00:52.556 1: HMLAN_Send:  HML S:SF691CF09 stat:  00 t:00000000 d:01 r:F691CF09 m:84 A441 100030 21CEA2 0116C8
2013.10.26 23:00:52.559 1: SND L:0C N:84 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 0116C8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x16 NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:00:52.893 1: HMLAN_Parse: HML R:RF691CEE8 stat:0002 t:00000000 d:FF r:7FFF     m:21 8002 1EA224 21968B 0101C800
2013.10.26 23:00:53.222 1: HMLAN_Parse: HML R:RF691CF09 stat:0008 t:00000000 d:FF r:7FFF     m:84 A441 100030 21CEA2 0116C8
2013.10.26 23:00:53.223 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:00.759 1: HMLAN_Parse: HML R:E21968B   stat:0000 t:0A6E2A23 d:FF r:FF9F     m:22 A441 21968B 1EA224 011D00
2013.10.26 23:01:00.762 1: RCV L:0C N:22 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 011D00 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1D NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:00.764 1: HMLAN_Send:  HML S:SF691EF1D stat:  00 t:00000000 d:01 r:F691EF1D m:22 8002 1EA224 21968B 0101C800
2013.10.26 23:01:00.770 1: SND L:0D N:22 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:01:00.801 1: HMLAN_Send:  HML S:SF691EF41 stat:  00 t:00000000 d:01 r:F691EF41 m:85 A441 100030 21CEA2 011700
2013.10.26 23:01:00.803 1: SND L:0C N:85 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 011700 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x17 NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:01.102 1: HMLAN_Parse: HML R:E21968B   stat:0000 t:0A6E2B1E d:FF r:FFA1     m:22 A041 21968B 1EA224 011D00
2013.10.26 23:01:01.390 1: HMLAN_Parse: HML R:RF691EF1D stat:0002 t:00000000 d:FF r:7FFF     m:22 8002 1EA224 21968B 0101C800
2013.10.26 23:01:01.464 1: HMLAN_Parse: HML R:RF691EF41 stat:0008 t:00000000 d:FF r:7FFF     m:85 A441 100030 21CEA2 011700
2013.10.26 23:01:01.465 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:07.474 1: HMLAN_Parse: HML R:E1F06B1   stat:0000 t:0A6E4463 d:FF r:FFD5     m:A5 A610 1F06B1 1EA224 06011A00
2013.10.26 23:01:07.477 1: RCV L:0D N:A5 F:A6 CMD:10 SRC:CUL_HM_HM_Sen_Wa_Od_1F06B1 DST:1EA224 06011A00 (INFO_ACTUATOR_STATUS) (,WAKEMEUP,CFG,BIDI,RPTEN)
2013.10.26 23:01:07.481 1: SND L:0A N:A5 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_Sen_Wa_Od_1F06B1 00 (ACK) (,RPTEN)
2013.10.26 23:01:08.449 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E4832 d:FF r:FFAC     m:1B 8400 21CEA2 1EA224 1000954B4551303537393935325900FFFF
2013.10.26 23:01:08.452 1: RCV L:1A N:1B F:84 CMD:00 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:1EA224 1000954B4551303537393935325900FFFF (DEVICE_INFO FIRMWARE:0x10 TYPE:0x0095 SERIALNO:0x4B455130353739393532 CLASS:0x59 PEER_CHANNEL_A:0x00 PEER_CHANNEL_B:0xFF UNKNOWN:0xFF) (,CFG,RPTEN)
2013.10.26 23:01:11.255 1: HMLAN_Parse: HML R:E21968B   stat:0000 t:0A6E532A d:FF r:FFA9     m:23 A441 21968B 1EA224 011EC8
2013.10.26 23:01:11.258 1: RCV L:0C N:23 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 011EC8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1E NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:11.262 1: HMLAN_Send:  HML S:SF692181E stat:  00 t:00000000 d:01 r:F692181E m:23 8002 1EA224 21968B 0101C800
2013.10.26 23:01:11.264 1: SND L:0D N:23 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:01:11.297 1: HMLAN_Send:  HML S:SF6921841 stat:  00 t:00000000 d:01 r:F6921841 m:86 A441 100030 21CEA2 0118C8
2013.10.26 23:01:11.312 1: SND L:0C N:86 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 0118C8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x18 NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:11.613 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E5435 d:FF r:FFB3     m:86 8002 21CEA2 100030 00
2013.10.26 23:01:11.615 1: RCV L:0A N:86 F:80 CMD:02 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:Button_Bad 00 (ACK) (,RPTEN)
2013.10.26 23:01:11.651 1: HMLAN_Parse: HML R:RF692181E stat:0002 t:00000000 d:FF r:7FFF     m:23 8002 1EA224 21968B 0101C800
2013.10.26 23:01:11.695 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E54CE d:FF r:FFB3     m:86 8002 21CEA2 100030 00
2013.10.26 23:01:11.828 1: HMLAN_Parse: HML R:RF6921841 stat:0008 t:00000000 d:FF r:7FFF     m:86 A441 100030 21CEA2 0118C8
2013.10.26 23:01:11.829 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:11.830 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E5567 d:FF r:FFB1     m:86 8002 21CEA2 100030 00
2013.10.26 23:01:13.504 1: HMLAN_Parse: HML R:E21968B   stat:0000 t:0A6E5BF4 d:FF r:FFA4     m:24 A441 21968B 1EA224 011F00
2013.10.26 23:01:13.507 1: RCV L:0C N:24 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 011F00 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1F NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:13.513 1: HMLAN_Send:  HML S:SF69220E9 stat:  00 t:00000000 d:01 r:F69220E9 m:24 8002 1EA224 21968B 0101C800
2013.10.26 23:01:13.519 1: SND L:0D N:24 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:01:13.550 1: HMLAN_Send:  HML S:SF6922109 stat:  00 t:00000000 d:01 r:F6922109 m:87 A441 100030 21CEA2 011900
2013.10.26 23:01:13.553 1: SND L:0C N:87 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 011900 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x19 NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:13.861 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E5CFF d:FF r:FFB1     m:87 8002 21CEA2 100030 00
2013.10.26 23:01:13.864 1: RCV L:0A N:87 F:80 CMD:02 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:Button_Bad 00 (ACK) (,RPTEN)
2013.10.26 23:01:13.900 1: HMLAN_Parse: HML R:RF69220E9 stat:0002 t:00000000 d:FF r:7FFF     m:24 8002 1EA224 21968B 0101C800
2013.10.26 23:01:13.943 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E5D98 d:FF r:FFB1     m:87 8002 21CEA2 100030 00
2013.10.26 23:01:14.076 1: HMLAN_Parse: HML R:RF6922109 stat:0008 t:00000000 d:FF r:7FFF     m:87 A441 100030 21CEA2 011900
2013.10.26 23:01:14.077 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:14.079 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E5E31 d:FF r:FFB1     m:87 8002 21CEA2 100030 00
2013.10.26 23:01:14.214 1: HMLAN_Send:  HML I:K
2013.10.26 23:01:14.218 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:0A6E5EC5 IDcnt:000B
2013.10.26 23:01:24.002 1: HMLAN_Parse: HML R:E21968B   stat:0000 t:0A6E84FD d:FF r:FFA7     m:25 A441 21968B 1EA224 0120C8
2013.10.26 23:01:24.007 1: RCV L:0C N:25 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 0120C8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x20 NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:24.009 1: HMLAN_Send:  HML S:SF69249EA stat:  00 t:00000000 d:01 r:F69249EA m:25 8002 1EA224 21968B 0101C800
2013.10.26 23:01:24.015 1: SND L:0D N:25 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:01:24.046 1: HMLAN_Send:  HML S:SF6924A0B stat:  00 t:00000000 d:01 r:F6924A0B m:88 A441 100030 21CEA2 011AC8
2013.10.26 23:01:24.049 1: SND L:0C N:88 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 011AC8 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1A NEXT:0xC8) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:24.361 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E8608 d:FF r:FFB2     m:88 8002 21CEA2 100030 00
2013.10.26 23:01:24.363 1: RCV L:0A N:88 F:80 CMD:02 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:Button_Bad 00 (ACK) (,RPTEN)
2013.10.26 23:01:24.400 1: HMLAN_Parse: HML R:RF69249EA stat:0002 t:00000000 d:FF r:7FFF     m:25 8002 1EA224 21968B 0101C800
2013.10.26 23:01:24.442 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E86A1 d:FF r:FFB2     m:88 8002 21CEA2 100030 00
2013.10.26 23:01:24.575 1: HMLAN_Parse: HML R:RF6924A0B stat:0008 t:00000000 d:FF r:7FFF     m:88 A441 100030 21CEA2 011AC8
2013.10.26 23:01:24.576 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:24.579 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E873A d:FF r:FFB2     m:88 8002 21CEA2 100030 00
2013.10.26 23:01:25.749 1: HMLAN_Parse: HML R:E21968B   stat:0000 t:0A6E8BD1 d:FF r:FFA4     m:26 A441 21968B 1EA224 012100
2013.10.26 23:01:25.752 1: RCV L:0C N:26 F:A4 CMD:41 SRC:CUL_HM_HM_SEC_SC_21968B DST:1EA224 012100 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x21 NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:25.754 1: HMLAN_Send:  HML S:SF69250BB stat:  00 t:00000000 d:01 r:F69250BB m:26 8002 1EA224 21968B 0101C800
2013.10.26 23:01:25.760 1: SND L:0D N:26 F:80 CMD:02 SRC:1EA224 DST:CUL_HM_HM_SEC_SC_21968B 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0x00 DOWN:0x00 LOWBAT:0x00) (,RPTEN)
2013.10.26 23:01:25.793 1: HMLAN_Send:  HML S:SF69250E1 stat:  00 t:00000000 d:01 r:F69250E1 m:89 A441 100030 21CEA2 011B00
2013.10.26 23:01:25.795 1: SND L:0C N:89 F:A4 CMD:41 SRC:Button_Bad DST:CUL_HM_HM_CC_RT_DN_21CEA2 011B00 (Sensor_event BUTTON:0x01 LONG:0x01 LOWBAT:0x01 VALUE:0x1B NEXT:0x00) (,CFG,BIDI,RPTEN)
2013.10.26 23:01:26.107 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E8CDC d:FF r:FFB2     m:89 8002 21CEA2 100030 00
2013.10.26 23:01:26.109 1: RCV L:0A N:89 F:80 CMD:02 SRC:CUL_HM_HM_CC_RT_DN_21CEA2 DST:Button_Bad 00 (ACK) (,RPTEN)
2013.10.26 23:01:26.146 1: HMLAN_Parse: HML R:RF69250BB stat:0002 t:00000000 d:FF r:7FFF     m:26 8002 1EA224 21968B 0101C800
2013.10.26 23:01:26.189 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E8D75 d:FF r:FFB3     m:89 8002 21CEA2 100030 00
2013.10.26 23:01:26.322 1: HMLAN_Parse: HML R:RF69250E1 stat:0008 t:00000000 d:FF r:7FFF     m:89 A441 100030 21CEA2 011B00
2013.10.26 23:01:26.323 1: HMLAN_Parse: HML no ACK from 21CEA2
2013.10.26 23:01:26.324 1: HMLAN_Parse: HML R:E21CEA2   stat:0000 t:0A6E8E0E d:FF r:FFB3     m:89 8002 21CEA2 100030 00
2013.10.26 23:01:39.217 1: HMLAN_Send:  HML I:K
2013.10.26 23:01:39.221 1: HMLAN_Parse: HML V:03C1 sNo:JEQ0706016 d:1EA224 O:1EA224 t:0A6EC07F IDcnt:000B

FHEM auf 3 x RaspberryPi, 1 x Fritzbox,1 x Win. FS20 über CUL, HomeMatic über HMLan, 6 x  HM_CC_RT_DN,2 x HM_LC_BL1_FM,3 x HM_SEC_KEY,2 x HM_RC_Key4_2,7 x HM_SEC_SC,1 x HM_SEC_WDS,1 x HM_Sen_RD_O, 1x HM_Sen_Wa_Od,2 x HM_RC_Key4_2, 5 x HM-ES-PMSw1-Pl,1 x HM_LC_SW4_WM,1 x HM_SCI_3_FM

martinp876

Hallo Stefan,

welchen fensterkontakt nutzt du? wenn ich es richtig sehe hast den Fensterkontalt mit FHEM gepeert und triggerst den RT über ein notify? Solchen Info ist natürlich wichtig und sollte bei einem Problem vermerkt werden.
Dann ist dein Problem also, dass das Kommando postEvent vom RT nicht abgearbeitet wird?
das sollte klar sein.
R-burstRx on # der RT kann burst - man KANN burst kommandos schicken
burstAccess off # FHEM started den burst zugriff NICHT automatisch
autoReadReg # hat damit garnichts zu tun

wenn bustAccess off ist kannst du den zugriff manuell starten, indem zu das kommando set burstXmit hinterher schickst.
Du kannst aber auch warten, bis der RT aufwacht - so alle 2,5min  dann wird das Kommando auch abgearbeitet.

ein burstXmit (wie jeder burst-start) belastet den HMLAN und dessen Stunden kontingent. Eine Idee. wo dein system liegt kannst du in HMInfo protocol einsehen

Stefan M.

Hallo Martin
Ja die Fensterkontakte sind so wie du es beschreibst eingebunden.  Ich habe nun mal burstAccess auf 1 Auto gesetzt und werde es mal beobachten.

Hast Du ein Manuel über eine aus Deiner Sicht beste Konfiguration von HM auf fhem ?
Das mit dem burstAccess ist bei mir bis heute morgen nicht richtig angekommen das es auf 1 stehen soll damit der Regler sofort aufwacht.

LG
Stefan

FHEM auf 3 x RaspberryPi, 1 x Fritzbox,1 x Win. FS20 über CUL, HomeMatic über HMLan, 6 x  HM_CC_RT_DN,2 x HM_LC_BL1_FM,3 x HM_SEC_KEY,2 x HM_RC_Key4_2,7 x HM_SEC_SC,1 x HM_SEC_WDS,1 x HM_Sen_RD_O, 1x HM_Sen_Wa_Od,2 x HM_RC_Key4_2, 5 x HM-ES-PMSw1-Pl,1 x HM_LC_SW4_WM,1 x HM_SCI_3_FM

martinp876

Hallo Stefan,

mit burstAccess musst du in sofern vorsichtig sein, da dies entsprechend Performance am HMLAN kostet. Da kann ich keine Empfehlung geben sondern nur raten, aufzupassen. .

Evtl überarbeite ich das Fehlerhandling - jedenfalls überdenke ich es gerade. Dazu werden ich evtl eine Empfehlung schreiben, jedenfalls ein paar erklärungen. Dauert aber noch....

Im Commandref ist es schon (etwas) geschrieben - in Englisch
Gruss Martin

smirnov

Hallo,

ich habe derzeit folgendes Problem: Ich habe 6 Stück HW-CC-RT-DN im Manu-Modus, welche von einem Raspberry Pi mit COC gesteuert werden. Grundsätzlich funktioniert alles, nur wenn ich z.B. zur Nachtabsenkung an alle RT's eine desired-temp schicken will, bekomme ich in 1 aus 3 Fällen bei einem beliebigen RT einen IOerr, und die Temp wird nicht gesetzt. Es lässt sich nicht auf einen RT festnageln, es sind immer unterschiedliche.
Wie kann ich bei einem COC den debug-modus einschalten und die raw-messages mitschneiden? Was bedeutet IOerr, wird mehrmals versucht, die temp zu setzen?

vielen dank,
lg
Tom

martinp876

Hallo Tom,

IOerr ist ein Problem des HMLAN. dort gab es entweder ein disconnect oder ein overload - ok, bei COC evtl noch einen andern zustand...
kannst du mitloggen, welchen Zustand der COC hat, wenn das Problem auftritt? ist coc dann evtl disconnected?

Dann die Frage, wie du den RT ansprichst im bezug auf burst mode
attr burstAccess
register burstRx
commando burstXmit

Gruss Martin

smirnov

Zitat von: martinp876 am 27 Oktober 2013, 16:46:03
kannst du mitloggen, welchen Zustand der COC hat, wenn das Problem auftritt? ist coc dann evtl disconnected?

tja, das ist die Frage, ich weiß leider nicht wie das geht beim COC?

danke,
Tom

martinp876

probiere
attr global verbose 1
attr COC loglevel 1
attr COC verbose 5
attr global mseclog 1

Samsi

Hallo,

seit dem ich gestern meine 2 HM-CC-RT-DN in betrieb genommen habe und FHEM upgedatet habe, bekomme ich leider auch bei mehreren Fensterkontakten (HM-SEC-SC) das Missing Ack im Status. Das hatte ich vorher nie.

Kurze Frage: war das Missing Ack schon immer im state eines Devices?

Weil der eigentliche Status 'closed' wurde korrekt an FHEM gemeldet:

contact closed (to HMLAN1) 2013-10-27 15:13:24
state MISSING ACK 2013-10-27 15:13:29


Das ärgerliche daran ist, das ich mehrere Kontakte in einer structure zusammenfasse und diese structure durch den state Missing Ack  insgesamt undefined ist, obwohl FHEM den eigentlichen Status 'closed' ja korrekt empfangen hat.

Kurzum: wenn das Missing Ack nicht im state stehen würden, würde es micht gar nicht so sehr  stören. Deshalb frage ich ob es schon immer im 'state' angezeigt wurde oder früher an andere Stelle und mir es einfach deshalb nie aufgefallen ist. 



FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

smirnov

Zitat von: martinp876 am 27 Oktober 2013, 19:18:53
probiere
attr global verbose 1
attr COC loglevel 1
attr COC verbose 5
attr global mseclog 1

das loglevel hat er nicht genommen, den rest schon. jetzt kommen im log folgende einträge:
2013.10.27 20:28:28.176 5: COC: A0F0E8610236D7E0000000AC0E60F6458 -66.5
2013.10.27 20:28:28.178 5: COC dispatch A0F0E8610236D7E0000000AC0E60F6458::-66.5:COC
2013.10.27 20:28:55.214 5: CUL/RAW: /A0FD0861
2013.10.27 20:28:55.217 5: CUL/RAW: A0FD0861/0236C810
2013.10.27 20:28:55.221 5: CUL/RAW: A0FD08610236C810/000000AB0DB0F435
2013.10.27 20:28:55.224 5: CUL/RAW: A0FD08610236C810000000AB0DB0F435/80B

2013.10.27 20:28:55.226 5: COC: A0FD08610236C810000000AB0DB0F4358 -68.5
2013.10.27 20:28:55.228 5: COC dispatch A0FD08610236C810000000AB0DB0F4358::-68.5:COC

reicht das? wenn ja, poste ich morgen die log-datei, bei der die umstellung geloggt wird.

dankeschön,
lg
Tom

betateilchen

Zitat von: Samsi am 27 Oktober 2013, 20:17:35Kurze Frage: war das Missing Ack schon immer im state eines Devices?

Ja.

Und dass das MISSING ACK kommt, obwohl der Status korrekt gemeldet wurde, hängt mit der logischen Reihenfolge der Datenkommunikation zusammen. Das erste, was passiert, ist die Meldung des Fenstersensors. Deshalb kommt die erstmal korrekt in fhem an, und erst danach tritt das Kommunikationsproblem auf, das letztendlich zur Meldung MISSING ACK kommt. Und da das eine Statusmeldung ist, gehört die auch völlig korrekterweise in das state.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Samsi

Ok, danke. Dann weiss ich ja jetzt zumindest mal, das ich also seit über einem Jahr nie Missing Ack hatte und das erst seit dem Update passiert.


Zitatund erst danach tritt das Kommunikationsproblem auf, das letztendlich zur Meldung MISSING ACK kommt.

Wie muss ich mir das vorstellen:

Der Fensterkontakt sendet close, bekommt keine  Bestätigung und sendet dann 5 Sekunden Später MissingAck?

Müsste er es dann nicht mehrmals Probieren, immerhin ist per Default eingestellt es 6 mal zu wiederholen (habs gerade noch mal überprüft) ?

Im Log steht es jedenfalls nur einmal:

2013-10-27_15:13:24 kontakt_1OG_Schlafzimmer_3 closed
2013-10-27_15:13:24 kontakt_1OG_Schlafzimmer_3 contact: closed (to HMLAN1)
2013-10-27_15:13:29 kontakt_1OG_Schlafzimmer_3 MISSING ACK


Und wird die Bestätigung automatisch vom HMLAN versendet oder wird das Ack erst gesendet wenn FHEM dem  HMLAN den Befehl gibt das Ack zu senden?

Wenn Letzters der Fall ist, dann könnte es ja daran liegen, das FHEM evtl. gerade sehr beschäftigt war und deshalb das Ack ausblieb. Nach dem Update gestern ist mir FHEM auch nachdem ich ein paar Einstellungen am Thermostat gemacht habe zum ersten mal so abgeschmiert das ich die FB neu starten musste, weil ich nicht mehr auf das FHEM Frontend zugreifen konnte. Die FritzBox selbst war aber noch erreichbar.

Und nach dem Neustart hat es auch sehr lange gedauert, bis das FHEM Web Frontend wieder lief, das war auch sehr ungewöhnlich.

Nochmals Danke und  viele Grüße

Samsi
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

smirnov

Zitat von: tomballarino am 27 Oktober 2013, 20:29:50
das loglevel hat er nicht genommen, den rest schon. jetzt kommen im log folgende einträge:
2013.10.27 20:28:28.176 5: COC: A0F0E8610236D7E0000000AC0E60F6458 -66.5
2013.10.27 20:28:28.178 5: COC dispatch A0F0E8610236D7E0000000AC0E60F6458::-66.5:COC
2013.10.27 20:28:55.214 5: CUL/RAW: /A0FD0861
2013.10.27 20:28:55.217 5: CUL/RAW: A0FD0861/0236C810
2013.10.27 20:28:55.221 5: CUL/RAW: A0FD08610236C810/000000AB0DB0F435
2013.10.27 20:28:55.224 5: CUL/RAW: A0FD08610236C810000000AB0DB0F435/80B

2013.10.27 20:28:55.226 5: COC: A0FD08610236C810000000AB0DB0F4358 -68.5
2013.10.27 20:28:55.228 5: COC dispatch A0FD08610236C810000000AB0DB0F4358::-68.5:COC

reicht das? wenn ja, poste ich morgen die log-datei, bei der die umstellung geloggt wird.

dankeschön,
lg
Tom



soooo, jetzt habe ich die log-einträge des COC studiert, und es geschafft, des öfteren einen IOerr zu provozieren, hier meine bisherigen Erkenntnisse:
das Problem mit IOerr hat nichts mit burst zu tun, ich habe burstAccess bei allen -DN's einmal auf 0_off gestellt, um besser mitschauen zu können.

Hier ein log-Auszug, wenn der Tranfer der desired-temp funktioniert:
2013.10.27 22:01:41.714 5: CUL/RAW: /A0FA1861
2013.10.27 22:01:41.717 5: CUL/RAW: A0FA1861/021C1F10
2013.10.27 22:01:41.720 5: CUL/RAW: A0FA1861021C1F10/000000AA0DA10005
2013.10.27 22:01:41.723 5: CUL/RAW: A0FA1861021C1F10000000AA0DA10005/805

2013.10.27 22:01:41.726 5: COC: A0FA1861021C1F10000000AA0DA100058 -71.5
2013.10.27 22:01:41.728 5: COC dispatch A0FA1861021C1F10000000AA0DA100058::-71.5:COC
2013.10.27 22:01:41.734 1: RCV L:0F N:A1 F:86 CMD:10 SRC:HeizK_Kueche DST:broadcast 0AA0DA100058 (INFO_TEMP SET:40 ACT:218 ERR:0x10 VALVE:0x10 MODE:0x10) (,WAKEMEUP,CFG,RPTEN)
2013.10.27 22:01:41.738 5: COC sending As09DAA112F1123421C1F1
2013.10.27 22:01:41.820 5: SW: As09DAA112F1123421C1F1
2013.10.27 22:01:41.836 1: SND L:09 N:DA F:A1 CMD:12 SRC:F11234 DST:HeizK_Kueche  (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2013.10.27 22:01:41.990 5: CUL/RAW: /A0ADA800221C1F1F112340007

2013.10.27 22:01:41.992 5: COC: A0ADA800221C1F1F1123400 -70.5
2013.10.27 22:01:41.995 5: COC dispatch A0ADA800221C1F1F1123400::-70.5:COC
2013.10.27 22:01:42.000 1: RCV L:0A N:DA F:80 CMD:02 SRC:HeizK_Kueche DST:F11234 00 (ACK) (,RPTEN)
2013.10.27 22:01:42.005 5: COC sending As0CDBA011F1123421C1F186042A
2013.10.27 22:01:42.089 5: SW: As0CDBA011F1123421C1F186042A
2013.10.27 22:01:42.105 1: SND L:0C N:DB F:A0 CMD:11 SRC:F11234 DST:HeizK_Kueche 86042A (,BIDI,RPTEN)
2013.10.27 22:01:42.249 5: CUL/RAW: /A0ADB800
2013.10.27 22:01:42.252 5: CUL/RAW: A0ADB800/221C1F1F
2013.10.27 22:01:42.256 5: CUL/RAW: A0ADB800221C1F1F/112340008

2013.10.27 22:01:42.258 5: COC: A0ADB800221C1F1F1123400 -70
2013.10.27 22:01:42.261 5: COC dispatch A0ADB800221C1F1F1123400::-70:COC
2013.10.27 22:01:42.266 1: RCV L:0A N:DB F:80 CMD:02 SRC:HeizK_Kueche DST:F11234 00 (ACK) (,RPTEN)


für mich als Homematic-Protkoll unkundigen meldet sich der HeizK_Kueche, FHEM sagt: HAVE_DATA, dann kommt ein ACK des DN, dann werden die Daten? übertragen, dann kommt noch ein ACK des DN.
Dieser protokollierte Vorgang hat funktioniert.

Nun ein Mitschnitt von einem fehlgeschlagenen:
2013.10.27 22:03:16.279 5: CUL/RAW: /A0FF5861
2013.10.27 22:03:16.282 5: CUL/RAW: A0FF5861/0236C810
2013.10.27 22:03:16.286 5: CUL/RAW: A0FF58610236C810/000000AA8EB0F1D5
2013.10.27 22:03:16.289 5: CUL/RAW: A0FF58610236C810000000AA8EB0F1D5/80A

2013.10.27 22:03:16.291 5: COC: A0FF58610236C810000000AA8EB0F1D58 -69
2013.10.27 22:03:16.294 5: COC dispatch A0FF58610236C810000000AA8EB0F1D58::-69:COC
2013.10.27 22:03:16.300 1: RCV L:0F N:F5 F:86 CMD:10 SRC:HeizK_WZ_R DST:broadcast 0AA8EB0F1D58 (INFO_TEMP SET:42 ACT:235 ERR:0x0F VALVE:0x0F MODE:0x0F) (,WAKEMEUP,CFG,RPTEN)
2013.10.27 22:03:16.304 5: COC sending As09DEA112F11234236C81
2013.10.27 22:03:16.386 5: SW: As09DEA112F11234236C81
2013.10.27 22:03:16.402 1: SND L:09 N:DE F:A1 CMD:12 SRC:F11234 DST:HeizK_WZ_R  (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2013.10.27 22:03:16.556 5: CUL/RAW: /A0ADE8002236C81F11234000A

2013.10.27 22:03:16.558 5: COC: A0ADE8002236C81F1123400 -69
2013.10.27 22:03:16.561 5: COC dispatch A0ADE8002236C81F1123400::-69:COC
2013.10.27 22:03:16.566 1: RCV L:0A N:DE F:80 CMD:02 SRC:HeizK_WZ_R DST:F11234 00 (ACK) (,RPTEN)
2013.10.27 22:03:16.571 5: COC sending As0CDFA011F11234236C8186042A
2013.10.27 22:03:16.654 5: SW: As0CDFA011F11234236C8186042A
2013.10.27 22:03:16.670 1: SND L:0C N:DF F:A0 CMD:11 SRC:F11234 DST:HeizK_WZ_R 86042A (,BIDI,RPTEN)
...danach kommt 10 sekunden nichts...


hier fehlt das letzte ACK des DN, die Anzeige im Webinterface geht auf IOerr, es wird nicht mehr versucht, den Befehl beim nächsten Aufwachen abzusetzen.
Sollte das nicht der Fall sein? Es kann ja durchaus vorkommen, dass Pakete verloren gehen, deshalb gibt es ja diese bidirektionale Kommunikation.

danke für die Hilfe,
lg
Tom


martinp876

IOErr kommt, wenn dein IO-device "nicht Sendebereit" signalisiert. Es muss sich also der state geaendert haben. kannst du dies prüfen? CUL_HM würde/sollte ansonsten einen timeout erkennen.
voraussichtlich ist der state nicht mehr "opened"

Gruss Martin