ECMD-Fehler

[Dr. Boris Neubert]

Wenn auch der Fehler an sich weiterhin besteht.
Fixen sollte man dies auf jeden Fall.

Von welchem Fehler sprichst Du?

Viele Grüße
Boris

[hummeruli]

Von welchem Fehler sprichst Du?

Viele Grüße
Boris

Ich spreche von dem Fehler, dass sich der fhem-Server von alleine jedes ECMD auf Status "disconnected" setzt.
So muss ich als erstes ein reopen machen, bevor ich ein ECMD steuern kann.
Das Device ist jedoch über die Weboberfläche jederzeit erreichbar. Dies zeigt, dass es nicht am Gerät liegt. Vielmehr
an fhem, das die Verbindung verliert.

[kpwg]

Ich spreche von dem Fehler, dass sich der fhem-Server von alleine jedes ECMD auf Status "disconnected" setzt.
So muss ich als erstes ein reopen machen, bevor ich ein ECMD steuern kann.

Alle Änderungen am Net-IO für eine stabile Funktion des ENC28J60 durchgeführt? Ich betreibe mehrere Eigenbau-Plattformen mit ATMega32 sowie ENC28J60-Modul aus China und habe seit der Inbetriebnahme letzten Dezember nicht einen Ausfall gehabt. Selbst über eine WLAN-Bridge lief es mehrere Tage testweise zuverlässig (wurde danach wieder abgebaut). Dabei schreibe ich etwa jede Minute auf das angeschaltene Display, lese alle 4min den DHT22 und steuere per control6 ein paar Pin's. Es würde auffallen, wenn einer der Vorgänge schief geht.

Das Device ist jedoch über die Weboberfläche jederzeit erreichbar. Dies zeigt, dass es nicht am Gerät liegt. Vielmehr an fhem, das die Verbindung verliert.

Das sehe ich nicht so. Testen würde ich nacheinander (!) Folgendes:
- ENC28J60 entsprechend modifiziert beschalten, falls noch nicht geschehen (im Wiki steht was; können wir auch nochmals recherchieren)
- auf Ethersex-Seite einen Watchdog zum zyklischen Resetten des ENC28J60 einrichten
- Stromversorgung des Net-IO optimieren, ENC28J60 tauschen

Betreibst Du mehrere Net-IO? In welchen Zeitabständen tritt das Problem auf? Was ist zwischen Net-IO und FHEM? Welche Plattform?

Viele Grüße, Ricardo

[Dr. Boris Neubert]

Ich spreche von dem Fehler, dass sich der fhem-Server von alleine jedes ECMD auf Status "disconnected" setzt.
Das Device ist jedoch über die Weboberfläche jederzeit erreichbar. Dies zeigt, dass es nicht am Gerät liegt. Vielmehr
an fhem, das die Verbindung verliert.

Den Schluß würde ich schon deswegen nicht ziehen, weil die Mechanismen nicht vergleichbar sind. Zweitens sehe ich auch nicht, warum es ein Fehler in FHEM sein soll, wenn FHEM die Verbindung "verliert". Die Diskussion ist allerdings müßig.

Code Auswählen Erweitern


define myReconnect notify myDevice:DISCONNECTED set myDevice reopen


und gut ist's.

Viele Grüße
Boris

[hummeruli]

Den Schluß würde ich schon deswegen nicht ziehen, weil die Mechanismen nicht vergleichbar sind. Zweitens sehe ich auch nicht, warum es ein Fehler in FHEM sein soll, wenn FHEM die Verbindung "verliert". Die Diskussion ist allerdings müßig.

Code Auswählen Erweitern


define myReconnect notify myDevice:DISCONNECTED set myDevice reopen


und gut ist's.

Viele Grüße
Boris

Danke,

werde es testen.

[tpm88]

Hallo,

Den Schluß würde ich schon deswegen nicht ziehen, weil die Mechanismen nicht vergleichbar sind. Zweitens sehe ich auch nicht, warum es ein Fehler in FHEM sein soll, wenn FHEM die Verbindung "verliert". Die Diskussion ist allerdings müßig.

Code Auswählen Erweitern


define myReconnect notify myDevice:DISCONNECTED set myDevice reopen


tatsächlich habe ich mit der neuen ECMD Implementierung auch bereits reproduzierbar beobachtet, dass die Verbindung zum AVR NetIO verlorgengeht.

Hier kurz das beobachtete Verhalten (nicht Fehler!! :

Ich habe zwei FHEM-Installationen, die per ECMD einen Connect auf den _gleichen_ AVR NetIO machen:

Eine produktive FHEM-Instanz auf einer FritzBox 7390 mit "alter" Version:
# $Id: 66_ECMD.pm 4426 2013-12-20 15:47:05Z borisneubert $
=> Verbindung über Wochen völlig stabil, regelmässiges Lesen von 1wire Temperaturwerten und Schalten von Relais

Eine Test FHEM-Instanz mit "neuer" Version auf einem RPi:
# $Id: 66_ECMD.pm 5551 2014-04-18 10:43:26Z borisneubert $
=> nur manuelles Testen z.B. neuer ClassDefs, keine regelmässigen Zugriffe auf den NetIO
=> nach reproduzierbar gut 2h (ohne Zugriff) geht die Verbindung auf "DISCONNECTED"

Code Auswählen Erweitern


2014-05-02_13:57:56 NETIO CONNECTED
2014-05-02_16:09:27 NETIO DISCONNECTED
...
2014-05-08_15:03:16 NETIO CONNECTED
2014-05-08_17:14:34 NETIO DISCONNECTED
...
2014-05-10_19:15:42 NETIO CONNECTED
2014-05-10_21:27:20 NETIO DISCONNECTED


Die "CONNECTED" Events wurden dabei jeweils durch ein manuelles reopen ausgelöst.

Klar kann ich die Verbindung durch obigen notify "wieder" öffnen. Möglicherweise "schliesst" ja auch der NetIO die TCP-Verbindung, wenn über 2h keine Daten über die Verbindung gehen.

Mein NetIO hat übrigens die (meisten) von kpwg  angesprochenen Änderungen zur Stabilisierung des ENC28J60.

Demnächst werde ich die produktive FHEM-Instanz auf den RPi mit neuer ECMD-Version umziehen. Erst dann kann ich berichten, ob die Verbindungsabbrüche auch ohne Leerlauf auftreten...

Gruss
Tobias

[Dr. Boris Neubert]

Hallo Tobias,

ich habe im Leerlauf auf meinen beiden AVR-NET-IOs ebenfalls alle zwei bis drei Stunden Verbindungsabbrüche.

Das war auch mit der alten ECMD-Version schon so. Das hat nur keiner gemerkt, weil es nicht protokolliert wurde. Mit dem neuen ECMD kam auch die Migration auf DevIO.pm.

Ich tippe darauf, daß ein irgendwie geartetes KeepAlive alle Stunde bereits die Verbindungsabbrüche beendet.

Viele Grüße
Boris

[hummeruli]

Danke Boris,
habe deinen Einzeiler mit Erfolg getestet. Ich hatte zwei "Disconnects", und wurden aber umgehend mit den "reopens" wieder reconnected.

Schnelle Lösung durch fachliche Kompetenz!!!