homematic empfang wird bei cul initialisierung nicht zuverlässig eingeschaltet

Begonnen von frank, 11 März 2024, 13:00:55

Vorheriges Thema - Nächstes Thema

frank

moin,

nach culfw update von 1.58 auf 1.67 wird der homematic empfang bei der initialisierung meines cul_v3 nicht mehr zuverlässig eingeschaltet (vielleicht 50% erfolg).
alle möglichen optionen sind betroffen (reopen, B00, fhem restart, attr rfmode toggeln, unplug/plug, ...).

durch den einbau einer debug meldung in rf_asksin.c am ende der funktion asksin_send() wird ersichtlich, dass die variable asksin_on nicht gesetzt wird, oder irgendwo wieder zurückgesetzt wird.
  if(asksin_on) {
    do {
      ccStrobe(CC1100_SRX);
    } while (cc1100_readReg(CC1100_MARCSTATE) != MARCSTATE_RX);
    if(cca) DS_P(PSTR("MST:RX\r\n"));//frank:
  } else {
    DS_P(PSTR("asksin_off\r\n"));//frank:
    set_txrestore();
  }

komischerweise wird im fehlerfall die erste funkmessage nach der initialisierung (immer?) noch empfangen.
sieht also eher nach wieder ausschalten von asksin_on aus.

2024.03.06 09:12:00.488 4: CUL_Parse: cul868 A 0C 0B 8670 1936FF 000000 009545FD -75.5
2024.03.06 09:12:00.497 5: cul868: dispatch A0C0B86701936FF000000009545::-75.5:cul868
2024.03.06 09:12:00.615 0: HMLAN_Parse: hmlan1 R:E1936FF   stat:0000 t:BC70540E d:FF r:FFCB     m:0B 8670 1936FF 000000 009545
2024.03.06 09:12:00.621 0: HMUARTLGW hmuart1 recv: 01 05 00 00 53 msg: 0B 86 70 1936FF 000000 009545

2024.03.06 09:12:07.463 3: set cul868 raw B00
2024.03.06 09:12:07.471 5: DevIo_SimpleWrite cul868: B00
2024.03.06 09:12:07.655 1: /dev/serial/by-id/usb-busware.de_CUL868-if00 disconnected, waiting to reappear (cul868)
2024.03.06 09:12:09.285 3: Setting cul868 serial parameters to 38400,8,N,1
2024.03.06 09:12:09.394 5: DevIo_SimpleWrite cul868: V
2024.03.06 09:12:09.401 5: DevIo_SimpleWrite cul868: ?
2024.03.06 09:12:09.459 3: cul868: Possible commands: ABbCeFGhKkLlMmNRTtUuVWXxZ
2024.03.06 09:12:09.464 5: DevIo_SimpleWrite cul868: X21
2024.03.06 09:12:09.469 5: DevIo_SimpleWrite cul868: Ar
2024.03.06 09:12:09.475 5: DevIo_SimpleWrite cul868: T01
2024.03.06 09:12:09.481 5: GOT CUL fhtid: 0000
2024.03.06 09:12:09.517 1: /dev/serial/by-id/usb-busware.de_CUL868-if00 reappeared (cul868)

2024.03.06 09:12:10.679 4: CUL_Parse: cul868 A 14 42 805E 266EA5 1ACE1F 000000000000000000000026 -55
2024.03.06 09:12:10.685 5: cul868: dispatch A1442805E266EA51ACE1F0000000000000000000000::-55:cul868
2024.03.06 09:12:10.701 0: HMUARTLGW hmuart1 recv: 01 05 00 00 33 msg: 42 80 5E 266EA5 1ACE1F 0000000000000000000000
2024.03.06 09:12:10.709 0: HMLAN_Parse: hmlan1 R:E266EA5   stat:0000 t:BC707BDD d:FF r:FFBC     m:42 805E 266EA5 1ACE1F 0000000000000000000000

2024.03.06 09:12:14.475 0: HMUARTLGW hmuart1 recv: 01 05 00 00 54 msg: B4 86 70 20DFE1 000000 003350
2024.03.06 09:12:14.585 0: HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:BC708AB0 d:FF r:FFAF     m:B4 8670 20DFE1 000000 003350

2024.03.06 09:12:15.134 0: HMUARTLGW hmuart1 recv: 01 05 00 00 4A msg: 4C 86 70 2064CB 000000 005B49
2024.03.06 09:12:15.141 0: HMLAN_Parse: hmlan1 R:E2064CB   stat:0000 t:BC708D43 d:FF r:FFB3     m:4C 8670 2064CB 000000 005B49

2024.03.06 09:12:16.192 5: cul868 sending As0B53A258B5B5B51C4E25031E
2024.03.06 09:12:16.197 5: DevIo_SimpleWrite cul868: As0B53A258B5B5B51C4E25031E
2024.03.06 09:12:16.243 0: HMUARTLGW hmuart1 recv: 01 05 00 00 1A msg: 53 A2 58 B5B5B5 1C4E25 031E
2024.03.06 09:12:16.252 4: CUL_Parse: cul868 a sk si n_of f 
2024.03.06 09:12:16.256 5: cul868: dispatch asksin_off
2024.03.06 09:12:16.315 3: cul868: Unknown code asksin_off, help me!
2024.03.06 09:12:16.319 0: HMLAN_Parse: hmlan1 R:EB5B5B5   stat:0000 t:BC709195 d:FF r:FFD8     m:53 A258 B5B5B5 1C4E25 031E


gibt es ideen wodurch dieses problem verursacht werden könnte?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

da in asksin_send nach dem aufruf von asksin_init eine verzögerung eingebaut ist, habe ich sie auch beim aufruf in der funktion asksin_func übernommen.

=> gefühlt ist die quote erfolgreicher initialisierungen von 50% auf 66% gestiegen.

anschliessend habe ich die verzögerung auch noch vor den aufruf von asksin_init eingefügt.

=> nun liegt die erfolgsquote vermutlich bei 90%.
gefühlt ist B00 anfälliger für probleme als zb reopen.


void
asksin_func(char *in)
{
#ifndef HAS_ASKSIN_FUP
  if(in[1] == 'r') {                // Reception on
#else
  if((in[1] == 'r') || (in[1] == 'R')) {                // Reception on
    if (in[1] == 'R') {
      asksin_update_mode = 1;
    } else {
      asksin_update_mode = 0;
    }
#endif
//    DS_P(PSTR("as_setOn\r\n"));//frank:kollidiert mit set raw T01
    my_delay_ms(3);             //frank: 3ms: Found by trial and error
    rf_asksin_init();
    my_delay_ms(3);             //frank: 3ms: Found by trial and error
    asksin_on = 1;

  } else if(in[1] == 's') {         // Send
    asksin_send(in+1);

  } else {                          // Off
    DS_P(PSTR("as_setOff\r\n"));//frank:
    asksin_on = 0;

  }
}


im moment habe ich den verdacht, dass irgendwann nach der initialisierung ein set_ccon() oder set_ccoff() die variable asksin_on ausschaltet, da im problemfall immer noch die erste message nach der initialisierung empfangen wird.
sogar wenn diese 1. message erst viele sekunden nach der initialisierung kommt.
erst danach fällt der empfang aus.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

warum wird eigentlich in asksin_send() in diesem if

  // in AskSin mode already?
  if(!asksin_on) {
    rf_asksin_init();
    my_delay_ms(3);             // 3ms: Found by trial and error
  }

nicht auch "asksin_on = 1;" gesetzt, also der empfang eingeschaltet?
macht es überhaupt sinn asksin zu senden, wenn man es nicht empfangen kann?

es ist ja sicherlich auch nicht "gesund", wenn bei ausgeschaltetem asksinempfang ständig bei jedem senden asksin_init() ausgeführt wird.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

Zitat von: frank am 12 März 2024, 11:42:21im moment habe ich den verdacht, dass irgendwann nach der initialisierung ein set_ccon() oder set_ccoff() die variable asksin_on ausschaltet, da im problemfall immer noch die erste message nach der initialisierung empfangen wird.
durch den einbau von meldungen in die beiden funktionen set_ccon und set_ccoff hat sich gezeigt, dass im problemfall ein ständiger aufruf der funktion set_ccon für das ausschalten des asksin-empfangs verantwortlich ist.

2024.03.24 14:11:12.558 3: set cul868 raw B00
2024.03.24 14:11:12.563 5: DevIo_SimpleWrite cul868: B00
2024.03.24 14:11:12.793 1: /dev/serial/by-id/usb-busware.de_CUL868-if00 disconnected, waiting to reappear (cul868)
2024.03.24 14:11:13.393 3: Setting cul868 serial parameters to 38400,8,N,1
2024.03.24 14:11:13.504 5: DevIo_SimpleWrite cul868: V
2024.03.24 14:11:13.509 5: DevIo_SimpleWrite cul868: ?
2024.03.24 14:11:13.551 3: cul868: Possible commands: ABbCeFGhKklMmNRTtUuVWXxZ
2024.03.24 14:11:13.554 5: DevIo_SimpleWrite cul868: X21
2024.03.24 14:11:13.557 5: DevIo_SimpleWrite cul868: Ar
2024.03.24 14:11:13.561 5: DevIo_SimpleWrite cul868: T01
2024.03.24 14:11:13.565 5: GOT CUL fhtid: as_setOff_ccon
2024.03.24 14:11:13.567 2: Setting cul868 fhtid from as_setOff_ccon to 0000
2024.03.24 14:11:13.570 5: DevIo_SimpleWrite cul868: T010000
2024.03.24 14:11:13.600 1: /dev/serial/by-id/usb-busware.de_CUL868-if00 reappeared (cul868)
2024.03.24 14:11:13.653 4: CUL_Parse: cul868 0 00 0   
2024.03.24 14:11:13.664 5: cul868: dispatch 0000
2024.03.24 14:11:13.708 3: cul868: Unknown code 0000, help me!

2024.03.24 14:11:18.266 1: ----- IODev-Change ----- => Ventil.Kueche: hmlan1 -> cul868
2024.03.24 14:11:18.291 5: cul868 sending As0BA8A258B1B1B11BFC5203FD
2024.03.24 14:11:18.295 5: DevIo_SimpleWrite cul868: As0BA8A258B1B1B11BFC5203FD
2024.03.24 14:11:18.350 0: HMLAN_Parse: hmlan1 R:EB1B1B1   stat:0000 t:1A38019D d:FF r:FFD8     m:A8 A258 B1B1B1 1BFC52 03FD
2024.03.24 14:11:18.360 0: HMUARTLGW hmuart1 recv: 01 05 00 00 19 msg: A8 A2 58 B1B1B1 1BFC52 03FD

2024.03.24 14:11:18.460 4: CUL_Parse: cul868 A 0E A8 8202 1BFC52 B1B1B1 0101C6803A19 -61.5
2024.03.24 14:11:18.463 5: cul868: dispatch A0EA882021BFC52B1B1B10101C6803A::-61.5:cul868
2024.03.24 14:11:18.532 0: HMLAN_Parse: hmlan1 R:E1BFC52   stat:0000 t:1A380222 d:FF r:FFCD     m:A8 8202 1BFC52 B1B1B1 0101C6803A
2024.03.24 14:11:18.537 0: HMUARTLGW hmuart1 recv: 01 05 00 00 36 msg: A8 82 02 1BFC52 B1B1B1 0101C6803A

2024.03.24 14:11:18.542 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:18.545 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:18.574 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:18.576 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:18.579 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:18.607 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:18.732 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:18.735 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:18.763 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:18.766 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:18.769 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:18.798 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:19.100 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:19.104 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:19.145 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:19.150 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:19.154 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:19.190 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:19.203 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:19.206 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:19.235 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:19.238 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:19.241 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:19.270 3: cul868: Unknown code as_setOff_ccon, help me!

2024.03.24 14:11:20.141 0: HMUARTLGW hmuart1 recv: 01 05 00 00 36 msg: 19 80 5E 266EA5 1ACE1F 0000000000000000000000
2024.03.24 14:11:20.150 0: HMLAN_Parse: hmlan1 R:E266EA5   stat:0000 t:1A3808AE d:FF r:FFC3     m:19 805E 266EA5 1ACE1F 0000000000000000000000

2024.03.24 14:11:20.484 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:20.489 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:20.538 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:20.542 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:20.546 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:20.587 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:20.731 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:20.734 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:20.763 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:20.766 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:20.769 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:20.797 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:23.212 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:23.218 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:23.271 3: cul868: Unknown code as_setOff_ccon, help me!
2024.03.24 14:11:23.276 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:23.280 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:23.309 3: cul868: Unknown code as_setOff_ccon, help me!

2024.03.24 14:11:23.773 0: HMUARTLGW hmuart1 recv: 01 05 00 00 48 msg: CF A2 70 6869B6 1ACE1F 007D462ACA0000C45E0B54
2024.03.24 14:11:23.801 1: ----- IODev-Change ----- => Wetter.Sued: hmlan1 -> cul868
2024.03.24 14:11:23.814 5: cul868 sending As0ACF80021ACE1F6869B600
2024.03.24 14:11:23.817 5: CUL 6869B6 dly:52ms
2024.03.24 14:11:23.871 5: DevIo_SimpleWrite cul868: As0ACF80021ACE1F6869B600
2024.03.24 14:11:23.985 0: HMLAN_Parse: hmlan1 R:E6869B6   stat:0000 t:1A3816DF d:FF r:FFBC     m:CF A270 6869B6 1ACE1F 007D462ACA0000C45E0B54
2024.03.24 14:11:23.991 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:1A38176D d:FF r:FFD8     m:CF 8002 1ACE1F 6869B6 00
2024.03.24 14:11:24.000 0: HMUARTLGW hmuart1 recv: 01 05 00 00 26 msg: CF 80 02 1ACE1F 6869B6 00
2024.03.24 14:11:24.006 0: HMUARTLGW hmuart1 recv: 01 05 00 00 19 msg: CF 80 02 1ACE1F 6869B6 00

2024.03.24 14:11:24.012 4: CUL_Parse: cul868 a s_ is Off   
2024.03.24 14:11:24.017 5: cul868: dispatch as_isOff
2024.03.24 14:11:24.090 3: cul868: Unknown code as_isOff, help me!

2024.03.24 14:11:24.092 4: CUL_Parse: cul868 a s_ se tOff _ccon 
2024.03.24 14:11:24.095 5: cul868: dispatch as_setOff_ccon
2024.03.24 14:11:24.123 3: cul868: Unknown code as_setOff_ccon, help me!


scheinbar wird nach dem empfang der ersten asksin message ständig die funktion rf_router_ping und dadurch set_ccon aufgerufen, denn nach dem auskommentieren von "#define HAS_RF_ROUTER" hat der spuk ein ende.
seit fast einem tag werden regelmässige initialisierungen (B00 und reopen) zu 100% zuverlässig ausgeführt.


gibt es hierzu ideen?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html