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

Adimarantis

Hi Ansgar,

Bitte (erst auf 98, dann nochmal auf 99) - ich sehe bei 99 aber keine Fehler im Device, er bleibt aber nach wie vor auf 98.
Wenns ein HW Problem ist, dann war der Wechsel ja ok. Der eine Use Case braucht nie mehr als 25%.
@frank: Adaptierfahrten hab ich seitdem ich das Problem festgestellt habe, schon des öfteren gemacht. Das ändert nichts.

Jörg

2021.01.17 16:07:45 4: TSCUL_Write: CUL_TS sending As0B92A2581122141123B803FA
2021.01.17 16:07:45 4: TSCUL_send:  CUL_TS  214264                 As 0B 92 A258 112214 1123B8 03FA
2021.01.17 16:07:45 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:1178
2021.01.17 16:07:45 4: TSCUL_Parse: CUL_TS  14894369 A F503 00779212 01 0B 92 A258 112214 1123B8 03FA _CCAdly:4
2021.01.17 16:07:45 4: TSCUL_Parse: CUL_TS  14894503 A F501 00779372 00 0E 92 8202 1123B8 112214 0101341031 -53.5dB
2021.01.17 16:10:30 4: TSCUL_Write: CUL_TS sending As0B93A2581122141123B800FA
2021.01.17 16:10:30 4: TSCUL_send:  CUL_TS  379041                 As 0B 93 A258 112214 1123B8 00FA
2021.01.17 16:10:30 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:1178
2021.01.17 16:10:30 4: TSCUL_Parse: CUL_TS  15059145 A F403 00943992 01 0B 93 A258 112214 1123B8 00FA _CCAdly:4
2021.01.17 16:10:30 4: TSCUL_Parse: CUL_TS  15059278 A F401 00944148 00 0E 93 8202 1123B8 112214 0101C40032 -53.5dB
2021.01.17 16:10:30 4: TSCUL_Write: CUL_TS sending As0994A1124444441123B8
2021.01.17 16:10:30 4: TSCUL_send:  CUL_TS  379265                 As 09 94 A112 444444 1123B8
2021.01.17 16:10:30 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2340
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15059753 A F403 00944244 01 09 94 A112 444444 1123B8  _CCAdly:4 _dhmSt:96
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15059753 A F401 00944396 00 0A 94 8002 1123B8 444444 00 -53.5dB
2021.01.17 16:10:31 4: TSCUL_Write: CUL_TS sending As1095A0014444441123B800040000000000
2021.01.17 16:10:31 4: TSCUL_send:  CUL_TS  379740                 As 10 95 A001 444444 1123B8 00040000000000
2021.01.17 16:10:31 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2347
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15059873 A F403 00944692 01 10 95 A001 444444 1123B8 00040000000000 _CCAdly:4 _dhmSt:296
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15060124 A F403 00944968 01 10 95 A001 444444 1123B8 00040000000000 _CCAdly:4 _dhmSt:572
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15060256 A F401 00945128 00 14 95 8010 1123B8 444444 0202010A440B440C440000 -53dB
2021.01.17 16:10:31 4: TSCUL_Write: CUL_TS sending As0B96A0014444441123B80103
2021.01.17 16:10:31 4: TSCUL_send:  CUL_TS  380252                 As 0B 96 A001 444444 1123B8 0103
2021.01.17 16:10:31 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2342
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15060376 A F403 00945224 01 0B 96 A001 444444 1123B8 0103 _CCAdly:4 _dhmSt:96
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15060511 A F401 00945384 00 13 96 8010 1123B8 444444 0111221401000000002D -53.5dB
2021.01.17 16:10:32 4: TSCUL_Write: CUL_TS sending As1097A0014444441123B801040000000005
2021.01.17 16:10:32 4: TSCUL_send:  CUL_TS  380516                 As 10 97 A001 444444 1123B8 01040000000005
2021.01.17 16:10:32 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2347
2021.01.17 16:10:32 4: TSCUL_Parse: CUL_TS  15060727 A F403 00945480 01 10 97 A001 444444 1123B8 01040000000005 _CCAdly:4 _dhmSt:96
2021.01.17 16:10:33 4: TSCUL_Parse: CUL_TS  15061956 A F401 00945636 00 10 97 8010 1123B8 444444 0209000A630000 -53.5dB
2021.01.17 16:13:00 4: TSCUL_Write: CUL_TS sending As0B94A2581122141123B803FD
2021.01.17 16:13:00 4: TSCUL_send:  CUL_TS  005015                 As 0B 94 A258 112214 1123B8 03FD
2021.01.17 16:13:00 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:1178
2021.01.17 16:13:00 4: TSCUL_Parse: CUL_TS  15209408 A F303 01094256 01 0B 94 A258 112214 1123B8 03FD _CCAdly:4
2021.01.17 16:13:01 4: TSCUL_Parse: CUL_TS  15209541 A F301 01094412 00 0E 94 8202 1123B8 112214 0101C41032 -53.5dB
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,

Zitatich sehe bei 99 aber keine Fehler im Device
motorErr blocked hätte bei 99% eigentlich beim 14er VD angezeigt werden müssen.

Von 26% auf 98% ist der 14er ohne Murren gefahren.

@Frank: solltest Du heute ein Update von CUL_HM und HMInfo fahren wollen, dann beobachte, ob Deine virtuellen TCs anlaufen. Da lauert ein Bug mit den Peer Namen (_chn-01), wie ich beim Umsetzen auf meine Version bemerkt habe, so dass ein virtueller TC nicht mehr checken kann, dass er mit einem VD gepeert ist und daher gar nicht mehr zum virtuellen TC werden kann.

Gruß, Ansgar.

frank

Zitat@frank: Adaptierfahrten hab ich seitdem ich das Problem festgestellt habe, schon des öfteren gemacht. Das ändert nichts.
beim adaptieren ist:
A1 zurückfahren
A2 total zurückgefahren, warten auf tasterdruck
A3 rausfahren, um die punkte 100% und 0% zu ermitteln.

wie weit ist der stössel bei A2 zurückgefahren?
fährt er vielleicht nicht mehr ganz zurück?


motorErr:
kleine abweichungen werden hier nicht gemeldet, nur die fehler codes F1-3, die auch im display zu sehen sind (siehe BA).

operState: hier steht dann etwa "target not met" und
operStateErrCnt: zählt hoch.



Zitat@Frank: solltest Du heute ein Update von CUL_HM und HMInfo fahren wollen,
vielen dank für den hinweis.  8)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

noansi

Hallo Frank,

Zitatkleine abweichungen werden hier nicht gemeldet, nur die fehler codes F1-3, die auch im display zu sehen sind (siehe BA).
das ist in Jörgs Log zum 14er (Firmware 1.4) zu sehen:
2021.01.17 14:46:17 4: TSCUL_send:  CUL_TS  044991                 As 0B 72 A258 112214 1123B8 03FD
2021.01.17 14:46:17 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:1178
2021.01.17 14:46:17 4: TSCUL_Parse: CUL_TS  10006503 A F103 03115380 01 0B 72 A258 112214 1123B8 03FD _CCAdly:4
2021.01.17 14:46:18 4: TSCUL_Parse: CUL_TS  10006636 A F101 03115540 00 0E 72 8202 1123B8 112214 0101C41230 -51.5dB
2021.01.17 14:49:16 4: TSCUL_Write: CUL_TS sending As0B73A2581122141123B800FD
2021.01.17 14:49:16 4: TSCUL_send:  CUL_TS  223257                 As 0B 73 A258 112214 1123B8 00FD
2021.01.17 14:49:16 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:1178
2021.01.17 14:49:16 4: TSCUL_Parse: CUL_TS  10184770 A F103 03293648 01 0B 73 A258 112214 1123B8 00FD _CCAdly:4
2021.01.17 14:49:16 4: TSCUL_Parse: CUL_TS  10184911 A F101 03293808 00 0E 73 8202 1123B8 112214 0101C4022F -52.5dB

Laut CUL_HM Code wird aus 0xC4=196 => 98% und aus 0x12 -> motor:opening/motorErr:blocked bzw. 0x02 -> motor:stop/motorErr:blocked, demnach F1(?).

Gruß, Ansgar.

Adimarantis

Zitat von: frank am 17 Januar 2021, 17:02:10
wie weit ist der stössel bei A2 zurückgefahren?
fährt er vielleicht nicht mehr ganz zurück?
Ganz schwer zu sagen. Ich spüre den Unterschied von 1% zumindest nicht :) Kam mir zumindest ok vor.

@Ansgar: Einen Übeltäter gibt es in meinem Produktivsystem auf jeden Fall noch: Ich rufe für einen über SPI angesteuerten Sensor ein C-Programm auf - und das hat auch usleeps drin. Nach intensiven Kämpfen in Perl mit pack/unpack eine ioctl Struktur aufzubauen und mit dem Sensor zu kommunizieren, habe ich das gestern Abend endlich geschafft. Da werde ich jetzt bei Gelegenheit ein einfaches Modul auf Basis meines ADS-Moduls bauen.
Richtig Schick wäre ja ein SPI Modul das kompatibel zum I2C Modul funktioniert. Der ADS hat eine SPI Variante (ADS1118) und z.B. der BME280 geht sowohl als auch. Das müsste man eigentlich transparent bauen können, so dass man nur die IODevice austauschen muss (naja, die Funktion i2cwrite würde halt bei SPI weiter i2c heissen müssen). Aber ich denke das überfordert meine Perl Kenntnisse momentan noch :)

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

frank

so sah letztens ein echtes blockieren bei mir aus, F1 im display:

2021.01.06 11:38:09.776 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8531CFAA d:FF r:FFD9     m:69 A258 B3B3B3 193A9A 00FD
2021.01.06 11:38:09.928 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8531D02D d:FF r:FFC5     m:69 8202 193A9A B3B3B3 0101C6003F
2021.01.06 11:45:45.381 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8538C397 d:FF r:FFD9     m:6C A258 B3B3B3 193A9A 00FD
2021.01.06 11:45:45.526 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8538C41A d:FF r:FFC5     m:6C 8202 193A9A B3B3B3 0101C6003F
2021.01.06 11:53:19.232 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:853FB0AB d:FF r:FFD9     m:6F A258 B3B3B3 193A9A 00FD
2021.01.06 11:53:19.380 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:853FB12E d:FF r:FFC5     m:6F 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:00:51.343 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:854696E8 d:FF r:FFD9     m:72 A258 B3B3B3 193A9A 00FD
2021.01.06 12:03:14.540 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8548C65B d:FF r:FFD9     m:73 A258 B3B3B3 193A9A 00FD
2021.01.06 12:03:14.698 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8548C6DE d:FF r:FFC5     m:73 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:11:05.387 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:854FF5DA d:FF r:FFD9     m:76 A258 B3B3B3 193A9A 00FD
2021.01.06 12:11:05.537 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:854FF65D d:FF r:FFC4     m:76 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:17:50.488 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8556247A d:FF r:FFD9     m:79 A258 B3B3B3 193A9A 00FD
2021.01.06 12:17:50.640 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:855624FE d:FF r:FFC4     m:79 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:25:37.839 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:855D464B d:FF r:FFD9     m:7C A258 B3B3B3 193A9A 00FD
2021.01.06 12:25:37.988 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:855D46CE d:FF r:FFC5     m:7C 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:30:41.446 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8561E79D d:FF r:FFD9     m:7E A258 B3B3B3 193A9A 03FD
2021.01.06 12:30:41.449 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8561E821 d:FF r:FFC3     m:7E 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:38:04.343 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8568AAB1 d:FF r:FFD9     m:81 A258 B3B3B3 193A9A 00FD
2021.01.06 12:38:04.489 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8568AB35 d:FF r:FFC3     m:81 8202 193A9A B3B3B3 0101C6003E
2021.01.06 12:46:29.444 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85705FFD d:FF r:FFD9     m:84 A258 B3B3B3 193A9A 03F8
2021.01.06 12:46:29.599 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85706080 d:FF r:FFC3     m:84 8202 193A9A B3B3B3 0101C6203E
2021.01.06 12:48:48.897 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:857280CB d:FF r:FFD9     m:85 A258 B3B3B3 193A9A 03F0
2021.01.06 12:48:49.053 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8572814E d:FF r:FFC2     m:85 8202 193A9A B3B3B3 0101C2203E
2021.01.06 12:53:48.809 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85771470 d:FF r:FFD8     m:87 A258 B3B3B3 193A9A 03DE
2021.01.06 12:53:48.969 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:857714F3 d:FF r:FFC2     m:87 8202 193A9A B3B3B3 0101BC203E
2021.01.06 12:58:54.960 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:857BC07D d:FF r:FFD9     m:89 A258 B3B3B3 193A9A 03CF
2021.01.06 12:58:55.118 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:857BC100 d:FF r:FFC3     m:89 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:01:06.402 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:857DC207 d:FF r:FFD8     m:8A A258 B3B3B3 193A9A 03C7
2021.01.06 13:04:07.352 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:858084F3 d:FF r:FFD9     m:8B A258 B3B3B3 193A9A 03C0
2021.01.06 13:04:07.500 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85808576 d:FF r:FFC3     m:8B 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:09:26.006 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:858561DB d:FF r:FFD8     m:8D A258 B3B3B3 193A9A 03B8
2021.01.06 13:09:26.164 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8585625D d:FF r:FFC3     m:8D 8202 193A9A B3B3B3 0101BC2241
2021.01.06 13:11:43.743 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85877BD4 d:FF r:FFD8     m:8E A258 B3B3B3 193A9A 03AE
2021.01.06 13:16:39.886 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:858C00D1 d:FF r:FFD8     m:90 A258 B3B3B3 193A9A 03A6
2021.01.06 13:16:40.035 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:858C0154 d:FF r:FFC3     m:90 8202 193A9A B3B3B3 0101BC223F
2021.01.06 13:21:42.266 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85909E36 d:FF r:FFD8     m:92 A258 B3B3B3 193A9A 039E
2021.01.06 13:21:42.429 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85909EB8 d:FF r:FFC4     m:92 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:26:51.160 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85955500 d:FF r:FFD8     m:94 A258 B3B3B3 193A9A 0397
2021.01.06 13:26:51.376 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85955583 d:FF r:FFC5     m:94 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:32:06.311 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:859A2437 d:FF r:FFD8     m:96 A258 B3B3B3 193A9A 038F
2021.01.06 13:32:06.469 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:859A24BB d:FF r:FFC4     m:96 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:36:23.717 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:859E11D0 d:FF r:FFD8     m:98 A258 B3B3B3 193A9A 0385
2021.01.06 13:36:23.878 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:859E1253 d:FF r:FFC4     m:98 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:44:13.564 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85A53D69 d:FF r:FFD8     m:9B A258 B3B3B3 193A9A 0085
2021.01.06 13:44:13.727 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85A53DEB d:FF r:FFC4     m:9B 8202 193A9A B3B3B3 0101BC023E
2021.01.06 13:46:21.293 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85A7304F d:FF r:FFD8     m:9C A258 B3B3B3 193A9A 037D
2021.01.06 13:52:01.665 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85AC6229 d:FF r:FFD8     m:9E A258 B3B3B3 193A9A 0375
2021.01.06 13:52:01.828 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85AC62AC d:FF r:FFC4     m:9E 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:59:48.020 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85B38014 d:FF r:FFD8     m:A1 A258 B3B3B3 193A9A 036B
2021.01.06 13:59:48.181 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85B38097 d:FF r:FFC4     m:A1 8202 193A9A B3B3B3 0101BC223E
2021.01.06 14:07:32.618 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85BA9726 d:FF r:FFD8     m:A4 A258 B3B3B3 193A9A 0363
2021.01.06 14:07:32.776 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85BA97A8 d:FF r:FFC4     m:A4 8202 193A9A B3B3B3 0101BC223E
2021.01.06 14:09:38.574 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85BC8335 d:FF r:FFD8     m:A5 A258 B3B3B3 193A9A 0359
2021.01.06 14:15:15.218 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85C1A667 d:FF r:FFD8     m:A7 A258 B3B3B3 193A9A 0059
2021.01.06 14:15:15.384 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85C1A6EB d:FF r:FFC5     m:A7 8202 193A9A B3B3B3 0101BC023E
2021.01.06 14:22:56.070 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85C8AED4 d:FF r:FFD8     m:AA A258 B3B3B3 193A9A 034F
2021.01.06 14:22:56.238 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85C8AF57 d:FF r:FFC5     m:AA 8202 193A9A B3B3B3 0101BC223E
2021.01.06 14:28:16.470 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85CD928C d:FF r:FFD8     m:AC A258 B3B3B3 193A9A 0347
2021.01.06 14:28:16.627 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85CD930F d:FF r:FFC5     m:AC 8202 193A9A B3B3B3 0101BC223E
2021.01.06 14:30:35.209 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85CFB06E d:FF r:FFD8     m:AD A258 B3B3B3 193A9A 0345
2021.01.06 14:35:33.079 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85D43C3F d:FF r:FFD8     m:AF A258 B3B3B3 193A9A 0045
2021.01.06 14:35:33.247 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85D43CC2 d:FF r:FFC4     m:AF 8202 193A9A B3B3B3 0101BC023E
2021.01.06 14:42:47.934 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85DADF1A d:FF r:FFD8     m:B2 A258 B3B3B3 193A9A 0045
2021.01.06 14:42:48.206 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85DADF9D d:FF r:FFBD     m:B2 8202 193A9A B3B3B3 0101FE064B


in der letzten message nach einem adaptierungsversuch hat er dann F3 (adjusting range too small) gemeldet.

ich musste den vd komplett auseinanderschrauben, da der stössel zu weit reingefahren war.
so ein totalausfall hatte ich das erste mal.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

noansi

Hallo Frank,

2021.01.06 12:58:55.118 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:857BC100 d:FF r:FFC3     m:89 8202 193A9A B3B3B3 0101BC223E
Hier hat er schon angefangen mit 0x22 Blockade (von 94% auf 87%) zu melden. Hat Dein Ventil da eventuell mechanisch gehangen?
Das würde zumindest den zu kleinen Einstellbereich nach der Adaptierfahrt mit erklären. (natürlich nicht, dass er sich dann auch noch intern fest fährt)

Lustig die Meldung des Öffnungsgrads in der letzten Zeile. 0xFE entspräche 127%, soll aber wohl eher FEhler bedeuten, könnte ich mir vorstellen.

Apropos Ventil Schwergängigkeit, machst Du in FHEM regelmäßig eine "Entkalkungsfahrt", wie es der reale TC laut Anleitung wohl machen würde?

Gruß, Ansgar.

noansi

Hallo Jörg,

ZitatDas müsste man eigentlich transparent bauen können, so dass man nur die IODevice austauschen muss (naja, die Funktion i2cwrite würde halt bei SPI weiter i2c heissen müssen). Aber ich denke das überfordert meine Perl Kenntnisse momentan noch
Eventuell kannst Du Dir auch noch Anregungen aus dem 97_PiXtendV2.pm Modul zu SPI holen. Da sieht's nach SPI Kommunikation aus + noch mehr.

Gruß, Ansgar.

Adimarantis

Hi Ansgar,

Zwischenstand mit hmAgcMaxDVGA = 0, ich schalte jetzt mal auf  =2 um.


    Device          receive         from             last   avg      min_max    count
    HM_VD_14        CUL_TS          HM_VD_14         -55.5  -55.5  -56.5< -52.5   468
    HM_VD_14        HM_VD_14        CUL_TS           -52.0  -51.7  -52.0< -48.0   468
    HM_VD_20        CUL_TS          HM_VD_20         -47.0  -46.9  -48.5< -46.0   449
    HM_VD_20        HM_VD_20        CUL_TS           -46.0  -46.1  -48.0< -45.0   449

    name     :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    HM_VD_14 : done           |  -       | 484      |  -       #  -       | 15       |  -       |  -       
    HM_VD_20 : done           |  -       | 477      |  -       #  -       | 26       |  -       |  -       
=======================================================================================================
    sum      0                |0         |961       |0         #0         |41        |0         |0     


Was mir aufgefallen ist: Er verliert irgendwie Registerinfos.


missing register list
    HM_VD_14: RegL_00.,RegL_05.
    HM_VD_20: RegL_00.,RegL_05.

PairedTo missing/unknown
    HM_VD_14:
    HM_VD_20:


Nach einem getConfig passt es dann wieder. Sofort nach dem ändern von hmAgcMaxDVGA und "clear all" vom hminfo wieder das selbe.

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,

hast Du auch noch gleichzeitig an der Antennenposition oder am Offset gedreht? Die RSSI Werte sind zwischen den beiden "gewandert".
Prozentual ist es insgesamt bei beiden etwas schlechter geworden.

ZitatWas mir aufgefallen ist: Er verliert irgendwie Registerinfos.
Wie hast Du das Attribut autoReadReg jetzt bei den beiden stehen?
Bei >= 5 wäre das so wohl gewollt bei clear all, warum auch immer.

Gruß, Ansgar.

Adimarantis

Hallo Ansgar,

Offset ist gleich, aber die beiden Ventile haben die Plätze getauscht (wegen dem 99% Fehler). Beide sind sehr nah an der CUL (ca. 1.5m und 3.5m).
autoReadReg ist auf default - beide Ventile auf 4.

Die aktuelle Versuchsreihe mit hmAgcMaxDVGA=2 läuft übrigens soweit etwas besser. Erst in Summe 6 fails auf 248 Sends. Mein SPI Modul ist jetzt übrigens soweit nutzbar und läuft (Source auch unter meinem GitHub).

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,

ZitatautoReadReg ist auf default - beide Ventile auf 4.
Ok, das clear all sorgt aber dafür, dass die Register Listen gelöscht werden (immer noch, wofür auch immer).

ZitatDie aktuelle Versuchsreihe mit hmAgcMaxDVGA=2 läuft übrigens soweit etwas besser. Erst in Summe 6 fails auf 248 Sends.
Gib dem was mehr Zeit vor dem Hoffnungsschimmer.
Wenn's weiter besser ausschaut, kannst Du natürlich auch die 3 noch testen. Die Empfindlichkeit sinkt damit zwar, aber Du willst ja nur auf kurze Distanz empfangen.

Gruß, Ansgar.

frank

hi ansgar,

ZitatHier hat er schon angefangen mit 0x22 Blockade (von 94% auf 87%) zu melden. Hat Dein Ventil da eventuell mechanisch gehangen?
Das würde zumindest den zu kleinen Einstellbereich nach der Adaptierfahrt mit erklären. (natürlich nicht, dass er sich dann auch noch intern fest fährt)
das war schon ein echtes blockieren, würde ich meinen, da nach dem entfernen des vd beim drücken auf den ventilstift ein einmaliges "rucken" zu spüren war.
das ventil ist auch noch eines der ältesten, vielleicht 20 jahre alt.

ZitatApropos Ventil Schwergängigkeit, machst Du in FHEM regelmäßig eine "Entkalkungsfahrt", wie es der reale TC laut Anleitung wohl machen würde?
das hatte ich anfänglich überlegt.
doch dann gab es einen thread, in dem viele von hängen gebliebenen ventilen beim rt während der entkalkungsfahrt berichtet haben. damit war die idee erst einmal gestorben.



macht es eigentlich sinn, tsculfw auch mit martins "original" dateien zu nutzen?
mich würde nämlich die möglichkeit der frequenzanpassung für homematic interessieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

noansi

Hallo Frank,

Zitatmacht es eigentlich sinn, tsculfw auch mit martins "original" dateien zu nutzen?
mich würde nämlich die möglichkeit der frequenzanpassung für homematic interessieren.

Gute Frage. Da ich es nicht teste, kann ich Dir nichts direktes zu Nebenwirkungen nach den letzten Ständen sagen.

Ich habe allerdings Optimierungen für CULs eingebaut und Martin hat nicht alles bezüglich TSCUL übernommen.
Insbesondere, dass zum FHEM Start die schon im CUL hinterlegten devices ausgelesen und nicht glöscht werden, was bei den CULs mit wenig Speicher zu weniger EEPROM Verschleiß führen soll, da auf denen das EEPROM als Speicher herhalten muss. Das betrifft nanoCULs und CUL V3/V4, um die wesentlichen zu nennen.
Außerdem habe ich die IO Zuteilung nach RSSI geändert, insbesondere mit einstellbarer switch Hysterese, um unnötige IO Umschaltung für solche CULs minimieren zu können.

Für virtuelle THs Sensoren, die nur einen peer haben, wird auch eine dynamische IO Zuweisung nach RSSI gemacht.

Virtuelle THs und TCs sind etwas anders im Sendeverhalten, wie Du ja schon mitbekommen hast.

Bei RTs werden logisch unnötige Reading Updates nicht mehr durchgeführt (auch beim Weather Channel wird die Temperatur noch raus fliegen).
Grundsätzlich bevorzuge ich den state (und lst) update zuletzt nach allen anderen Readings (und das auch mit Timer leicht verzögert), so dass das state event meist auch anzeigt, dass alle anderen Readings schon aktualisiert wurden und damit aktuell direkt aus dem device gelesen werden können, statt mehrere Events zu aktivieren und verarbeiten zu müssen.

Und viele Kleinigkeiten mehr, wenn mir was auffällt oder im Forum was auffällt. Die letzte Änderung von Martin ist noch nicht in dem enthalten, was Du hier findest. Es ist schwierig, einen Überblick zu bekommen, wo welche Namensvariante verwendet wird/wurde/werden muss, um das gerade zu ziehen.

Feedback zur Nutzung mit Standard CUL_HM fehlt hier (sicherlich weil ich ja auch darauf hinweise, meine Variante zu nutzen).
Probier es halt (kontrolliert) aus und berichte. Allerdings musst Du Dich mit Änderungswünschen an der Standard CUL_HM letztlich an Martin wenden. Ich kann dann nur versuchen zur Problemaufklärung beizutragen. Im Code umsetzen muss es Martin.

Gruß, Ansgar.

Adimarantis

So, Testreihe mit den verschiedenen hmAgcMaxDVGA settings abgeschlossen.
Nach dieser Reihe hat der Wert =2 leicht die Nase vorn - die Daten basieren allerdings auf weniger Sends als bei den anderen. Ich stelle das jetzt mal ein und lasse es so über länger laufen.
Alles in allem sind die Werte aber nicht so unterschiedlich, wobei "0" und "3" schon sichtbar schlechter sind.

Details siehe Textfile.

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)