CUNO STATE disconnected

Elektrolurch · 07 Juli 2014, 18:10:49

Hallo,

habe seit einigen Monaten einen CUNO zusätzlich in Betrieb genommen.
Nun steht heute im log, dass er disconnected ist.
Er lässt sich aber auf der Adresse anpingen, stromlos schalten und fhem neu starten half auch nichts.
Was könnte das Problem sein und wie lösen?

Gruß

Elektrolurch

Puschel74 · 07 Juli 2014, 18:13:38

Hallo,

verbose 5 und FHEM mal neu starten.

Grüße

Elektrolurch · 07 Juli 2014, 20:46:30

Hallo,

verbose 5 war auch nicht erhellend:
2014.07.07 20:27:29 5: Cmd: >define CUNO_1 CUL 192.168.1.18:2323 2136<
2014.07.07 20:27:29 3: Opening CUNO_1 device 192.168.1.18:2323
2014.07.07 20:27:29 3: Can't connect to 192.168.1.18:2323: Connection refused

ping auf 192.168.1.18 geht
telnet auf 192.168.1.18 2322 geht nicht.

Halb kaputt oder ist die Firmware irgendwie halb defekt?
Wenn der Port nicht mehr geht, kann man wohl von fhem aus ja auch nichts machen.
Muss das 'CUNOchen neu geflashed werden?

Oder hat noch jemand einen anderen Tipp?

Elektrolurch

Elektrolurch · 08 Juli 2014, 10:57:15

Hallo,
nachdem ich den CUNO gestern für eine Stunde vom Strom genommen hatte, war er wieder für einige Minuten in fhem present (Initzialihzed), dann aber wieder weg.
Heute nacht um ca. 4 Uhr hat fhem ihn wieder "gefunden". Bislang läuft er nun wieder störungsfrei.
Der CUNO ist in einem Betriebsraum installiert, die Umgebungstemperatur geht schon mal auf 30 Grad.
So wie das für mich aussieht, hat das Teil einfach "thermische" Probleme.
Leider konnte ich im Forum dazu nichts finden.

Gruß

Elektrolurch

Elektrolurch · 05 Dezember 2014, 14:53:49

Hallo,

jetzt ist der CUNO 5 Monate fehlerfrei gelaufen und der oben beschriebene Fehler tritt nun wieder auf:
1. CUNO -> state disconnected
2. Lässt sich über LAN auf der IP-Adresse anpingen (1 ms)
3. telnet 192.168.1.18 2323
gibt keinen connect auf dem Port.

Was habe ich schon gemacht?
1. Stromversorgung des CUNO gewechselt
2. Switchport, an dem der CUNO angeschlossen ist, gewechselt
3. fhem neu gestartet, was aber natürlich nichts brachte.
2014.12.05 14:46:37 0: Server shutdown
2014.12.05 14:46:37 5: SW: X00
2014.12.05 14:46:45 1: Including fhem.cfg
... mehr kommt nicht, was den CUNO betrifft.
4. attr CUNO_1 verbose 5

ergibt beim initialisieren keinen Fehler.
Sendet man raw-Befehle, seht folgendes im log:
2014.12.05 14:26:37 5: SW: T02
2014.12.05 14:26:53 3: set CUNO_1 raw D00
2014.12.05 14:26:53 5: SW: D00
2014.12.05 14:34:42 1: CUNO_1 status disconnected
2014.12.05 14:44:42 1: CUNO_1 status disconnected

Beim "raw T02" - Befehl kommt "no answer" auf dem Screen zurück, der "raw D00" wird ohne Fehlermeldung ausgeführt.

set Ku_Deckenlampe ein
ergibt im log:
2014.12.05 14:50:21 5: CUNO_1 sending F40e05011
2014.12.05 14:50:21 5: SW: F40e05011
2014.12.05 14:50:22 5: CUNO_1 sending F40e05711
2014.12.05 14:50:22 5: CUNO_1 sending F40e40e10
2014.12.05 14:50:22 5: SW: F40e05711
2014.12.05 14:50:23 5: SW: F40e40e10

Die Lampe wird natürlich nicht eingeschaltet.

Könnte doch die Hardware vom CUNO defekt sein, ping geht ja, telnet-Port nicht?

Heute morgen wurden über den CUNO noch einige Lampen eingeschaltet und sofort danach stand der STATE auf disconnected.
Seit dem mag das Teil nicht mehr.

Elektrolurch

Starkstrombastler · 06 Dezember 2014, 20:04:54

Bei mir hat der Cuno auch ab und zu mal einen Aussetzer.

Ich habe jetzt einen Watchdog auf ein Signal von meinem Stromzähler mitlaufend:

Code Auswählen


define wdCuno watchdog 50WhImp:off 00:30:00 SAME set pmIPhone message Cuno: Watchdog-Alert;;set cuno reopen;;trigger wdCuno .

Wenn länger als 30 Minuten kein Impuls kommt, wird der Cuno mit "reopen" reanimiert, was bis jetzt immer geholfen hat.

Elektrolurch · 15 Dezember 2014, 19:17:49

Its a mystery tour...
Nach zwei Tagen war der CUNO wieder da um heute erneut zu "verschwinden".
Anpingen läßt sich seine IP--Adresse, auf dem Port 2323 bekomme ich jedoch keinen connect.
Leider hat das mit dem "set cuno reopen" nicht funktioniert.
Keine Fehlermeldung im log oder sonst noch eine Ausgabe.
Eigentlich müsste man davon ausgehen, das ein Gerät entweder gar nicht geht oder ....
Aber ping auf die IP geht und connect zum Port 2323 nicht.... ist schon strange.

Elektrolurch

Merlin2000 · 24 April 2015, 22:27:12

Hallo Elektrolurch,
Hat sich das Problem schon gelegt oder hast Du eine Lösung gefunden?
Bei mir taucht exakt das gleiche Problem auf, und zwar seit dem letzten Update von FHEM.

Beste Grüße,
Dirk

Mitch · 24 April 2015, 23:46:35

Habe mit dem CUNO auch massive Probleme und bin mittlerweile so weit, dass ich ihn deaktiviert habe.

Wir sind aber nicht die Einzigen mit Problemen: http://forum.fhem.de/index.php/topic,36529.0.html

Merlin2000 · 26 April 2015, 18:40:11

Ich habe das Problem bei mir gelöst. Der Fehler war simpel und ärgerlich:
Ich hatte für die Stromversorgung bei der Installation in die Kiste gegriffen und ein Billig-Netzteil (Travel Charger von irgend einem Handy) verwendet.
Das funktioniert wohl nicht im Dauerbetrieb und hatte wohl Aussetzer oder keine konstante Spannung.
Aufgefallen ist es mir nur, weil ich zufällig sah, dass die Kontrollleuchte mal etwas flackerte...
Neues Netzteil, jetzt keine Probleme mehr...

Beste Grüße,
Dirk

Elektrolurch · 27 April 2015, 14:56:38

Hallo,

das scheint ja Murphys law zu sein: Jetzt ist der CUNO monatelang ohne Probleme gelaufen und gestern um 18:00 Uhr kam wieder alle 10 Minuten die Meldung: state disconnected.
Man kann ihn per ping erreichen, aber auf dem telnet-Port kann man ihn nicht connecten.

Den CUNO stromlos zu schalten, hat nicht geholfen.
Die Fritzbox und den Switch, an dem der CUNO hängt, stromlos zu schalten, hat auch nicht geholfen.

Und das USB-Netzteil war sogar ein relativ teueres... Daran sollte es eigentlich auch nicht liegen.

Jetzt kann ich nur fabulieren:
Habe gestern die Ports der Fritzbox auf 1 GBit/s umgeschaltet, weil ich eine größere Datenmenge auf einen neu eingerichteten Cubietruck kopiert habe. Und als das Kopieren nach zwei Stunden fertig war, ging der CUNO nicht mehr.

Und jetzt kommts: Um 01:55 Uhr war der CUNO dann plötzlich wieder da. Um die Uhrzeit macht fhem einen check der Geräte. Und dabei wird auch versucht, die Sendebuffer von CUL, CUL_433 und CUNO auszulesen. Und nach dieser Operation war der CUNO wieder da! Murphy?

Kann bei dem Problem leider immer noch keine systematik erkkennen, zumal der Auffall zu selten passiert....

Elektrolurch