CUL HM empfängt nicht oder sendet Empfangsdaten nicht an den Rechner

[tpm88]

Das vorläufige Testergebnis nach über 4 Tagen Test zeigt bisher nur bei dem ersten CUL das Problem mit dem fehlenden PLL Lock.
Der neue CUL hat als Unterschied zum ersten noch den Metall-Schirm. Da ich aber in der Nähe keine großen erkennbaren Störsender/-quellen habe, denk ich nicht, dass das den Unterschied ausmacht.

Vielleicht habe ich auf dem CUL eine "Montags" cc1101 drauf oder eine Lötstelle ist nicht ganz sauber oder ein Pufferkondensator etwas schwach... und einen Software Workaround gefunden.

Hallo Ansgar,

ich glaube (noch) nicht an deine "Montags"-CUL.

Zwischenzeitlich habe ich  jetzt auch PLLNOLOCK geloggt. Insgesamt 4x in 3 Tagen, davon je 2x mit der modifizierten CUL FW 1.59 und 2x mit der 99.60.

Code Auswählen Erweitern


2014.06.02 14:58:30.497 4: CUL_send:  CUL_HMAs 0B 19 8670 119901 000000 00CC
2014.06.02 14:58:34.255 4: CUL_Parse: CUL_HM A 0F 75 8610 220839 000000 0A98CB0E060D37 -46.5
2014.06.02 14:58:35.579 4: CUL_Parse: CUL_HM A 0F 41 8610 21DE95 000000 0A88C50F005838 -46
2014.06.02 14:59:14.963 4: CUL_Parse: CUL_HM A 0F 37 8610 21DC30 000000 0A88CF0E005831 -49.5
2014.06.02 15:00:36.894 4: CUL_Parse: CUL_HM A 0F E9 8610 21F220 000000 0A88CC09006321 -57.5
2014.06.02 15:01:06.257 4: CUL_Parse: CUL_HM A 0F 76 8610 220839 000000 0A98CB0E060D37 -46.5
2014.06.02 15:01:08.827 4: CUL_Parse: CUL_HM P LL NO LOCK   
2014.06.02 15:01:08.872 2: CUL_HM: unknown message PLLNOLOCK
2014.06.02 15:01:08.879 4: CUL_Parse: CUL_HM A 0F 42 8610 21DE95 000000 0A88C50F005838 -46
2014.06.02 15:01:22.973 4: CUL_send:  CUL_HMAs 0B 1A 8670 119901 000000 00CC
2014.06.02 15:02:17.715 4: CUL_Parse: CUL_HM A 0F 38 8610 21DC30 000000 0A88CF0E005830 -50
2014.06.02 15:02:58.145 4: CUL_Parse: CUL_HM A 0F EA 8610 21F220 000000 0A88CC09006321 -57.5
2014.06.02 15:03:23.754 4: CUL_Parse: CUL_HM A 0F 77 8610 220839 000000 0A98CB0E070D36 -47
2014.06.02 15:03:27.578 4: CUL_Parse: CUL_HM A 0F 43 8610 21DE95 000000 0A88C50F005837 -46.5
...
2014.06.03 18:40:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.8
2014.06.03 18:45:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.8
2014.06.03 18:46:00 2: CUL_HM: unknown message PLLNOLOCK
2014.06.03 18:50:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.8
2014.06.03 18:55:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.8
...
2014.06.04 10:30:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.4
2014.06.04 10:35:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.4
2014.06.04 10:38:31 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 10:38:31 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 10:40:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.4
2014.06.04 10:45:00 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.4
...
2014.06.04 20:52:22 3: ku_Switch1_off return value: OK
2014.06.04 20:52:52 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 20:52:52 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 20:53:16 0: Server shutdown


Ich habe den Umzug meines produktiven FHEM auf den RPi jetzt fast fertig. Wenn das stabil läuft, kann ich mit dem CUL auf der FB7390 künftig nach Herzenslust testen. Als nächsten Step werde ich die von Martin mit Timing versehene 00_CUL.pm aus http://forum.fhem.de/index.php/topic,24225.0.html einspielen.

Gruss
Tobias

[noansi]

Hallo Tobias,


danke für's mutige mit Testen.

Dann hat mein Workaround wohl doch seine Berechtigung, auch wenn nicht jede CUL davon betroffen zu sein scheint. Dann wäre die Mühe nicht vergebens gewesen.

Für eine Empfangsaussetzter Aussage ist es bei Dir wohl noch etwas früh, denke ich. Bei mir wirkts zumindest gut. Es besteht also Hoffnung auch für Dich.
Dann werde ich meine PLLNOLOCK Ausgabe wohl auch drin lassen. Vielleicht mache ich sie abschaltbar.

Kannst Du bitte mal get raw C99 prüfen und Deine Ausgabe hier posten zum Registervergleich.


Gruß, Ansgar.

[tpm88]

Hallo Ansgar,

hier im Vergleich meine (CUL_HM) Registerwerte zu den von dir bereits weiter oben berichteteten (CUL_0 und CUL_1):


CUL_0 raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AE2A16114100597F3E81350B00
CUL_1 raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AC2B16114100597F3E81350B00 
CUL_HM raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AD2B17114100597F3E81350B00


Kann der "Laie" aus den unterschiedlichen Registerwerten etwas herauslesen?

Gruss
Tobias

PS: Die von Martin angepasste 00_CUL.pm mit Timing habe ich seit gestern auch in Betrieb. Ein Update der gesamten FHEM Installation war aus meiner Sicht bisher nicht notwendig. Die Kombination läuft mit deiner CUL FW 99.60 bisher ohne Auffälligkeiten.

[noansi]

Hallo Tobias,


mich interessieren die Registerwerte nur in sofern, als es interessant gewesen wäre, ein auffälliges Verhalten für weniger PLL-stabile CULs zu erkennen. Aber es sieht nicht danach aus. Die Register sind auch in der Chip-Doku nicht im Detail beschrieben.
Vielleicht sind manche Transceiver bei der Abstimmung nahe an der Grenze zwischen verschiedenen Einstellungen und kippen dann über Temperatur und Spannungsschwankungen, während andere satt mitten in ener Einstellung liegen und dann stabil mit PLL Lock laufen? Aber das ist nur eine schwache Vermutung.
Bei meiner Problem CUL ändern sich die Werte schon mal mit der Rekalibrierung nach einem PLLNOLOCK Event.

Da die Chipdoku aber empfiehlt, den PLL-Lock Zustand vor Senden und Empfang zu prüfen, was bisher in der Firmware 1.58 nicht drin war, bewegen wir uns nicht in einem fehlerhaften Verhalten.

Bei mir sieht der Test mit TimeStamp Firmware und Test 00_CUL auch gut aus. Resends sehe ich nur noch ganz selten. Und die können durch zeitfressende Aktionen anderer Module verursacht sein, so dass es nicht mehr möglich ist eine Ack Nachricht rechtzeitig auf den Weg zu bringen. Apptime gibt Hinweise dazu mit mittleren und maximalen Ausführungszeiten. Sendefehler habe bei nunmehr über 600 Sendeevents nicht gesehen.

Es bringt übrigens nichts, die Test 00_CUL mit einer älteren Firmware zu testen, da dann im besten Fall nichts passiert und bei Test der älteren Varianten der Empfang wegen des unbekannten Einschaltbefehls zur "Strafe" abgeschaltet wird. 


Gruß, Ansgar

[tpm88]

Hallo Ansgar,

deine PLLNOLOCK Erweiterungen zur CUL-Firmware haben bei mir definitiv die Stabilität verbessert. Vorher mit CUL FW 1.58 hatte ich häufig schlagartig Komplettausfälle (kein Empfang, kein Senden mehr möglich) der CUL Kommunikatiotion. Der ActionDetector meldet dann den gleichzeitigen Ausfall meiner 4 HM Thermostate. Hier alle Ausfälle vom Mai:

Code Auswählen Erweitern

2014-05-04_13:03:47 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-07_09:10:49 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-08_16:11:42 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-08_22:51:50 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-12_10:57:21 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-14_07:17:49 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-20_03:37:23 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-20_19:57:32 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-28_21:12:27 ActionDetector alive:0 dead:4 unkn:0 off:0


Meist hat es dann zwischen einer und mehreren Stunden gedauert, bis die Kommunikation plötzlich wieder funktioniert hat. Seit 29.05. teste ich jetzt die CUL-Firmware mit den PLLNOLOCK Erweiterungen von noansi. Seitdem hat der ActionDetektor keinen einzigen Ausfall mehr registriert. Die PLLNOLOCK Routine wurde seither einige Mal aufgerufen:

Code Auswählen Erweitern

# grep -i pll fhem-2014-06.log
2014.06.02 15:01:08.872 2: CUL_HM: unknown message PLLNOLOCK
2014.06.03 18:46:00 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 10:38:31 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 10:38:31 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 20:52:52 2: CUL_HM: unknown message PLLNOLOCK
2014.06.04 20:52:52 2: CUL_HM: unknown message PLLNOLOCK
2014.06.09 09:03:52.392 2: CUL_HM: unknown message PLLNOLOCK
2014.06.10 08:22:44.579 2: CUL_HM: unknown message PLLNOLOCK
2014.06.11 00:14:16.083 2: CUL_HM: unknown message PLLNOLOCK
2014.06.11 14:17:02.237 2: CUL_HM: unknown message PLLNOLOCK


Die in v1.61 ebenfalls eingebaute Timingfunktionalität für CUL hat zusammen mit der von Martin hierfür modifizierten 00_CUL.pm zu messbar (HMinfo protoEvents Auswertung) weniger HomeMatic Resends bei meiner Konfiguration gesorgt. Vom Gefühl tragen die Timinganpassungen gerade für meine langsame Plattformen FritzBox7390 deutlich zur Stabilität von HM mit CUL bei.

Probleme (Senden) hatte ich nur mit CUL FW v1.59 (siehe mein Beitrag vom 01.06. hier)

Bitte beide Erweiterungen unbedingt in das FHEM Repository aufnehmen.

Gruss
Tobias

[noansi]

Hallo Leute,


Rudolf hat mit der Version 1.59 der CUL Firmware heute die Änderungen bezüglich PLL Lock Problematik für AskSin eingecheckt.

Damit sollte das ursprüngliche Problem dieses Threads mit Homematik Aussetzern bei Empfang und Versand nun gelöst sein.

Die Meldung im Hauptlog, falls das PLL Lock Problem erkannt wurde (und die CUL auf verbose 2 eingestellt ist) lautet nun "PLL0" statt "PLLNOLOCK". Das ist nur ein Hinweis und mit der Rekalibrierung, die dann erfolgt, sollte der Tranceiver wieder in den Tritt kommen.

Falls die dann versuchte Rekalibrierung scheitert erscheint zusätzlich "PLL1".

Wenn "PLL1" abwechselnd mit "PLL0" in kurzen Abständen wiederholt auftaucht, dann ist was faul mit der Hardware, wenn ich meine "Problem" CUL mal als Maßstab nehmen darf. "PLL1" ist noch nicht vorgekommen. Dafür pro Tag bis zu 10 mal "PLL0" in wechselnden Zeitabständen.


Gruß, Ansgar.

PS: Noch nicht drin ist die TimeStamp Option. Damit habe ich noch etwas Arbeit.