Hallo,
ich hoffe mal ich bin hier richtig gelandet - wenn nicht dann bitte @Admin verschieben.
Ich habe einen AVR-NET-IO mit Ethersex im Einsatz.
Passend dazu das ECMD-Decive lt. Wiki definiert aber seit heute morgen habe ich folgende Fehlermeldung:
ZitatUse of uninitialized value $r[0] in join or string at ./FHEM/66_ECMD.pm line 635.
Use of uninitialized value $r[0] in join or string at ./FHEM/66_ECMD.pm line 635.
Use of uninitialized value $r[0] in join or string at ./FHEM/66_ECMD.pm line 635.
Use of uninitialized value $r[0] in join or string at ./FHEM/66_ECMD.pm line 635.
Ein reopen brachte Abhilfe bis kurz nach 20:15
ZitatUse of uninitialized value $r[0] in join or string at ./FHEM/66_ECMD.pm line 635
Im Chart sieht das so aus:
(siehe Anhang / see attachement)
Ich habe 2 Sensoren für die Bodenfeuchtemessung an unseren Tomaten im Einsatz.
Der AVR-NET-IO ist in einem IP66-Gehäuse untergebracht und die Sensoren über je einen 6-poligen Lemo-Stecker direkt am Gehäuse angeschlossen.
Das ganze (Gehäuse mit Stecker) ist unter Dach und die Sensoren selbst sind halb-unter Dach (stehen auf der überdachten Terrasse an der vorderen Seite mitten in der Mittagssonne - endlich haben wir mal eine).
Die Anbindung ist per Devolo dLan500 duo+ gelöst.
Ich weiß - die Infos sind dürftig.
Wenn mehr benötigt wird zur Fehlereingrenzung dann bitte nur her mit den Anweisungen.
Grüße
P.S.: Ist jetzt nicht tragisch - ich bin nur froh das ich schonmal sehe das meine Schwiegermutter die Pflanzen "ertränken" will ^^
"Die sind ja ganz trocken, die muss man giessen" - schütt ^^
Im Zuge dessen möchte ich noch auf einen kleinen Fehler in der Doku hinweisen:
Zitat von: Zeile 320 - 67_EMCDevice.pm<code>set myDisplay text This\x20text\x20has\x20blanks!</code><br>
Dadurch sind aktuell alle folgenden Module in <code>-Formatierung gehalten.
Viele Grüße
Markus
Hallo,
ich vermute mal ich hab den Fehler gefunden (Langzeittest läuft grad).
Ich hatte noch die classdef erweitert um das Relaisboard - dieses aber nicht am NET-IO dran da ich es im Moment
nicht brauche und das Gehäuse für beide zu klein ist.
Nachdem ich die classdef abgeändert hatte und nur noch adc drinnen steht (anschliessendes reopen durchgeführt) haben die beiden Kurven auch wieder die Plätze getauscht.
Nun wird wieder so geloggt wie erwartet.
Nun warte ich mal ab bis morgen und werde wieder berichten.
Grüße
Edith: Ich brauchte gar nicht bis morgen warten :-(
ZitatUse of uninitialized value $r[0] in join or string at ./FHEM/66_ECMD.pm line 635.
um 16:39 lt. Plot.
Nach diesem Fehler tauschen die beiden Kurven im Plot die Plätze - so als ob adc1 und adc2 vertauscht werden.
Edith2: Fehler anscheinend gefunden. Der Devolo hat sich sporadisch disconnected.
Gestern um 20 Uhr getauscht - seither ist Ruhe.
Hallo!
Ich habe diesen Fehler auch.
Use of uninitialized value $r[0] in join or string at ./FHEM/66_ECMD.pm line 635.
Manchmal auch $r[1] statt $r[0].
Bei mir kommt er jedes mal, wenn ich ein Kommando absetze und KEINE Antwort zurückkommt.
Man merkt auch, dass es eine Art "Timeout" gibt, das Modul also kurz hängt und dann daraufhin diesen Fehler ausgibt.
Ich kann das gut reproduzieren, weil bei manchen Kommandos, die ich absetze, keine Antwort erwartet wird.
2013.11.23 03:31:19 5: Cmd: >set DMX_Effects Licht_3<
2013.11.23 03:31:19 5: ECMDDevice: Analyze command >{"runcommand 7 10 3"}<
2013.11.23 03:31:19 5: DMXControl sending runcommand 7 10 3
2013.11.23 03:31:22 5:
2013.11.23 03:31:22 5: Triggering DMX_Effects (1 changes)
2013.11.23 03:31:22 5: Notify loop for DMX_Effects Licht_3:
2013.11.23 03:31:22 4: ECMDDevice DMX_Effects Licht_3
Kann es sein, dass es daran liegt?
Viele Grüße
Spiff
Zitat von: Markus Bloch am 08 Juni 2013, 00:08:04
Im Zuge dessen möchte ich noch auf einen kleinen Fehler in der Doku hinweisen:
Hilf mir bitte auf die Sprünge. Bei mir ist das nicht der Fall und ich sehe auch nicht, was an der zitierten Zeile falsch sein sollte.
Viele Grüße
Boris
Zitat von: Spiff am 23 November 2013, 18:03:33
Use of uninitialized value $r[0] in join or string at ./FHEM/66_ECMD.pm line 635.
Die von ECMD zurückgegebenen Werte werden in Zeile 635 mit \n aneinandergehängt. Wenn es nichts aneinanderzuhängen gibt, kommt es zum Fehler.
Kannst Du mal bitte ausprobieren, ob der weg geht, wenn Du die Zeile 635 durch
return @r ? join("\n", @r) : undef;
ersetzt?
Viele Grüße
Boris
Hallo Boris!
Ich habe die Zeile ersetzt. Leider kommen jetzt 2 Fehler:
Use of uninitialized value $text in concatenation (.) or string at fhem.pl line 650.
Use of uninitialized value $r[0] in join or string at ./FHEM/66_ECMD.pm line 635.
Viele Grüße
Spiff.
Hallo Spiff,
die neue Meldung kommt, weil die aufrufende Routine über das undef stolpert.
Die Meldungen sind nicht schlimm. Ich plane für irgendwann einmal eine großangelegte Überarbeitung des Moduls (Umstellung auf DevIO.pm, Auswerten spontan empfangener Nachrichten). Da werde ich solche Sachen miterledigen, vielleicht über einen Modifier an Kommandos, das nicht auf Rückmeldung gewartet werden soll.
Viele Grüße
Boris
Hallo Boris,
das klingt gut!
Ich habe diese Zeile wieder auf die alte korrigiert, weil komischerweise der Status meiner Funksteckdosen (PCA301 über JeeLink) nicht mehr ausgelesen werden konnte. Das Glühbirnen-Symbol war immer als Fragezeichen dargestellt. Nachdem ich die Zeile zurückgeändert hatte, wurde der Status wieder korrekt dargestellt. Merkwürdig.
[Edit: ist Käse. Das muss einen anderen Grund gehabt haben, war wohl Zufall. Ich konnte es mir nicht vorstellen und habe es nochmal mit der neuen Zeile probiert. Geht natürlich.]
Damit mein fhem nicht immer 3 Sekunden hängt, habe ich temporär den Wartewert auf die Rückantwort verkürzt:
my $to = 1; # 3 seconds timeout # now 1 second
Auch wenn es hier nicht ganz reinpasst - aber bei meinen Versuchen kamen hin und wieder auch ECMD-Fehler, dann passt's vielleicht doch:
ist es möglich, die SET-Kommandos nicht nur für den direkten Austausch mit der Terminal-Schnittstelle zu missbrauchen?
In meinen classdefs befinden sich nur "set <xxx> cmd {"Terminal-Befehl"}.
Ich würde gerne ein SET für "rgb" mit den Optionen "colorpicker,RGB" einbauen.
Der Hintergrund ist jetzt bestimmt schon klar. :)
Ich steuere RGB-LEDs und möchte gerne den Colorpicker (http://www.fhemwiki.de/wiki/Color (http://www.fhemwiki.de/wiki/Color)) benutzen.
Danke & viele Grüße
Spiff
Hallo,
Zitat von: Spiff am 24 November 2013, 10:57:38
ist es möglich, die SET-Kommandos nicht nur für den direkten Austausch mit der Terminal-Schnittstelle zu missbrauchen?
In meinen classdefs befinden sich nur "set <xxx> cmd {"Terminal-Befehl"}.
Ich würde gerne ein SET für "rgb" mit den Optionen "colorpicker,RGB" einbauen.
ich habe nicht ganz verstanden, was Du erreichen willst. Ich nehme an, daß Du über den Colorpicker eine Farbe auswählst und das Ergebnis der Farbauswahl später in einem Befehl an das ECMD-Gerät senden möchtest.
Die set-Befehle sind dazu gedacht, über die Schnittstelle Kommandos an das ECMD-Gerät zu senden. Du könntest aber mit einem Dummy-Gerät (dummy) für die Farbauswahl arbeiten, die über einen Notify die Farbe als User-Attribut ans ECMD-Gerät klebt. Das User-Attribut kannst Du an in einem Set-Kommando auslesen.
Ich hoffe, diese auf die schnelle geschriebenen Zeilen helfen Dir weiter.
Viele Grüße
Boris
der colorpicker in der set liste ist nur ein modifier für das rgb kommando damit fhemweb den colorpicker einblendet sobald das rgb kommando in der webCmd liste auftaucht.
d.h. zunächst ein mal ist es ein ganz normales kommando mit namen rgb das die farbe als 6 zeichen hex wert als paramter hat.
nur in der 'set ?' liste des device muss es als rgb:colorpicker,RGB auftauchen. genau so wie ein dim als dim:slider... auftaucht.
gruss
andre
Hallo,
Zitat von: Dr. Boris Neubert am 24 November 2013, 11:55:32
Die set-Befehle sind dazu gedacht, über die Schnittstelle Kommandos an das ECMD-Gerät zu senden. Du könntest aber mit einem Dummy-Gerät (dummy) für die Farbauswahl arbeiten, die über einen Notify die Farbe als User-Attribut ans ECMD-Gerät klebt. Das User-Attribut kannst Du an in einem Set-Kommando auslesen.
Den Colorpicker habe ich inzwischen als Dummy definiert bekommen. Dieser gibt als State "rgb <hex-Farbe>" aus.
Das User-Attribut sieht dann ungefähr so aus? attr global userattr attr_DMX_1
Und das Notify des Dummys schreibt die <hex-Farbe> in attr_DMX_1 und ruft danach das Set-Kommando in der classdef auf, das dieses attr_DMX_1 ausliest und an das ECMD-Gerät weitergibt. Habe ich das so richtig verstanden?
Warum muss ich den Weg über ein User-Attribut gehen und kann den State des Dummys z.B. mit
set NAMETEST cmd {"sc %DMX_R {ReadingsVal("Licht_Test","state","")}"}
nicht direkt benutzen? Dass da lauter Fehler kommen, liegt bestimmt an meinem falschen Syntax (sind mehrere {} überhaupt nötig/zulässig?). ::)
Ich habe in den Beispielen der classdefs leider nichts über eigene User-Attribute gesehen, nur über die eigens deklarierten params und die allgemein gültigen wie %NAME.
Dann muss ich nur noch die <hex-Farbe> in 3 einzelne Dezimalfarben umwandeln und wissen, wie man das als User-Attribut ans ECMD-Gerät klebt.
Entschuldigt das Anfängergesülze.
Viele Grüße,
Spiff.
Hallo,
die meisten Antworten konnte ich mir selbst beantworten:
http://forum.fhem.de/index.php/topic,16610.msg110123.html#msg110123
Vielen Dank für die Denkanstöße & Grüße,
Spiff
Hallo Boris,
ich habe noch 2 Fragen, evtl. auch Fehler:
1.) In der fhem.save werden mehrzeilige Antworten auch mehrzeilig gespeichert. Das hat zur Folge, dass ab der 2. Zeile ein Fehler ausgespuckt wird, weil fhem die Kommandozitate nicht kennt. Hier ein Auszug aus meiner fhem.save:
setstate RGB1 2013-11-29 23:21:32 ColorPicker CV 1 200
CV 2 255
CV 3 18
Vielleicht kann man diese Einträge auch einzeilig darstellen? Oder ist das so gewollt und ich müsste sowieso der Sauberkeit halber eigentlich die Zeilenumbrüche mit postproc entfernen?
2.) Ich würde über einen Befehl gerne eine GET-Aktion auslösen und die Antwort verwerten. Da die Antwort mehrere Informationen enthält, muss ich auf ein Notify zurückgreifen und die Aktionen mit $EVTPARTx filtern, richtig?
Ich bekomme es einfach nicht hin, dass ein Notify nur auf dieses GET reagiert. Beispiel:
get Farbwert cmd {"gc 1" . "\ngc 2" . "\ngc 3"}
Die Antwort sieht so aus:
Farbwert CV 1 200
CV 2 255
CV 3 18
und im State des Devices steht jetzt:
Farbwert CV 1 200 CV 2 255 CV 3 18
Mein Test-Notify sieht so aus:
define not_LED_get notify RGB1:Farbwert.* set LED2 rgb 000000
Wenn ich das ":Farbwert.*" entferne, reagiert es auch ordnungsgemäß, allerdings natürlich immer.
An welcher Stelle sind Tomaten auf meinen Augen? Mein Brillenputztuch ist auch weg. Herrjeh...
Danke & viele Grüße,
Spiff.
Hallo,
das Speichern mehrzeiliger Werte in fhem.save hat Rudi m.W. mittlerweile ermöglicht.
Bzgl. der unitialized-Meldungen habe ich ein paar Änderungen vorgenommen, die ab morgen per Update erhältlich sind.
Grüße
Boris
Hallo Boris,
habe es ausprobiert, der Fehler ist weg. Danke!
Kann man den Timeout per Benutzerattribut oder in der classDef einstellen?
Ich meine, wenn ich von Anfang an weiss, dass keine Antwort kommt, kann ich das Timeout für manche Befehle ja auch auf 0 setzen.
In meinem Fall müsste das allerdings tatsächlich pro Befehl und nicht pro Device einstellbar sein, da manche Befehle auch eine Rückgabe bringen.
Viele Grüße,
Spiff.
Zitat von: Spiff am 20 Dezember 2013, 18:36:15
Kann man den Timeout per Benutzerattribut oder in der classDef einstellen?
Das ist nicht vorgesehen.
Vielleicht findet sich jemand, der einen Patch bereitstellt, mit dem man in der classdef
set <command> options noreplyschreiben kann, damit das Modul nicht auf Rückmeldung wartet.
Viele Grüße
Boris
Zitat von: Spiff am 30 November 2013, 00:42:03
Vielleicht kann man diese Einträge auch einzeilig darstellen? Oder ist das so gewollt und ich müsste sowieso der Sauberkeit halber eigentlich die Zeilenumbrüche mit postproc entfernen?
Daran bin ich auch schon verzweifelt. Leider scheint es keine dokumentierte Möglichkeit zu geben, mehrere Werte in eine Zeile zu bekommen.
Zitat von: kpwg am 25 Dezember 2013, 12:10:59
Daran bin ich auch schon verzweifelt. Leider scheint es keine dokumentierte Möglichkeit zu geben, mehrere Werte in eine Zeile zu bekommen.
M.W. hat Rudi das Speichern mehrzeiliger Werte in Readings schon vor einigen Tagen in fhem.pl ermöglicht. Update gemacht?
Ansonsten gibt es in der Commandref dazu auch ein Beispiel, auf dem Du aufbauen kannst:
set on postproc {s/^OK\nOK\nOK\nOK$/success/; "$_" eq "success" ? "ok" : "error"; }Ungetestet:
set DeinBefehl postproc { s/\n//g; $_; }Grüße
Boris
Zitat von: Dr. Boris Neubert am 25 Dezember 2013, 12:26:57
M.W. hat Rudi das Speichern mehrzeiliger Werte in Readings schon vor einigen Tagen in fhem.pl ermöglicht. Update gemacht?
Jawohl. Schaue praktisch täglich nach, was es Neues gibt.
Zitat von: Dr. Boris Neubert am 25 Dezember 2013, 12:26:57
Ungetestet:
set DeinBefehl postproc { s/\n//g; $_; }
Grüße
Boris
Danke Boris, das funktioniert vorzüglich. Bin noch sehr unsicher im Anwenden von Perl, aber es wird. Den "s///"-Operator hatte ich schon am Wickel, aber es kam nur Murks dabei heraus.
Mein kleines Projekt ist ja noch immer das korrekte Einbinden der DHT22 Sensoren. Prinzipiell habe ich aktuell richtige Werte da stehen, die sich aktualisieren und in einem Plot gut darstellen lassen. Ich meine aber, mit den Workarrounds nicht das eigentliche Problem lösen zu können:
saubere einzeilige Werte im Log und korrekte Readings.
Ich kann den DHT22 per classdef mit
get DHT cmd {"dht temp" . "\ndht humid"}
auslesen und mit
set DHT postproc { s/\n//g; $_; } bringt nun die (noch-nicht-)readings auf eine Zeile. Jetzt muss ich den Werten noch T: und H: voranstellen und die readings
temperature und
humidity zuordenen. Mal schauen, wie das geht... oder weißt du Rat?
Viele Grüße,
Ricardo
Zitat von: kpwg am 25 Dezember 2013, 17:00:32
Ich kann den DHT22 per classdef mit get DHT cmd {"dht temp" . "\ndht humid"} auslesen. Jetzt muss ich den Werten noch T: und H: voranstellen und die readings temperature und humidity zuordenen.
Was kommt denn beim Auslesen raus? Poste mal bitte den Output auf get DHT.
Grüße
Boris
Es kommt 2013.12.25 19:55:34 3: WZ_TH: DHT 20.6
41.8 im Log an. Ich unterdrücke das im Log mit verbose 1. Aktuell hatte ich Temperatur und Feuchte getrennt abgefragt uns als zwei Werte übergeben. Mit T und H lässt sich dann arbeiten, aber "echte" Readings wie bei anderen Sensoren sind das nicht. Nur Anzeigen ist kein Thema, aber damit weiterarbeiten geht schief.
Aha, du hast also ein Reading DHT am Gerät, wo "20.6 41.8" drinsteht?
Dann versuche bitte mal
get DHT postproc { s/(.*)\n(.*)/T: $1 H: $2/; $_; }
Den Rest erledigst Du dann mit einem FileLog und Regexp DHT.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 25 Dezember 2013, 20:46:16
Dann versuche bitte mal get DHT postproc { s/(.*)\n(.*)/T: $1 H: $2/; $_; } Den Rest erledigst Du dann mit einem FileLog und Regexp DHT.
Schaut gut aus:
2013-12-26 09:48:11 ECMDDevice WZ_Klima DHT: T: 20.7 H: 35.7Habe auch halbwegs verstanden, was da passiert: (.*)\n(.*) teilt in alles vor dem Zeilenumbruch, den Zeilenumbruch selbst und alles nach dem Zeilenumbruch, T: $1 H: $2 fügt das T: und H: vor die Werte und ersetzt den Zeilenumbruch mit "nichts". Perl ist nicht immer einfach, oft aber überraschend einfach. ::) Mal schauen, wie ich das
DHT: noch weg bekomme.
Jetzt schaue ich noch, wie ich die readings hinbekomme. Filelog ist soweit klar, zu regexp lese ich mich mal 'rein.
Viele Grüße,
Ricardo
Hallo,
ganz kurze Frage zum Thema ECMD und Verbindungsabbrüche: Ich nutze FHEM 5.5 unter Linux u.a. zum Auslesen von 1Wire-Sensoren via Ethersex (auf AVR NET-IO). Das NET-IO läuft netzwerktechnisch stabil, die Spannungsversorgung wurde dementsprechend geändert. Dennoch habe auch ich das Problem, dass FHEM sporadisch die Telnet-Verbindung zum AVR verliert, dies auch anzeigt und anschließend nicht wieder aufbaut, obwohl der AVR weiterhin via LAN verfügbar ist. Ist es empfehlenswert, auf das aktuelle FHEM-Snapshot zu aktualisieren? Vorerst werde ich vor Absetzen des ECMD-Befehls zum Auslesen der Sensoren ein "reopen" mitgeben, finde diese Notlösung aber nicht sehr schön. Könnte man ein notify auf das Ereignis "disconnect" setzen, welches automatisch den "reopen" anstößt? Zumindest wäre das ein "Workaround".
Dass der AVR weiter via LAN verfügbar ist, sehe ich auch daran, dass meine S0-Zähler weiter Daten senden.
Gruß, Eike
Hallo,
ich beobachte den Fall erst einmal, nachdem ich gerade ein Update durchgeführt habe. Somit ist nun der neueste Development-Stand aktiv.
Gruß, Eike
Hallo,
weiß jemand, wie man prüft, ob eine Socket-Verbindung noch offen ist, BEVOR man versucht zu senden?
Grüße
Boris
Zitat von: Eike am 12 Februar 2014, 14:27:46
Hallo,
ganz kurze Frage zum Thema ECMD und Verbindungsabbrüche: Ich nutze FHEM 5.5 unter Linux u.a. zum Auslesen von 1Wire-Sensoren via Ethersex (auf AVR NET-IO). Das NET-IO läuft netzwerktechnisch stabil, die Spannungsversorgung wurde dementsprechend geändert. Dennoch habe auch ich das Problem, dass FHEM sporadisch die Telnet-Verbindung zum AVR verliert, dies auch anzeigt und anschließend nicht wieder aufbaut, obwohl der AVR weiterhin via LAN verfügbar ist. Ist es empfehlenswert, auf das aktuelle FHEM-Snapshot zu aktualisieren? Vorerst werde ich vor Absetzen des ECMD-Befehls zum Auslesen der Sensoren ein "reopen" mitgeben, finde diese Notlösung aber nicht sehr schön. Könnte man ein notify auf das Ereignis "disconnect" setzen, welches automatisch den "reopen" anstößt? Zumindest wäre das ein "Workaround".
Dass der AVR weiter via LAN verfügbar ist, sehe ich auch daran, dass meine S0-Zähler weiter Daten senden.
Gruß, Eike
Da ich dieses Problem auch habe, würde es mich freuen, wenn es eine vernünftige Lösung für den "disconnect" gibt.
Danke
Hi,
ich habe das Problem mit den Verbindungsabbruechen auch.
Was mir aufgefallen ist ist dass das automatische ropen nach einem Lesefehler (timeout) nicht erfolgreich ist.
Ich hab deshalb mal den timeout auf 10sec hochgesetzt, seitdem ist das reopen erfolgreich (ca 1-2 mal am Tag)
Irgendwie scheint das reopen sehr lange zu dauern.
Gruss,
Wolle
Zitat von: wollet42 am 08 Mai 2014, 13:16:52
Hi,
ich habe das Problem mit den Verbindungsabbruechen auch.
Was mir aufgefallen ist ist dass das automatische ropen nach einem Lesefehler (timeout) nicht erfolgreich ist.
Ich hab deshalb mal den timeout auf 10sec hochgesetzt, seitdem ist das reopen erfolgreich (ca 1-2 mal am Tag)
Irgendwie scheint das reopen sehr lange zu dauern.
Gruss,
Wolle
Super Tip, das werde ich mal testen, nur wäre es für mich hilfreich, wenn Du den Code hier zeigen könntest.
Dies ist zumindest ein Lösungsweg. Wenn auch der Fehler an sich weiterhin besteht.
Fixen sollte man dies auf jeden Fall.
Gruß
Uli
Zitat von: hummeruli am 08 Mai 2014, 23:41:55
Wenn auch der Fehler an sich weiterhin besteht.
Fixen sollte man dies auf jeden Fall.
Von welchem Fehler sprichst Du?
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 10 Mai 2014, 10:03:13
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.
Zitat von: hummeruli am 10 Mai 2014, 12:59:00
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.
Zitat von: hummeruli am 10 Mai 2014, 12:59:00Das 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
Zitat von: hummeruli am 10 Mai 2014, 12:59:00
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.
define myReconnect notify myDevice:DISCONNECTED set myDevice reopen
und gut ist's.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 10 Mai 2014, 15:04:59
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.
define myReconnect notify myDevice:DISCONNECTED set myDevice reopen
und gut ist's.
Viele Grüße
Boris
Danke,
werde es testen.
Hallo,
Zitat von: Dr. Boris Neubert am 10 Mai 2014, 15:04:59
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.
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"
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
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
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!!!