TSCUL für CUL mit HM-Timestamp

[noansi]

Hallo Rudolf,

Hier ein Log von einem USB CUL mit tsculfw. Hier wird versucht, erst den USB Buffer zu füllen und dann zu senden, wie Du es meinst.

Code Auswählen Erweitern

2017.04.12 06:34:37.599 5: TSCUL/RAW CUL_WS868: /KB739600700D40239_6533266D266D00002C677E062C697E022C70840E2D6A7C022C6B7E022C6B7E022C6A7E04
p 32  856  368  360  856  9  9 7 39
2017.04.12 06:34:37.603 4: TSCUL_Parse: CUL_WS868 KB739600700D40239_6533266D266D00002C677E062C697E022C70840E2D6A7C022C6B7E022C6B7E022C6A7E04 -45.5
2017.04.12 06:34:37.606 5: CUL_WS868: dispatch 810d04xx4027a0017b930670004d20_6533266D266D00002C677E062C697E022C70840E2D6A7C022C6B7E022C6B7E022C6A7E04
2017.04.12 06:34:37.641 5: TSCUL/RAW CUL_WS868: p 32  856  368  360  856  9  9 7 39 / 45 EEE790B7A1084B7484FE  360   0   0

2017.04.12 06:34:37.644 4: TSCUL_Parse: CUL_WS868 p 32  856  368  360  856  9  9 7 39  45 EEE790B7A1084B7484FE  360   0   0
2017.04.12 06:34:57.146 5: SW CUL_WS868: CC0
2017.04.12 06:34:57.152 5: TSCUL/RAW CUL_WS868: /Ci0037032C0002E5D10003A9D8430B000002580000A92F00000585

2017.04.12 06:34:57.172 4: TSCUL_Parse: CUL_WS868 Ci0037032C0002E5D10003A9D8430B000002580000A92F00000585
2017.04.12 06:34:58.264 5: TSCUL/RAW CUL_WS868: /K1149030042_66322C6F2C6F00002D6A7A082E6B78042D6B7A042D6C7A02673408742771840C66340674
p 32  832  400  352  880  9  6 1 42  41 8C665C84217D00  312   0   0

2017.04.12 06:34:58.271 4: TSCUL_Parse: CUL_WS868 K1149030042_66322C6F2C6F00002D6A7A082E6B78042D6B7A042D6C7A02673408742771840C66340674 -41
2017.04.12 06:34:58.273 5: CUL_WS868: dispatch K11490300_66322C6F2C6F00002D6A7A082E6B78042D6B7A042D6C7A02673408742771840C66340674
2017.04.12 06:34:58.329 4: TSCUL_Parse: CUL_WS868 p 32  832  400  352  880  9  6 1 42  41 8C665C84217D00  312   0   0
2017.04.12 06:35:02.748 5: TSCUL/RAW CUL_WS868: /K7162507957_6139267026700000682C0E822D707E082C6B78062D6B76042D6C760266350874672D0C80
p 32  832  392  352  872  9  6 1 57  30 8F52D0D67D9E00  360   0   0

2017.04.12 06:35:02.753 4: TSCUL_Parse: CUL_WS868 K7162507957_6139267026700000682C0E822D707E082C6B78062D6B76042D6C760266350874672D0C80 -30.5
2017.04.12 06:35:02.755 5: CUL_WS868: dispatch K71625079_6139267026700000682C0E822D707E082C6B78062D6B76042D6C760266350874672D0C80
2017.04.12 06:35:02.869 4: TSCUL_Parse: CUL_WS868 p 32  832  392  352  872  9  6 1 57  30 8F52D0D67D9E00  360   0   0
2017.04.12 06:35:09.070 5: TSCUL/RAW CUL_WS868: /K0103425034_68312D702D700000672D0C826C2E08842C6F7E062D6A7808673408762771840A66340676
p 32  832  400  344  880  9  6 1 34  48 88721494358D00  312   0   0


Hier ein Log vom untersten SCC mit tsculfw. Hier wird ab dem ersten Zeichen im seriellen Puffer gesendet, um die Latenz möglichst gering zu halten (serielles Interface):

Code Auswählen Erweitern

2017.04.12 06:36:49.955 5: TSCUL/RAW SCC_WS868: /K2102525
2017.04.12 06:36:50.061 5: TSCUL/RAW SCC_WS868: K2102525/116_6335276C633500006236020062350200633500006335000062360200623602006235020063350000276C78002D6A6C0C6634067A662D107E6C2D0E862C6F7A0C653404762670820865340478662D0E822C707C0A652D0E842D69740C6C2D0A826D2D0A842C697A0A6B2D04806D2D06846C2C06826B2D02802D687C0A6B2
2017.04.12 06:36:50.065 5: TSCUL/RAW SCC_WS868: K2102525116_6335276C633500006236020062350200633500006335000062360200623602006235020063350000276C78002D6A6C0C6634067A662D107E6C2D0E862C6F7A0C653404762670820865340478662D0E822C707C0A652D0E842D69740C6C2D0A826D2D0A842C697A0A6B2D04806D2D06846C2C06826B2D02802D687C0A6B2/D027E34636E126C2D027C6C2D027C2D697C04326A78086C2E027A2D647C106B2E00782D697C04336A780A662D0C786D2D067A6C2C047A2D687C08336A780A662D0C7834697608662D0A782D6A78086C2D06782D69
2017.04.12 06:36:50.069 5: TSCUL/RAW SCC_WS868: K2102525116_6335276C633500006236020062350200633500006335000062360200623602006235020063350000276C78002D6A6C0C6634067A662D107E6C2D0E862C6F7A0C653404762670820865340478662D0E822C707C0A652D0E842D69740C6C2D0A826D2D0A842C697A0A6B2D04806D2D06846C2C06826B2D02802D687C0A6B2D027E34636E126C2D027C6C2D027C2D697C04326A78086C2E027A2D647C106B2E00782D697C04336A780A662D0C786D2D067A6C2C047A2D687C08336A780A662D0C7834697608662D0A782D6A78086C2D06782D69/7A066C2D047A6D2D
2017.04.12 06:36:50.073 5: TSCUL/RAW SCC_WS868: K2102525116_6335276C633500006236020062350200633500006335000062360200623602006235020063350000276C78002D6A6C0C6634067A662D107E6C2D0E862C6F7A0C653404762670820865340478662D0E822C707C0A652D0E842D69740C6C2D0A826D2D0A842C697A0A6B2D04806D2D06846C2C06826B2D02802D687C0A6B2D027E34636E126C2D027C6C2D027C2D697C04326A78086C2E027A2D647C106B2E00782D697C04336A780A662D0C786D2D067A6C2C047A2D687C08336A780A662D0C7834697608662D0A782D6A78086C2D06782D697A066C2D047A6D2D/047C2C698006326A
2017.04.12 06:36:50.077 5: TSCUL/RAW SCC_WS868: K2102525116_6335276C633500006236020062350200633500006335000062360200623602006235020063350000276C78002D6A6C0C6634067A662D107E6C2D0E862C6F7A0C653404762670820865340478662D0E822C707C0A652D0E842D69740C6C2D0A826D2D0A842C697A0A6B2D04806D2D06846C2C06826B2D02802D687C0A6B2D027E34636E126C2D027C6C2D027C2D697C04326A78086C2E027A2D647C106B2E00782D697C04336A780A662D0C786D2D067A6C2C047A2D687C08336A780A662D0C7834697608662D0A782D6A78086C2D06782D697A066C2D047A6D2D047C2C698006326A/780A6C2E007A662D
2017.04.12 06:36:50.081 5: TSCUL/RAW SCC_WS868: K2102525116_6335276C633500006236020062350200633500006335000062360200623602006235020063350000276C78002D6A6C0C6634067A662D107E6C2D0E862C6F7A0C653404762670820865340478662D0E822C707C0A652D0E842D69740C6C2D0A826D2D0A842C697A0A6B2D04806D2D06846C2C06826B2D02802D687C0A6B2D027E34636E126C2D027C6C2D027C2D697C04326A78086C2E027A2D647C106B2E00782D697C04336A780A662D0C786D2D067A6C2C047A2D687C08336A780A662D0C7834697608662D0A782D6A78086C2D06782D697A066C2D047A6D2D047C2C698006326A780A6C2E007A662D/0E782D687C06
p
2017.04.12 06:36:50.085 4: TSCUL_Parse: SCC_WS868 K2102525116_6335276C633500006236020062350200633500006335000062360200623602006235020063350000276C78002D6A6C0C6634067A662D107E6C2D0E862C6F7A0C653404762670820865340478662D0E822C707C0A652D0E842D69740C6C2D0A826D2D0A842C697A0A6B2D04806D2D06846C2C06826B2D02802D687C0A6B2D027E34636E126C2D027C6C2D027C2D697C04326A78086C2E027A2D647C106B2E00782D697C04336A780A662D0C786D2D067A6C2C047A2D687C08336A780A662D0C7834697608662D0A782D6A78086C2D06782D697A066C2D047A6D2D047C2C698006326A780A6C2E007A662D0E782D687C06 -63
2017.04.12 06:36:50.088 5: SCC_WS868: dispatch K21025251_6335276C633500006236020062350200633500006335000062360200623602006235020063350000276C78002D6A6C0C6634067A662D107E6C2D0E862C6F7A0C653404762670820865340478662D0E822C707C0A652D0E842D69740C6C2D0A826D2D0A842C697A0A6B2D04806D2D06846C2C06826B2D02802D687C0A6B2D027E34636E126C2D027C6C2D027C2D697C04326A78086C2E027A2D647C106B2E00782D697C04336A780A662D0C786D2D067A6C2C047A2D687C08336A780A662D0C7834697608662D0A782D6A78086C2D06782D697A066C2D047A6D2D047C2C698006326A780A6C2E007A662D0E782D687C06
2017.04.12 06:36:50.186 5: TSCUL/RAW SCC_WS868: p /32  856  368  376  840  9  6 1 16  63 8A5214D6354C80  408   0   0

2017.04.12 06:36:50.189 4: TSCUL_Parse: SCC_WS868 p 32  856  368  376  840  9  6 1 16  63 8A5214D6354C80  408   0   0
2017.04.12 06:36:53.292 5: TSCUL/RAW SCC_WS868: /*AFF0100
2017.04.12 06:36:53.300 5: TSCUL/RAW SCC_WS868: *AFF0100/6A69ED00169786532A133F0000000041
2017.04.12 06:36:53.304 5: TSCUL/RAW SCC_WS868: *AFF01006A69ED00169786532A133F0000000041/01AE42014143006D
2017.04.12 06:36:53.308 5: TSCUL/RAW SCC_WS868: *AFF01006A69ED00169786532A133F000000004101AE42014143006D/44FF933B

2017.04.12 06:36:53.310 5: SCC_WS868: dispatch *AFF01006A69ED00169786532A133F000000004101AE42014143006D44FF933B
2017.04.12 06:36:53.432 5: TSCUL/RAW SCC_WS868: /*AFF01006A69F8001697C6532A133F000000004101AE42014143006D44FF9329

2017.04.12 06:36:53.435 5: SCC_WS868: dispatch *AFF01006A69F8001697C6532A133F000000004101AE42014143006D44FF9329
2017.04.12 06:36:53.485 5: SCC_WS868 sending *As0E1FB011F110342E16750201000000
2017.04.12 06:36:53.486 5: SW SCC_WS868: *As0E1FB011F110342E16750201000000
2017.04.12 06:36:53.881 5: TSCUL/RAW SCC_WS868: /*AFF1300
2017.04.12 06:36:53.885 5: TSCUL/RAW SCC_WS868: *AFF1300/6A6A27020E1FB011
2017.04.12 06:36:53.888 5: TSCUL/RAW SCC_WS868: *AFF13006A6A27020E1FB011/F110342E16750280
2017.04.12 06:36:53.892 5: TSCUL/RAW SCC_WS868: *AFF13006A6A27020E1FB011F110342E16750280/

2017.04.12 06:36:53.895 5: SCC_WS868: dispatch *AFF13006A6A27020E1FB011F110342E16750280
2017.04.12 06:36:54.011 5: TSCUL/RAW SCC_WS868: /*AFF1100
2017.04.12 06:36:54.015 5: TSCUL/RAW SCC_WS868: *AFF1100/6A6AA100111FA002
2017.04.12 06:36:54.019 5: TSCUL/RAW SCC_WS868: *AFF11006A6AA100111FA002/2E1675F1103404BF
2017.04.12 06:36:54.023 5: TSCUL/RAW SCC_WS868: *AFF11006A6AA100111FA0022E1675F1103404BF/DC46D239700413

2017.04.12 06:36:54.025 5: SCC_WS868: dispatch *AFF11006A6AA100111FA0022E1675F1103404BFDC46D239700413
2017.04.12 06:36:54.166 5: TSCUL/RAW SCC_WS868: /*AFF1300
2017.04.12 06:36:54.170 5: TSCUL/RAW SCC_WS868: *AFF1300/6A6ABF01191FA003
2017.04.12 06:36:54.174 5: TSCUL/RAW SCC_WS868: *AFF13006A6ABF01191FA003/F110342E1675EC80
2017.04.12 06:36:54.178 5: TSCUL/RAW SCC_WS868: *AFF13006A6ABF01191FA003F110342E1675EC80/


oder

Code Auswählen Erweitern

2017.04.12 06:37:20.662 5: TSCUL/RAW SCC_WS868: /tA07E723
2017.04.12 06:37:20.666 5: TSCUL/RAW SCC_WS868: tA07E723/7242D_9D793D78A1
2017.04.12 06:37:20.669 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A1/7500009D7C0E0098
2017.04.12 06:37:20.673 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E0098/7C1000987B0C003D
2017.04.12 06:37:20.677 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D/78C2009C7A02C23D
2017.04.12 06:37:20.681 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D/79C0029B
2017.04.12 06:37:20.685 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B/7310BCA17808C89B
2017.04.12 06:37:20.689 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B/750EBCA2770ACA9D
2017.04.12 06:37:20.693 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D/7606C09F7506C43C
2017.04.12 06:37:20.697 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C/79C4024371C20E42
2017.04.12 06:37:20.701 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E42/77B8083C75C80A42
2017.04.12 06:37:20.705 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A42/78B80A3B77C60A9E
2017.04.12 06:37:20.709 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E/7504BEA07504C23C
2017.04.12 06:37:20.713 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C/78C6063F
2017.04.12 06:37:20.717 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F/75C4044377B80A98
2017.04.12 06:37:20.721 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A98/7B0EBA997808B63D
2017.04.12 06:37:20.725 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A987B0EBA997808B63D/7DBE0C997708B49E
2017.04.12 06:37:20.728 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A987B0EBA997808B63D7DBE0C997708B49E/7A0AC09A7708B63E
2017.04.12 06:37:20.732 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A987B0EBA997808B63D7DBE0C997708B49E7A0AC09A7708B63E/7BBC043D72CC14A2
2017.04.12 06:37:20.736 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A987B0EBA997808B63D7DBE0C997708B49E7A0AC09A7708B63E7BBC043D72CC14A2/730CC64472C00C3E
2017.04.12 06:37:20.740 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A987B0EBA997808B63D7DBE0C997708B49E7A0AC09A7708B63E7BBC043D72CC14A2730CC64472C00C3E/79C0043D78C2069D
2017.04.12 06:37:20.744 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A987B0EBA997808B63D7DBE0C997708B49E7A0AC09A7708B63E7BBC043D72CC14A2730CC64472C00C3E79C0043D78C2069D/7902BE9B
2017.04.12 06:37:20.748 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A987B0EBA997808B63D7DBE0C997708B49E7A0AC09A7708B63E7BBC043D72CC14A2730CC64472C00C3E79C0043D78C2069D7902BE9B/7708B83E75C408A1
2017.04.12 06:37:20.752 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A987B0EBA997808B63D7DBE0C997708B49E7A0AC09A7708B63E7BBC043D72CC14A2730CC64472C00C3E79C0043D78C2069D7902BE9B7708B83E75C408A1/7708C49C750ABA44
2017.04.12 06:37:20.756 5: TSCUL/RAW SCC_WS868: tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A987B0EBA997808B63D7DBE0C997708B49E7A0AC09A7708B63E7BBC043D72CC14A2730CC64472C00C3E79C0043D78C2069D7902BE9B7708B83E75C408A17708C49C750ABA44/77B40A9C7508B8

2017.04.12 06:37:20.760 4: TSCUL_Parse: SCC_WS868 tA07E7237242D_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A987B0EBA997808B63D7DBE0C997708B49E7A0AC09A7708B63E7BBC043D72CC14A2730CC64472C00C3E79C0043D78C2069D7902BE9B7708B83E75C408A17708C49C750ABA4477B40A9C7508B8 -51.5
2017.04.12 06:37:20.762 5: SCC_WS868: dispatch TXA07E723724_9D793D78A17500009D7C0E00987C1000987B0C003D78C2009C7A02C23D79C0029B7310BCA17808C89B750EBCA2770ACA9D7606C09F7506C43C79C4024371C20E4277B8083C75C80A4278B80A3B77C60A9E7504BEA07504C23C78C6063F75C4044377B80A987B0EBA997808B63D7DBE0C997708B49E7A0AC09A7708B63E7BBC043D72CC14A2730CC64472C00C3E79C0043D78C2069D7902BE9B7708B83E75C408A17708C49C750ABA4477B40A9C7508B8
2017.04.12 06:37:20.820 5: TSCUL/RAW SCC_WS868: /p  8 1264  952  512  952  4  4 4 2D  51 07E7237240 1240   0   0

2017.04.12 06:37:20.823 4: TSCUL_Parse: SCC_WS868 p  8 1264  952  512  952  4  4 4 2D  51 07E7237240 1240   0   0


Das lange Zeug hinten dran sind Bittimingdaten, wenn das Logging dazu aktiviert ist.
Aber bereits vorne wird gesplittet Empfang "gemeldet".

Es hängt von der FHEM Durchlaufzeit und vom Betreibssystem ab, wann zum ersten mal Empfangsdaten gemeldet werden. Die Stufung zeigt, wie die Teildaten ankommen.
Und es hängt vom Zufall ab, wann ein Sync Get dazwischen haut.

Ein CUNO2 arbeitet beim Netzwerkbetrieb mit TCP/IP Paketen, und daher ähnlich wie USB, also auch in Paketen und nicht Zeichen für Zeichen.

So lange die Puffer nicht überlaufen sorgt die SCC Firmware dafür, dass Sendemessages immer vollständig übertragen werden, ehe eine weitere message gesendet wird, unabhängig davon welches SCC Modul die message sendet.

Gruß, Ansgar.

[rudolfkoenig]

Ich sehe im Moment keine Probleme mit deinem letzten CULsim.pl, auch wenn ich direkt nach einer Teilmeldung eine Anfrage schicke. K31070200 wird immer als Ganzes weiterverarbeitet, und auch die Antwort auf die Anfrage kommt richtig an.

Teilmeldungen (d.h. ohne NL) koennen nur auf der untersten Ebene passieren, weil Nachrichten ohne NL von CUL_Read bzw. CUL_ReadAnswer nicht an CUL_Parse (und dadurch an die STACKABLE Funktionen) weitergegeben weden. Damit aendert sich wg. STACKABLE nichts, das Problem der Teilnachrichten gab es auch bisher, und wird mW richtig geloest.

Die SCC Firmware muss sicherstellen, dass Nachrichten unterschiedlicher Ebenen nicht gemischt werden. Ob das der Fall ist, weiss ich nicht, aber wenn ja, dann kan man das auf der FHEM-Seite nicht mehr auseinanderdividieren.

An CUL.pm oder STACKABLE.pm sehe ich keinen Aenderungsbedarf.

[rudolfkoenig]

Korrektur: es gibt ein zusaetzliches Problem im STACKABLE_IOReadFn fur synchrone gets (die hoffentlich Ausnahme sind, da sie FHEM blockieren koennen). Ich habe jetzt in dieser Funktion PARTIAL beruecksichtigt, sie wird aber (da sie zu einer tieferen Ebene gehoert) nicht ausgewertet. Immerhin verwirrt sie nicht mehr beim Empfang der naechsten Nachricht.

[noansi]

Hallo Rudolf,

Teilmeldungen (d.h. ohne NL) koennen nur auf der untersten Ebene passieren

Da stimme ich Dir zu.

Die SCC Firmware muss sicherstellen, dass Nachrichten unterschiedlicher Ebenen nicht gemischt werden.

Bei der tsculfw habe ich eingebaut, dass Raum für ein \r\n im Puffer vorgehalten wird, so dass auch bei einem Pufferüberlauf der Abschluss auch einer unvollständigen Nachricht möglich bleibt. Bei einem einfachen Überlauf innerhalb der Übertragungszeit von 2 Zeichen sollte es sicher sein.
culfw ist da nach meiner Erinnerung unvorsichtiger.
Allerdings wird es normalerweise nur bei so langen Nachrichten, wie ich sie mit dem Bittiming Logging erzeuge auch kritisch mit der Puffergröße.

Hier mein letzter Stand ohne Wegwerfen von "Müll". Mit dieser Variante benötige ich nur noch ein Flag $me->{IODev}{helper}{ChkPart} um die Daten für die unteren Ebenen auch bei Empfang direkt parsen zu können.
Im Cient muss in der ReadFn bei gesetztem Flag nur das Lesen von der Schnittstelle übersprungen werden, so dass alles vollständige in PARTIAL geparst wird.
Wird das Flag von einem Client nicht unterstützt, dann werden dessen asynchrone Daten später erst verarbeitet, wenn neue Daten eintreffen.

Code Auswählen Erweitern

#####################################
sub
STACKABLE_IOReadFn($) # used by synchronous get
{
  my ($hash) = @_; # our client, e.g. TSCUL, CUL ...
  my $me = $hash->{IODev};
  my $meIOh = $me->{IODev}; # e.g. TSCUL, CUL ...

  my $rpf = AttrVal($me->{NAME},"readPrefix","\\*");

  my $buf;
 
  my $srpf = AttrVal($hash->{STACKED},"readPrefix","\\*") if defined($hash->{STACKED});
 
  my $sg;
  if (defined($hash->{STACKED})) {
    if (!$defs{$hash->{STACKED}}{SGIS}) {
      $sg = 1; # with us our client is doing sýnchronuos get
    }
  } else {
    $sg = 1; # with us our client is doing sýnchronuos get
  }
  $me->{SGIS} = 1;

  # we have also to consider asynchronous data from other devices in the stack e.g. received data
  # maybe there is allready partial data in real IODev
  # or complete data not for us
  my $ppart = \$meIOh->{PARTIAL}; # IODev has to have and use it! Else it may increase endless !
  if (!defined($ppart)) { # but maybe it is not existing yet
    $meIOh->{PARTIAL} = "";
    $ppart = \$meIOh->{PARTIAL};
  }

  $buf = ${$ppart};
  my $ret = DevIo_SimpleReadWithTimeout($meIOh, 1); # may block
  return undef if(!defined($ret));
  $buf .= $ret;
  ${$ppart} = "";

  $me->{SGIS} = 0;

  $ret = "";

  # now check for our clients data or data for one of our stacked devices
  while($buf =~ m/\n/) {

    my $t;
    ($t,$buf) = split("\n", $buf, 2); # maybe something more arrived

    if ($t =~ m/^$rpf/) { # is it data for our client or one of our stacked devices?

      if (!defined($srpf)) { # not someone stacked?
        # must be for our client
        $t =~ s/^.//;             # Cut off prefix
        $ret .= $t . "\n";
        next;
      }

      if ($t !~ m/^.$srpf/) { # not for one of our stacked devices?
        # must be for our client
        if ($sg) { # are we the one waiting for data?
          $t =~ s/^.//;           # Cut off prefix
          $ret .= $t . "\n";
        } else {
          ${$ppart} .= $t . "\n"; # let IODev handle it later, when it receives new data.
                                  # How can we force a non blocking Read for IODev later to avoid the delay until next reception of data?
        }
        next;
      }

      # must be for one of our stacked devices
      if (!$sg) { # are we not the ones waiting for data?
        $t =~ s/^.//;             # Cut off prefix
        $ret .= $t . "\n";
        next;
      }
    }

    # must be for IODev
    ${$ppart} .= $t . "\n";       # let IODev handle it later, when it receives new data
                                  # How can we force a non blocking Read for IODev later to avoid the delay until next reception of data?
  }

  ${$ppart} .= $buf; # let IODev handle the remainig later, when it receives new data

  if (defined($meIOh->{helper}{ChkPart}) && (${$ppart} =~ m/\n/)) { # or try to do it now, if IODev supports it
    $meIOh->{helper}{ChkPart} = 1; # IODev needs to support it, this flag inhibits reading from device, just parse {PARTIAL}. IODev needs to clear the flag after!
    CallFn($meIOh->{NAME},"ReadFn",$meIOh); # Parse what arrived at IO
  }

  if(AttrVal($me->{NAME},"binary",0)) {
    $ret =~ s/[\r\n]//g;    #? is binary mode fully covered just here? More than one message can arrive here.
    return pack("H*",$ret); #? is binary mode fully covered just here?
  } else {
    return $ret;
  }
}


Was erscheint Dir an diesem Parsen zu riskant? Würde gerade kein SyncGet ausgeführt, würden diese Daten doch auch geparst?!?

CUL_ReadAnswer($$$$) parst auch die asynchronen Daten vor der erwarteten Nachricht!?!

Für TSCUL habe ich mir zum Test in TSCUL_ReadAnswer($$$$) nun auch eingebaut, die vollständigen Daten im Puffer nach der gewünschten Nachricht noch zu parsen. Erst dann wird die Synchrone Antwort geliefert.
Im Bezug auf HM ist eine Empfangsverzögerung für rechtzeitiges Antworten leider maximal kontraproduktiv.

Die Signalisierung mit {SGIS} wäre kritisch, wenn das Parsen der Daten ein weiteres SynchGet auf anderer Ebene auslösen würde.
Allerdings halte ich SynchGet, wie es das IT Modul nutzt, generell in FHEM für fehl am Platz und auch unnötig.

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

in Zusammenhang mit IT ist mir aufgefallen, dass die Nutzung der GetFn von 00_CUL mit raw durch IT (oder auf FHT) bei gleichzeitigem Empfang anderer Daten im Stack ungünstig enden kann.

GetFn mit raw aufgerufen liefert das erste, was ankommt. Im Stapel kann aber zuerst etwas von einem anderen device ankommen, bevor die erwartete Antwort kommt.

Es fehlt ein Match auf das erwartete Ergebnis (wie bei CUL_ReadAnswer), der aber durch ein weiteres Array Element im Parameter zur GetFn leicht ergänzt werden kann.

Ab Zeile 423 in 00_CUL.pm

Code Auswählen Erweitern

  } else {

    CUL_SimpleWrite($hash, $gets{$a[1]}[0] . $arg);
    my $mtch = defined($a[3]) ? $a[3] : $gets{$a[1]}[1]; # optional match for expected result
    ($err, $msg) = CUL_ReadAnswer($hash, $a[1], 0, $mtch);
    if(!defined($msg)) {
      DevIo_Disconnected($hash);
      $msg = "No answer";

    } elsif($a[1] eq "cmds") {       # nice it up


sorgt für eine solche Match Möglichkeit.
Damit kann IT, FHT etc. beim GetFn raw Aufruf entprechend ergänzt werden, um die erwartete Nachricht festzulegen.

Gruß, Ansgar.

[rudolfkoenig]

Was erscheint Dir an diesem Parsen zu riskant?

- es ist viel Code, und ich brauche viel Zeit um es (samt Nebeneffekten) zu verstehen.

- ich habe keinen Testfall, um zu pruefen, ob es ein Problem behebt, was die aktuelle Version nicht tut => ich brauche keinen Patch, sondern etwas, was mir das Problem demonstriert.

- es behandelt (mAn) nur selten vorkommende Faelle, falls man get verwendet. Das get im CUL ist blockierend, fuer FHEM ist das Gift, man sollte es meiden. Wenn manche Module darauf angewiesen sind, dann sollte man diese Module umbauen, bevor ich dafuer aufwendige Loesungen einbaue. Eigentlich sollte ich das CUL get auf async umbauen, so wie das im ZWave schon der Fall ist, dann waere diese Diskussion hier auch obsolet.

Ab Zeile 423 in 00_CUL.pm...sorgt für eine solche Match Möglichkeit.

Danke, ich habe es eingecheckt.

[noansi]

Hallo Rudolf,

Eigentlich sollte ich das CUL get auf async umbauen, so wie das im ZWave schon der Fall ist, dann waere diese Diskussion hier auch obsolet.

Hmm, wie löst das das Problem?

- Das get wird nur verwendet, wenn eine Antwort vom IO erwartet wird.
- Wird die Antwort nicht benötigt, dann kann man das get auch durch ein set ersetzen und den Parser den Müll aussortieren lassen.
- Wird die Antwort aber benötigt, dann ist get die einfachste Methode damit umzugehen, um die zugehörige Antwort zu erhalten und auswerten zu können und wird daher auch von Modulentwicklern gewählt, denke ich.
- Async geht es nur mit Statemachines zur Auswertung der Antwort und Fortsetzung einer Befehlsfolge ans IO.

In jedem Fall muss die Antwort eindeutig auszusortieren sein. Antworten ohne Protokollkennung, also z.B. nur ein Wert, sind dabei ungünstig.
In der Firmware wären daher mAn die ersten Aufräumarbeiten nötig, damit der Parser solche Antworten an die jeweiligen Module weitergeben kann.


Bei STACKABLE_Parse ist mir noch eine Schwäche aufgefallen. In TSCUL habe ich auch readings, die mit gewissen Nachrichten aktualisiert werden.
Bei TSCULs im Stack wird das notify dazu aber nicht ausgelöst, sondern es sammeln sich CHANGED Einträge an.
Das liegt daran, dass immer "" zurück geliefert wird und damit in fhem.pl die CHANGED Daten nicht ausgewertet werden.

Code Auswählen Erweitern

    return $ch->{NAME} if (defined($ch->{CHANGED})); # let client notifies device work


in

Code Auswählen Erweitern

sub
STACKABLE_Parse($$)
{
  my ($iohash,$msg) = @_;

  return "UNDEFINED $iohash->{NAME}_STACKABLE STACKABLE $iohash->{NAME}"
    if(!$iohash->{STACKED});

  my $name = $iohash->{STACKED};
  return "" if(IsIgnored($name));

  $msg =~ s/^.//; # Cut off prefix *, dispatcher "verified" it
  my $sh = $defs{$name};

  my $ch = $sh->{".clientHash"};
  if($ch) {
    delete $ch->{IOReadFn};
    $ch->{IODevRxBuffer} = (AttrVal($name,"binary",0) ?
                                pack("H*",$msg) : $msg."\n");
    CallFn($ch->{NAME}, "ReadFn", $ch);
    $ch->{IOReadFn} = "STACKABLE_IOReadFn";
    return $ch->{NAME} if (defined($ch->{CHANGED})); # let client notifies device work
  } else {
    Log 1, "STACKABLE_Parse $name: no client device assigned";
  }
  return "";
}


sorgt dafür, das CHANGED verarbeitet wird und Notifies ausgelöst werden.

Als nicht erwünschter Nebeneffekt werden dabei aber auch MSGCNT und .*_MSGCNT im device erhöht. Um das zu beheben müsste ein zusätzliches Flag von fhem.pl unterstützt werden, das diese MSGCNT Updates unterdrückt.

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

bist Du Dir bewusst, dass

Code Auswählen Erweitern

my $v = 1 if (condition);

nicht immer das gleiche in $v erzeugt, wie

Code Auswählen Erweitern

my $v;
$v = 1 if (condition(;

wenn die condition nicht true ist?

Mir ist das jetzt unangenehm aufgefallen beim rekursiven Aufruf in STACKABLE.
Es wurde dabei statt undef etwas in $v gesetzt, was zuvor mal drin stand. Sehr unangenehm zu finden!

Daher folgender Patchvorschlag und Verzichtsanregung auf die abkürzende Schreibweise my mit Bedingung.

Code Auswählen Erweitern

--- old/fhem.pl Mon May 01 09:07:22 2017
+++ new/fhem.pl Wed May 10 21:01:56 2017
@@ -27,7 +27,7 @@
#
#  Homepage:  http://fhem.de
#
-# $Id: fhem.pl 14152 2017-05-01 09:07:23Z rudolfkoenig $
+# $Id: fhem.pl 14097 2017-04-24 11:50:40Z rudolfkoenig $


use strict;
@@ -239,7 +239,7 @@
use vars qw(@structChangeHist); # Contains the last 10 structural changes

$selectTimestamp = gettimeofday();
-$cvsid = '$Id: fhem.pl 14152 2017-05-01 09:07:23Z rudolfkoenig $';
+$cvsid = '$Id: fhem.pl 14097 2017-04-24 11:50:40Z rudolfkoenig $';

my $AttrList = "alias comment:textField-long eventMap group room ".
                "suppressReading userReadings:textField-long ".
@@ -1732,7 +1732,9 @@
   if(defined($hash->{".triggerUsed"}) && $hash->{".triggerUsed"} == 0) {
     shift @a;
     # set arg if the module did not triggered events
-    my $arg = join(" ", @a) if(!$hash->{CHANGED} || !int(@{$hash->{CHANGED}}));
+#    my $arg = join(" ", @a) if(!$hash->{CHANGED} || !int(@{$hash->{CHANGED}}));
+    my $arg;
+    $arg = join(" ", @a) if(!$hash->{CHANGED} || !int(@{$hash->{CHANGED}}));
     DoTrigger($dev, $arg, 0);
   }
   delete($hash->{".triggerUsed"});
@@ -3807,8 +3809,12 @@
                   map { $_ =~ s/.*?=//s; $_ =~ s/.*?://s; "$_:noArg" } @emList);
   }

-  my $dname = shift @{$str} if(!$dir);
-  my $nstr = join(" ", @{$str}) if(!$dir);
+#  my $dname = shift @{$str} if(!$dir);
+  my $dname;
+  $dname = shift @{$str} if(!$dir);
+#  my $nstr = join(" ", @{$str}) if(!$dir);
+  my $nstr;
+  $nstr = join(" ", @{$str}) if(!$dir);

   my $changed;
   foreach my $rv (@emList) {
@@ -4235,14 +4241,20 @@
       } elsif($modifier eq "difference") {
         $result= $value - $oldvalue if(defined($oldvalue));
       } elsif($modifier eq "differential") {
-        my $deltav= $value - $oldvalue if(defined($oldvalue));
-        my $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
+#        my $deltav= $value - $oldvalue if(defined($oldvalue));
+        my $deltav;
+        $deltav= $value - $oldvalue if(defined($oldvalue));
+#        my $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
+        my $deltat;
+        $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
         if(defined($deltav) && defined($deltat) && ($deltat>= 1.0)) {
           $result= $deltav/$deltat;
         }
       } elsif($modifier eq "integral") {
         if(defined($oldt) && defined($oldvalue)) {
-          my $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
+#          my $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
+          my $deltat;
+          $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
           my $avgval= ($value + $oldvalue) / 2;
           $result = ReadingsVal($name,$reading,$value);
           if(defined($deltat) && $deltat>= 1.0) {


Die Perl Doku weist auch in einer Note auf das nicht definierte Verhalten dieses my ... if Konstrukts hin.
Im Bereich um Zeile 1732 oder 4235 hat es in alter Form bei meinen STACKABLE Tests auch Quatsch gemacht, wie ich an den MSGCNT Zählwerten gesehen habe.

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

hier noch ein verbesserter Ansatz für STACKABLE_IOReadFn($).

Code Auswählen Erweitern

#####################################
sub
STACKABLE_IOReadFn($) # used by synchronous get
{
  my ($hash) = @_; # our client, e.g. TSCUL, CUL ...
  my $myhash = $hash->{IODev};
  my $myIOh = $myhash->{IODev}; # e.g. TSCUL, CUL ...

  Log3 $myhash->{NAME}, 0, "STACKABLE_IOReadFn $myhash->{NAME}: bad recursive call detected!" if ($myhash->{IORM} ne "");

  my $m; # do not use  "my $m = $defs{$hash->{STACKED}}{IORM} if (defined($hash->{STACKED}));" That results in strange recursive behaviour!
  $m = $defs{$hash->{STACKED}}{IORM} if (defined($hash->{STACKED}));
  $m .= "\\*";

  $myhash->{IORM} = $m; # set our "trace" down the stack

  my $ret = DevIo_SimpleReadWithTimeout($myIOh, 1); # may block for 1 second each call
                                                    # will call STACKABLE_IOReadFn recursivly
                                                    # down to the first CUL in stack
                                                    # this may also modify it's {PARTIAL} buffer
                                                    # by parsing

  $myhash->{IORM} = ""; # reset before any return, not to break the recursive reset!

  return undef if(!defined($ret));

  # we have also to consider asynchronous data from other devices in the stack e.g. received data
  # maybe there is allready partial data in real IODev
  # or complete data not for us
  my $pIOpart = \$myIOh->{PARTIAL}; # IODev has to have and use it! Else it may increase endless !

  my $buf = ${$pIOpart};

#  Log3 $myhash->{NAME}, 5, "TSCUL $myIOh->{NAME}/RAW $myhash->{NAME} match:$m pre: $buf/$ret";

  $buf .= $ret;
  ${$pIOpart} = "";

  $ret = "";

  # now check for our clients data or data for one of our stacked devices
  while($buf =~ m/\n/) {

    my $t;
    ($t,$buf) = split("\n", $buf, 2); # maybe something more arrived

    if ($t =~ m/^$m[^\*]/) { # is it data we are looking for for the requesting stack member?
      $t =~ s/^.//;      # Cut off prefix
      $ret .= $t . "\n"; # deliver to next stack level
      next;
    }

    # must be for IODev or should be handled by IODev
    ${$pIOpart} .= $t . "\n"; # let IODev handle it later, when it receives new data
  }

  ${$pIOpart} .= $buf; # let IODev handle the remainig later, when it receives new data

#  Log3 $myhash->{NAME}, 5, "TSCUL $myIOh->{NAME}/RAW $myhash->{NAME} ret: ${$pIOpart}/$ret";

  if ((${$pIOpart} =~ m/\n/) && defined($myIOh->{helper}{ChkPart}) && $init_done) { # let IODev handle it's data now, if IODev supports it
    $myIOh->{helper}{ChkPart} = 1; # IODev needs to support this flag.
                                   # This flag inhibits reading from device, just parse {PARTIAL}.
                                   # IODev needs to clear the flag after!
                                   # See TSCUL_Read($) for a usage example for implementing
                                   # and add a line "$hash->{helper}{ChkPart} = 0;" in define function
                                   # as in TSCUL_Define($$)
    CallFn($myIOh->{NAME},"ReadFn",$myIOh); # Parse what arrived at IO, avoid long async reception delays!
                                            # normaly only at bottom of stack this is executed
                                            # cause only there data should remain in ${$pIOpart}
                                            # this way they are parsed in order except the messages
                                            # for the requesting stack member
  }

  if(AttrVal($myhash->{NAME},"binary",0)) {
    $ret =~ s/[\r\n]//g;    # binary mode is only allowed for a device on top of stack!!!
    return pack("H*",$ret); # else we may get in trouble here,
                            # if more than one message arrives with
                            # messages also for stacked devices
  } else {
    return $ret;
  }
}


{IORM} muss noch in STACKABLE_Define($$) mit "" vorbelegt werden.

Es wird ein * Matchmuster bis nach unten im Stack gebildet und dort dann gezielt aus den ankommenden Daten passende Nachrichten für das anfordernde Device extrahiert.
Damit bleibt die Nachrichtenreihenfolge für asynchrone Daten anderer devices im Stack erhalten, was in meinen vorherigen Ansätzen nicht der Fall war.
Und diese können unten per Dispatch auch direkt verarbeitet werden, mit kleiner Ergänzung am IODev.
Damit würden dann für andere devices im Stack keine Nachrichtenverluste auftreten und die Empfangsreihenfolge nebst Empfangszeitpunkt blieben für diese auch erhalten.
Wenn das IODev nicht für den Dispatch modifiziert wird, dann werden die Daten mit den nächsten asynchronen Daten für eines der Stackdevices verzögert verarbeitet, was ich schlechter finde.

Nur das pollende Modul im Stack würde die Antwort, auf die es ohnehin wartet, ggf. etwas verzögert bekommen.

Eine Log Meldung ist auch drin, um festzustellen, ob böse rekursive Aufrufe durch das Dispatchen auftreten.

Gruß, Ansgar.

[rudolfkoenig]

bist Du Dir bewusst, dass...

Inzwischen schon, ich musste vor (gefuehlt) einem Jahr eine Stelle deswegen anpassen.
Mir ist nur in diesen Faellen noch nicht klar, warum es zu einem Problem fuehrt.

hier noch ein verbesserter Ansatz für STACKABLE_IOReadFn($).

Ich glaube, wir drehen uns im Kreis. Wie ich das vor zwei Wochen schon geschrieben habe: ich brauche keinen Patch, sondern etwas, was mir das Problem demonstriert.

[noansi]

Hallo Rudolf,

Mir ist nur in diesen Faellen noch nicht klar, warum es zu einem Problem fuehrt.

Auf perldoc http://perldoc.perl.org/perlsyn.html#Compound-Statements findest Du:

NOTE: The behaviour of a my, state, or our modified with a statement modifier conditional or loop construct (for example, my $x if ... ) is undefined. The value of the my variable may be undef, any previously assigned value, or possibly anything else. Don't rely on it. Future versions of perl might do something different from the version of perl you try it out on. Here be dragons.

Daher fällt dies bei mir unter vorrausschauende Bug Vermeidung, alle diese Konstrukte in eine semantisch eindeutige und sichere Form umzuschreiben. Oder hast Du Lust, nach einem Perl Update ggf. merkwürdige Nebeneffekte zu suchen und zu korrigieren? Oder wenn nur jemand oder Du selbst eine Funktion mal rekursiv nutzt?

Beim Dispatch Versuch in STACKABLE ist es mir nicht als drastisches Problem aufgefallen. Aber die MSGCNT Zähler, die ich mit der geänderten Rückgabe in STACKABLE_Parse bei vorhandenen {CHANGED} Einträgen indirekt über Dispatch aktiviert hatte (siehe oben), haben Quatsch gezählt. Im ersten gestapelten Device wurde gezählt, was in höheren hätte gezählt werden müssen. Ob noch mehr dadurch Schief gelaufen ist, kann ich nicht sagen und habe ich auch nicht untersucht.

Es ist halt eine böse Falle, ebenso, wie ein versehentlich vergessenes oder gelöschtes"my" bei einer lokalen Variablen Deklaration bei dem Perl dann u.U. eine andere existierende lokale Variable nutzt. Schwer zu finden oder nachzuvollziehen, erst recht, wenn eine Funktion lange Zeit tadellos funktioniert hat.

Ich glaube, wir drehen uns im Kreis. Wie ich das vor zwei Wochen schon geschrieben habe: ich brauche keinen Patch, sondern etwas, was mir das Problem demonstriert.

Ich habe Dir in realen Logs gezeigt, dass lange Nachrichten im Puffer auftauchen können, wenn FHEM lange mit z.B. Notify Abarbeitung beschäftigt ist. Ebenso können also auch mehrere Nachrichten im Puffer auflaufen, bis FHEM Zeit für die Verabeitung hat.
Wenn eine HM Nachricht mit Antwortflag dabei ist, die noch nicht zu lange darin verweilt, dann besteht die Chance, sie noch rechtzeitig seitens FHEM zu beantworten, und das möchte ich.

Selbst wenn ich Dir das jetzt im Simulator ein entsprechndes Konstrukt einbaue, wirst Du mir immer noch sagen, dass es ein seltener Fall ist, den Du meinst in Kauf nehmen zu können. In den meisten Fällen wird das auch so sein, da HM devices normalerweise auch wiederholen.
Ich empfange im Stack auch WS2000 Sensordaten. Da wird nicht wiederholt und der Empfang ist ohnehin gerne mit Verlusten behaftet. Da möchte ich ebenfalls möglichst keine Daten verlieren und benötige auch die einigermaßen korrekte Empfangszeit.
Wenn es im realen Leben also gerade mal "passiert" habe ich bestimmt gerade nicht das passende Logging laufen, um es Dir auf dem Weg nachweisen zu können.

Für mich geht es also darum, ob Du mit meinen Änderungswunsch doch noch mitgehst oder ob ich von STACKABLE (und auch DeviceIo) wieder eine TS Variante bauen muss, um dahin zu kommen (was ja eigentlich gegen den Sinn dieser beiden ist).

STACKABLE finde ich grundsätzlich super und eine wesentliche Verbesserung gegenüber der alten Lösung, Danke dafür!
Und natürlich ausbaufähig auch für andere IOs die so ein Protokoll nutzen. Datenverluste stören mich dagegen, insbesondere dann, wenn ich sie gerade doch mal nicht brauchen kann.

Gruß, Ansgar.

[rudolfkoenig]

Mir ist nur in diesen Faellen noch nicht klar, warum es zu einem Problem fuehrt..

Ich habe das Gefuehl, dass du diese Frage indirekt mit "nein" bzw. "weiss nicht" beantwortet hast, korrigiere mich, wenn ich falsch liege. Ich habe die Stellen angepasst, einerseits weil ich relativ sicher bin, kein Problem dadurch zu verursachen, andererseits weil ich dich nicht unnoetig aergern will.

Für mich geht es also darum, ob Du mit meinen Änderungswunsch doch noch mitgehst

Nein, da an solchen stellen der Kode von mir stammen muss, damit ich es auch nach eine Weile verstehe und ihn warten kann. Natuerlich bin ich weiterhin bereit, nachstellbare Probleme zu beheben.

[noansi]

Hallo Rudolf,

Ich habe das Gefuehl, dass du diese Frage indirekt mit "nein" bzw. "weiss nicht" beantwortet hast

Ich weiß nicht, ob die "my if" Korrektur, außer dem durch meine zusätzliche Dispatcherei aufgefallenen _MSGCNT Fehlverhalten, weitere Probleme löst und habe es auch bisher nicht untersucht.
Mir ist aber aufgefallen, dass ich seit dem noch keine merkwürdige HM Wiederholungen durch 10_CUL_HM gesehen habe, die ich mir bisher nicht erklären kann (und wegen des Seltenheitswerts auch nicht in Rohdaten loggen konnte). In 10_CUL_HM habe ich natürlich auch direkt dieses Konstrukt gesucht und umgebaut. Die Testzeit ist aber noch zu kurz, um wirklich empirisch auf eine Verbesserung zu schließen.
Wenn Du meinst, dass ich meine, dass Du die Frage so beantwortet hast, dann liegst Du falsch. Ich habe nur gelernt, dass es teilweise schwierig bis unmöglich ist, eine aus meiner Sicht sinnvolle oder nützliche Änderung zu bewirken, ohne konkretes Fehler-/Problemlog sondern nur mit reiner Überlegung oder empirischer Erfahrung. In diesem Fall war die Hoffnung größer wegen der PerlDoc Note.
Dafür bin ich auch immer wieder überrascht, welche Alternativlösungen dabei teilweise raus kommen.

Ich habe die Stellen angepasst, einerseits weil ich relativ sicher bin, kein Problem dadurch zu verursachen, andererseits weil ich dich nicht unnoetig aergern will.

Danke!
Ärgern tue ich mich aber nicht. Es ist nur insbesondere bei fhem.pl ein großer Aufwand ein fhem upate mitzuziehen, wenn ich dann meine Änderungen wieder nachziehen muss.
Seit meinem ersten Versuch eine Empfangstimestamp in fherm.pl unterzubringen, meide ich Eingriffe in fhem.pl eigentlich.
Ich hoffe Du ärgerst Dich nicht, wenn ich es immer wieder teilweise etwas hartnäckig (und dann auch noch in für Dich suboptimaler Form) versuche, Dich von einer Änderung zu überzeugen.

Nein, da an solchen stellen der Kode von mir stammen muss, damit ich es auch nach eine Weile verstehe und ihn warten kann.

Ok und kein Problem. Solltest Du STACKABLE und DeviceIo doch noch mal sinngemäß gleichziehen wollen oder müssen, wäre es schön doch auf einen gemeinsamen Stand zu kommen, um meine Variante sterben zu lassen.
Das geht mir genauso, dass fremder Code häufig schlechter zu verstehen ist. Nach längerer Zeit auch der eigene.

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

Ich habe die Stellen angepasst

Hmm, aber nicht alle?!

Hier das diff dazu:

Code Auswählen Erweitern

--- old/fhem.pl Fri May 12 05:48:16 2017
+++ new/fhem.pl Sat May 13 10:11:10 2017
@@ -27,7 +27,7 @@
#
#  Homepage:  http://fhem.de
#
-# $Id: fhem.pl 14252 2017-05-12 05:48:17Z rudolfkoenig $
+# $Id: fhem.pl 14097 2017-04-24 11:50:40Z rudolfkoenig $


use strict;
@@ -239,7 +239,7 @@
use vars qw(@structChangeHist); # Contains the last 10 structural changes

$selectTimestamp = gettimeofday();
-$cvsid = '$Id: fhem.pl 14252 2017-05-12 05:48:17Z rudolfkoenig $';
+$cvsid = '$Id: fhem.pl 14097 2017-04-24 11:50:40Z rudolfkoenig $';

my $AttrList = "alias comment:textField-long eventMap group room ".
                "suppressReading userReadings:textField-long ".
@@ -3808,7 +3808,9 @@
                   map { $_ =~ s/.*?=//s; $_ =~ s/.*?://s; "$_:noArg" } @emList);
   }

-  my $dname = shift @{$str} if(!$dir);
+#  my $dname = shift @{$str} if(!$dir);
+  my $dname;
+  $dname = shift @{$str} if(!$dir);
   my $nstr;
   $nstr = join(" ", @{$str}) if(!$dir);

@@ -4237,14 +4239,20 @@
       } elsif($modifier eq "difference") {
         $result= $value - $oldvalue if(defined($oldvalue));
       } elsif($modifier eq "differential") {
-        my $deltav= $value - $oldvalue if(defined($oldvalue));
-        my $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
+#        my $deltav= $value - $oldvalue if(defined($oldvalue));
+        my $deltav;
+        $deltav= $value - $oldvalue if(defined($oldvalue));
+#        my $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
+        my $deltat;
+        $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
         if(defined($deltav) && defined($deltat) && ($deltat>= 1.0)) {
           $result= $deltav/$deltat;
         }
       } elsif($modifier eq "integral") {
         if(defined($oldt) && defined($oldvalue)) {
-          my $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
+#          my $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
+          my $deltat;
+          $deltat= $hash->{".updateTime"} - $oldt if(defined($oldt));
           my $avgval= ($value + $oldvalue) / 2;
           $result = ReadingsVal($name,$reading,$value);
           if(defined($deltat) && $deltat>= 1.0) {


Hat der patch nicht funktioniert?

Gruß, Ansgar.

[rudolfkoenig]

Hab diese jetzt auch geaendert.