CUNX bleibt hängen

Begonnen von lingerb, 14 Juni 2018, 14:13:27

Vorheriges Thema - Nächstes Thema

lingerb

Hallo,

ich stelle die Frage mal im Anfänger-Forum, weil ich bezüglich FHEM ein absoluter Newbie bin:

Ich habe mir kürzlich eine CUNX gekauft, um Daten unserer Techem Heizkostenverteiler zu loggen. Das funktioniert im Prinzip soweit, aber der Empfang stoppt nach einiger Zeit - nach unterschiedlicher Dauer - meist zwischen einer und vier Stunden kommen keine neuen Daten mehr an.
Jetzt ist mir aufgefallen, dass die Interne "Uhr" der CUNX auf dem Zeitpunkt stehen bleibt, an dem der Datenempfang stoppt.
Beipiel: Im device overview steht der Wert auf
Internals:
CUNX_TIME 2018-06-13 22:29:46
Das ist genau der Zeitpunkt gestern Abend, nach dem nichts mehr geloggt wurde.
Interessanterweise antwortet die CUNX nach wie vor auf get Kommandos und lässt sich auch mit
set CUNT raw B00
wieder für eine Weile anschubsen.

Zur Info:
VERSION V 2.67 CUL868
initString X21 brt

Jetzt die Frage: deutet das eher auf einen Hardware - Software - oder einen Benutzerfehler?

Grüße - Bernd

amenomade

Zitat von: lingerb am 14 Juni 2018, 14:13:27
Jetzt die Frage: deutet das eher auf einen Hardware - Software - oder einen Benutzerfehler?
Ohne weitere Infos (z.B. "list" des CUNX, Log Ausgaben bei der Zeitpunkt, wo er stehen geblieben ist, usw.) schwierig zu sagen.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Beta-User

Bist du sonst sicher, dass FHEM weitergelaufen ist (andere Devices usw.)?

Den CUL-Bereich hast du durchsucht, ob da was ähnliches berichtet wurde, nehme ich an (so wie du das rechtfertigst, dass es im Anfänger-Bereich gepostet ist).

Wie ist denn die Netzwerkverbindung zu dem CUNX? Manche seriell via Netz angebundenen Devices (sowas ist es doch, oder?) reagieren empfindlich auf Verbindungsabbrüche. "Berühmt" sind hierfür PowerLAN-Verbindungen, uU. auch WLAN (Raspberry+FritzBox?).

Bitte daher Infos zur Infrastruktur.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

lingerb

Hallo,

ok, die Infos hab ich natürlich und kann sie liefern, wollte nur nicht mit der Tür ins Haus fallen.
  * Mein FHEM läuft auf einem HPE ProLiant MicroServer Gen10, der 24/7 auch noch andere Aufgaben erledigt. Einen Fehler an dieser Stelle würde ich ausschließen.
  * Im CUL-Bereich habe ich leider nichts passendes gefunden.
  * Die CUNX hängt an einem eigenen switch port und ist permanent gut erreichbar. Auch passt meines Erachtens der Fehler nicht zur Netzwerkschicht.
  * Hier sind die lists und logs:

===
log
Internals:
   CMDS       BbCFikApZGMKUYRTVWXefmltuxEz
   CUNTX_MSGCNT 3233
   CUNTX_TIME 2018-06-13 22:29:46
   Clients    :TechemHKV:WMBUS:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        192.168.69.51:2323 0000
   DeviceName 192.168.69.51:2323
   FD         13
   FHTID      0000
   MessageEncoding CUL
   NAME       CUNTX
   NR         34
   PARTIAL   
   RAWMSG     b32446850790176416980FEDCA001FF226B03D00CB301290834080000D6B800000000025638797D11081400000000D41B000000000000000000FFFF8219
   RSSI       -61.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 2.67 CUL868
   initString X21
brt
   MatchList:
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     J:WMBUS    ^b.*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-06-13 15:43:35   ccconf          freq:868.950MHz bWidth:325KHz rAmpl:33dB sens:8dB
     2018-06-14 14:04:10   cmds             B b C F i k A p Z G M K U Y R T V W X e f m l t u x E z
     2018-06-06 21:25:42   fhtbuf          AE
     2018-06-13 22:29:46   state           Initialized
     2018-06-14 14:04:17   uptime          0 16:35:21
     2018-06-06 21:25:53   version         V 2.67 CUL868
Attributes:
   rfmode     WMBus_T


===
log
2018.06.13 21:16:37 3: set CUNTX raw B00
2018.06.13 21:16:49 1: 192.168.69.51:2323 disconnected, waiting to reappear (CUNTX)
2018.06.13 21:16:49 3: CUNTX: Unknown code assigned IP from DHCP, help me!
2018.06.13 21:16:49 3: CUNTX: Possible commands: BbCFikApZGMKUYRTVWXefmltuxEz
2018.06.13 21:16:49 2: Setting CUNTX fhtid from TMODE to 0000
2018.06.13 21:16:49 1: 192.168.69.51:2323 reappeared (CUNTX)
2018.06.13 21:16:50 3: CUNTX: Unknown code 0000, help me!
2018.06.13 21:17:58 2: WMBUS WMBUS_TCH_72163389_118_240 Error during ApplicationLayer parse:Unsupported CI Field a0, remaining payload is 009f23cb240030cb24008006000314006ba1007cb2008dc3009ed4000fe500
2018.06.13 21:21:48 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 21:29:47 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 21:37:28 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 21:44:57 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 21:46:23 2: WMBUS WMBUS_TCH_72163389_118_240 Error during ApplicationLayer parse:Unsupported CI Field a0, remaining payload is 009f23cb240030cb24008006000314006ba1007cb2008dc3009ed4000fe500
2018.06.13 21:50:25 2: WMBUS WMBUS_TCH_72163389_118_240 Error during ApplicationLayer parse:Unsupported CI Field a0, remaining payload is 009f23cb240030cb24008006000314006ba1007cb2008dc3009ed4000fe500
2018.06.13 21:52:56 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 21:53:39 3: CCURPC: CB9292 Received 500 events from CCU since last check
2018.06.13 21:53:45 3: UWZ Unwetterwarnungen: Run.1043 Done fetching data
2018.06.13 21:54:52 1: 192.168.69.51:2324 disconnected, waiting to reappear (CUNTY)
2018.06.13 21:54:56 3: CUNTY: Possible commands: mBbCFiAZGMKYRTVWXefltux
2018.06.13 21:54:56 1: 192.168.69.51:2324 reappeared (CUNTY)
2018.06.13 22:00:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 22:02:38 2: WMBUS WMBUS_TCH_72163389_118_240 Error during ApplicationLayer parse:Unsupported CI Field a0, remaining payload is 009f23cb240030cb24008006000314006ba1007cb2008dc3009ed4000fe500
2018.06.13 22:08:10 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 22:15:38 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 22:18:54 2: WMBUS WMBUS_TCH_72163389_118_240 Error during ApplicationLayer parse:Unsupported CI Field a0, remaining payload is 009f23cb240030cb24008006000314006ba1007cb2008dc3009ed4000fe500
2018.06.13 22:23:02 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 22:30:58 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 22:33:28 3: CCURPC: CB9292 Received 500 events from CCU since last check
2018.06.13 22:38:24 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 22:45:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.06.13 22:53:45 3: UWZ Unwetterwarnungen: Run.1043 Done fetching data

===
letzte Zeilen im FileLog:
2018-06-13_22:22:03 THKV_1_0226 temp2: 20.61
2018-06-13_22:22:17 THKV_1_0235 temp1: 20.94
2018-06-13_22:22:17 THKV_1_0235 temp2: 21.02
2018-06-13_22:22:24 THKV_1_0218 temp1: 20.01
2018-06-13_22:22:24 THKV_1_0218 temp2: 19.91
2018-06-13_22:25:33 THKV_1_0220 temp1: 20.09
2018-06-13_22:25:33 THKV_1_0220 temp2: 20.01
2018-06-13_22:26:04 THKV_1_0226 temp1: 19.99
2018-06-13_22:26:04 THKV_1_0226 temp2: 20.58
2018-06-13_22:26:17 THKV_1_0216 temp1: 18.75
2018-06-13_22:26:17 THKV_1_0216 temp2: 18.78
2018-06-13_22:26:32 THKV_1_0218 temp1: 20.00
2018-06-13_22:26:32 THKV_1_0218 temp2: 19.90
2018-06-13_22:27:07 THKV_1_0235 temp1: 20.94
2018-06-13_22:27:07 THKV_1_0235 temp2: 21.02
2018-06-13_22:27:12 THKV_1_0236 temp1: 21.18
2018-06-13_22:27:12 THKV_1_0236 temp2: 21.34

An dieser Stelle endet das log.
Irgendwelche Ideen?

Grüße - Bernd

lingerb

Hallo,

am Ende der angeregten Diskussion möchte ich der Vollständigkeit halber wenigstens dokumentieren, wie ich mir selber geholfen habe - falls doch nochmal jemand das gleiche Problem hat.
Ob es jetzt letztlich ein Hardware- oder ein Software-Problem ist, konnte ich nicht klären. Wenn ich das Teil in Ruhe lasse, hängt es sich nach wie vor nach einiger Zeit weg.
Als Workaround habe ich jetzt einen at job aufgesetzt, der den Empfangsmodus regelmäßig triggert:

  define Retrigger_CUNTX at +*03:00 set CUNTX raw brt

Damit läuft's jetzt durch. Danke für Euer Interesse.

Grüße
Bernd