OWDevice schickt FHEM in die Wüste

[ritchie]

Hi,

sorry, es waren "dropped" Packet.

RX packets:10027 errors:0 dropped:17 overruns:0 frame:0

Was macht die Anzeige des OWservers via Http: arbeitet dieser korrekt ?

http://fhem-server:2121/

Was steht hier
http://fhem-server:2121/statistics/errors

Läuft das system den noch, wenn FHEM eingefroren ist.

Was sieht Du bei

>ssh pi@fhem-server
und dann
>ps -aux

Siehe auch hier : http://www.howtoforge.de/anleitung/bashbefehle-und-programme-um-traffic-und-auslastung-zu-prufen/

Gruss R.

[Joachim]

Moin ritchie,
http://fhem-server:2121/ arbeitet immer wenn ich reinsehe korrekt,
http://fhem-server:2121/statistics/errors hat keine errors.
(siehe Anhang / see attachement)

Gruß Joachim

[ritchie]

na das ist ja mal ein toller Fehler..

Kannst Du zu diesem Zeitpunkt via Konsole Dich anmelden und
mittels

>ps -aux

prüfen wie die Processor Last ist ?

Vielleicht kann man ja hier den Prozess erkennen, der hängt.

Gruss R.

[Joachim]

Moin ritchie,

Das Problem ist, dass ich dann permanent vor dem Pi sitzen müsste, der Fehler sagt ja nicht vorher bescheit, dass er kommt.
Das einzige, was ich anbieten kann ist
(siehe Anhang / see attachement)

Der erste Absturz war ein Totalabsturz von FHEM,Zugriff auf http://fhem-server:2121/ war allerdings möglich, FHEM neustarten nicht,FHEM konnte nur durch Stromklau des Pi's wiederbelebt werden, die beiden anderen, da hat sich FHEM
nach ca. 14 Minuten gefangen.
Der hohe Load nach 17:00 Uhr, hier läuft wireshark auf dem Pi.

Der Prozess, der hängt, ist FHEM

Gruß Joachim

[ritchie]

Hallo Joachim,

klar, das diese Fehler immer dann kommen, wenn man keine Möglichkeit hat, sie zu beobachten (Murpheys Gesetz ;-) )

Ich habe mir nochmals den Thread durchgelesen und nach Deiner Aussage scheint das Problem
der Windows Server zu sein.

Kannst Du auf dem Server einen "Performance Monitor" anlegen und diesen mit aufzeichnen lassen (CPU, Netzlast, Dienste,...)

Es wäre vielleicht interessant zu sehen, was der Server macht, während der Raspberry Probleme hat.

Kannst Du in den Windows Events des Servers irgendwelche Einträge entdecken, zum Zeitpunkt der Probleme,
welche auf Probleme des Server hinweisen könnten.

Gruss R.

[Joachim]

Moin ritchie,

Habe wohl gestern mein gesamtes Netzwerk komplett verkonfiguriert, bin jetzt mit meinem Notrechner im Netz.
Das bestätigt mich in dem Entschluss, den ich heute Nacht schon gefasst habe.

Die gesamte Anlage wird neu aufgebaut / aufgesetzt und durchgemessen, dabei gleich GB-Lan Tauglichkeit hergestellt.
Das wird sicherlich mindestens zwei Wochen dauern.
danach wird der Raspberry mit FHEM scheibchenweise an seine Aufgaben herangeführt, und gesucht, wann der Fehler
erstmalig auftaucht. Dann werde ich einen neuen Traed öffnen, wenn es nicht mit OWServer zusammenhängt.

Dir ersteinmal vielen Dank.

Gruß Joachim

[ritchie]

Hallo Joachim,

ich bin jetzt der festen Meinung, das es der OWServer ist.

Seit dem ich eine zweite Verbindung zu dem OWServer aufgebaut hatte,
bricht mein System nach kurzer Zeit zusammen.
Das kannst Du forsieren, wenn Du die Abtastrate nach unter legst (schneller Abfragen).

Eine Idee muss ich noch prüfen, ob der verwendete Port des OWServers von einer
anderen Software auch noch verwendet wird.

Na dann mal viel Erfolg mit dem Neuaufbau.

Gruss R.

[Joachim]

Moin ritchie,

Diese Seite kennst Du:
http://fischer-net.de/hausautomation/haustechnik/1-wire/60-1-wire-integration-in-fhem.html

Leider gibt es zur Zeit (Stand Ende Januar 2013) noch ein Problem mit owserver. Sobald der owserver Daemon nicht mehr erreichbar ist, "friert" FHEM komplett ein. Hierzu stehen wir derzeit in Kontakt mit den Entwicklern des OWFS 1-Wire Filesystem. Zwar könnte man dieses Verhalten innerhalb von FHEM umgehen, doch es ist Zielführender das Problem direkt an der Quelle (OWNet.pm) zu beheben.

Tja, das wird eine lustige Bastelei, aber ersteinmal alle Rechner und die Fritzbox aufräumen. Das war schon lange mal an der Zeit.

Gruß Joachim

[justme1968]

ich musste eben einen meiner raspberry pi mit owfs neu booten und fhem ist prompt hängen geblieben.

mal sehen ob ich mehr rausfinde wenn es so gut reproduzierbar ist :(

gruss
  andre

[Joachim]

Moin Andre,

ich bin immer noch beim Neuaufbau meines gesamten Netzwerks, heute ist die neue FB 7390 dran.
bin auch immer noch auf der Fehlersuche, es scheint aber kein isoliertes Problen mit OWDevice/OWServer zu sein, sondern ein generelles Netzwerkproblem, da diese Aussetzer auch auf Systemen auftreten, auf denen kein OWServer installiert ist, die aber in irgendeiner Art über Module auf das Netzwerk zugreifen.
Um FHEM-Ausfälle besser zu finden, habe ich mir mal ein dummy-Device angelegt, In der fhem.cfg einfach folgendes eintraagen:

define alive dummy
attr alive setList 0 1
define at_alive at +*00:01:00 {if ("$value{alive}" == 0) {fhem("set alive 1")} else {fhem("set alive 0")}}
define Log_alive FileLog ./log/alive-%Y-%m-%d.log alive.*
define SVG_Log_alive_1 SVG Log_alive:SVG_Log_alive_1:CURRENT

und ein passendes SVG_Log_alive_1.gplot erstellen.

damit sieht man dann auf einen Blick, wenn FHEM aussetzer hatte.

Gruß Joachim

[justme1968]

ich denke ich habe eben zumindest einen grund gefunden warum fhem trotz aktivem nonblocking im OWServer blockiert wenn das owfs nicht mehr erreichbar ist.

mehr hier: Link

gruss
  andre