OWX: DS2480 detected/re-detected

[fhem-challenge]

Exakt das gleiche Problem habe ich auch!

Seit ca. 4 Tagen. ein "service fhem stop;service fhem start" funktioniert.

Wenn ich in FHEM selbst (webinterface) die fhem.cfg ändere, und speichere, bleibt der prozess vollständig hängen. service fhem stop hilt dann auch nichts mehr.

Lediglich ein kill -9 xxxx führt natürlich noch zum Erfolg.

Gruss

Andreas

[larsberghahn]

Hallo,

Das gleiche Problem besteht bei mir auch immernoch, rereadcfg und FHEM hängt. Der letzte Eintrag im Log lautet:
2014.03.24 17:31:41 1: OWX: 1-Wire bus Arduino_OW_Temp1: interface Firmata detected in Arduino2

Egal ob ich OWX am USB-Arduino oder Ethernet-Arduino aktiviere
Der USB-Arduino lief vorher immer tadellos mit OWX
Nurnoch Kill -9 funktioniert.
Habe OWX ersteinmal auskommentiert.

Nachdem ich gestern abend gelesen habe, dass das Problem nicht nur bei mir besteht und ihr gerne Logs von der Konsole hättet
habe ich versucht welche zu generieren aber nicht hinbekommen.

Bei sudo service fhem start tritt der Fehler ja ersteinmal nicht auf.
Gibt es nicht z.b. die Möglichkeit von der Konsole ein rereadcfg anzustossen sodass ich dort was mitloggen kann was weiterhilft?

MFG Lars

[ntruchsess]

nicht als service starten. Einfach in das fhem-verzeichnis gehen und dort './fhem.pl fhem.cfg' eingeben

[larsberghahn]

Hallo,
habs so gestartet wie du gesagt hast, klappt auch. Dann in der Weboberfläche rereadcfg eingegeben und dann bleibt er wieder bei der besagten Zeile stehen.

2014.03.25 20:11:06 1: Including ./log/fhem.save
2014.03.25 20:11:07 3: Opening Arduino1 device /dev/ttyACM0
2014.03.25 20:11:07 3: Setting Arduino1 baudrate to 57600
2014.03.25 20:11:07 3: Arduino1 device opened
2014.03.25 20:11:10 3: querying Firmata Firmware Version
2014.03.25 20:11:10 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.03.25 20:11:11 3: Arduino2: port 3030 opened
2014.03.25 20:11:11 1: OWX: 1-Wire bus Arduino_OW_Temp1: interface Firmata detected in Arduino1

Beim ersten start stehn auf der Console ein paar HM Fehler. Nach dem rereadcfg kommt nix mehr:

> /opt/fhem $ sudo ./fhem.pl fhem.cfg
Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 362.
Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 362.
Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 362.

Diese Fehler hab ich aber schon immer wenn ich mich richtig erinnere und dürften mit dem OWX Problem nichts zu tun haben


MFG Lars

[ntruchsess]

hm merkwürdig, ich hätte jetzt mit irgendeinem fatalen perl-fehler auf der Konsole gerechnet. Ist fhem denn dann gar nicht mehr erreichbar (per WebFrontend?). Schalt doch mal global verbose auf 5 um zu sehen, ob FRM nach der letzten Logausgabe noch mit dem Arduino redet. Und häng Deine fhem.cfg mal hier an. Ich kann morgen abend mal versuchen das mit 2 Ethernet-arduinos und Deiner fhem.cfg zu reproduzieren.

Gruß,

Norbert

[larsberghahn]

Hallo,

ich bin jetzt schon ne weile am probieren aber ich habe zum debuggen noch keine bessere möglichkeit gefunde als im perl code
von Punkt zu Punkt Logeinträge zu generieren.

Verbose 5 hatte ich vorhin bereits probiert, aber nach dem besagten Logeintrag kommt garnichts mehr.

Aber folgendes:
In 00_OWX.pm im Sub OWX_Start wird in der drittletzten Zeile ein Internal Timer mit waitIfInitNotDone=1 gesetzt.
Das ist der Punkt wo er mir einfriert.

Wenn ich das waitIfInitNotDone auf 0 habe ich bei einem rereadcfg halt das problem, dass er einen 1wire sensor anmeckert den er
dann im nächsten moment wieder findet aber es friert nichts mehr ein.

Dann habe ich im InternalTimer weitergeloggt und bei: select(undef, undef, undef, $tim-gettimeofday());
steht das ganze dann ersteinmal.
Da tim$ in dem moment ja 300sec in der Zukunft liegt dauert die Geschichte dann erstmal 300sec.
In der Zeit steht alles, auch Fhemweb.
Dann kommt er zu: &{$fn}($arg); -> Ich muss dazu sagen, ich hab perl erst kürzlich das erste mal gesehn und kann nicht sagen was da passiert.
Auf jeden Fall läuft er danach sofort wieder zu dem select welches die ganze Sache wieder für 300s stoppen lässt...
Und das macht er so lange bis ich ihn mit Kill -9 davon abbringe. service stop oder shutdown now wirken nicht.

Hilft das weiter?


Ich kann dir auch gerne meine .cfgs zukommen lassen aber dann schlägst du wahrscheinlich die Hände überm Kopf zusammen

Hier erstmal nur der Auszug der die Ardinos mit OWX betrifft.
Weiter bin ich an dem Punkt auch noch nicht gewesen...

define Arduino1 FRM /dev/ttyACM0@57600
attr Arduino1 room Arduino
define FileLog_Arduino1 FileLog ./log/Arduino1-%Y.log Arduino1
attr FileLog_Arduino1 logtype text
attr FileLog_Arduino1 room Arduino
define Arduino2 FRM 3030 [192.168.10.225]
attr Arduino2 room Arduino
define FileLog_Arduino2 FileLog ./log/Arduino2-%Y.log Arduino2
attr FileLog_Arduino2 logtype text
attr FileLog_Arduino2 room Arduino
#define Arduino_OW_Temp1 OWX 40
#attr Arduino_OW_Temp1 IODev Arduino1
#attr Arduino_OW_Temp1 room Arduino
define Arduino_OW_Temp2 OWX 9
attr Arduino_OW_Temp2 IODev Arduino2
attr Arduino_OW_Temp2 room Arduino

MFG Lars

[ntruchsess]

Hilft das weiter?

Ja, perfekt!

Ich denke dass ich das mit der Info morgen Nachmittag oder Abends fixen kann, den code in der Ecke verstehe ich mittlerweile ich recht gut.

Code Auswählen Erweitern

&{$fn}($arg) ruft die Funktion 'fn', die dem InternalTimer übergeben wurde mit dem Argument '$arg' auf. &{..} dereferenziert eine Funktionsreferenz, (..) sind dann die zur Funktion gehörigen Klammern um die Aufrufparameter.

Gruß,

Norbert

[Jojo11]

Heute ist mein System im laufenden Betrieb einfach so eingefroren 
Ich kann natürlich nicht sagen, ob es am selben Thema liegt, aber ich habe sonst nichts geändert. Im logfile findet sich auch nichts Auffälliges.

Ich hatte mir in der Vergangenheit mal aufgrund von Stabilitätsproblemen einen cronjob eingerichtet:

Code Auswählen Erweitern


...
cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
if [ "$cnt" -eq "0" ] ; then
...


Der greift bei diesem Einfrieren aber leider auch nicht, so dass ich es nur zufällig entdeckt habe 

schöne Grüße
Jo

[ntruchsess]

ich habe $waitIfInitNotDone beim InternalTimer in OWX_Start und OWX_Kick jetzt auf 0 gesetzt. Damit ist der Hänger an der Stelle sicher weg.

Ich hatte bei der Voranalyse nicht genau genug nachgeprüft und übersehen, dass fhem.pl $init_done beim 'rereadcfg' erst [url=https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/fhem.pl#L1178nach dem event 'global REREADCFG' auf 1 setzt. Ob das Sinn macht, sollte man mal separat diskutieren, aber das - in Verbindung mit dem $wairIfInitNotDone=1 (und der Tatsache, dass OWX_Kick in dieser Konstellation recursiv InternalTimer() aufruft) war der Auslöser des Hängers.

Gruß,

Norbert

[justme1968]

das waitIfInitNotDone ist etwas das es eigentlich gar nicht gibt.

das ist scheinbar irgendein überbleibsel von etwas das in einem single threaded programm so wie es implementiert ist auch gar nicht geht. laut rudi weiß er inzwischen auch nicht mehr was er dich dabei gedacht hatte.

es darf niemals auf 1 gesetzt werden.

siehe hier: http://forum.fhem.de/index.php/topic,18707.msg124901.html#msg124901 und folgender.

gruss
  andre

[ntruchsess]

ja, das habe ich mich auch schon gefragt, was sich Rudi damals dabei gedacht hat. Ist aber schon 7 Jahre her, wundert mich nicht, dass er sich heute das selbe fragt

Das mit der InititialiizedFn, das Du hier anregst habe ich in meinen FRM-modulen modul-intern umgesetzt. Der Punkt ist nämlich, dass man mit einer NotifyFn auf 'global INITIALIZED' nicht erreichen kann, dass bei mehrstufigen Modulen die Client-module nach dem IODev initialisiert werden. Ich rufe die InitializedFn der Clients daher aus dem IODev-modul heraus auf. Im IODev benutze ich die NotifyFn. Wenn die DefineFn manuel aufgerufen wird ($init_done == 1) dann kann diese bei schon aktivem IODev direkt in die InitializeFn verzweigen.
Das funktioniert prima, mit der gleichen Logic kann man auch schön sauber die Client-instanzen reinitialisieren, wenn das IODev mal abgeklemmt und wiederangesteckt wird.

Gruß,

Norbert

[justme1968]

bei mehrstufigen modulen kannst du über $hash->{NotifyOrderPrefix} die reihenfolge zwischen server und client modul festlegen. so habe ich es bei OWServer/OWDevice gemacht. das geht eigentlich problemlos.

die unterscheidung zwischen automatischem start und manuellem define hab ich jeweils auch über $init_done abgefangen.

wichtig ist noch das man in der NotifyFn nicht nur auf INITIALIZED prüft sondern auch auf REREADCFG. sonst gibt es beschwerden

gruss
  andre

[Prof. Dr. Peter Henning]

Na, die Hauptsache ist, dass dies erst einmal behoben ist, ich hatte keine Minute Zeit dafür.

Nach wie vor offen ist die asynchrone Behandlung der 1-Wire-Abfragen - das ist auch durch das zusätzliche externe Framework von ntruchsess m.E. noch nicht zufriedenstellend gelöst.

LG

pah

[Jojo11]

Vielen Dank für den fix!
Läuft wieder wie es sollte 

schöne Grüße
Jo

[larsberghahn]

Hallo,
irgendwas ist aber immernoch nicht rund.
Nach ein paar Stunden bleibt FHEM wieder stehen.

Der letzte eintrag im Log ist
2014.03.27 23:34:34 1: 3030 disconnected, waiting to reappear

Ich hatte das vorgestern, hab gestern nochmal "Update" gemacht und dann die Nacht Stands auch wieder.
Irgendwas mit dem Ethernet Arduino wie es aussieht. Ist das einzige was bei mir was mit 3030 zu tun hat (Der Port)

Also FHEMWeb ist nicht erreichbar aber diesmal kann ich FHEM noch mit sudo service fhem stop beenden.

Was gibt es eigendlich für Debuggingmöglichkeiten in so einem Fall?

MFG Lars