Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.43

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

noansi

Hallo Ralf,

ich habe nochmal einige Korrekturen und Verbesserungen eingepflegt, die mir noch aufgefallen sind.

Gruß, Ansgar.

Ralf9

Ich hab mal drüber geschaut, Du hast Da einiges geändert.
Ich werde nur ein Teil übernehmen, vieles verstehe ich nicht.

Wo in welchem Fall wird das $hash->{OLDDEF} definiert?
  if ($hash->{OLDDEF}) {
    delete($hash->{CODE}{1});
    my @b = split(/[ \t]+/, $hash->{OLDDEF}, 2);
    delete($modules{IT}{defptr}{lc($b[0])}{$name});
    delete($hash->{READINGS}{protocol});
    delete($hash->{READINGS}{mode});
    delete($hash->{READINGS}{unit});
    delete($hash->{READINGS}{group});
    for my $c (keys(%it_c2b)) {
      delete($hash->{$c});
    }
  }

Zitatmy $ioTsculfw        = ($io->{TYPE} eq 'TSCUL' && $io->{helper}{SVTS});
Damit wird es als CUL behandelt, wenn $io->{helper}{SVTS} nicht definiert ist.
Ich werde es ohne das $io->{helper}{SVTS} einbauen.
my $ioTsculfw        = ($io->{TYPE} eq 'TSCUL');
Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

noansi

Hallo Ralf,

Wo in welchem Fall wird das $hash->{OLDDEF} definiert?Das wird bei CommandModify definiert. In der fhem.pl findest Du es.

Damit wird es als CUL behandelt, wenn $io->{helper}{SVTS} nicht definiert ist.$io->{helper}{SVTS} ist eine Info, dass es eine tsculfw bedient, die SlowRf hat. Es beruht auf der Abfrage, dass die Firmware Version mit VTS anfängt.
Wenn es nicht existiert, dann wurde ein CUL mit cufw oder a-culfw als TSCUL definiert. Und dann würde sich das i Kommando entsprechend anders verhalten, wie bei CUL.

Gruß, Ansgar.

Ralf9

Hallo Ansgar,

ich habe ein Teil Deiner änderungen übernommen, nun müsste das set auch mit dem TSCUL funktionieren.

https://github.com/Ralf9/10_IT/commit/a1b24db77cddc4c00bc76223e4680ba6e0a77b85
https://github.com/Ralf9/10_IT/blob/master/FHEM/10_IT.pm

ZitatDas wird bei CommandModify definiert. In der fhem.pl findest Du es.
Danke, damit ist es klar.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

noansi

Hallo Ralf,

Zitatich habe ein Teil Deiner änderungen übernommen, nun müsste das set auch mit dem TSCUL funktionieren.
Ich habe nicht nur über die Code Änderungen geschaut, sondern auch real getestet.
Es wird damit mit TSCUL und tsculfw gesendet.  :)

Was mir jedoch aufgefallen ist.
Im Code bist Du meinem Hinweis zum notwendigen Check auf das i-Kommando auch für CUL nicht gefolgt. Warum?
return "IODev $io->{NAME} does not support IT" if ($ioTsculfw && defined($io->{CMDS}) && $io->{CMDS} !~ m/i/); # TSCUL muss das i Kommando kennen
Auch CUL muss das i Kommando kennen. Man kann beim Compilieren das Senden von IT in der board.h weg lassen (HAS_INTERTECHNO nicht definieren -> kein i Kommando). Mit HAS_IT kann man dennoch den IT Empfang in die Firmware compilieren.

Dann fällt mir weiter auf, dass gesendete IT HE und HEEU Telegramme mit Hinweis auf Längenfehler nicht dekodiert werden können.
Hier mal ein Log Auszug dazu. Gesendet wurde über CUNO2_WS868 und empfangen über PIG_WS433, jeweils mit tsculfw, mal mit Deiner Version 20839 2023-12-12 18:00:00Z Ralf9 gesendet und dekodiert und mal mit meiner 10_IT.pm 18090k 2023-12-10 00:00:00Z noansi gesendet und dekodiert.
Version Ralf9 HE
2023.12.13 08:14:41.348 4: TSCUL_Parse: PIG_WS433 ihD9D0E6101B -60.5
2023.12.13 08:14:41.491 4: TSCUL_Parse: CUNO2_WS868 ish1101100111010000111001100001
2023.12.13 08:14:41.497 3: PIG_WS433 IT: message "ihd9d0e610" (10) too short!
2023.12.13 08:14:42.903 4: TSCUL_Parse: PIG_WS433 ihD9C114501B -60.5
2023.12.13 08:14:43.005 3: PIG_WS433 IT: message "ihd9c11450" (10) too short!
2023.12.13 08:14:43.026 4: TSCUL_Parse: CUNO2_WS868 ish1101100111000001000101000101
Version noansi HE
2023.12.13 08:44:44.498 4: TSCUL_Parse: PIG_WS433 ihD9D0E6101D -59.5
2023.12.13 08:44:44.636 4: PIG_WS433 IT: msgcode "1101100111010000111001100001" (28) bin = 11011001110100001110011000010000
2023.12.13 08:44:44.638 4: receiverID: 1 OFF/ON/DIM: 1 Rolling-Code: 1 Transmitter-ID: 1234
2023.12.13 08:44:44.680 4: TSCUL_Parse: CUNO2_WS868 ish1101100111010000111001100001
2023.12.13 08:44:45.509 4: TSCUL_Parse: PIG_WS433 ihD9C114501D -59.5
2023.12.13 08:44:45.648 4: TSCUL_Parse: CUNO2_WS868 ish1101100111000001000101000101
2023.12.13 08:44:45.652 4: PIG_WS433 IT: msgcode "1101100111000001000101000101" (28) bin = 11011001110000010001010001010000
2023.12.13 08:44:45.654 4: receiverID: 1 OFF/ON/DIM: 0 Rolling-Code: 2 Transmitter-ID: 1234

Version Ralf9 HEEU
2023.12.13 08:15:38.349 4: TSCUL_Parse: PIG_WS433 ih3CCF33CCF33EC20018 -62
2023.12.13 08:15:38.452 3: PIG_WS433 IT: message "ih3ccf33ccf33ec200" (18) too short!
2023.12.13 08:15:38.475 4: TSCUL_Parse: CUNO2_WS868 ise001111001100111100110011110011001111001100111110110000100
2023.12.13 08:15:39.899 4: TSCUL_Parse: PIG_WS433 ih3CCF33CCF33DC20019 -61.5
2023.12.13 08:15:40.001 3: PIG_WS433 IT: message "ih3ccf33ccf33dc200" (18) too short!
2023.12.13 08:15:40.024 4: TSCUL_Parse: CUNO2_WS868 ise001111001100111100110011110011001111001100111101110000100
Version noansi HEEU
2023.12.13 08:44:48.272 4: TSCUL_Parse: PIG_WS433 ih3CCF33CCF33EC2001A -61
2023.12.13 08:44:48.413 4: TSCUL_Parse: CUNO2_WS868 ise001111001100111100110011110011001111001100111110110000100
2023.12.13 08:44:48.417 4: PIG_WS433 IT: msgcode "001111001100111100110011110011001111001100111110110000100" (57) bin = 001111001100111100110011110011001111001100111110110000100000
2023.12.13 08:44:49.539 4: TSCUL_Parse: PIG_WS433 ih3CCF33CCF33DC2001A -61
2023.12.13 08:44:49.642 4: PIG_WS433 IT: msgcode "001111001100111100110011110011001111001100111101110000100" (57) bin = 001111001100111100110011110011001111001100111101110000100000
2023.12.13 08:44:49.682 4: TSCUL_Parse: CUNO2_WS868 ise001111001100111100110011110011001111001100111101110000100

Hier noch die Definition des Test HE devices:
define ITSteckdose433_ITHE IT HE800 1234 1
attr ITSteckdose433_ITHE IODevList CUNO2_WS868
attr ITSteckdose433_ITHE protocol HE800
attr ITSteckdose433_ITHE room Tests
und des HEEU Test devices:
define ITSteckdose433_ITHEEU IT 0011110011001111001100111100110011110011001111 0 0000100
attr ITSteckdose433_ITHEEU IODevList CUNO2_WS868
attr ITSteckdose433_ITHEEU protocol HE_EU
attr ITSteckdose433_ITHEEU room Tests

Da ich den Empfang nur mit dem testen kann, was ich via tsculfw sende weil ich kein itV3, itHE oder itHEEU Gerät besitze, erhebe ich keinen Anspruch auf Richtigkeit.
Logisch wäre es aber schon, dass das gesendete Telegramm auch wieder empfangen und dekodiert werden kann, sollten die realen Geräte ja auch damit können.
Wenn die Fernbedienung sendet, sollte der neue Status beim fhem IT device entsprechend Empfang auch angezeigt werden können.
Vielleicht kannst Du mir den Widerspruch auch erklären?

Gruß, Ansgar.

Ralf9

Hallo Ansgar,

ZitatIm Code bist Du meinem Hinweis zum notwendigen Check auf das i-Kommando auch für CUL nicht gefolgt. Warum?
Ich kann nicht abschätzen wie zuverlässig die Abfrage der CMDS in der 00_cul DoInit funktioniert.
Falls es mal Probleme bei der Abfrage der CMDS geben sollte, würde das Senden eines i-Kommando nicht funktionieren.

ZitatDann fällt mir weiter auf, dass gesendete IT HE und HEEU Telegramme mit Hinweis auf Längenfehler nicht dekodiert werden können.
Ich habe mal mit einer Homeeasy Fernbedienung IT HE gesendet, das wurde problemlos vom sduino und nanocul empfangen.

Beim senden vom nanocul zum sduino konnte ich auch keine Probleme erkennen
2023.12.13 16:26:52.342 3: CULnano IT_set: IT_HE800_1234_1 on
2023.12.13 16:26:52.347 5: CULnano IT_set: Type=CUL Protocol=HE800
2023.12.13 16:26:52.351 5: mode is 1
2023.12.13 16:26:52.351 4: msg 228396641 - bin1 1101100111010000111001100001
2023.12.13 16:26:52.637 5: IT_Set: GetFn(raw): message = ish1101100111010000111001100001 Antwort =   raw => ish1101100111010000111001100001
2023.12.13 16:26:52.638 4: sduinoA/msg READredu: MS;P0=-1008;P2=-4970;P3=331;P4=1014;P5=-317;D=3230304530304545303030453045454545303030454530304545454530;CP=3;SP=2;R=119;O;b=89;s=1;m0;
2023.12.13 16:26:52.638 4: sduinoA: Matched MS Protocol id 35 -> HomeEasy HE800, bitLen=28
2023.12.13 16:26:52.638 5: sduinoA: Starting demodulation at Position 2
2023.12.13 16:26:52.638 5: sduinoA: dispatching bits: 1 1 0 1 1 0 0 1 1 1 0 1 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 1
2023.12.13 16:26:52.638 5: sduinoA: applying postDemodulation , value before : 1 1 0 1 1 0 0 1 1 1 0 1 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 1
2023.12.13 16:26:52.638 5: sduinoA: rcode=1, modified after postDemodulation: 1 1 0 1 1 0 0 1 1 1 0 1 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0
2023.12.13 16:26:52.638 4: sduinoA: Decoded MS Protocol id 35 dmsg ihD9D0E61000 length 40 RSSI = -14.5
2023.12.13 16:26:52.639 5: sduinoA: dispatch ihD9D0E61000
2023.12.13 16:26:52.639 4: sduinoA IT: message "ihD9D0E61000" (12)
2023.12.13 16:26:52.639 4: sduinoA IT: msgcode "1101100111010000111001100001" (28) bin = 11011001110100001110011000010000
2023.12.13 16:26:52.639 4: sduinoA IT: msg:ihD9D0E61000 msgcode:D9D0E610
2023.12.13 16:26:52.639 4: sduinoA IT: HEX:ihD9D0E61000 DEC:3654346256
2023.12.13 16:26:52.639 4: sduinoA IT: DEC:40038814
2023.12.13 16:26:52.639 4: sduinoA IT: DEC:160155256
2023.12.13 16:26:52.639 4: sduinoA IT: mn: 8 7 6 12 11 8 0
2023.12.13 16:26:52.639 4: sduinoA IT: mn: 1 6 2 13 4 0 0
2023.12.13 16:26:52.639 4: receiverID    : 1
2023.12.13 16:26:52.639 4: OFF/ON/DIM    : 1
2023.12.13 16:26:52.639 4: Rolling-Code  : 1
2023.12.13 16:26:52.639 4: Transmitter-ID: 1234
2023.12.13 16:26:52.639 3: sduinoA IT: IT_HE800_1234_1 on->on
2023-12-13 16:26:52.344 IT IT_HE800_1234_1 on
2023-12-13 16:26:52.348 IT IT_HE800_1234_1 lastDimValue:
2023-12-13 16:26:52.637 CUL CULnano raw: ish1101100111010000111001100001
2023-12-13 16:26:52.640 IT IT_HE800_1234_1 on
2023-12-13 16:26:52.640 IT IT_HE800_1234_1 RAWMSG: MS;P0=-1008;P2=-4970;P3=331;P4=1014;P5=-317;D=3230304530304545303030453045454545303030454530304545454530;CP=3;SP=2;R=119;O;b=89;s=1;m0;
2023-12-13 16:26:52.640 IT IT_HE800_1234_1 DMSG: ihD9D0E61000
2023-12-13 16:26:52.640 IT IT_HE800_1234_1 Protocol_ID: 35
2023-12-13 16:26:52.640 IT IT_HE800_1234_1 RSSI: -14.5

Vom sduino zum nanocul wars auch problemlos
2023.12.13 16:30:15.818 3: sduinoA IT_set: IT_HE800_1234_1 on
2023.12.13 16:30:15.823 5: sduinoA IT_set: Type=SIGNALduinoAdv Protocol=HE800
2023.12.13 16:30:15.828 5: mode is 1
2023.12.13 16:30:15.828 4: msg 228396641 - bin1 1101100111010000111001100001
2023.12.13 16:30:15.828 4: sduinoA IT_set: sendMsg=P35#1101100111010000111001100001#R6
2023.12.13 16:30:15.828 5: sduinoA: sendmsg Preparing rawsend command for protocol=35, repeats=6, clock=280 bits=1101100111010000111001100001
2023.12.13 16:30:15.829 4: sduinoA/set: sending via SendMsg: SR;R=6;P0=280;P1=-5040;P2=-1120;P3=952;P4=-280;D=0102023402023434020202340234343434020202343402023434343402;
2023-12-13 16:30:15.823 IT IT_HE800_1234_1 on
2023-12-13 16:30:15.828 IT IT_HE800_1234_1 lastDimValue:
2023.12.13 16:30:15.942 4: sduinoA SendrawFromQueue: msg=SR;R=6;P0=280;P1=-5040;P2=-1120;P3=952;P4=-280;D=0102023402023434020202340234343434020202343402023434343402;
2023.12.13 16:30:16.048 4: CUL_Parse: CULnano ihD9D0E61071
2023.12.13 16:30:16.049 4: CULnano IT: message "ihd9d0e61071" (12)
2023.12.13 16:30:16.049 4: CULnano IT: msgcode "1101100111010000111001100001" (28) bin = 11011001110100001110011000010000
2023.12.13 16:30:16.049 4: CULnano IT: msg:ihd9d0e61071 msgcode:d9d0e610
2023.12.13 16:30:16.049 4: CULnano IT: HEX:ihd9d0e61071 DEC:3654346256
2023.12.13 16:30:16.049 4: CULnano IT: DEC:40038814
2023.12.13 16:30:16.049 4: CULnano IT: DEC:160155256
2023.12.13 16:30:16.049 4: CULnano IT: mn: 8 7 6 12 11 8 0
2023.12.13 16:30:16.049 4: CULnano IT: mn: 1 6 2 13 4 0 0
2023.12.13 16:30:16.049 4: receiverID    : 1
2023.12.13 16:30:16.049 4: OFF/ON/DIM    : 1
2023.12.13 16:30:16.049 4: Rolling-Code  : 1
2023.12.13 16:30:16.049 4: Transmitter-ID: 1234
2023.12.13 16:30:16.049 3: CULnano IT: IT_HE800_1234_1 on->on
2023-12-13 16:30:16.052 IT IT_HE800_1234_1 on

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

noansi

Hallo Ralf,

ZitatIch kann nicht abschätzen wie zuverlässig die Abfrage der CMDS in der 00_cul DoInit funktioniert.
Falls es mal Probleme bei der Abfrage der CMDS geben sollte, würde das Senden eines i-Kommando nicht funktionieren.
Dann darfst Du die Abfrage gar nicht machen.

Zur Zuverlässigkeit kann ich nur für Rf-Router angebundene TSCULs sagen, dass die CMDs Abfrage mal scheitern kann, weil das Protokoll ohne Rückmeldung läuft, damit also die Abfrage oder Antwort auf die Cmds-Abfrage verloren gehen kann.
Ich würde allerdings auf diesem Weg auch nichts einschalten, eben genau deswegen. Rf-Router ist nur geeignet, um verlustbehaftet Sensordaten von weiter entfernten Sensoren zu empfangen.

ZitatVom sduino zum nanocul wars auch problemlos
Ahhh, ich sehe das Problem. In 00_CUL.pm wird in CUL_Parse der RSSI für die ih messages nicht abgetrennt.
  if($dmsg =~ m/^[AFTKEHRStZrib]([A-F0-9][A-F0-9])+$/) { # RSSI

Bei TSCUL in TSCUL_Parse dagegen schon, wie es (aus meiner Sicht) richtig ist.

Deswegen siehst Du zusätzlich immer 2 HEX Zeichen vom RSSI mehr am Ende bei ih messages.
Also noch ein Unterschied mehr bei TSCUL, den Du diesmal beim Parse berücksichtigen musst.

Daher hatte ich seinerzeits beide Längenvarianten für ih messages in 10_IT.pm zugelassen.
Die RSSI Codierung ist prinzipell zunächst CUL spezifisch und sollte daher auch in 00_CUL.pm dekodiert werden.

Gruß, Ansgar.

Ralf9

Dann muß ich am Anfang vom IT_Parse noch die Abfrage "if ($hash->{TYPE} eq 'TSCUL' .." einbauen
  if ((substr($msg, 0, 1)) ne 'i') {
    Log3 $hash,4,"$ioname IT: message not supported by IT \"$msg\"!";
    return '';
  }
  if ($hash->{TYPE} eq 'TSCUL' && substr($msg, 1, 1) eq 'h') {
    $msg .= '00';
    Log3 $hash,4,"$ioname IT: TYPE=TSCUL, add 00 at then end";
  }

Warum werden bei der TSCUL nur bei den ih messages die 2 HEX Zeichen vom RSSI entfernt und nicht auch bei IT V1 und V3?
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

noansi

Hallo Ralf,

ZitatWarum werden bei der TSCUL nur bei den ih messages die 2 HEX Zeichen vom RSSI entfernt und nicht auch bei IT V1 und V3?
Bei TSCUL werden die RSSI Zeichen sowohl bei IT V1 als auch bei IT V3 als auch bei ih messages (und auch im messages) ausgwertet und entfernt. Damit funktioniert dann auch die RSSI Anzeige zum Empfang von IT HE/HEEU von verschiedenen IOs via Dispatch.

Bei CUL dagegen nur bei IT V1 und bei IT V3, was an der schon gezeigten Abfrage vor RSSI Abspaltung und Auswertung in CUL_Parse liegt.
Ich vermute, das wurde bei der 10_IT.pm Entwicklung/Erweiterung übersehen/nicht verstanden und daher nicht von Rudolf an der 00_CUL.pm zur Änderung angefordert???

ZitatDann muß ich am Anfang vom IT_Parse noch die Abfrage "if ($hash->{TYPE} eq 'TSCUL' .." einbauen
Ich will Dich nicht in Deiner Kreativität einschränken, aber Du benötigst für das dekodieren von HE/HEEU Protokolldaten eigentlich nur jeweils 2 Zeichen weniger und RSSI kann dran hängen oder nicht, wäre also als optionaler Zusatz zu verstehen.
Der RSSI ist nicht Bestandteil des Protokolls, sondern wird vom Empfangs-IO nach Vermögen und Gusto anghangen. Kein CC1101 -> u.U. kein RSSI verfügbar -> kein RSSI wird angehangen.

Gruß, Ansgar.

Ralf9

Hallo Ansgar,

ich habe den Code in der IT_Parse nun angepasst, so ähnlich wie es Du auch gemacht hast.
Bei HomeEasy HE800 können nun Längen von 9,10 und 12 verarbeitet werden.
Bei HomeEasy EU können nun Längen von 17,18 und 20 verarbeitet werden.
Da bei HE800 nur 28 Bit gesendet werden, erfolgt nun bei der kommenden 00_SIGNALduinoAdv.pm auch der Dispatch mit nur 9 Zeichen "ih1234567"
Bei HE EU ist es ähnlich.

Anscheinend gibts bei HE800 auch eine alte Version, bei IT_Set wurde dies zwar vorbereitet, aber nicht fertig programmiert.

https://github.com/Ralf9/10_IT/commit/9d4b397e497833ec06afcc3b04daf3b50d39e99a

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

noansi

Hallo Ralf,

ich habe Deinen letzten Stand mit TSCUL und tsculfw getestet und kann senden und empfangen, was gesendet wurde.  :)

ZitatDa bei HE800 nur 28 Bit gesendet werden, erfolgt nun bei der kommenden 00_SIGNALduinoAdv.pm auch der Dispatch mit nur 9 Zeichen "ih1234567"
Ich habe es in meinem neuen Stand berücksichtigt, etwas anders, als Du und etwas klarer kommentiert.
Von culfw und tsculfw kommen ganze angefangene Bytes, daher ergibt sich das zusätzliche Nibble bei HE800 und HE EU.

Gruß, Ansgar.

noansi

Hallo Ralf,

ZitatAnscheinend gibts bei HE800 auch eine alte Version, bei IT_Set wurde dies zwar vorbereitet, aber nicht fertig programmiert.
Ich vermute eher, nicht ganz richtig programmiert trifft es besser.

Ich mutmaße mal, dass in der Vergangenheit für jeden count ein on bzw. off Reading existierte.

Mit neuer Kodierung sollte vermutlich dann das alte noch genutzt werden können, so lange das jeweilige Reading da war???

Jedoch wurde im Code direkt bis VAL gelesen, was die Readings leer erzeugt, wenn sie nicht existieren. Ich habe es mal mit ReadingsVal gemacht und dann klappt das, was vermutlich gedacht war.

Gruß, Ansgar.

noansi

Hallo Ralf,

ich habe nochmal weiter in meiner Variante aufgeräumt.

Das Attribut protocol wird nicht genutzt, von daher überflüssig und entfernt.

userV1setCodes habe ich mal intern mit userV1Code2set zur Rückwärtssuche ergänzt und beim Parsen hinten dran gehängt. Damit kann man dann bestehende Kommandos durch userV1setCodes mit gleichem Code aber anderem Namen im state beim Empfang sichtbar machen.

Das model 'ev1527' habe ich aus der Attributsauswahl raus geworfen. Macht eigentlich nur Probleme und ich erkenne keinen Nutzwert. Das Reading protocol 'ev1527' reicht aus define und bringt kein zusätzliches Codes durcheinander. Irgend jemand würde sicherlich weinen...

Parse habe ich mal etwas geradliniger strukturiert. Ist so auch verständlicher, meine ich. Ob die Interpretation insbesondere mit autocreate so klappt, muss jemand mit Hardware testen.
Die Dimmer Prozente habe ich für v3 verändert, damit es einerseits noch zu den Dim Icons passt und andererseits Schieberegler weniger oder falsch springen.

Gruß, Ansgar.

PS: Über die Testerei ist mir dann aufgefallen, das tsculfw noch kein ITV1 'D' senden kann und daher kein EV1527. Kommt in der nächsten Version. Bei HE werde ich im TSCUL Modul die überflüssige 0 am Ende enfernen, wie Du es vorhast.

noansi

Hallo Testwillige,

hier eine neue Version 0.41 der Timestamp Firmware und der dazu benötigten FHEM Module.

Die Version hat einige Verbesserungen erhalten, Auszug aus der Changed:
Version VTS 0.41
- CC1101_FSCTRL1 default settings adapted to frequency bands
- marker handling configuration at compile time enhanced
- reduced interrupt disabled times
- CUNX, resolved possible Ethernet connect problems, if connected to a host via USB
- CUNX, speed enhancement in Ethernet connection
- SPI transfer little optimized
- HOERMANN send added
- SOMFY send corrected and optimized
- changed USB currents for CUL and CUNX
- ASKSIN for B112/A112 to multible devices better keep of send order for command after
- fswrapper, qfs, df adapted to reversed buffer access, to be tested
- RFR_SHADOW removed
- serial IO and stacking serial IO interrupt routines done in assembler for ATMEGA
- Analog in function 'a' added, allows read of processor temp voltage for CULV3 or allows analog in on one analog input for ATMEGA (done for CUNO2 and nanoCUL/miniCUL)
- Digital in/out function 'd' added, allows digital input or output on upto 8 digital I/O pins for ATMEGA (done for CUNO2 and nanoCUL/miniCUL)
- added Intertechno V1 send of 'D'. 'D' is sent, if not '0', '1' or 'F' is character

Version VTS 0.40
- HOERMANN receive corrected

Beschreibung 'a' Firmware Kommando für Analoge Eingabe auf einem ADC Pin oder CPU Temperature Voltage:
aiTTT: TTT dezimal. Setzt das Abfrage und Reporting Intervall in Sekunden, 0 schaltet es ab.
        Ist es eingeschaltet, dann kommt im Intervall eine aHHHH Message mit dem Analogwert in 16 Bit HEX

acC:  C Buchstabe. Auswahl der Spannungquelle. Wird kein Buchstabe angegeben, dann wird die aktuelle Einstellung ausgegeben als acX oder aXX hex Code.
        acp wählt den analogen Eingabe Pin, vgl. board.h
        acg wählt Analog GMD
        acr wählt die Vbg Referenzspannung
        act wählt den Temperatursensor (so in der CPU vorhanden)

arC:  C Buchstabe. Auswahl des Referenzwertes. Wird kein Buchstabe angegeben, dann wird die aktuelle Einstellung ausgegeben als acX oder aXX hex Code.
        arA wählt AREF
        ar3 wählt VACC
        ar2 wählt 2.56V interne Referenz
        ar1 wählt Vbg

TSCUL zeigt den Spannungswert im Reading VoltAnIn an. Dazu gibt es noch die Attribute AInVref_AVCC_Volt, AInVref_2_56_Volt und AInVref_Vbg_Volt mit denen die Referenzspannungswerte für die Auswertung kalibriert werden können.
Der CPU Temperaturwert wird im Reading Temperature angezeigt. Jedoch muss dieser für jeden CUL indivudell kalibriert werden. Dazu gibt es das Attribut AInTempCalib zur Einstellung einer linearen Kalibrierung.

Bisher nur kompiliert für CUL V3 (nur interne Temperatur), CUNO2, nanoCUL und miniCUL.
Da direkt an die CPU angeschlossen wird, ist natürlich entsprechende Vorsicht walten zu lassen, um den Eingang nicht mit unzulässigen Spannungen zu zerstören.

Beschreibung 'd' Firmware Kommando für Digitale Ein- und Ausgabe auf bis zu 8 digital I/O Pins.
diTTT: TTT dezimal. Setzt das Abfrage und Reporting Intervall für die Pins in Sekunden, 0 schaltet es ab.
        Ist es eingeschaltet, dann kommt im Intervall eine dHH Message mit den Pin Stati in 8 Bit HEX

doHH:  HH hex. Setzt die in HH mit binär 1 gesetzten Pins auf Ausgang, mit binär 0 gweählten Pins auf Eingang.
        Ist ein Pin auf Eingang geschaltet, so werden keine Pullup oder Pulldown Widerstände aktivert. Der Eingang ist also unbeschaltet floatened und liefert demensprechend wechselnde Statuswerte.
        Wird kein Hex Wert angegeben, wird die aktuelle Auswahl als doXX als 6 Bit HEX ausgegeben

dr:    Liest den aktuellen Pin Status als dHH, wie beim Intervall.
drII:  Liest den aktuellen Pin Status des mit II (hex, 0-7) gewählten Pins als dII0 oder dII1. Eine ungültige Pinnummer II liefert ein ?.

dsVV:  setzt alle gewählten Ausgänge auf den Wert im übergebenen 8 Bit HEX Wert VV
dsOOvv: setzt den mit OO (hex, 0-7) gewählten Pin auf 1 wenn vv ungleich 0 oder auf 0, wenn vv gleich 0.
        Ist der Pin nicht mit do auf Ausgabe gewählt, dann passiert nichts.  Eine ungültige Pinnummer OO liefert ein ?.
        Es wird abschließend der aktuelle Pinstatus als dHH ausgegeben, wie bei Intervall.

TSCUL zeigt den Pin Status als Reading DigIn 0xXX hex an.

Bisher nur kompiliert für CUNO2, nanoCUL und miniCUL.
Da direkt an die CPU angeschlossen wird, ist natürlich entsprechende Vorsicht walten zu lassen, um den Eingang nicht mit unzulässigen Spannungen zu zerstören.
Beim do Kommando muss natürlich darauf geachtet werden, den Ausgang nicht zu überlasten, z.B. durch schalten auf eine Spannungsquelle...

CUNO2 Pins auf Jp1:
Pin 1 (CPU PC2)  Digital Ein- oder Ausgang 0
Pin 2 (CPU PA0)  Analogeingang
Pin 3 VDD
Pin 4 GND
Pin 5 (CPU PC3)  Digital Ein- oder Ausgang 1
Pin 6 +5V von USB

nanoCUL:
Board pin A4 (CPU PC4)  Digital Ein- oder Ausgang 0
Board pin A5 (CPU PC5)  Digital Ein- oder Ausgang 1
Board pin A7 (CPU ASC7) Analogeingang


Die Version 0.39 bietet einige Timingänderungen für HM. Außerdem ist das Commandref überarbeit. Bei TSCUL werden sets und gets nun abhängig von rfmode und unterstützten Firmwarebefehlen angeboten.

Die Version 0.38 verhindert repeats für TC und TH Messages, was für virtuelle TC und TH Sensoren sinnvoll ist.
Auszug aus de Changed:
- ASKSIN repeats for TC and TH messages set to 0
- ASKSIN Ag command added, allow setting ASKSIN non FUP AGCCTRL2 value in EEPROM
Außerdem Verbesserungen in Modulen, insbesondere für virtuelle TCs und TH Sensoren.
Beim Reboot nach dem Flashen werden alle EEPROM Einstellungen auf Default gesetzt. Also alle am CUL vorgenommenen Einstellungen notieren, um sie wieder einstellen zu können.

In Version 0.37 ist der Readout des Tranceiver RX Fifos insbesondere für ASKSIN verändert. Beim Reboot nach dem Flashen werden alle EEPROM Einstellungen auf Default gesetzt. Also alle am CUL vorgenommenen Einstellungen notieren, um sie wieder einstellen zu können.
RF_Router und fast_rf sind verändert und nicht kompatibel zu vorherigen Versionen.

Version 0.36 behebt ein Überlaufproblem des RX-FIFOs des Transceivers, der zum Empfangsausfall führen konnte (fiel nur beim reinen Empfangsbetrieb ohne regelmäßiges Senden auf). Danke Stefan für den Hinweis.

Auszug aus der Changed:
- little correction in rf_native, if slowrf monitoring is active
- lacrosse emu reworked
- SlowRf reception adapted for better ESA reception with still well E and HMS reception
- generic Manchester raw send added with Gm command
- ESA send added with 'S' command
- HMS send added with 'Q' command
- IT reception corrected
- RfRouter with repeat in FastRF packet, better send timing and reduced receive timeout
- for pure USB CULs blinking while waiting on watchdog reboot and during boot/bootloader reboot with different frequencies
- message finalization with \n on PIM receive buffer full
- ASKSIN, fastRF, RF-Router, moritz, rwe, RX-FIFO Overflow detection improved

Noch als Hinweis, für HMS und ESA scheint sens 12 eine ungünstige Einstellung für den Empfang  dieser Protokolle zu sein.

Diese Version bietet wakup support und keep awake Support. Für CULs mit wenig Speicher kann dies mit dem Attribut "hmForceLzyCfg" aktiviert werden, siehe auch der Hinweis zum EEPROM Verschleiß weiter unten.

Das RF-Router Ping Timing ist geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw und auch nicht zur Version 0.32.
Ergänzt ist SlowRf Empfang von Pearl NC7427 Temperatur/Luftfeuchte Sensoren. Entsprechend Kanalwahlschalter können 3 Stück empfangen werden. Zum Anlernen mittels autocreate muss der TEST Taster am Sensor gedrückt werden.

Das EEPROM Layout ist geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- FULL_PA_RAMPING bugs corrected
- CCA CS thresholds setable for ASKSIN, MORITZ, HAS_RWE, RFNATIVE and MBUS with XTxy, x=CARRIER_SENSE_REL_THR, y=CARRIER_SENSE_ABS_THR as in AGCCTRL1
- SlowRf receive timing limits corrected
- SlowRf lower filter switched off by define in rf_receive_timing.h
- RFR timing/timeout shortened, FastRF CCA disabled
- auto Ci interrupt counter messages
- XP command extended to switch on auto Ci messages, AP removed as all PLL messages switchable by XP
- improvement and corrections for CUNX RS485 PIG support
- CUNX: PIG RTS controllable by USB Host for serial foward and RS485 serial forward
- CUNX: DMX interupts changed to HI priority and CC1101 interrupts to MED priority
- CUNX: USB interrupts to LO priority
- GPIOR1 used for USB USB_DeviceState
- GPIOR1 used for SERIAL STACKING stacking_ST_state


Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
  rr:
  report known protocol data                                                      Bit 0
  report repeated data                                                            Bit 1
  report received bits                                                            Bit 2
  report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout  Bit 3
  report edges, bit times and timeouts                                            Bit 4
  report S300 data with valid checksum only                                      Bit 5
  report FHT                                                                      Bit 6
  report 'l' RSSI decimal data continuosly                                        Bit 7
  t:
  report recorded SlowRF timing                                                  Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters


TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCULbzw.
TSCULflash <minidevicename> TSminiCULversuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls (nur über USB Anschluss) möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR
AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_xx.zip und FHEM_Modules_00_xxx.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUL_V3_RFR (via USB), TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann z.B. TSCUL_V3.
Beispiel:
TSCULflash MeinCulV3Device TSCUL_V3
Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034

Ergänzender Hinweis zu USB CULs: Nach dem flashen von TSCUL kann es sein, dass das Betriebssystem TSCUL eine neue Schnittstelle zuweist und ggf. auch anderen USB devices. Auf Linux mit "dmesg" heraus zu lesen.
Auch beim Neustart des Systems kann sich die Reihenfolge ändern. Bei meinem Raspi sogar abhängig von der Startart Reboot oder Einschalten.
Für CULs mit nativer USB Schnittstelle (z.B. CUL V3.x oder CUN) kann die \Firmware\tsculfw-code-459-trunk_lufa_00_08\culfw\Devices\99-usb-serial.rules nach /etc/udev/rules.d/99-usb-serial.rules kopiert werden. Dann wird CUL stets der Schnittstelle /dev/CUL868_0 (oder /dev/CUL433_0 bei 433.9MHz Version) zugewiesen und er kann mit
define CUL_868 TSCUL /dev/CUL868_0@12000000 1234bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

Das geht leider nicht bei nicht nativen USB CULs wie z.B. nanoCUL oder CUNO2. Hier muss eine 99-usb-serial.rules nach den Daten in der dmesg Ausgabe erstellt oder modifiziert werden, um den gleichen Effekt zu erzielen, sofern der USB-Seriell Interfacebaustein eine eindeutige Seriennummer liefert.
Ansonsten kann es noch mit der USB-Schnittstelle probiert werden, an der CUL eingesteckt ist ("lsusb" Ausgabe), was an meinem RasPi aber nicht funktioniert hat, da dieser abhängig von Warmstart oder Kaltstart andere USB-Portnummern vergibt.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000
Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000
Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

00_TSCUL.pm        -> statt der 00_CUL.pm, aus CUL devices werden damit TSCUL devices in der fhem.cfg (händisch anzupassen)
DevIoTS.pm            -> verbesserte Version von DevIo.pm für die TS Module
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)
97_timerTS.pm          -> Austausch-Timerroutinen und fhemFork()

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL IO-devices zu verwenden, aus UNIRoll wird dann UNIRoll_TS  in der fhem.cfg (händisch anzupassen)
13_TSKS300.pm    -> statt der 13_KS300.pm, mit TSCUL IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL IO-devices zu verwenden, aus CUL_TX wird dann TSCUL_TX  in der fhem.cfg (händisch anzupassen)
14_TSCUL_WS.pm  -> statt der 14_CUL_WS.pm, mit TSCUL IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
14_TSCUL_NC7427.pm  -> NC7427 Unterstützung
15_TSCUL_EM.pm  -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
12_TSHMS.pm        -> statt der 12_HMS.pm zu verwenden
CalcUtil.pm              -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

98_fhemdebug.pm    -> fhemdebug zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details
10_IT.pm                  -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm    -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm        -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert. Nur diese Version bietet derzeit vollständige TSCUL/tsculfw Unterstützung. Zur Einsparung redundanter Events werden teilweise Readings (actuator, desired-temp, measured-temp) nicht mehr zusätzlich im HM-device, sondern nur noch in den jeweiligen Channels aktualisiert.
HMConfig.pm            -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm          -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
98_HMtemplate.pm  -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden.
Die 4 Dateien entsprechen einem Stand von Anfang 09/2020. Derzeit sollten diese verwendet werden.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

98_autocreate.pm      -> autocreate mit TSCUL Unterstützung

98_Cumulate              -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm        -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.
98_IntervalTimer.pm  -> optional, Intervalltimer um FEHM-Timerbasiert Kommandos in möglichst konstanten Intervallen absetzen zu können.

Wie immer, vor Austausch und Veränderungen der Module und fhem.cfg, erst Backup dann Ändern!

Mit folgendem Eintrag (oder Ergänzung des attributs) in der fhem.cfg kann man das fhem Update am ungewollten Austausch der angepassten Module hindern:
attr global exclude_from_update 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 14_TSCUL_NC7427.pm ReadingUtil.pm 97_timerTS.pm 98_TSCULflash.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm 98_HMtemplate.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.pm 98_fhemdebug.pm
Hier https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057 noch Rudolfs zwingend auszuführender Tip zur Aktualisierung des Commandref  nach dem Kopieren/Austausch der Dateien so dass dann auch Doku zur Nutzung zu lesen ist.
fhem> { `perl contrib/commandref_join.pl` }
Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.40 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCUsetzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Devicesofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.
Mit dem Attribut "hmForceLzyCfg" kann wakeup und keep awake support bei solchen CULs aktiviert werden. Das erhöht den EEPROM Verschleiß beim Lesen oder Verändern von Registerwerten bei wakup und lazy config devices.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:
define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}

Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:
define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}

Zum regelmäßigen Senden von Sensordaten kann der IntervalTimer genutzt werden.
Beispiel:
define AussenSend_WS11 IntervalTimer CUNO2_WS868 176.5
attr AussenSend_WS11 offCmd {fhem("set @ KSSend T: ".ReadingsVal("C_Aussen","temperature",0.0)." H: ".ReadingsVal("C_Aussen","humidity",0.0)." Code:21")}
attr AussenSend_WS11 onCmd {fhem("set @ KSSend T: ".ReadingsVal("C_Aussen","temperature",0.0)." H: ".ReadingsVal("C_Aussen","humidity",0.0)." Code:21")}

Hier geht es zur vorherigen Version https://forum.fhem.de/index.php?msg=1167796.

Gruß, Ansgar.

yersinia

#1424
Hi noansi,

Danke nochmal für deine firmware, die läuft immernoch unauffällig und gut für meinen HM-Zoo und den zwei nanoCULs. :)

Ich betreibe immernoch zwei nanoCULs mit deiner (ich meine aktuellsten) TSCUL firmware:
nanoCUL_868_1 version => VTS 0.41 CSM868
nanoCUL_868_1 versionHW => nanoCUL_V1.x_0014

nanoCUL_868_2_Net version => VTS 0.41 CSM868
nanoCUL_868_2_Net versionHW => nanoCUL_V1.x_0014
version der Module:
Latest Revision: 28820
# $Id: 98_autocreate.pm 23727a 2021-02-13 13:00:00Z noansi $
# $Id: 10_CUL_HM.pm 24449t 2023-09-11 00:00:00Z noansi $
# $Id: 98_HMinfo.pm 26935c 2023-03-27 00:00:00Z noansi $
97_timerTS.pm                    15 2022-08-23 00:00:00Z noansi
00_TSCUL.pm                     148 2022-10-22 00:00:00Z noansi
CalcUtil.pm                      12 2023-11-12 00:00:00Z noansi
DevIoTS.pm                       37 2023-01-05 00:00:00Z noansi
ReadingUtil.pm                   12 2022-06-23 22:33:47Z noansi

Ich hab zwei Auffälligkeiten.

'Neuerdings' bekomme ich die Historie in den log, wenn anscheinend was ungeplant abläuft:
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01102093 A F101 13947972 00 0F 34 803F [HMID] 3C95EB 02042DC5F400 -74.5dB
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01102189 A F101 13948072 00 10 35 A001 [HMID] 3C95EB 00040000000000 -75.5dB
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01102461 A F101 13948340 00 10 35 A001 [HMID] 3C95EB 00040000000000 -75.5dB
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01102733 A F101 13948608 00 10 35 A001 [HMID] 3C95EB 00040000000000 -76dB
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01102828 A F103 13948684 01 10 A9 A001 [HMID] 40AA4F 00050000000007 _CCAdly:4 _dhmSt:1556
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01102992 A F101 13948876 00 0A 33 8002 [HMID] 3C775B 00 -76.5dB
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01103101 A F101 13948976 00 0F 33 803F [HMID] 3C775B 02042DC5F401 -77.5dB
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01103134 A F103 13948980 08 10 A9 A001 [HMID] 40AA4F 00050000000007 _CCAdly:32 _dhmSt:1852
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01103389 A F103 13949248 01 10 A9 A001 [HMID] 40AA4F 00050000000007 _CCAdly:4 _dhmSt:2120
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01103629 A F109 13949512 00 10 A9 A001 [HMID] 40AA4F 00050000000007 _sfail _noAnsw
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01103869 A F101 13949740 00 10 34 A001 [HMID] 3C775B 00050000000007 -77.5dB
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01104125 A F101 13950008 00 10 34 A001 [HMID] 3C775B 00050000000007 -76.5dB
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01104397 A F101 13950276 00 10 34 A001 [HMID] 3C775B 00050000000007 -77dB
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01105469 A F101 13951348 00 10 35 A001 [HMID] 3C95EB 00040000000000 -76.5dB
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01103120 A F101 13611720 00 10 A9 A001 [HMID] 40AA4F 00050000000007 -79.5dB
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01103393 A F101 13611988 00 10 A9 A001 [HMID] 40AA4F 00050000000007 -78dB
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  055236                 As 10 34 A001 [HMID] 3C775B 00050000000007
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01103857 A F103 13612432 01 10 34 A001 [HMID] 3C775B 00050000000007 _CCAdly:4 _dhmSt:1844
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01104129 A F103 13612700 01 10 34 A001 [HMID] 3C775B 00050000000007 _CCAdly:4 _dhmSt:2112
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01104401 A F103 13612968 01 10 34 A001 [HMID] 3C775B 00050000000007 _CCAdly:4 _dhmSt:2380
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01104625 A F109 13613232 00 10 34 A001 [HMID] 3C775B 00050000000007 _sfail _noAnsw
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  056841                 As 10 35 A001 [HMID] 3C95EB 00040000000000
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01105457 A F103 13614036 01 10 35 A001 [HMID] 3C95EB 00040000000000 _CCAdly:4
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01105729 A F103 13614308 01 10 35 A001 [HMID] 3C95EB 00040000000000 _CCAdly:4
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01106001 A F103 13614576 01 10 35 A001 [HMID] 3C95EB 00040000000000 _CCAdly:4
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01106241 A F109 13614840 00 10 35 A001 [HMID] 3C95EB 00040000000000 _sfail _noAnsw
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01106402 A F101 13614992 00 14 C5 A45F 2D4787 [HMID] 803F0500235C028D093502 -76dB
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01106500 A F101 13615104 00 0A C5 8002 [HMID] 2D4787 00 -78dB
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01103120 A F101 13611720 00 10 A9 A001 [HMID] 40AA4F 00050000000007 -79.5dB
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01103393 A F101 13611988 00 10 A9 A001 [HMID] 40AA4F 00050000000007 -78dB
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  055236                 As 10 34 A001 [HMID] 3C775B 00050000000007
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01103857 A F103 13612432 01 10 34 A001 [HMID] 3C775B 00050000000007 _CCAdly:4 _dhmSt:1844
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01104129 A F103 13612700 01 10 34 A001 [HMID] 3C775B 00050000000007 _CCAdly:4 _dhmSt:2112
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01104401 A F103 13612968 01 10 34 A001 [HMID] 3C775B 00050000000007 _CCAdly:4 _dhmSt:2380
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01104625 A F109 13613232 00 10 34 A001 [HMID] 3C775B 00050000000007 _sfail _noAnsw
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  056841                 As 10 35 A001 [HMID] 3C95EB 00040000000000
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01105457 A F103 13614036 01 10 35 A001 [HMID] 3C95EB 00040000000000 _CCAdly:4
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01105729 A F103 13614308 01 10 35 A001 [HMID] 3C95EB 00040000000000 _CCAdly:4
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01106001 A F103 13614576 01 10 35 A001 [HMID] 3C95EB 00040000000000 _CCAdly:4
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01106241 A F109 13614840 00 10 35 A001 [HMID] 3C95EB 00040000000000 _sfail _noAnsw
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01106402 A F101 13614992 00 14 C5 A45F 2D4787 [HMID] 803F0500235C028D093502 -76dB
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01106500 A F101 13615104 00 0A C5 8002 [HMID] 2D4787 00 -78dB
[...]
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01116994 A F101 13962884 00 09 34 A03F 3C775B [HMID]  -73dB
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01117102 A F101 13962984 00 0F 35 803F [HMID] 3C95EB 02042DC5F40F -78dB
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01117184 A F101 13963080 00 0A 34 8002 [HMID] 3C775B 00 -78dB
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01117294 A F101 13963180 00 0F 34 803F [HMID] 3C775B 02042DC5F410 -78.5dB
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01117760 A F103 13963636 01 0B B9 A001 [HMID] 40AA4F 0203 _CCAdly:4 _dhmSt:1468
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01118033 A F103 13963900 01 0B B9 A001 [HMID] 40AA4F 0203 _CCAdly:4 _dhmSt:1732
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01118288 A F103 13964164 01 0B B9 A001 [HMID] 40AA4F 0203 _CCAdly:4 _dhmSt:1996
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01118528 A F109 13964424 00 0B B9 A001 [HMID] 40AA4F 0203 _sfail _noAnsw
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01119643 A F101 13965528 00 14 74 845E 2D4787 000000 803F0800290202DD093301 -46.5dB
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  072037                 As 0B B9 A001 [HMID] 40AA4F 0203
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01120656 A F103 13966528 01 0B B9 A001 [HMID] 40AA4F 0203 _CCAdly:4
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01120927 A F103 13966796 01 0B B9 A001 [HMID] 40AA4F 0203 _CCAdly:4
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01121184 A F103 13967060 01 0B B9 A001 [HMID] 40AA4F 0203 _CCAdly:4
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01121424 A F109 13967320 00 0B B9 A001 [HMID] 40AA4F 0203 _sfail _noAnsw

Wenn ich raten müsste, hängt es mit den _noAnsw zusammen:
2024.05.02 08:49:40 1: LogHist nanoCUL_868_2_Net:  01103629 A F109 13949512 00 10 A9 A001 [HMID] 40AA4F 00050000000007 _sfail _noAnsw
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01104625 A F109 13613232 00 10 34 A001 [HMID] 3C775B 00050000000007 _sfail _noAnsw
2024.05.02 08:49:43 1: LogHist nanoCUL_868_1:  01106241 A F109 13614840 00 10 35 A001 [HMID] 3C95EB 00040000000000 _sfail _noAnsw
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01104625 A F109 13613232 00 10 34 A001 [HMID] 3C775B 00050000000007 _sfail _noAnsw
2024.05.02 08:49:44 1: LogHist nanoCUL_868_1:  01106241 A F109 13614840 00 10 35 A001 [HMID] 3C95EB 00040000000000 _sfail _noAnsw
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01118528 A F109 13964424 00 0B B9 A001 [HMID] 40AA4F 0203 _sfail _noAnsw
2024.05.02 08:49:59 1: LogHist nanoCUL_868_2_Net:  01121424 A F109 13967320 00 0B B9 A001 [HMID] 40AA4F 0203 _sfail _noAnsw
40AA4F, 3C775B und 3C95EB sind die drei HM-TC-IT-WM-W-EU, die zwar (mit FHEM) gepaired aber nicht gepeert sind; ich nutze die nur zur Temperatur- und Luftfeuchtemessung. Zu dem Zeitpunkt gestern hab ich die Temperaturprofile für den Sommer verteilt (neben den drei TC auch an die sieben RT-DNs). Könnte hier was am Pairing nicht stimmen? Bisher hat mich das nicht weiter interessiert und die Sende-Historie ist bisher nie im log aufgetaucht.


Zum Anderen ist mir aufgefallen, dass ein set reopen nicht mehr funktioniert, wenn einer der nanoCULs nicht mehr erreichbar ist. Dies kann durch Netzwerkunterbrechung zum ser2net oder bei USB-Power-Störung am RasPi passieren. Die nanoCULs selbst scheinen stabil zu laufen - jdfs soweit ich das bewerten kann. Im laufenden FHEM-Betrieb bekomme ich die nanoCULs nicht mehr reinitialisiert via reopen - durch einen FHEM-restart läuft es danach wieder wie gehabt. Hast du eine Idee, woran das liegen könnte? Lists der nanoCULs hab ich angehängt.
Im log finde ich dann zB diese Einträge:
2024.04.17 08:30:00 1: TSCUL_Parse: nanoCUL_868_2_Net Restart: C_ReadyCSM868
2024.04.17 08:30:00 1: 192.168.0.1:28682 disconnected (Restart detected), waiting to reappear nanoCUL_868_2_Net
2024.04.17 08:30:30 1: TSCUL_RecoverHMQlen: nanoCUL_868_2_Net recovered from Qlen XmitOpen lock
2024.04.17 08:31:01 1: TSCUL_Parse: nanoCUL_868_2_Net Restart: C_ReadyCSM868
2024.04.17 08:31:01 1: 192.168.0.1:28682 disconnected (Restart detected), waiting to reappear nanoCUL_868_2_Net
2024.04.17 08:31:31 1: TSCUL_RecoverHMQlen: nanoCUL_868_2_Net recovered from Qlen XmitOpen lock
2024.04.17 08:32:01 1: TSCUL_Parse: nanoCUL_868_2_Net Restart: C_ReadyCSM868
2024.04.17 08:32:01 1: 192.168.0.1:28682 disconnected (Restart detected), waiting to reappear nanoCUL_868_2_Net
2024.04.17 08:32:31 1: TSCUL_RecoverHMQlen: nanoCUL_868_2_Net recovered from Qlen XmitOpen lock
2024.04.17 08:33:03 1: TSCUL_Parse: nanoCUL_868_2_Net Restart: C_ReadyCSM868
2024.04.17 08:33:03 1: 192.168.0.1:28682 disconnected (Restart detected), waiting to reappear nanoCUL_868_2_Net
2024.04.17 08:33:33 1: TSCUL_RecoverHMQlen: nanoCUL_868_2_Net recovered from Qlen XmitOpen lock
Und dies wiederholt sich bis zum restart - und der nanoCUL bleibt auf disconnected.

Brauchst du sonst noch was? Danke vorab.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl