CUN disconnected

[KlausB]

FW Stand 1.49
Nach ein paar Tagen Laufzeit "verabschiedet" sich mein CUN. Ethernet LED = an. Kommunikations-LED = blinkt und es werden scheinbar (siehe unregelmäßiges blinken) auch Pakete von Devices empfangen. Aber trotzdem ist der Status = disconnected. "get MyCUN raw V" geht auch nicht mehr.

Behebung: CUN kurz stromlos gemacht und schon läuft er wieder (für ein paar Tage). Shutdown restart fhem bzw. rereadcfg ist nicht notwendig.
N.B. Es gab im vergangenen Jahr schon einige Threads dazu, aber eine Lösung des Problems war mir nicht ersichtlich.

Ideen?

Gruß
Klaus

[Elektron]

Hallo zusammen,

Ich habe das gleiche Problem, zumindest im Winter...
...seitdem ich die Heizung ausgemacht habe und alle FHTs auf Solltemperatur OFF gestellt habe, ist Ruhe.
Seit Wochen läuft mein CUN durch.

Symptom bei mir: LED auf der Platine dauerhaft an oder aus, auf jeden Fall ohne Bewegung. CUN nicht mehr per Netzwerk erreichbar, das Status in FHEM geht auf Opened und das wars.
Neustarten über Abschalten der Betriebsspannung hilft manchmal, wenn ich Pech habe ist das Ding so am Ende, dass ich die Firmware neu flashen muss.
Diverse Standorte und Netzteile ausprobiert um Einflüsse durch EMV auszuschließen...

Schade ist, dass es für den "alten CUN" keine aktuelle Firmware gibt.
@Rudolph evtl. Kannst Du die aktuelle Firmware mal für den alten CUN mit dem alten Compiler übersetzen? Wäre super!


Viele Grüße
Michael

[rudolfkoenig]

> @Rudolph evtl. Kannst Du die aktuelle Firmware mal für den alten CUN mit dem alten Compiler übersetzen?

Funktioniert die letzte Version (von mgernoth) nicht?

Er hat es mWn mit dem letzten Compiler (4.7.2) uebersetzt, der bei RFR nicht mehr die Probleme der Version 4.6.2 (was ich als "neuer Compiler" bezeichnet habe) zeigt.

Mehr kann ich leider nicht tun, da ich kein CUNO habe.
Und ich will auch keins, sonst haette ich diese schoene Ausrede nicht :)

[Elektron]

Hi Rudolph,

Ich werde das in kürze ausprobieren, bin das Wochenende aber nicht zuhause.
Ich weiß nicht ob das eineUnterschied macht, aber ich sprach von einem CUN ohne O...

Viele Grüße
Michael

PS.: gibts denn in der aktuellen Version Verbesserungen die in diesem Thema hefen könnten?

Vielen Dank und Grüse
Michael

[rudolfkoenig]

>  PS.: gibts denn in der aktuellen Version Verbesserungen die in diesem Thema hefen könnten?

Das wuerde mich stark wundern.

[Elektron]

Hallo Rudolf,

Nach einiger Zeit und mehreren Änderungen meiner Installation ist der Fehler immer noch da...
Hier einige Details, evtl hast Du oder sonst jemand eine Idee...

- FHEM umgezogen von Dockstar auf RaspberryPi
- Firmware auf CUN (ohne O) auf 1.55 geupdated.

Was mir aufgefallen ist:

- Als ich an den FHTs die Heizung ausgeschaltet hatte, hielt das CUN sehr lange ohne Absturz durch.
- Seit dem die Heizkörper wieder an sind, (2 Tage) X Abstürze gehabt...

Wie sieht der Absturz aus:

- Netzwerk LED an, (an RJ45-Buchse)
- Traffic LED blinkt (an RJ45-Buchse)
- LED im CUN dauer an oder dauer aus, auf jeden Fall tut sich da nichts mehr...
- in FHEM steht der CUN immer noch auf initialized
- es werden keine Daten mehr empfangen...

Vielen Dank und Grüße
Michael

[fiedel]

Hi Michael,

versuche mal, ob du den CUN wenn er hängt noch mit "set CUN raw B00" resetten kannst. Dann könntest du ihn regelmäßig, oder nach einer Zeit der Inaktivität automatisch resetten. Das wäre ein Workaround, falls nichts anderes hilft.

Gruß

Frank

[KlausBüker]

Habe einiges getestet, alles ohne Erfolg:
a) Prüfung fhtbuf, vielleicht buffer overflow
b) Shutdown/restart jede Stunde
c) CUN reboot alles 30 Minuten

Es hilft bisher nur eines zur Wiederbelebung des CUN: USB-Netzstecker ziehen.


#----- CUN Trace w/ Absturz des CUNs
define at_CUN1 at +*00:10:00 { \
  fhem "get MyCUN fhtbuf";;\
  fhem "get MyCUN uptime";;\
}
#----- CUN Zwangs-Reboot w/ Absturz des CUNs
define at_CUN2 at +*00:30:00 { \
  fhem "set MyCUN raw B00";;\
}
#----- Shutdown/Restart alle Stunde w/ Absturz des CUNs
define at_CUN3 at +*01:00:00 { \
  fhem "shutdown restart";;\
}

[fiedel]

Noch zwei Ideen aus der Praxis: Mal ein separates USB- Netzteil verwenden, falls das nicht hilft und du keinen neuen CUL oder CUNO anschaffen willst: Sobald er auf "disconn." geht, per Programm und Relais (z.B. 1-Wire) kurz Spannung unterbrechen.

Gruß

Frank

[KlausBüker]

Hi Frank,
da ich ja nicht der Einzige bin mit dem disconnected Problem, gehe ich ganz stark von einem SW-Problem aus, also dürfte ein neuer CUN nicht wirklich helfen, oder sehe ich das falsch?

Ein separates USB-Netzteil hatte ich eh schon (und testweise auch schonmal ausgewechselt).

An ein FS20 Schaltsteckdose denke ich noch, um den CUN (sprich das USB Netzteil) kurz stromlos zu schalten, ist aber "mit der Brust durchs Auge". 
Oder gibt es ein CUN vergleichbares Produkt (mit RJ45)?

Gruß
Klaus

[fiedel]

Hi Klaus,

ich nutze u.a. den CUNO. Der disconnectet sich zwar auch, wegen Problemen im TCP- Stack der CULFW (vermutlich). Das ist aber mit ein paar Zeilen Code zum reinitialisieren gut zu beherrschen. Und das ist auch nur notwendig, wenn man den 1-Wire Port und die HMS- Emulation des CUNO nutzt.
Ich weiß nicht, ob man die CUNO- FW irgendwie sinvoll auf den CUN bügeln kann. Das könnte das Problem auch lösen.

Gruß

Frank

[KlausBüker]

Hi Frank,
nur zur Info, ich nutze jetzt seit ein paar Wochen die FS20 Schaltsteckdose um nach disconnect den CUN kurz stromlos zu schalten. Damit hat sich das Problem erstmal erledigt. Der Log zeigt mir im Schnitt >10 mal Disconnected pro Tag, so viele "harte" Abstürze hätte ich eigentlich nicht erwartet.

Gruß
Klaus