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

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

Vorheriges Thema - Nächstes Thema

presskopf

Hallo Ansgar,
so, habe den CUL1 mal auf verbose 4 gestellt und den betreffenden Rolli ein Stück gefahren:

021.02.11 08:49:51 3: CUL_HM set roll_dining_right 90
2021.02.11 08:49:51 4: TSCUL_send:  CUL1  087716                 As 0C 8D A011 E47309 3E0FFC 0201B4
2021.02.11 08:49:51 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 08:49:51 4: TSCUL_Parse: CUL1  087775 A F103 16692296 01 0C 8D A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 08:49:51 4: TSCUL_Parse: CUL1  087935 A F101 16692448 00 0E 8D 8002 3E0FFC E47309 0101C82059 -67dB
2021.02.11 08:49:56 4: TSCUL_Parse: CUL1  092903 A F001 16697440 00 0D 8E A410 3E0FFC E47309 0601B400 -70dB
2021.02.11 08:49:56 4: TSCUL_Parse: CUL1  092994 A F103 16697536 01 0A 8E 8002 E47309 3E0FFC 00 _CCAdly:4 _dhmSt:96
2021.02.11 08:49:57 4: TSCUL_Parse: CUL1  093688 A F101 16697996 00 0F BD 8610 440AAE 000000 0AB0CA0F6440 -65dB
2021.02.11 08:49:59 4: TSCUL_Parse: CUL1  095534 A F101 16700104 00 0D 97 8410 5160AA E47309 06012C00 -58.5dB
2021.02.11 08:50:15 4: TSCUL_Parse: CUL1  112192 A F001 16716772 00 0C F1 865A 3F81A7 000000 B0DD25 -40dB
2021.02.11 08:50:18 4: TSCUL_Parse: CUL1  114841 A F001 16719436 00 0C BE 865A 3EF2D6 000000 B0E123 -49dB
2021.02.11 08:50:28 4: TSCUL_Parse: CUL1  124729 A F001 16729280 00 0D B5 8041 430EFE 4B7CB0 07EBC880 -80dB
2021.02.11 08:50:33 4: TSCUL_Parse: CUL1  130014 A F001 16734608 00 0C 61 865A 43110F 000000 B0CA30 -76dB
2021.02.11 08:50:33 4: TSCUL_Parse: CUL1  130089 A F001 16734680 00 0C 69 865A 432C73 000000 A8C031 -66.5dB
2021.02.11 08:50:35 4: TSCUL_Parse: CUL1  132184 A F001 16736796 00 0C F1 8470 3F81A7 000000 00DD25 -40dB
2021.02.11 08:50:38 4: TSCUL_Parse: CUL1  134861 A F001 16739460 00 0C BE 8470 3EF2D6 000000 00E123 -49dB
2021.02.11 08:50:51 4: TSCUL_Parse: CUL1  148292 A F001 16752920 00 0D A3 8041 3F81A7 4B7E69 07EEC880 -40dB
2021.02.11 08:50:53 4: TSCUL_Parse: CUL1  150019 A F001 16754632 00 0C 61 8470 43110F 000000 00CA30 -76dB
2021.02.11 08:50:53 4: TSCUL_Parse: CUL1  150107 A F001 16754704 00 0C 69 8470 432C73 000000 00C031 -68.5dB
2021.02.11 08:51:06 4: TSCUL_Parse: CUL1  162947 A F001 16767580 00 0C 7F 865A 430ED3 000000 A4C032 -59.5dB
2021.02.11 08:51:17 4: TSCUL_Parse: CUL1  174183 A F001 00001624 00 0D DF 8041 432C73 4B7CB0 0792C880 -65dB
2021.02.11 08:51:26 4: TSCUL_Parse: CUL1  182953 A F001 00010384 00 0C 7F 8470 430ED3 000000 00C032 -59.5dB
2021.02.11 08:51:45 4: TSCUL_Parse: CUL1  201913 A F001 00029376 00 0C 9D 865A 3F81C7 000000 A8A435 -75dB
2021.02.11 08:51:47 4: TSCUL_Parse: CUL1  203814 A F001 00031288 00 0C 28 865A 430EFE 000000 8CA736 -77.5dB
2021.02.11 08:51:55 4: TSCUL_Parse: CUL1  211916 A F001 00039392 00 0E A9 8410 3F81C7 000000 0BA8A40D00 -75.5dB
2021.02.11 08:51:56 4: TSCUL_Parse: CUL1  213256 A F001 00040732 00 0D B8 8410 6263BB E47309 06017A00 -60dB
2021.02.11 08:52:05 4: TSCUL_Parse: CUL1  221907 A F001 00049400 00 0C 9D 8470 3F81C7 000000 00A435 -75.5dB
2021.02.11 08:52:07 4: TSCUL_Parse: CUL1  223841 A F001 00051312 00 0C 28 8470 430EFE 000000 00A736 -78dB
2021.02.11 08:52:11 4: TSCUL_Parse: CUL1  227595 A F001 00055044 00 0D C7 8041 430ED3 4B7CB0 0728C880 -59.5dB

noansi

Hallo Matthias,

ok, es wird auf jeden Fall was anderes gesendet, als in Deinen Problemlogs.

Kommt also aus der CUL_HM.

Es wird anscheinend ein "toggleDir" oder "stop" gesendet, was nicht beantwortet wird.
Kannst Du bitte mal mit verbose 4 am CUL1 ein toggleDir und ein stop am Actor senden und das log posten.

Gruß, Ansgar.

noansi

Hallo Matthias,

ich habe doch noch einen Firmwareunterschied gefunden.

Probier es nochmal mit der V0.37 und setz den hmFreqOffs jeweils wieder entsprechend der alten Einstellung bei den CUls.
Dann noch ein set patable 9 bei den CULs.

Ich habe die Sendleistung über die Versionen auch einstellbar gemacht und der default ist 8, aber 9 entsprechend ist der alte fixe Stand in V0.30 für hm.

Gruß, Ansgar.

presskopf

Hallo Ansgar,

Hut ab, es tut mit 0.37!
Deinen ersten Beitrag habe ich erst übersehen und bin gleich zum Versuch mit set CULx patable 9 übergegangen.
Damit funktionieren alle Aktoren. Die Gegenprobe mit zurück auf den Wert 8 zeigte wieder das Versagen.

Woran erkenne ich denn in den Readings, welchen Wert das patable hat?
Soll ich nochmal den Test aus Deinem ersten Beitrag zum Erkenntnisgewinn nachschieben oder ist das nicht mehr nötig?

Alles logs mit 0.37, verbose 4 am CUL1
Hier im Log mit patable 8: Da habe ich an roll_office ein stopp gesendet, welches quittiert wurde; danach ein set_90 an roll_dining_right, welches Probleme macht:
2021.02.11 21:23:35 3: CUL_HM set roll_office stop noArg
2021.02.11 21:23:35 4: TSCUL_Write: CUL1 sending As0B8CA011E473093E10060301
2021.02.11 21:23:35 4: TSCUL_send:  CUL1  222806                 As 0B 8C A011 E47309 3E1006 0301
2021.02.11 21:23:35 4: TSCUL_XmitDlyHM:  CUL1  id:3E1006 rtoms:2342
2021.02.11 21:23:35 4: TSCUL_Parse: CUL1  222851 A F703 00742132 01 0B 8C A011 E47309 3E1006 0301 _CCAdly:4
2021.02.11 21:23:35 4: TSCUL_Parse: CUL1  222984 A F701 00742288 00 0E 8C 8002 3E1006 E47309 0101000034 -45.5dB
2021.02.11 21:23:36 4: TSCUL_Parse: CUL1  224290 A F702 00743600 00 34 AA00112200000049AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:44 4: TSCUL_Parse: CUL1  231786 A F702 00751100 00 34 AA00112200000048AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:44 4: TSCUL_Write: CUL1 sending As0C52A011E473093E0FFC0201B4
2021.02.11 21:23:44 4: TSCUL_send:  CUL1  231904                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:44 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 21:23:44 4: TSCUL_Parse: CUL1  231952 A F703 00751244 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:44 4: TSCUL_Parse: CUL1  232222 A F703 00751512 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:44 4: TSCUL_Parse: CUL1  232495 A F703 00751780 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:45 3: LogHist CUL1:  208182 A F802 00727468 00 34 AA00112200000051AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:45 3: LogHist CUL1:  208617 A F801 00727908 00 0C C6 8470 3F81C7 000000 00B834 -71dB
2021.02.11 21:23:45 3: LogHist CUL1:  217381 A F701 00736468 00 0F E6 8610 440AAE 000000 0AB0C70F6440 -68dB
2021.02.11 21:23:45 3: LogHist CUL1:  218202 A F702 00737500 00 34 AA00112200000050AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:45 3: LogHist CUL1:  219737 A F701 00739020 00 0C 50 8470 430EFE 000000 00B137 -74.5dB
2021.02.11 21:23:45 3: LogHist CUL1:  222806                 As 0B 8C A011 E47309 3E1006 0301
2021.02.11 21:23:45 3: LogHist CUL1:  222851 A F703 00742132 01 0B 8C A011 E47309 3E1006 0301 _CCAdly:4
2021.02.11 21:23:45 3: LogHist CUL1:  222984 A F701 00742288 00 0E 8C 8002 3E1006 E47309 0101000034 -45.5dB
2021.02.11 21:23:45 3: LogHist CUL1:  224290 A F702 00743600 00 34 AA00112200000049AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:45 3: LogHist CUL1:  231786 A F702 00751100 00 34 AA00112200000048AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:45 3: LogHist CUL1:  231904                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:45 3: LogHist CUL1:  231952 A F703 00751244 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:45 3: LogHist CUL1:  232222 A F703 00751512 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:45 3: LogHist CUL1:  232495 A F703 00751780 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:45 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  232718 A F709 00752044 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:46 4: TSCUL_XmitAwaitHMTo CUL1: timeout - 3E0FFC
2021.02.11 21:23:48 4: TSCUL_Write: CUL1 sending As0C52A011E473093E0FFC0201B4
2021.02.11 21:23:48 4: TSCUL_send:  CUL1  236109                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:48 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 21:23:48 4: TSCUL_Parse: CUL1  236156 A F703 00755452 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:48 4: TSCUL_Parse: CUL1  236429 A F703 00755724 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 4: TSCUL_Parse: CUL1  236698 A F703 00755992 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  222806                 As 0B 8C A011 E47309 3E1006 0301
2021.02.11 21:23:49 3: LogHist CUL1:  222851 A F703 00742132 01 0B 8C A011 E47309 3E1006 0301 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  222984 A F701 00742288 00 0E 8C 8002 3E1006 E47309 0101000034 -45.5dB
2021.02.11 21:23:49 3: LogHist CUL1:  224290 A F702 00743600 00 34 AA00112200000049AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:49 3: LogHist CUL1:  231786 A F702 00751100 00 34 AA00112200000048AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:49 3: LogHist CUL1:  231904                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:49 3: LogHist CUL1:  231952 A F703 00751244 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  232222 A F703 00751512 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  232495 A F703 00751780 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  232718 A F709 00752044 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:49 3: LogHist CUL1:  236109                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:49 3: LogHist CUL1:  236156 A F703 00755452 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  236429 A F703 00755724 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  236698 A F703 00755992 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  236938 A F709 00756256 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:50 4: TSCUL_XmitAwaitHMTo CUL1: timeout - 3E0FFC
2021.02.11 21:23:54 4: TSCUL_Write: CUL1 sending As0C52A011E473093E0FFC0201B4
2021.02.11 21:23:54 4: TSCUL_send:  CUL1  242111                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:54 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 21:23:54 4: TSCUL_Parse: CUL1  242168 A F703 00761460 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:54 4: TSCUL_Parse: CUL1  242421 A F703 00761732 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 4: TSCUL_Parse: CUL1  242696 A F703 00762000 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  231904                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:55 3: LogHist CUL1:  231952 A F703 00751244 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  232222 A F703 00751512 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  232495 A F703 00751780 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  232718 A F709 00752044 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:55 3: LogHist CUL1:  236109                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:55 3: LogHist CUL1:  236156 A F703 00755452 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  236429 A F703 00755724 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  236698 A F703 00755992 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  236938 A F709 00756256 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:55 3: LogHist CUL1:  242111                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:55 3: LogHist CUL1:  242168 A F703 00761460 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  242421 A F703 00761732 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  242696 A F703 00762000 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  242926 A F709 00762264 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:55 4: TSCUL_Parse: CUL1  243240 A F701 00762560 00 0C A8 865A 430ED3 000000 98CA31 -61dB
2021.02.11 21:23:56 4: TSCUL_XmitAwaitHMTo CUL1: timeout - 3E0FFC
2021.02.11 21:23:57 4: TSCUL_Parse: CUL1  245389 A F702 00764728 00 34 AA00112200000047AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:24:00 4: TSCUL_Write: CUL1 sending As0C52A011E473093E0FFC0201B4
2021.02.11 21:24:00 4: TSCUL_send:  CUL1  247929                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:24:00 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 21:24:00 4: TSCUL_Parse: CUL1  247986 A F703 00767284 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:00 4: TSCUL_Parse: CUL1  248254 A F703 00767560 02 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:8
2021.02.11 21:24:01 4: TSCUL_Parse: CUL1  248543 A F803 00767832 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  236429 A F703 00755724 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  236698 A F703 00755992 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  236938 A F709 00756256 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:24:01 3: LogHist CUL1:  242111                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:24:01 3: LogHist CUL1:  242168 A F703 00761460 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  242421 A F703 00761732 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  242696 A F703 00762000 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  242926 A F709 00762264 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:24:01 3: LogHist CUL1:  243240 A F701 00762560 00 0C A8 865A 430ED3 000000 98CA31 -61dB
2021.02.11 21:24:01 3: LogHist CUL1:  245389 A F702 00764728 00 34 AA00112200000047AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:24:01 3: LogHist CUL1:  247929                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:24:01 3: LogHist CUL1:  247986 A F703 00767284 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  248254 A F703 00767560 02 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:8
2021.02.11 21:24:01 3: LogHist CUL1:  248543 A F803 00767832 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  248766 A F809 00768096 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:24:02 4: TSCUL_XmitAwaitHMTo CUL1: timeout - 3E0FFC
2021.02.11 21:24:06 4: TSCUL_Parse: CUL1  253848 A F701 00773192 00 0C 1B 865A 3F81A7 000000 B8F824 -40.5dB
2021.02.11 21:24:15 4: TSCUL_Parse: CUL1  263261 A F701 00782580 00 0C A8 8470 430ED3 000000 00CA31 -60.5dB
2021.02.11 21:24:17 4: TSCUL_Parse: CUL1  264903 A F702 00784260 00 34 AA00112200000046AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:24:20 4: TSCUL_Parse: CUL1  267906 A F701 00787252 00 0C 8B 865A 43110F 000000 B0C831 -86dB
2021.02.11 21:24:23 4: TSCUL_Parse: CUL1  270593 A F702 00789944 00 34 AA00112200000045AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:24:26 4: TSCUL_Parse: CUL1  273872 A F701 00793216 00 0C 1B 8470 3F81A7 000000 00F824 -40.5dB
2021.02.11 21:24:29 4: TSCUL_Parse: CUL1  276593 A F701 00795932 00 0D E8 8410 516081 E47309 06012200 -66dB
2021.02.11 21:24:30 4: TSCUL_Parse: CUL1  277935 A F701 00797264 00 0E BC 8410 43110F 000000 0BB0C80D40 -86.5dB
2021.02.11 21:24:31 4: TSCUL_Parse: CUL1  278803 A F701 00798096 00 0D 10 8041 3F81C7 4B7E69 07E4C880 -71dB
2021.02.11 21:24:31 4: TSCUL_Parse: CUL1  279032 A F702 00798404 00 34 AA00112200000044AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping


Und so schaut ein set_80 an mit patable 9 aus.
2021.02.11 21:26:52 4: TSCUL_Parse: CUL1  420091 A F701 00939616 00 0D 63 A641 6263BB E47309 01000080 -60dB
2021.02.11 21:26:52 4: TSCUL_Parse: CUL1  420224 A F701 00939736 00 0A 63 8002 E47309 6263BB 00 -62dB
2021.02.11 21:26:52 4: TSCUL_Parse: CUL1  420313 A F701 00939840 00 0D 63 8002 E47309 6263BB 01010000 -62dB
2021.02.11 21:26:52 4: TSCUL_Parse: CUL1  420412 A F701 00939916 00 0C 8C 865A 43110F 000000 B0C931 -86dB
2021.02.11 21:26:56 4: TSCUL_Parse: CUL1  424321 A F702 00943848 00 34 AA00112200000029AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:27:00 4: TSCUL_Write: CUL1 sending As0C53A011E473093E0FFC0201A0
2021.02.11 21:27:00 4: TSCUL_send:  CUL1  427767                 As 0C 53 A011 E47309 3E0FFC 0201A0
2021.02.11 21:27:00 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 21:27:00 4: TSCUL_Parse: CUL1  427811 A F703 00947316 01 0C 53 A011 E47309 3E0FFC 0201A0 _CCAdly:4
2021.02.11 21:27:00 4: TSCUL_Parse: CUL1  427937 A F701 00947472 00 0E 53 8002 3E0FFC E47309 0101C82059 -67.5dB
2021.02.11 21:27:01 4: TSCUL_Parse: CUL1  428546 A F701 00948056 00 0C E9 865A 3EF2D6 000000 B0E422 -47.5dB
2021.02.11 21:27:02 4: TSCUL_Parse: CUL1  430413 A F701 00949928 00 0E BD 8410 43110F 000000 0BB0C90D40 -83dB
2021.02.11 21:27:02 4: TSCUL_Parse: CUL1  430479 A F701 00950012 00 0C A9 8470 430ED3 000000 00CA32 -60dB
2021.02.11 21:27:03 4: TSCUL_Parse: CUL1  431150 A F701 00950692 00 0D 2C 8410 51609B E47309 06012500 -63.5dB
2021.02.11 21:27:07 4: TSCUL_Parse: CUL1  434794 A F701 00954332 00 0D 54 A410 3E0FFC E47309 0601A000 -70dB
2021.02.11 21:27:07 4: TSCUL_Write: CUL1 sending As0A548002E473093E0FFC00
2021.02.11 21:27:07 4: TSCUL_Parse: CUL1  434907 A F703 00954428 01 0A 54 8002 E47309 3E0FFC 00 _CCAdly:4 _dhmSt:96
2021.02.11 21:27:11 4: TSCUL_Parse: CUL1  439057 A F702 00958604 00 34 AA00112200000028AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:27:12 4: TSCUL_Parse: CUL1  440388 A F701 00959940 00 0C 8C 8470 43110F 000000 00C931 -86.5dB
221 serrano closing connection (timeout)
2021.02.11 21:27:20 4: TSCUL_Parse: CUL1  448124 A F701 00967672 00 0C C8 865A 3F81C7 000000 A8B834 -71dB
2021.02.11 21:27:20 4: TSCUL_Parse: CUL1  448523 A F701 00968080 00 0C E9 8470 3EF2D6 000000 00E422 -47.5dB
2021.02.11 21:27:23 4: TSCUL_Parse: CUL1  450980 A F702 00970540 00 34 AA00112200000027AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:27:24 4: TSCUL_Parse: CUL1  451543 A F701 00971096 00 0D 50 8410 5160AA E47309 06012200 -57dB
2021.02.11 21:27:35 4: TSCUL_Parse: CUL1  462618 A F702 00982164 00 34 AA00112200000026AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:27:37 4: TSCUL_Parse: CUL1  465057 A F701 00984604 00 0C 94 865A 432C73 000000 98CD2F -71.5dB

noansi

Hallo Matthias,

ZitatWoran erkenne ich denn in den Readings, welchen Wert das patable hat?
get PAtable1 und Blick in den Code

ZitatSoll ich nochmal den Test aus Deinem ersten Beitrag zum Erkenntnisgewinn nachschieben oder ist das nicht mehr nötig?
Der Erkenntnisgewinn ist schon da.  ;)

Gruß, Ansgar.

PS: Der Empfangslevel auf Aktorseite ist nicht gut. -89dB. Deswegen macht die Änderung wohl den Unterschied.
      Die 8 bleibt aber Default, als Hinweis für das nächste Update.

presskopf

Danke nochmal!

Da werde ich mir bei Gelegenheit mal die Antenne angucken.

Adimarantis

Hi Ansgar,

Zitat von: noansi am 09 Februar 2021, 21:10:02
Im Anhang nochmal ein neuer Satz Module, in den auch Martins letzte Änderungen eingeflossen sind.
Schau bitte mal, ob es Auffälligkeiten gibt.

laufen jetzt seit ein paar Tagen. Wir hatten doch vor einer Weile diesen Stacktrace:
2021.02.10 20:46:26 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4591.
2021.02.10 20:46:26 1: stacktrace:
2021.02.10 20:46:26 1:     main::__ANON__                      called by fhem.pl (4591)
2021.02.10 20:46:26 1:     main::AttrVal                       called by ./FHEM/00_TSCUL.pm (1381)
2021.02.10 20:46:26 1:     main::TSCUL_ParseTsHM               called by ./FHEM/00_TSCUL.pm (711)
2021.02.10 20:46:26 1:     main::TSCUL_Parse                   called by ./FHEM/00_TSCUL.pm (639)
2021.02.10 20:46:26 1:     main::TSCUL_Read                    called by fhem.pl (3818)
2021.02.10 20:46:26 1:     main::CallFn                        called by fhem.pl (759)


Da dachte ich ja der wäre nach deinem kleinen Patch weg gewesen - nun, war er da noch nicht - aber jetzt scheint er wirklich weg zu sein.
Dafür habe ich jetzt einen Seiteneffekt mit deiner modifizierten timerTS und GPIO4:

2021.02.12 07:36:47 1: PERL WARNING: readline() on closed filehandle DATA at ./FHEM/58_GPIO4.pm line 132.
2021.02.12 07:36:47 1: stacktrace:
2021.02.12 07:36:47 1:     main::__ANON__                      called by ./FHEM/58_GPIO4.pm (132)
2021.02.12 07:36:47 1:     main::GPIO4_Get                     called by ./FHEM/58_GPIO4.pm (123)
2021.02.12 07:36:47 1:     main::GPIO4_DeviceUpdateLoop        called by ./FHEM/97_timerTS.pm (60)
2021.02.12 07:36:47 1:     main::HandleTimeout                 called by fhem.pl (681)


Das kommt nur alle paar Stunden, dafür dann gleich 2-3 hintereinander (ich habe 10 GPIO4 Temperatursensoren, ich nehme mal an das es da wirklich ein Problem auf dem Bus gibt - nur mit der alten TimerTS hab ich das nie gesehen.

Sonst läuft es unauffällig. Aktuell scheine ich noch weniger resends zu haben (nur so 2%), allerdings finden witterungsbedingt aktuell kaum Ventiländerungen statt. Mal sehen ob das wieder hochgeht, wenn der Schnee weg ist und die Solaranlage wieder warmes Wasser liefert.
Das würde dann meine alte These unterstützen, dass Ventiländerungen eher zu resends führen.

Gruß,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

noansi

Hallo Jörg,

Zitat58_GPIO4.pm
Das Modul ist nicht im SVN vorhanden. Was ist der Inhalt? In contrib hat es sich versteckt...

ZitatDafür habe ich jetzt einen Seiteneffekt mit deiner modifizierten timerTS und GPIO4:
Hier muss ich stark vermuten, dass es sich um einen Fall von "Shit in -> Shit Out" handelt.

timerTS führt da einen Timer "GPIO4_DeviceUpdateLoop" zur vorgesehen Zeit aus. Anscheinend hat aber das Modul auf anderem Wege bereits den File handle geschlossen (und hätte den Timer abschießen müssen oder gar nicht erst starten dürfen)Das Modul öffnet da eine Zeile zuvor ein File, prüft aber nicht, ob die Aktion von Erfolg gekrönt ist, was zu dem Fehlerbild führt.
Das wirst Du wohl im 58_GPIO4.pm Modul debuggen müssen.

Gruß, Ansgar.

noansi

Hallo Testwillige,

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

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> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen 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_FHEM_Modules_00_xx.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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die 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 1234
bzw.
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 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim 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.36 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 VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern 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/topic,24436.msg1098370.html#msg1098370.

Gruß, Ansgar.

Edit: zip aktualisiert auf Modulstand 00_64.
Edit2: zip aktualisiert auf Modulstand 00_65.
Edit3: zip aktualisiert auf Modulstand 00_66, neues TSCUL Attribut 'forceAlivePing'.
Edit4: zip aktualisiert auf Modulstand 00_68, verbessertes Pairing
Edit5: zip aktualisiert auf Modulstand 00_69
Edit6: zip aktualisiert auf Modulstand 00_70, TC statusRequest
Edit6: zip aktualisiert auf Modulstand 00_71, wakeup, lazy config Verbesserungen
Edit7: zip aktualisiert auf Modulstand 00_74, Korrekturen Registeread, Pairing, AES und IO Zuweisung
Edit8: zip aktualisiert auf Modulstand 00_75, nextSend Verbesserung
Edit9: zip aktualisiert auf Modulstand 00_76, IO Zuweisung und IOgrp 'none' Option
Edit10: zip aktualisiert auf Modulstand 00_77, kleine Änderungen für pairing
Edit11: zip aktualisiert auf Modulstand 00_78, IO Zuweisung und IOgrp 'none' Korrektur HMInfo
Edit12: zip aktualisiert auf Modulstand 00_79, Register Read Korrekturen
Edit13: zip aktualisiert auf Modulstand 00_80, Register Read Korrekturen
Edit14: zip aktualisiert auf Modulstand 00_81, IO Zuweisung nach Reading IODev. Bei physischen HM-devices bitte Attribut IODev händisch löschen, da sonst der Attributwert benutzt wird und ohne Save Config vor einem Restart ist der Attributwert veraltet, was unnötige Änderungen in der IO Zuweisung zur Folge hat. Ich bitte um Rückmeldung wenn ein Log Eintrag "CUL_HM hint: <HMdeviceName> first CUL_HM_assignIO differs from fhem.pl restore" beim FHEM Restart auftauchen sollte.
Edit15: zip aktualisiert auf Modulstand 00_82, Rauchmelderkommandos
Edit16: zip aktualisiert auf Modulstand 00_83, getConfig für config devices mit Anlernknopf https://forum.fhem.de/index.php/topic,120268.0.html
Edit17: zip aktualisiert auf Modulstand 00_84, IO Zuweisung
Edit18: zip aktualisiert auf Modulstand 00_85, IO Zuweisung Bug bei config message
Edit19: zip aktualisiert auf Modulstand 00_86, wakup Verbesserungen und HMInfo showTimer
Edit20: zip aktualisiert auf Modulstand 00_87, wakup Verbesserungen und HMInfo showTimer
Edit21: zip aktualisiert auf Modulstand 00_89, wakup Verbesserungen
Edit22: zip aktualisiert auf Modulstand 00_90, wakup Verbesserungen, CUL_HM fwupdate Verbesserung, IO Zuweisung

Adimarantis

Zitat von: noansi am 13 Februar 2021, 09:24:09
Das Modul öffnet da eine Zeile zuvor ein File, prüft aber nicht, ob die Aktion von Erfolg gekrönt ist, was zu dem Fehlerbild führt.
Das wirst Du wohl im 58_GPIO4.pm Modul debuggen müssen.

Da gibts denke ich nicht viel zu debuggen. Wie du schon sagst, fehlt der Test auf erfolgreiches "open" und das kann ja bei einem Kommunikationsverlust mit dem Sensor mal passieren.
Hab ich jetzt mal gefixed. Das hatte entweder gar nix mit dir zu tun, oder deine Änderung hat eine ohnehin vorhandene race condition getriggert.

Sind Contrib Module verwaist? Ich lasse meinen Fix jetzt mal laufen, aber ich denke das sollte man irgendwann einchecken. Ich zumindest nutze das extensiv.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

noansi

Hallo Jörg,

ZitatDas hatte entweder gar nix mit dir zu tun, oder deine Änderung hat eine ohnehin vorhandene race condition getriggert.
So ist es auch. TimerTS als Timerersatz ruft auch nur Funktionen auf, wie es auch Standard Timer tun und übergibt auch genauso den mitgegebenen Parameter.
Wenn eine Funktion mit Schwächen auf dem Timer-Weg aufgerufen wird, dann passiert in beiden Varianten das gleiche: die Funktion fällt auf die Nase.

Der Stacktrace sagt bei Timern noch nichts direktes zu Quelle eines Problems.

ZitatSind Contrib Module verwaist?
Wenn in der MAINTAINER.txt nix drin steht... dann bleibt Dir noch der Copyright Hinweis als Anlaufstelle zu Nachfrage.

Gruß, Ansgar.

noansi


Adimarantis

#1182
Hi Ansgar,

nach dem letzten Update reagiert mein Raspi extrem träge (Klicks auf der Weboberfläche brauchen gerne mal 10s bevor etwas aktualisiert), obwohl die Gesamtbelastung vom Raspi (CPU%, load) ganz ok ist. Der FHEM Prozess hat aber immer 27-30% CPU (Raspi 1 ist nur Single Core, oder?). Die Fehlerrate ist auch hochgeschossen.
Ich wollte jetzt ausschliessen das das eine andere Ursache hat, leider habe ich die alten Testversionen gelöscht und im Thread hast du sie wohl auch aufgeräumt.
Kannst du das nachvollziehen? Kannst du mir nochmal eine ältere Version auschecken damit ich den Vergleich machen kann?

EDIT: Mir ist nach dem Schreiben dieser Zeilen noch eine andere Änderung eingefallen die ich zeitgleich gemacht hatte. Die habe ich jetzt mal zurückgenommen, mal sehen ob es das war.

Danke,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Zitat von: Adimarantis am 22 Februar 2021, 11:16:38
EDIT: Mir ist nach dem Schreiben dieser Zeilen noch eine andere Änderung eingefallen die ich zeitgleich gemacht hatte. Die habe ich jetzt mal zurückgenommen, mal sehen ob es das war.

Ich denke ich kann Entwarnung geben, läuft jetzt ein paar Tage und das Problem ist nicht mehr aufgetreten.
Nichts für ungut.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

noansi

Hallo Jörg,

puhh, Glück gehabt, dass ich es spät genug gelesen habe.  ;)

Gruß, Ansgar.