Lan adapter disconnected andauernd

Dietmar63 · 09 Mai 2013, 16:07:48

Ich habe soeben ins Modul geschaut und gesehen, dass es genau so ist wie du schreibst - ping wird nicht genutzt, http Aufrufe wirken aber vielleicht ähnlich.

Kann es dann sein, dass wenn der Receiver nicht angeschaltet ist, etwas länger auf eine Antwort gewartet wird, dadurch fhem, wie hier im Thread beschrieben, blockiert und dann HMLAN nicht wach gehalten wird?

Die Beschreibung von AK-868 deutet jedenfalls darauf hin: Nachdem er den Receiver angeschaltet hat war das Problem scheibar gelöst.

Vielleicht hilft es ja auch den Status des Receivers seltener abzufragen.

Markus Bloch · 09 Mai 2013, 16:17:29

Zitat von: Dietmar63 schrieb am Do, 09 Mai 2013 16:07Kann es dann sein, dass wenn der Receiver nicht angeschaltet ist, etwas länger auf eine Antwort gewartet wird, dadurch fhem, wie hier im Thread beschrieben, blockiert und dann HMLAN nicht wach gehalten wird?

Das kommt drauf an was AK-868 mit ausgeschaltet meint.

Meint er mit ausgeschaltet wirklich physikalisch den Strom zu trennen? Dann ja, da würde es zu der genannten 10 Sekunden-Verzögerung kommen, da der Receiver nicht antwortet.

Meint er mit ausgeschaltet den Receiver per Fernbedienung auszuschalten ohne aktivierten Network-Standby (keine rote Standby-Leuchte am Receiver)? Da würde es ebenfalls zu der 10 Sekunden Verzögerung kommen.

Meint er mit ausgeschaltet den Receiver per Fernbedienung auszuschalten mit aktivierten Network-Standby (rote Standby-Leuchte am Receiver leuchtet)? Dann nein. In diesem Fall antwortet der Receiver sofort und die Antwort wird sofort durch FHEM verarbeitet ohne nennenswerte Verzögerung.

Genau aus diesem Grund wird in der Commandref hingewiesen den Network Standby zu aktivieren. Was ich daher nur machen kann, ist die Wartezeit auf die HTTP Antwort runter zu setzen auf ca. 5 Sekunden. Weiter runter würde ich da nicht gehen wollen.

Viele Grüße

Markus

Markus Bloch · 09 Mai 2013, 16:18:27

Natürlich kann ich auch nur 1 Sekunde auf eine HTTP Antwort warten, aber das währe in dem ein oder anderen Fall zu wenig.

Markus Bloch · 09 Mai 2013, 16:40:30

Ich habe im SVN die Wartezeit jetzt auf 4 Sekunden gesetzt. im HMLAN wird aller 25 Sekunden ein KeepAlive gesendet was innerhalb von 30 Sekunden ankommen muss. Damit sollte also noch 1 Sekunde Luft bleiben.

Bitte morgen via update installieren oder direkt aus dem SVN ziehen.

Viele Grüße

Markus

AK-868 · 09 Mai 2013, 16:49:05

Ich hab getrennt geschrieben.

Getrennt = Kein Netzwerk zugriff
Getrennt = Network Standby nicht aktiv
Getrennt = Kein Strom

Ich habe noch ganz Oldschool eine Steckdosenleiste mit Schalter daran. Das soll sich aber bald ändern mit einem EQ-767-93.

Da wird der Yamaha aber auch keinen Strom haben. Ohne Strom kein Network Standby.

Oder ich muß irgendwann wenn ich das mal kann ein Programm schreiben, das wenn ich nicht Zuhause bin der Yamaha nicht definiert ist.

Wenn ich dann hier her komme er definiert wird.

Was FEHM angeht bin ich noch gaaaanz unten.

Andre

Markus Bloch · 09 Mai 2013, 16:54:59

Versuchs erstmal morgen mit dem update ;-)

Jeder hat mal klein angefangen.

Viele Grüße

Markus

AK-868 · 09 Mai 2013, 17:07:02

OT:

Update ist schon drauf, oder gibts schon wieder was neues?
Yamaha lässt sich ja auch Steuern, alles super ;)

Lad-Adapter ist dran und zwei aktoren für Jalousien sind jetzt verbunden.

Ich such gerade rum wie ich die umbenannt bekomme. Im Wiki steht da ist nix mit umbennen... naja...
Vorallem die Fahrzeiten sind noch utopisch, ich möchte die auch ändern? FHEM How to ich google schon überdurchschnittlich viel ;)

Markus Bloch · 09 Mai 2013, 17:13:50

Ab morgen wird mit eine Update eine neue Yamaha-Version verteilt, die FHEM nicht mehr so stark behindert, so das die LAN Disconnects weniger bis gar nicht mehr vorkommen sollten.

Um ein Device umzubenennen einfach in der Oberfäche oben "rename <name-alt> <name-neu>" eingeben.

Um die Fahrzeiten einzustellen einfach die Fahrzeiten messen und dann mit den Befehlen eintragen:

Code Auswählen


set <name> regSet driveUp 26.0              # Fahrtzeit nach oben
set <name> regSet driveDown 26.0            # Fahrtzeit nach unten (ist meistens identisch mit der Fahrtzeit nach oben
set <name> regSet driveTurn 0.2             # Die Zeit die gebraucht wird um die Fahrtrichtung zu wechseln

Alle angaben in Sekunden mit einer Kommastelle.

Viele Grüße

Markus

AK-868 · 09 Mai 2013, 17:37:49

Hallo Markus, echt super das du mir da so hilfst!!
Bin dir zu Dank verpflichtet

martinp876 · 09 Mai 2013, 19:45:15

@Markus
Ich halte alle Wartezeiten über 100ms für unschön, über 1sec für nicht akzeptabel. Immerhin hat dies Auswirkungen auf das schalten und anderes mehr.
Das Disconnect wird es wahrscheinlich beheben, es macht aber FHEM instabil und unzuverlässig.

Im presents modul ist bereits eine einfache Implementierung aktiv, die solche Wartezeiten dispatched. Es ist auf jeden Fall eine Möglichkeit, wird es auch noch einmal verbessert, so dass man einen sauberen parallel-prozess am laufen hat.

Wäre cool, wenn du das Warten aus dem main-process entfernen könntest.

Gruss
Martin

Markus Bloch · 09 Mai 2013, 20:09:16

Werd ich mich demnächst mal drum kümmern.

Dietmar63 · 09 Mai 2013, 21:47:00

@ Martin
@ Andre

Da habe ich ja ordentlich was losgetreten.

Ist denn niemand dabei, der das 98_WOL testen kann. Das war nämlich meine eigentliche Absicht. Auch dort ist ein
ping enthalten, der Blockieren verursachen kann, den ich ausgebaut habe. Ich würde es nicht so gern einchecken bevor nicht jemand Drittes darauf geschaut hat:
Link

Markus Bloch · 09 Mai 2013, 22:11:44

Hallo Dietmar,

ich habe mir dein Modul angeschaut und würde es gerne noch überarbeiten da hier noch einige wichtige Details fehlen.

* UndefFn um einen laufenden Fork zu beenden bei einem Shutdown oder Neustart
* eine adequate AbortFn inkl. Argumenten um den InternalTimer weiterlaufen zu lassen im Falle eines Abbruchs
* verhindern von parrallelen aufrufen, die sich sonst später hochschaukeln können

Dies sind alles Randdetails die sich im Laufe der Zeit bei meinem PRESENCE-Modul offenbart haben. Ich würde das gerne noch einmal überarbeiten wollen. Was ich aber erst ab Samstag schaffen würde.

Viele Grüße

Markus

Dietmar63 · 09 Mai 2013, 22:23:25

das wäre klasse!

Dietmar63 · 10 Mai 2013, 10:55:34

Zitat von: Markus Bloch schrieb am Do, 09 Mai 2013 22:11Hallo Dietmar,

ich habe mir dein Modul angeschaut und würde es gerne noch überarbeiten da hier noch einige wichtige Details fehlen.

* UndefFn um einen laufenden Fork zu beenden bei einem Shutdown oder Neustart
* eine adequate AbortFn inkl. Argumenten um den InternalTimer weiterlaufen zu lassen im Falle eines Abbruchs
* verhindern von parrallelen aufrufen, die sich sonst später hochschaukeln können

Dies sind alles Randdetails die sich im Laufe der Zeit bei meinem PRESENCE-Modul offenbart haben. Ich würde das gerne noch einmal überarbeiten wollen. Was ich aber erst ab Samstag schaffen würde.

Viele Grüße

Markus

ich sehe mir deine Anmerkungen heute nochmals an. Presence ist ja ein gutes Beispiel.
Dann ist es vielleicht schon am Samstag fertig.