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

frank

moin,

mein cul funktioniert endlich wieder ohne probleme.  :)

das problem waren letztendlich daten im eeprom, die diesen "trouble-modus" aktiviert haben.
ein einfaches "set cul raw e" (eeprom reset) hätte das problem beseitigt.


1. die initialisierungsprobleme lassen sich reproduzieren, indem man im rfmode=HomeMatic zusätzlich die RF_ROUTER funktionen für einen remote cul eingeschaltet hat (zb "set cul raw ui0201").
beim einschalten verstellt sich allerdings zunächst die empfangskonfiguration auf:
ccconf: freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:12dBalso manuell wieder auf die default homematic konfiguration umgestellen:
ccconf: freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dBda im rfmode=HomeMatic manuelle einstellungen verhindert werden, muss man während der konfiguration den SlofRF mode im attribut setzen!!!

eigentlich müsste man den RF_ROUTER verriegeln, wenn im attr rfmode=HomeMatic gesetzt ist. bekommt man einen gebrauchten cul, kann es einen auch eiskalt erwischen.


2. die prozedur der eeprom initialisierung (ein "eeprom reset" wird nur ausgeführt, wenn sich die versions nummer der fw ändert) hat vermutlich die "bösen" daten geliefert.

ich hatte wie beschrieben, zunächst von 1.58 auf 1.67 updated. dabei wurde der eeprom wahrscheinlich neu initialisiert.

einen tag später habe ich dann in einer nacht-und-nebel-aktion versucht, die tsculfw zum laufen zu bringen. da 00_TSCUL.pm aber mittlerweile diverse abhängigkeiten zu weiteren eigenen modul-dateien hat, die ich noch nicht installiert hatte, hat fhem natürlich ständig 00_TSCUL nicht geladen. zu später stunde habe ich die aktion abgebrochen und bin zurück zur "normalen" culfw v1.67.

bei diesem hin und her müssen die eeprom daten entstanden sein, denn in meinen alten logs habe ich die genannte konfiguration des funkchips gefunden.
ccconf: freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:12dB
vielleicht sollte man mal einen hinweis platzieren (culfw.de), dass es sinn macht, nach jedem flashen ein eeprom reset (raw e) auszuführen?
meine selbst kompilierten fw haben ja auch kein eeprom reset gemacht, da die fw version gleich geblieben ist.

erst das flashen der cul_v3.hex (v1.68) von sourceforge hat zufällig den eeprom neu initialisiert und das problem behoben. 
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

irgend einem bot muss dieser thread wohl gefallen.  ;)
ob chatgpt hier auf lösungen hofft?
seit ein paar tagen gibt es hier über 1000 aufrufe täglich.
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

moin,

die herkunft der "falschen" eepromdaten ist nun auch gelöst.


die eingebaute eeprom initialisierung, die nur aktiviert wird, wenn sich die fw versionsnummer geändert hat, ist nicht robust genug.
wird die eeprom initialisierung gestartet, wird als erstes die neue fw versionsnummer ins eeprom gespeichert und erst anschliessend die restlichen eepromdaten.

kommt es nun zu einem abbruch der eeprom initialisierung nach dem ändern der versionsnummer, bleiben die restlichen alten daten im eeprom erhalten.
jede weitere cul initialisierung verhindert nun die eeprom initialisierung, da die fw versionsnummer nun identisch ist.


in meinem fall habe ich den cul an einem externen pc mit dem FLIP tool geflasht.
bis zum abziehen des cul am externen pc wurde die neue fw noch nicht gestartet.
beim einstecken des cul am fhem-pi muss es dann zum abbruch der eeprom initialisierung gekommen sein.

durch schnelles ein-aus-ein-stecken des cul am pi konnte ich so einen abbruch nachstellen, der anschliessend die beschriebenen initialisierungsprobleme zeigt.

die "alten" eepromdaten von der tsculfw 0.39 haben dafür gesorgt, dass nun der RF_Router aktiviert war.

"set cul raw u" zeigte nun "0043".


hier das log dazu:
2024.04.21 16:16:00.701 3: Setting cul868 serial parameters to 38400,8,N,1
2024.04.21 16:16:00.811 5: DevIo_SimpleWrite cul868: V
2024.04.21 16:16:00.816 5: DevIo_SimpleWrite cul868: ?
2024.04.21 16:16:00.857 3: cul868: Possible commands: ABbCeFGhiKkLlMmNRTtUuVWXxYZ
2024.04.21 16:16:00.860 5: DevIo_SimpleWrite cul868: X21
2024.04.21 16:16:00.863 5: DevIo_SimpleWrite cul868: Ar
2024.04.21 16:16:00.867 5: DevIo_SimpleWrite cul868: T01
2024.04.21 16:16:00.872 5: GOT CUL fhtid: 0B27
2024.04.21 16:16:00.875 2: Setting cul868 fhtid from 0B27 to 0000
2024.04.21 16:16:00.877 5: DevIo_SimpleWrite cul868: T010000
2024.04.21 16:16:00.907 1: /dev/serial/by-id/usb-busware.de_CUL868-if00 reappeared (cul868)
2024.04.21 16:16:15.329 4: CUL_Parse: cul868 A 0C 8D 8670 1BF81B 000000 00A63E2A -53
2024.04.21 16:16:15.339 5: cul868: dispatch A0C8D86701BF81B00000000A63E::-53:cul868
2024.04.21 16:16:15.495 0: HMLAN_Parse: hmlan1 R:E1BF81B   stat:0000 t:AAAA7275 d:FF r:FFD2     m:8D 8670 1BF81B 000000 00A63E
2024.04.21 16:16:15.501 0: HMUARTLGW hmuart1 recv: 01 05 00 00 2E msg: 8D 86 70 1BF81B 000000 00A63E
2024.04.21 16:16:18.448 0: HMUARTLGW hmuart1 recv: 01 05 00 00 4A msg: 22 86 70 2064CB 000000 005B47
2024.04.21 16:16:18.461 0: HMLAN_Parse: hmlan1 R:E2064CB   stat:0000 t:AAAA7EA1 d:FF r:FFB0     m:22 8670 2064CB 000000 005B47
2024.04.21 16:16:19.503 0: HMUARTLGW hmuart1 recv: 01 05 00 00 34 msg: 25 80 5E 266EA5 1ACE1F 0000000000000000000000
2024.04.21 16:16:19.514 0: HMLAN_Parse: hmlan1 R:E266EA5   stat:0000 t:AAAA82BF d:FF r:FFCA     m:25 805E 266EA5 1ACE1F 0000000000000000000000
2024.04.21 16:16:21.173 0: HMUARTLGW hmuart1 recv: 01 05 00 00 3D msg: 45 86 70 20E183 000000 00A341
2024.04.21 16:16:21.184 0: HMLAN_Parse: hmlan1 R:E20E183   stat:0000 t:AAAA8947 d:FF r:FFBF     m:45 8670 20E183 000000 00A341
2024.04.21 16:16:22.422 0: HMUARTLGW hmuart1 recv: 01 05 00 00 49 msg: BF A2 70 83765A 1ACE1F 007E4828000000541A0B54
2024.04.21 16:16:22.477 1: ----- IODev-Change ----- => Wetter.Nord: hmlan1 -> cul868
2024.04.21 16:16:22.493 5: cul868 sending As0ABF80021ACE1F83765A00
2024.04.21 16:16:22.497 5: CUL 83765A dly:20ms
2024.04.21 16:16:22.520 5: DevIo_SimpleWrite cul868: As0ABF80021ACE1F83765A00
2024.04.21 16:16:22.617 0: HMLAN_Parse: hmlan1 R:E83765A   stat:0000 t:AAAA8E22 d:FF r:FFC1     m:BF A270 83765A 1ACE1F 007E4828000000541A0B54
2024.04.21 16:16:22.622 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:AAAA8EB7 d:FF r:FFD7     m:BF 8002 1ACE1F 83765A 00
2024.04.21 16:16:22.632 0: HMUARTLGW hmuart1 recv: 01 05 00 00 27 msg: BF 80 02 1ACE1F 83765A 00
2024.04.21 16:16:22.637 0: HMUARTLGW hmuart1 recv: 01 05 00 00 17 msg: BF 80 02 1ACE1F 83765A 00
2024.04.21 16:16:26.376 1: Timeout for SIP_ListenStart reached, terminated process 4312
2024.04.21 16:16:30.284 4: CUL_Parse: cul433 tA012609602E8 -86
2024.04.21 16:16:34.000 0: HMLAN_Parse: hmlan1 R:E1936FF   stat:0000 t:AAAABB5F d:FF r:FFC8     m:85 8670 1936FF 000000 009745
2024.04.21 16:16:35.053 0: HMUARTLGW hmuart1 recv: 01 05 00 00 51 msg: 46 A2 70 6869B6 1ACE1F 009E362ACB000299DF0AF0
2024.04.21 16:16:35.092 1: ----- IODev-Change ----- => Wetter.Sued: hmlan1 -> cul868
2024.04.21 16:16:35.109 5: cul868 sending As0A4680021ACE1F6869B600
2024.04.21 16:16:35.112 5: CUL 6869B6 dly:36ms
2024.04.21 16:16:35.151 5: DevIo_SimpleWrite cul868: As0A4680021ACE1F6869B600
2024.04.21 16:16:35.260 0: HMLAN_Parse: hmlan1 R:E6869B6   stat:0000 t:AAAABF80 d:FF r:FFBD     m:46 A270 6869B6 1ACE1F 009E362ACB000299DF0AF0
2024.04.21 16:16:35.265 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:AAAAC00F d:FF r:FFD7     m:46 8002 1ACE1F 6869B6 00
2024.04.21 16:16:35.272 0: HMUARTLGW hmuart1 recv: 01 05 00 00 27 msg: 46 80 02 1ACE1F 6869B6 00
2024.04.21 16:16:35.277 0: HMUARTLGW hmuart1 recv: 01 05 00 00 18 msg: 46 80 02 1ACE1F 6869B6 00
2024.04.21 16:16:38.361 0: HMUARTLGW hmuart1 recv: 01 05 00 00 35 msg: 26 80 5E 266EA5 1ACE1F 0000000000000000000000
2024.04.21 16:16:38.373 0: HMLAN_Parse: hmlan1 R:E266EA5   stat:0000 t:AAAACC6D d:FF r:FFC9     m:26 805E 266EA5 1ACE1F 0000000000000000000000
2024.04.21 16:16:57.219 0: HMUARTLGW hmuart1 recv: 01 05 00 00 34 msg: 27 80 5E 266EA5 1ACE1F 0000000000000000000000
2024.04.21 16:16:57.233 0: HMLAN_Parse: hmlan1 R:E266EA5   stat:0000 t:AAAB1619 d:FF r:FFCA     m:27 805E 266EA5 1ACE1F 0000000000000000000000
2024.04.21 16:17:12.673 3: set cul868 raw u
2024.04.21 16:17:12.681 5: DevIo_SimpleWrite cul868: u
2024.04.21 16:17:12.751 4: CUL_Parse: cul868 0 04 3   
2024.04.21 16:17:12.757 5: cul868: dispatch 0043
2024.04.21 16:17:12.813 3: cul868: Unknown code 0043, help me!


um dieses problem auszuschliessen, plant @noansi für die tsculfw das speichern einer neuen fw versionsnummer erst am ende der eeprom initialisierungsprozedur durchzuführen.


@rudolfkoenig
liest du hier eigentlich auch mit?


gruss frank
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

rudolfkoenig

Zitat@rudolfkoenig
liest du hier eigentlich auch mit?
Ja. Habe aber (noch?) nicht vor, was zu aendern.

frank

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