CUL DISCONNECTED

Begonnen von AndreasS, 17 Juli 2014, 22:48:52

Vorheriges Thema - Nächstes Thema

bgewehr

Ich habe vor einiger Zeit das Update gemacht und seitdem keinen Disconnect mehr erlebt. Vielen Dank also für die gute Lösung!
FritzBox 7590, Synology DS216+II mit Docker
Docker: FHEM mit hmlan, Homebridge, node-red, mosquitto, ems-collector für Buderus EMS mit AVR Net-IO
Gartenwasser über MQTT auf R/Pi A+
Volkszaehler.org auf R/Pi 2B mit Pi_Erweiterung
Raspberrymatic auf R/Pi 4B mit RPI-RF-MOD u. CUL868

SVLoneStar

Hallo - ich habe seit einigen Tagen auch das Problem, daß sich meine nanoCULs (nicht aber mein Busware CUL...?) mehrmals täglich disconnecten.
Wird die Änderung, die in den oben angefügten '1.65+' culfw-Firmwares enthalten ist, den Weg in die nächste Release der culfw auch für nanoCULs finden?
FHEM 21222 auf Gigabyte NUC, CubieTruck & RasPis (Test)
CUL 868MHz, nanoCUL 868MHz, nanoCUL 433MHz, JeeLink Clone, JeeLink Classic, HM-CFG-USB2, Rademacher
Devices: FHT, FS20, KS300, MAX, IT, HMS100, LaCrosse, PCA301, Revolt, HomeMatic, ESA2000, UNIRoll, Sonos, Duofern, Tasmota, MySensors

sasquuatch

Zitat von: skeleton am 05 September 2015, 13:32:59
2015.09.05 13:31:39 2: COC: unknown message ERR:CCA

Zitat von: mgernoth am 05 September 2015, 14:08:54
Du hast einen Störsender, der ständig auf der Frequenz funkt, weswegen der CUL selbst nicht senden kann. Das führt jetzt zu dieser Meldung, davor zum Absturz. Nicht alle HM-Komponenten machen CCA, weswegen Du noch manche Meldungen von diesen Komponenten empfängst.

Also mal alle HM-Komponenten nacheinander deaktivieren und schauen, wer schuld ist (oder mit einem billigen rtlsdr direkt nach der Störquelle suchen).

mal eine frage, ich habe die selbe fehlermeldung und weiß ziemlich genau welcher HM (rollladen)aktor das ist. der hat mir schon zu schaffen gemacht auf meinem alten raspi mit COC. da hatte ich dann an fast allen aktoren missing ack stehen, da war das netzteil zu schwach. jetzt habe ich meine micro sd-karte in einem raspi 2 mit USB-CUL stecken und finde auf einmal neue fehlermeldungen, eben diese obige und so ziemlich jedes mal wenn ich den rollladen betätige, erhalte ich diese meldung. was kann ich da machen?
so langsam ist es anstrengend von einer Baustelle in die nächste zu rutschen :'(

2016.03.01 10:10:58.687 3: CUL_HM set Dachfenster_Rollladen_Kueche 86
2016.03.01 10:12:25.548 3: CUL_HM set Dachfenster_Rollladen_Kueche 100
2016.03.01 10:12:28.833 2: CUL: unknown message ERR:CCA
2016.03.01 10:12:53.856 3: CUL_HM set Dachfenster_Rollladen_Kueche 64
2016.03.01 10:12:58.578 2: CUL: unknown message ERR:CCA
2016.03.01 10:17:48.451 3: CUL_HM set Dachfenster_Rollladen_Kueche 100
2016.03.01 10:17:52.963 2: CUL: unknown message ERR:CCA
2016.03.01 10:23:18.947 3: CUL_HM set Rollladen_links 83
2016.03.01 10:23:20.876 3: CUL_HM set Rollladen_rechts 83
2016.03.01 10:23:44.119 3: CUL_HM set Rollladen_links 100
2016.03.01 10:23:45.375 3: CUL_HM set Rollladen_rechts 100
2016.03.01 10:24:08.310 3: CUL_HM set Kaffeemaschine on


vielleicht hat der Rollladenaktor auch mit dem folgenden Fehler zu tun
2016.03.01 03:26:08.945 2: CUL: unknown message PLL0
und wenn ich den ERR:CCA abstellen kann, ist vielleicht auch der PLL0 fehler weg :s

martin5233

Hallo,

auch ich gehöre zu denjenigen, die von diesem Problem mit den Disconnects betroffen sind. Bei mir geht leider seit ca. 2 Monaten gar nichts mehr, vorher lief meine FHEM-Installation über ca. 2 Jahre recht problemlos.  Ich setze einen Cubietruck mit FHEM 5.7 ein.
Um dem Problem auf die Spur zu kommen, habe ich diverse Dinge ausprobiert, die mich zu der Vermutung bringen, dass das Ganze etwas mit der USB-Kommunikation zu tun hat.
Ich habe den CUL bei mir an vier verschiedene Rechner angeschlossen, alle mit der identischen Linux-Kernel-Version 3.16, die derzeit in einem Debian-Stable verwendet wird.
Am Cubietruck und an einem Notebook mit Intel-Prozessor tritt das bekannte Problem auf, dass beim Senden von Kommandos sich der CUL abmeldet und anschließend wieder anmeldet. Auf zwei Desktop-Rechnern (einmal mit identischer Software-Konfiguration) tritt das Problem jedoch nicht auf. Änderungen der Linux-Kernel-Version bewirken nichts, d.h. weder mit älteren noch neueren Versionen ändert sich das beschriebene Verhalten auf allen getesteten Rechnern.
Ich habe auch die Spannungsversorgung an drei der vier Rechner nachgemessen, beim Cubietruck war die Spannung sogar am höchsten von allen dreien, daran kann es wohl also auch nicht liegen.

Meine Vermutung geht jetzt in die Richtung, dass hier irgendetwas bei der USB-Kommunikation schiefgeht, evtl. gibt es einen Timing-Zusammenhang. Ansonsten kann ich mir nicht erklären, warum das früher auf dem Cubietruck ging und heute nicht mehr. Ich habe mir mal das in der CUL-Firmware verwendete LUFA angeschaut, das für die USB-Kommunikation eingesetzt wird. In der aktuellen CUL-FW ist ein LUFA-Stand von 2009 drin, innerhalb des LUFA-Projektes sind zwischenzeitlich diverse Fehlerkorrekturen eingebaut worden. Leider sind die Änderungen im LUFA-Projekt so umfangreich, dass sich diese vermutlich nicht ohne Weiteres in die CUL-FW integrieren lassen.

Bringen all diese Beobachtungen einen von euch auf irgendwelche Ideen?

Martin  :(

rudolfkoenig

ZitatBringen all diese Beobachtungen einen von euch auf irgendwelche Ideen?
Durch welche Aenderung wurde das Problem ausgeloest?
Hilft ein culfw factory reset (e)?
Hast du die Moeglichkeit, ein weiteres CUL zu probieren?
Man koennte auch USB-debugging (usbmon/etc) porbieren, ich habe damit aber keine Erfahrung.

martin5233

Hallo Rudolph,

wodurch die Änderung ausgelöst wurde, weiß ich leider nicht. Ich hatte erst ein Linux-Kernel-Update im Verdacht, aber ich habe bereits diverse ältere Kernel installiert und auch einen aktuelleren, aber ohne Erfolg. In den Log-Files habe ich auch früher schon Meldungen bzgl. "Disconnects" gefunden, aber da hat es dann trotzdem beim zweiten oder dritten Anlauf funktioniert, sodass das nicht weiter auffiel. Das ist auch der Grund, warum ich Timing-Probleme vermute, die evtl. durch Alterungseffekte ausgelöst werden können.
Einen Factory-Reset habe ich bereits ausprobiert, einen anderen CUL habe ich leider nicht zur Verfügung. Was mich so irritiert, ist die Tatsache, dass das Problem an zwei Rechnern auftritt und an zwei anderen nicht.
usbmon habe ich ebenfalls ausprobiert: Ich habe dabei die Logs von einem funktionierendem System mit dem vom nicht funktionierendem Notebook verglichen. In der Phase des Ansteckens und Initialisierens sieht beides sehr ähnlich aus, aber wenn der CUL dann etwas senden soll, kommt via USB dann erst einmal keine Antwort zurück, erst nach ca. 2 Sekunden kommt dann ein neues Connect. Ich kann Dir gerne die Logs zukommen lassen, wenn Du damit etwas anfangen kannst.
Ich werde noch versuchen, die bisherige Erklärung auszuschließen, dass dort irgendwer den Funkkanal blockiert. Ich habe mir dazu einen USB-Stick für RTL-SDR besorgt, aber das noch nicht getestet. Ich halte das aber für extrem unwahrscheinlich, weil es ja auf einem unmittelbar neben den beiden anderen Rechnern stehenden Rechner problemlos funktioniert. Wenn eine Funkstörung vorläge, müsste die ja alle gleichmäßig betreffen.

Martin

martin5233

Hallo zusammen,

ich habe eben testweise mal einen USB-Hub (ohne eigene Stromversorgung) zwischen den CUL und den jeweiligen Rechner gehängt und siehe da: Jetzt funktioniert alles wie gewohnt. Mein Verdacht, dass das Problem mit den Disconnects an der USB-Verbindung liegt, scheint sich damit zu bestätigen. Das Ganze funktioniert sowohl an meinem Notebook, mit dem es vorher nicht klappte, als auch am Cubietruck. Jetzt lassen sich wieder sämtliche Geräte ohne irgendwelche Fehlermeldungen steuern.

Martin  ;D

bgewehr

Ich hatte immer schon einen Hub dazwischen und habe trotzdem disconnects!
FritzBox 7590, Synology DS216+II mit Docker
Docker: FHEM mit hmlan, Homebridge, node-red, mosquitto, ems-collector für Buderus EMS mit AVR Net-IO
Gartenwasser über MQTT auf R/Pi A+
Volkszaehler.org auf R/Pi 2B mit Pi_Erweiterung
Raspberrymatic auf R/Pi 4B mit RPI-RF-MOD u. CUL868

martin5233

Ich vermute mal, dass Hub nicht unbedingt gleich Hub ist. Wenn es stimmt, das die Timings vom CUL nicht ganz sauber sind, kann es ja durchaus sein, dass manche Hubs hier pingeliger als andere sind. Vielleicht kannst Du den Hub versuchsweise mal durch ein anderes Fabrikat ersetzen und gucken, ob sich etwas ändert.

Martin

bgewehr

Gibt der CUL eigentlich ein event "CUL868:disconnected" raus, wenn er "stirbt"? Ich kann in meinen Logs keins finden, obwohl er regelmäßig auf disconnected springt.
FritzBox 7590, Synology DS216+II mit Docker
Docker: FHEM mit hmlan, Homebridge, node-red, mosquitto, ems-collector für Buderus EMS mit AVR Net-IO
Gartenwasser über MQTT auf R/Pi A+
Volkszaehler.org auf R/Pi 2B mit Pi_Erweiterung
Raspberrymatic auf R/Pi 4B mit RPI-RF-MOD u. CUL868

rudolfkoenig

Das kann man doch leicht testen: Event Monitor aufrufen, CUL abstecken bzw. wieder einstecken.
Es sei denn, mit "stirbt" meint man was anderes.

bgewehr

Gut.

Ich erhalte


2016.04.24 19:08:24 1 : /dev/CUL868 disconnected, waiting to reappear (CUL868)
2016-04-24 19:08:24 CUL CUL868 DISCONNECTED


Dann CUL wieder angesteckt. Immer noch disconnected.

Was ich machen möchte, ist ein watchdog, der bei disconnect ein set CUL reopen absetzt, das klappt nämlich meistens.

Mein jetziger Watchdog ist ein


define CUL_watchdog watchdog CUL868:DISCONNECTED.* 00:00:10 CUL868:initialized set CUL868 reopen


Habt Ihr noch eine bessere Idee?
Das hat noch nicht wirklich etwas verhindert...

Elektrisch werde ich mal den HUB auswechseln, vielleicht hilft das. Allerdings habe ich den schon immer und es gab auch schon lange stabile Phasen.
FritzBox 7590, Synology DS216+II mit Docker
Docker: FHEM mit hmlan, Homebridge, node-red, mosquitto, ems-collector für Buderus EMS mit AVR Net-IO
Gartenwasser über MQTT auf R/Pi A+
Volkszaehler.org auf R/Pi 2B mit Pi_Erweiterung
Raspberrymatic auf R/Pi 4B mit RPI-RF-MOD u. CUL868

rudolfkoenig

ZitatDann CUL wieder angesteckt. Immer noch disconnected.
Ist unueblich, im Normalfall wird es nach spaetestens 5 Sekunden erkannt, und eingebunden, und ein watchdog ist eher stoerend.
Ich habe in ca 8 Jahren (mit "richtigen" CULs) solche Probleme nicht gehabt.

Elektrolurch

Zitat:
« Antwort #42 am: 24 April 2016, 20:28:20 »
Zitat
Dann CUL wieder angesteckt. Immer noch disconnected.

Leider kann ich von einem ähnlichen Effekt berichten:
Wenn ich fhem auf einem Cubie neu starte (nur fhem) dann kann es so mit ca. 30 % iger Wahrscheinlichkeit passieren, dass die CULs, die über USB angeschlossen sind, von vorne herein "disconnected" sind und auch über einen "set CUL_0 reopen" Befehl nicht mehr ins Leben gerufen werden können. Dann kann ich nur noch den Cubie koplett neu starten.
Für mich schaut das so aus, als wäre der USB-Treiber von fehm nach dem Neustart von fhem immer noch aktiv und würde so einen reconnect gelegentlich verhindern.
Macht ja von der Prozeßlogik keinen Sinn, aber eine andere Erklärung fällt mir nicht ein. Zumal die Sache nur  gelegentlich auftritt und nicht eindeutig reproduzierbar ist.

Elektrolurch
configDB und Windows befreite Zone!

rudolfkoenig

In so einem Fall muss aber im Log was stehen. Kannst du bitte pruefen, was?