OWX: DS2480 detected/re-detected

[ntruchsess]

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

das kommt, wenn es auf der Netzwerkverbindung zum Arduino einen Fehler gibt (oder dieser sich abmelden würde, was in der Firmata aber nicht vorgesehen ist, die versucht im Fehlerfall sofort wieder zu verbinden). Eigentlich ist das (aus FHEM bzw. FRM-sicht) kein wirklicher Fehler, ab dem Moment wartet FRM wieder darauf, dass der Arduino sich wieder meldet.

Hängen sollte das in der Zeit natürich nicht, könnte aber sein, dass OWX in dem Moment grade auf eine Antwort wartet, in der Zeit reagiert die Weboberfläche nicht (in der synchronen OWX-Version, ich bin grade dabei die asynchrone Version mit den letzten Änderungen im IODev-handling anzupassen, damit blockiert OWX nicht alles während es auf die Antwort wartet).
Ich schau mir aber erst mal den code in der Ecke des Tcp-Verbindungsabbruchs genauer an, eigentlich sollte OWX beim Warten sofort auf einen Fehler laufen wenn die Verbindung zum Arduino unterbrochen ist, aber das funktioniert mit dem IODev-handlich umbau eventuell nicht mehr sauber.
Ich muss mir aber erst mal einen Reproducer bauen (eine Firmata, die sich regelmäßig selber disconnected, ein bischen wartet und sich dann wieder meldet). Wenn man einfach das Netzwerkkabel zieht, dann dauert es manchmal sehr lang, bis o.g. Meldung überhaupt kommt.

zum Debuggen kann man im FRM (oder global) verbose auf 5 setzten, dann sieht man ob bzw. was vor dem Fehler noch über die Leitung ging. Ob das in dem Fall weiterhilft kann ich aber nicht sagen - wenn es hängt, dann kommuniziert es vermutlich auch nicht mehr... Da kann man eigentlich nur an geeigneter Stelle ein paar weitere Log-meldungen in den code einbauen.

Gruß,

Norbert

[ntruchsess]

gelöscht (doppelpost)

[larsberghahn]

Hallo,
ich habe 1wire am Ethernet wegen der hänger erstmal wieder deaktiviert. Ist imo aber auch nicht tragisch.

Auf die Asynchrone Variante bin ich schon sehr gespannt
Die gibts dann aber erstmal nur auf eigene Gefahr zm testen vom Github oder?

MFG Lars

[ntruchsess]

Auf die Asynchrone Variante bin ich schon sehr gespannt
Die gibts dann aber erstmal nur auf eigene Gefahr zm testen vom Github oder?

ja, erst mal auf Github. Die Changes aus dem SVN-trunk habe ich grade schon gemerged - ich will noch die Anpassungen an den OWxxx-modulen von PAH asynchron aktivieren und testen bevor ich es auf Github hochlade. Sollte morgen abend oder so drin sein.

Gruß,

Norbert

[larsberghahn]

Hallo,

das hört sich ja gut an, aber nur die Ruhe bei dem schönen Wetter komm ich eh nicht viel dazu

MFG Lars

[dirkbn]

Bei mir "friert" FHEM seit ein paar Tagen auch komplett ein. Ich starte meinen Fritz neu und dann läuft FHEM (mit 1-wire) wieder ein paar Tage. Seit heute jedoch nicht mehr, in der Logfile steht dafür das hier :
2014.03.30 20:13:01 1: usb create starting
2014.03.30 20:13:02 3: Probing TCM310 device /dev/ttyUSB0
2014.03.30 20:13:02 3: Probing TCM120 device /dev/ttyUSB0
2014.03.30 20:13:03 3: Probing FHZ device /dev/ttyUSB0
2014.03.30 20:13:03 3: Probing TRX device /dev/ttyUSB0
2014.03.30 20:13:04 3: Probing ZWDongle device /dev/ttyUSB0
2014.03.30 20:13:04 3: Probing FRM device /dev/ttyUSB0
2014.03.30 20:13:10 1: usb create end
In der Oberfläche von FHEM erscheint Der Adapter aber nicht.
Auch "update" brachte keine Änderung. Am 1-Wire-Adapter dürfte es nicht liegen,. denn am Windows-PC wird der Adapter erkannt und die angeschlossenen Sensoren ausgelesen.
Ziehe ich den 1-Wire-Adapter ab und starte neu, dann erscheint der Eintrag nicht.

[ntruchsess]

@dirkbn

ein paar Details wären jetzt schon nicht schlecht: Art des Adapters, fhem-bzw owx- Version, fhem.cfg (owx-relevante Einträge)...
Du kannst erst mal den loglevel von OWX hochdrehen (oder global verbose auf 5), damit man überhaupt was relevantes sieht.

@lars:
bin doch nicht fertig geworden, das Wetter war zu gut und beim Integrieren der von Pah gemergten OWX-clients im asynchronen Modus gibts noch ein bischen zu tun.

- Norbert

[Prof. Dr. Peter Henning]

@ntruchsess: Klar - das ist ja auch ungetestet.

Ich denke übrigens, dass die gesamte Bussuche (und damit auch das Verify) in den externen Thread ausgelagert werden müssen. Sonst bremst jeder OWID nach wie vor.

LG

pah

[ntruchsess]

@ntruchsess: Klar - das ist ja auch ungetestet.

kein Problem, ich bin halt erst jetzt dazugekommen das mal zusammenzuführen. Wenn es grundsätzlich läuft werde das asynchrone OWX wohl auch erst mal als '00_OWX_ASYNC.pm' einchecken. Dann kann jeder nach Gusto damit testen ohne Files aus anderen Quellen zusammensuchen zu müssen.

Ich denke übrigens, dass die gesamte Bussuche (und damit auch das Verify) in den externen Thread ausgelagert werden müssen. Sonst bremst jeder OWID nach wie vor.

Prinzipiell fände ich Multithreadding an der Stelle auch prima, das asynchrone OWX-modul habe ich ja auch erst mal Thread-basiert geschrieben. Bis auf das Stoppen des Threads hat auch alles einwandfrei funktioniert. Beim Stoppen ist mir der Perl-prozess aber immer mit einer Access-violation abgeschmiert (also ein Bug im Perl, nicht im perl-code). Wobei man für Multithreadding eigentlich FHEM grundsätzlch um einen Threadpool erweitern müsste, den sich die Module teilen. Ein Thread in Perl ist leider keine(!) leichtgewichtige Sache und sollte möglichst als erstes nach dem Start des Perl-prozesses erzeugt werden. Das kann ein Modul (das ja auch jederzeit neu geladen werden kann) nicht leisten, da hängt in jedem Background-thread erst mal eine komplette Kopie aller Variablen des aktuellen FHEM-prozesses mit drin.

Gruß,

Norbert

[ntruchsess]

@ntruchsess: Klar - das ist ja auch ungetestet.

Ich hab in die OWX-Clients grade ein autodetect for asynchrones OWX eingebaut und ins SVN committed. Das erkennt, wenn der Type des IODevs 'OWX_ASYNC' ist. Im zukünftigen OWX_ASYNC.pm muss ich aber noch ein bischen basteln (redundante Methoden entweder umbenennen oder entsorgen), damit das sauber mit OWX.pm koexistieren kann.

Gruß,

Norbert

[ntruchsess]

asynchrones OWX geht im dazugehörigen Thread weiter...