PRESENCE Fhem Absturz

Begonnen von ChrisW, 03 Februar 2013, 15:54:42

Vorheriges Thema - Nächstes Thema

ChrisW

Das sind die letzten Logs:

2013.02.03 15:50:39 1: Terminated -7680
2013.02.03 15:51:33 1: Terminated -6356
2013.02.03 15:51:50 1: ERROR: Select error -1 (10038), error count= 0


Und das ist der Code den ich bisher nutze:
define HandyChris PRESENCE lan-ping 192.168.2.50 30
define watchdog_Anwesenheit watchdog HandyChris:absent 00:15 Handy:present { fhem "set Wohnzimmer_FunkSteckdose3 off";; fhem "setstate watchdog_Anwesenheit defined";;}
attr watchdog_Anwesenheit regexp1WontReactivate 1
Raspberry PI3 mit allem möglichen.

Markus Bloch

Hallo Chris,

geh ich richtig in der Annahme, dass das ganze auf Windows 7 läuft? Wenn ja, dann ist das durchaus möglich, da ich das Modul unter Linux entwickelt habe und keine Windows spezifischen Sachen eingebaut habe.

Was nutzt du für eine Perl Umgebung unter Windows? Dann kann ich das die Tage mal Nachstellen und korrigieren.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

ChrisW

Hallo,
ja genau nutze Win7 64 bit mit Active Perl.
Wäre Klasse ;)
Raspberry PI3 mit allem möglichen.

Markus Bloch

Ich teste das und geb dir Bescheid
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

Hallo Chris,

ich habe mir soeben die aktuellste Version ActivePerl von http://www.activestate.com/activeperl heruntergeladen und installiert. Habe ein FHEM installiert. Vorher nochmal ein update durchgeführt und anschließend ein PRESENCE Device definiert mit lan-ping.

Geht einwandfrei.

Version: ActivePerl-5.16.2.1602-MSWin32-x64

Hast du evtl. eine ältere Version von Active Perl?

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

ChrisW

5.16.1 hab ich.
Komisch nach ein paar Sekunden stürzt fhem ab
define HandyChris PRESENCE lan-ping 192.168.2.50 30
Raspberry PI3 mit allem möglichen.

ChrisW

Das steht im CMD Fenster:
Select error -1 (10038)
Error in PurgeComm at fhem.pl line 0.
Das Handle ist ung³ltig.
Error in GetCommTimeouts at fhem.pl line 0.
Error Closing handle 132 for \\.\com3
Das Handle ist ung³ltig.
Error closing Read Event handle 176 for \\.\com3
Das Handle ist ung³ltig.
Error closing Write Event handle 180 for \\.\com3
Das Handle ist ung³ltig.
Raspberry PI3 mit allem möglichen.

Markus Bloch

Hallo Chris,

auch wenn ich es mit Sicherheit nicht weis, so denke liegt es daran, dass sich PRESENCE unter Windows nicht mit einer CUL verträgt. Was man da genau machen kann, weis ich leider auch nicht.

Alternativ evtl. unter Windows eine zweite FHEM Instanz laufen lassen wo PRESENCE läuft und mit FHEM2FHEM koppeln.

Mehr kann ich dir da leider nicht helfen.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

ChrisW

oha immer wieder diese Windows Probleme :(
Dann muss ich wohl bei meiner eigenen Ping abfrage bleiben bis es vielleicht eine Lösung gibt.
Das komische es funktioniert ja ein paar Sekunden.
Raspberry PI3 mit allem möglichen.

ChrisD

Hallo,

Ich habe das gleiche Problem wenn ich das PRESENCE-Modul unter ActivePerl benutze. Soweit ich feststellen konnte führt der exit(0)-Aufruf in BlockingCall dazu dass unter anderem die seriellen Schnittstellen geschlossen werden, was zu den Fehlermeldungen 'Error in PurgeComm...' führt. Versuchsweise habe ich
exit(0);
durch
sleep($timeout*2);
ersetzt. Dadurch wird der Child-Prozess über den Kill in BlockingKill beendet und es wird nichts geschlossen. Die Kommunikation mit dem CUL (und einer FHZ1000) laufen damit problemlos. Allerdings führt dies zu einem Speicherleck von 8K pro Kill.

Ich habe jetzt zu Testzwecken Strawberry Perl installiert und hier scheint das Problem nicht aufzutreten (nach 1 Stunde mit 5 Pings alle 30s).

Grüße,

ChrisD

Markus Bloch

Hallo Chris,

das liegt daran, dass das Modul Blocking.pm von Rudi eher für die Linux-Welt gedacht ist. Ich bin aber drann hier entsprechende Modifikationen durchzuführen, damit das ganze auch unter Windows läuft.

Der Unterschied zwischen Linux und Windows in dem Falle ist, das unter Linux ein komplett eigenständiger Prozess erzeugt wird (eine Kopie des aktuell laufenden FHEMs), der komplett losgelöst vom FHEM Mutterprozess läuft (Forking). Unter Windows ist das so nicht möglich. Hier wird ein Thread unterhalb des FHEM Prozesses erzeugt, der aber noch in bestimmten Teilen mit dem Mutter-Prozess verbunden ist. Technisch gesehen ist das noch ein Prozess.

Ich habe mal soeben mit Active Perl rumprobiert und habe folgendes in der Blocking.pm verändert.

oben bei den ganzen use-Befehlen bitte folgende Zeile einfügen.


use threads;


Da wo du bereits exit(0); durch sleep ersetzt hast bitte deine Zeile durch folgendes ersetzen.


threads->exit();


Damit läuft es bei mir bisher sauber durch, der Thread wird auch immer ordentlich beendet (kann man unter Windows im Ressourcen-Monitor pro Prozess sehen).

Währe super falls du das bei dir mit Active Perl und Strawberry Perl verifizieren könntest.

Vielen Dank und Gruß

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

ChrisW

hey cool das scheint zu klappen. Bisher 15 Minuten ohne Probleme :=)
Was mich noch etwas stört sind die Log einträge:
2013.02.05 08:28:20 1: Terminated -4648
2013.02.05 08:28:41 1: Terminated -9136
2013.02.05 08:29:02 1: Terminated -1216
2013.02.05 08:29:11 1: Terminated -7244
Raspberry PI3 mit allem möglichen.

ChrisW

Und hier gerade eben nach 20 Minuten kommt folgende Konsolen meldung Fhem läuft aber noch:

select: Ein Vorgang bezog sich auf ein Objekt, das kein Socket ist. at C:/Perl64
/lib/Net/Ping.pm line 633.
ioctl failed: Ein Vorgang bezog sich auf ein Objekt, das kein Socket ist. at ./F
HEM/73_PRESENCE.pm line 367.


Raspberry PI3 mit allem möglichen.

ChrisW

Na toll nach einer längeren Zeit folgendes in der Konsole:
Select error -1 (10038)
Error in PurgeComm at fhem.pl line 0.
Das Handle ist ung³ltig.
Error in GetCommTimeouts at fhem.pl line 0.
Error Closing handle 132 for \\.\com3
Das Handle ist ung³ltig.
Error closing Read Event handle 176 for \\.\com3
Das Handle ist ung³ltig.
Error closing Write Event handle 180 for \\.\com3
Das Handle ist ung³ltig.
Raspberry PI3 mit allem möglichen.

Markus Bloch

Zitat von: ChrisW schrieb am Di, 05 Februar 2013 08:31hey cool das scheint zu klappen. Bisher 15 Minuten ohne Probleme :=)
Was mich noch etwas stört sind die Log einträge:
2013.02.05 08:28:20 1: Terminated -4648
2013.02.05 08:28:41 1: Terminated -9136
2013.02.05 08:29:02 1: Terminated -1216
2013.02.05 08:29:11 1: Terminated -7244

Das sind Log-Meldungen durch Blocking.pm. Hier müsste man im Falle einer Negativen PID (Windows-Thread-ID) den Kill verhindern. Da muss ich noch einen Patch fertig machen und mit Rudi abstimmen.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

ChrisW

das war der letzet FHEM Log eintrag bevor er abgestürzt ist :
2013.02.05 08:42:39 1: ERROR: Select error -1 (10038), error count= 0

Hier meine blocking.pm
##############################################
# $Id: $
package main;

=pod
### Usage:
sub TestBlocking() { BlockingCall("DoSleep", 5, "SleepDone", 8); }
sub DoSleep($)     { sleep(shift); return "I'm done"; }
sub SleepDone($)   { Log 1, "SleepDone: " . shift; }
=cut


use strict;
use warnings;
use IO::Socket::INET;
use threads;

sub BlockingCall($$@);

sub
BlockingCall($$@)
{
  my ($blockingFn, $arg, $finishFn, $timeout) = @_;

  my $pid = fork;
  if(!defined($pid)) {
    Log 1, "Cannot fork: $!";
    return undef;
  }

  if($pid) {
    InternalTimer(gettimeofday()+$timeout, "BlockingKill", $pid, 0)
      if($timeout);
    return $pid;
  }

  # Child here
  no strict "refs";
  my $ret = &{$blockingFn}($arg);
  use strict "refs";

  exit(0) if(!$finishFn);

  # Look for the telnetport
  my $tp;
  foreach my $d (sort keys %defs) {
    my $h = $defs{$d};
    next if(!$h->{TYPE} || $h->{TYPE} ne "telnet" || $h->{TEMPORARY});
    next if($attr{$d}{SSL} || $attr{$d}{password});
    next if($h->{DEF} =~ m/IPV6/);
    $tp = $d;
    last;
  }

  if(!$tp) {
    Log 1, "CallBlockingFn: No telnet port found for sending the data back.";
    threads->exit();
  }

  # Write the data back, calling the function
  my $addr = "localhost:$defs{$tp}{PORT}";
  my $client = IO::Socket::INET->new(PeerAddr => $addr);
  Log 1, "CallBlockingFn: Can't connect to $addr\n" if(!$client);
  $ret =~ s/'/\\'/g;
  syswrite($client, "{$finishFn('$ret')}\n");
  threads->exit();
}

sub
BlockingKill($)
{
  my $pid = shift;
  Log 1, "Terminated $pid" if($pid && kill(9, $pid));
}


1;
Raspberry PI3 mit allem möglichen.

ChrisW

Und mir ist noch etwas aufgefallen wenn ich das in Fhem eintrage:
define HandyChris PRESENCE lan-ping 192.168.2.50 30

Kommt eine 00_CUL error ( hab ich leider nicht mehr die Meldung )
Ich kann keine Funksteckdosen mehr schalten ..
2013.02.05 09:56:49 2: IT IODev device didn't answer is command correctly:   raw => No answer

Ausgebaut fhem restart geht wieder..
Raspberry PI3 mit allem möglichen.

ChrisD

Hallo,

Ich habe eine ganze Reihe an Tests mit diversen Blocking.pm Versionen (original, Patch von Markus, SVN mit Patch, eigene Varianten) sowie ActivePerl und Strawberry Perl gemacht. Leider habe ich bis jetzt keine einzige Kombination gefunden welche längerfristig funktioniert. Insbesondere wenn mehrere PRESENCE-Bausteine gleichzeitig verwendet werden kommt es relativ schnell zum Absturz.

Ich bin auch nicht sicher ob die Änderung mit thread->exit() verhindert dass die Schnittstellen geschlossen werden. Ich benutze eine FHZ1000PC und einen CUL. Im PortMonitor von Sysinternals kann ich sehen dass die Schnittstelle des CULs kurz nach dem Aufruf von thread->exit() geschlossen wird, die der FHZ1000PC dagegen nicht. Es kommt aber keine Meldung (Error in PurgeComm ...), es werden aber keine Daten mehr über den CUL empfangen.

Ich werde als nächstes versuchen Perl unter Cygwin zu verwenden, hier wird fork anscheinend nicht emuliert.

Grüße,

ChrisD





Markus Bloch

Hi Chris,

nach den heutigen Änderungen in PRESENCE und den letzten Änderungen habe ich bisher noch keinen Absturz von FHEM unter Windows gehabt.

Probier es morgen nach einem update mal bitte aus.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

ChrisW

hi, vor 5 Minuten Update gemacht nur die 1. Zeile wie es oben steht eingebaut. nach 1-2 Minuten folgendes in der Konsole:
Select error -1 (10038)
Error in PurgeComm at fhem.pl line 0.
Das Handle ist ung³ltig.
Error in GetCommTimeouts at fhem.pl line 0.
Error Closing handle 132 for \\.\com3
Das Handle ist ung³ltig.
Error closing Read Event handle 176 for \\.\com3
Das Handle ist ung³ltig.
Error closing Write Event handle 180 for \\.\com3
Das Handle ist ung³ltig.


und das im fhem Log:
2013.02.08 09:24:55 1: ERROR: Select error -1 (10038), error count= 0
Raspberry PI3 mit allem möglichen.

ChrisD

Hallo,

Ich habe das Update auf die neue Version gemacht. Leider ist das Problem damit nicht behoben, ich habe ähnliche Meldungen wie ChrisW mit ActivePerl und Strawberry.

Mit Cygwin läuft das PRESENCE-Modul mit dem CUL jetzt seit 30 Stunden. Mit dem neuen PRESENCE-Modul funktioniert es unter Cygwin aber nicht mehr da die Abfrage if($^O =~ m/Win/) ... auf Cygwin nicht zutrifft und somit versucht wird den Ping des Betriebssystems zu benutzen. Dabei passen aber weder die Aufrufparameter (-c) noch das Format der Rückgabewerte. Ich habe deshalb die Abfrage in if(($^O =~ m/Win/) || ($^O =~ m/cygwin/)) umgeändert.

Positiv bei Cygwin:
- PRESENCE funktioniert mit CUL, es wird bei jedem fork ein eigener Perl-Prozess gestartet
- shutdown restart funktioniert (ohne Modifikation an fhem.pl)

Negativ:
- aufwendigere Installation
- nach einem Neustart des Rechners kommt die Kommunikation zum CUL nicht zustande (Can't open /dev/ttyS12: Invalid argument), ein Mal fhem über Strawberry starten und CUL initialisieren lassen reicht aber aus. Da ich den Server quasi nie neu starte ist dies für mich kein Problem
- beim Starten von fhem kommt es manchmal zu einer längerer Wartezeit beim Öffnen des CULs, die Wartezeit hängt dabei von der Anzahl der PRESENCE-Bausteine ab (3 Minuten bei 4 Bausteinen, 5 Minuten bei 8)
- die geforkten Perl-Instanzen stürzen mit einer Exception ab, dies scheint aber keinerlei Auswirkung auf die Funktion zu haben, unschön ist nur dass das Shell-Fenster voller Stack-Traces ist

Beim PRESENCE-Modul sind mir auch noch ein paar merkwürdige Effekte aufgefallen die ich noch untersuche. Einer davon betrifft das Disable-Attribut. Wenn es auf 1 ist sollte das Modul meiner Meinung nach nichts machen. Es wird aber trotzdem ein Ping beim starten gemacht. In PRESENCE_Define wird nämlich immer (unabhängig vom Zustand von Disable) PRESENCE_StartLocalScan($hash); aufgerufen.

Im Moment werde ich bei Cygwin bleiben, kann aber weiterhin Tests mit den beiden anderen machen.

Grüsse,

ChrisD

Markus Bloch

Hallo Chris,

ich habe deinem Vorschlag entsprechend Cygwin mit aufgenommen und PRESENCE_Define() so angepasst, dass nun das disable-Attribut berücksichtigt wird.

Generell ist cygwin hier die beste Wahl, da es der Unix-Welt am nächsten kommt. Da ich unter Windows kein FHEM mit CUL betreibe, kann ich euch da leider nicht wirklich unterstützen. Ohne ein CUL läuft das Modul ohne Probleme unter Windows.

Ich bin daher über jeden Tipp dankbar um PRESENCE auch unter Windows mit CUL stabil zu bekommen.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

ChrisD

Hallo,

Ich habe deine Änderung eingespielt. Leider hat der Patch nicht den gewünschten Effekt. In meine Config-Datei habe ich:

define CHK_P1 PRESENCE lan-ping 192.168.0.100 15
attr CHK_P1 disable 1


Ich habe einige Log-Aufrufe in 73_PRESENCE hinzugefügt und festgestellt dass beim Aufruf von PRESENCE_Define Disable noch undefiniert ist. Erst 2s später wird Disable über PRESENCE_Attr gesetzt.

Die 2s Verzögerung kommen übrigens aus der Funktion InternalTimer. Diese blockiert fhem komplett da zum Zeitpunkt des Aufrufes aus PRESENCE_Define $init_done=0 und $waitIfInitNotDone=1 ist. Der Aufruf von InternalTimer aus der _Define-Funktion scheint mir keine gute Idee. Gibt es keine Möglichkeit global:INITIALIZED auszuwerten und erst hierüber die PRESENCE-Funktion zu starten ?

Grüsse,

ChrisD

ChrisW

Heute neuer Test immer noch:
c:\fhem>perl fhem.pl fhem.cfg
Select error -1 (10038)
Error in PurgeComm at fhem.pl line 0.
Das Handle ist ung³ltig.
Error in GetCommTimeouts at fhem.pl line 0.
Error Closing handle 132 for \\.\com3
Das Handle ist ung³ltig.
Error closing Read Event handle 176 for \\.\com3
Das Handle ist ung³ltig.
Error closing Write Event handle 180 for \\.\com3
Das Handle ist ung³ltig.


Es lief aber ca 4 Minuten

FHEMLOG:
2013.02.12 13:51:46 1: ERROR: Select error -1 (10038), error count= 0
Raspberry PI3 mit allem möglichen.

Reinerlein

Hi Markus,

wir hatten ja schon per PN Kontakt zu dem Thema...

Besteht denn in deiner Anwendungsstruktur die Möglichkeit die Thread-Beendigung zu verhindern?

Ich habe meinen Code für Sonos ja auch so umgestellt, dass ich denselben Thread immer wieder verwende, und die notwendigen Informationen und Aufträge in beiden Threads synchronisiere bzw. per Signalling und Queues transportiere.
Eine Baustelle habe ich da aber auch immer noch, mal schauen, was ich damit mache :-)

Vielleicht wäre das auch ein Ansatz bei dir. Allgemein wird das in den Perl-Foren, die sich mit Threading beschäftigen, auch empfohlen, da das Erzeugen eines Threads ja sehr Zeitaufwändig ist. Leider kann man es nur nicht immer so umsetzen (man kann ja z.B. keine Objekte transportieren o.ä.).

Grüße Reinerlein

justme1968

ein vorschlag in eine ähnliche richtung: wie wäre es den das ping über den presenced zu machen? der könnte einfach laufen bleiben und es wäre trozdem entkoppelt.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Markus Bloch

Zitat von: Reinerlein schrieb am Di, 12 Februar 2013 17:05Hi Markus,

wir hatten ja schon per PN Kontakt zu dem Thema...

Besteht denn in deiner Anwendungsstruktur die Möglichkeit die Thread-Beendigung zu verhindern?

Ich habe meinen Code für Sonos ja auch so umgestellt, dass ich denselben Thread immer wieder verwende, und die notwendigen Informationen und Aufträge in beiden Threads synchronisiere bzw. per Signalling und Queues transportiere.
Eine Baustelle habe ich da aber auch immer noch, mal schauen, was ich damit mache :-)

Vielleicht wäre das auch ein Ansatz bei dir. Allgemein wird das in den Perl-Foren, die sich mit Threading beschäftigen, auch empfohlen, da das Erzeugen eines Threads ja sehr Zeitaufwändig ist. Leider kann man es nur nicht immer so umsetzen (man kann ja z.B. keine Objekte transportieren o.ä.).

Grüße Reinerlein

Hallo Reinerlein,

dazu muss man erstmal 2 Sachen trennen.

1. PRESENCE ist ein völig normales FHEM Modul was so an sich erstmal keinerlei Threading oder dergleichen nutzt, bzw. steuert. Es verwendet das Modul Blocking.pm (welches von Rudi stammt) um einen zeitintensiven Aufruf von FHEM zu entkoppeln und dabei zu vermeiden, dass dieses stehen bleibt.

2. Blocking.pm ist ein Modul, welches eine übergebene Funktion abarbeiten soll, ohne FHEM dabei lahm zu legen. Dazu führt dieses Modul einen Fork durch (es wird ein zweiter Prozess erstellt, welcher eine 1:1 Kopie des Mutterprozesses ist). Dieser Fork-Prozess führt umgehend die gewünschte Funktion aus (bei PRESENCE den jeweiligen Test: Ping, FritzBox, Bluetooth) und gibt das Ergebniss über einen vorher erzeugten (oder bereits bestehenden) Telnet Socket an den Mutter-Prozess zurück.

Es wurde dabei diese Methode gewählt, da diese unter jedem Linux-System (egal welcher Platform) und auf allen FritzBoxen funktioniert gewählt.

Windows stellt hierbei eine Sonderlocke da, da "Forking" aus der Unix-Welt kommt: Da Windows kein Forking ermöglicht, erzeugen die meisten Perl-Interpreter unter Windows im Hintergrund einen neuen Thread, der sich (theoretisch) so verhalten soll, wie ein Fork-Child in der Unix-Welt.

Das ist allerdings leider nicht wirklich der Fall, wie ihr ja bereits festgestellt habt, aufgrund einiger Unterschiede in der Behandlung von File-Descriptoren, etc. Dazu kommen dann noch die eine oder andere Spezialität im Umgang mit seriellen Devices unter Windows in Perl (Da der Fehler ja nur bei einer CUL auftritt, aber nicht bei anderen File-Handles).

Aufgrund dessen, kam mein Vorschlag unter Windows einen Fork-Child mittels threads->exit(); zu beenden um ein Schließen der File-Descriptoren zu verhindern. Allerdings scheint dies nicht zu greifen.

In der ActivePerl-Dokumentation steht zum Thema "fork()" folgender Absatz:

On some operating systems, notably Solaris and Unixware, calling exit() from a child process will flush and close open filehandles in the parent, thereby corrupting the filehandles. On these systems, calling _exit() is suggested instead. _exit() is available in Perl through the POSIX module. Please consult your systems manpages for more information on this.

Hier könnte man noch ausprobieren den Fork-Child mittels POSIX::_exit(); zu beenden. Ich glaube mich aber erinnern zu können, dass dieses Modul bei ActivePerl nicht direkt mit dabei ist. Allerdings nutze ich Perl unter Windows leider nicht, evtl. hat hier jemand mehr Erfahrungen.

Ich hatte Rudi bereits vorgeschlagen das Modul Blocking.pm auf die verwendung von Threads (inkl. Thread::Queue) umzustellen. Dies hatte er aber (zurecht) verweigert, da dies unter FritzBoxen nicht funktionieren würde.

Ich hatte bereits mehrere Windows-spezifische Änderungen an Blocking.pm an Rudi herangetragen, welche er auch alle umgesetzt hat.

Leider kann ich da auch nicht wirklich helfen, da ich keinen CUL an Windows mit FHEM betreibe.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

Zitat von: justme1968 schrieb am Di, 12 Februar 2013 17:10ein vorschlag in eine ähnliche richtung: wie wäre es den das ping über den presenced zu machen? der könnte einfach laufen bleiben und es wäre trozdem entkoppelt.

gruss
  andre
Hi Andre,

prinzipiell währe das durchaus möglich. Ich weis allerdings nicht, ob der presenced auch unter Windows läuft (was ja hier aktuell das Hauptproblem ist).

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Markus Bloch

Hallo ChrisD

Zitat von: ChrisD schrieb am Di, 12 Februar 2013 11:18Hallo,

Ich habe deine Änderung eingespielt. Leider hat der Patch nicht den gewünschten Effekt. In meine Config-Datei habe ich:

define CHK_P1 PRESENCE lan-ping 192.168.0.100 15
attr CHK_P1 disable 1


Ich habe einige Log-Aufrufe in 73_PRESENCE hinzugefügt und festgestellt dass beim Aufruf von PRESENCE_Define Disable noch undefiniert ist. Erst 2s später wird Disable über PRESENCE_Attr gesetzt.

Die 2s Verzögerung kommen übrigens aus der Funktion InternalTimer. Diese blockiert fhem komplett da zum Zeitpunkt des Aufrufes aus PRESENCE_Define $init_done=0 und $waitIfInitNotDone=1 ist. Der Aufruf von InternalTimer aus der _Define-Funktion scheint mir keine gute Idee. Gibt es keine Möglichkeit global:INITIALIZED auszuwerten und erst hierüber die PRESENCE-Funktion zu starten ?

Grüsse,

ChrisD

Danke, das du mich darauf aufmerksam gemacht hast. Ich habe dies geändert. Als ich mit der Modul-Programmierung angefangen hatte, war mir nicht ganz klar, was dieser Parameter zu bedeuten hatte und wofür man den benötigt. Ich hab $waitIfInitNotDone auf 0 gesetzt um eine Blockierung hier zu verhindern.

Aus dem Wiki geht nicht hervor wie dieser Parameter genau zu verwenden ist.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

ChrisD

Hallo,

So weit ich die Dokumentation (und den Code) verstanden habe ist presenced.pl nur für Bluetooth-Scans. Somit ist es keine Lösung für lan-ping.

Das Problem was ich im letzten Beitrag (Di, 12 Februar 2013 11:18) beschrieben habe hat nicht mehr direkt mit dem ursprünglichen Problem zu tun, es tritt auch unter Linux auf. Soll ich dafür einen neuen Thread beginnen ?

Grüße,

ChrisD

justme1968

die idee war ja auch lan-ping in den presenced einzubauen und so das threading zu entkoppeln. das wäre das blockig nicht mehr nötig.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Markus Bloch

Zitat von: ChrisD schrieb am Di, 12 Februar 2013 18:47Das Problem was ich im letzten Beitrag (Di, 12 Februar 2013 11:18) beschrieben habe hat nicht mehr direkt mit dem ursprünglichen Problem zu tun, es tritt auch unter Linux auf. Soll ich dafür einen neuen Thread beginnen ?


Hallo Chris,

probier bitte morgen mal die Änderungen aus, die ich heute eingebracht habe. Wenn du da noch Probleme siehst, oder Fragen hast, dann mach bitte einen neuen Thread auf, damit wir hier wieder etwas übersichtlicher werden ;-)

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

ChrisD

Hallo,

Danke für das Update. Das Disable-Attribut wird jetzt beim Start korrekt ausgewertet.

Mit dem Vorschlag von Andre könnte das ursprüngliche Problem (PRESENCE Fhem Absturz) unter Windows gelöst werden. Ich werde dies mal austesten.

Grüße,

ChrisD

Markus Bloch

Zitat von: ChrisD schrieb am Mi, 13 Februar 2013 18:30Mit dem Vorschlag von Andre könnte das ursprüngliche Problem (PRESENCE Fhem Absturz) unter Windows gelöst werden. Ich werde dies mal austesten.


Gelöst wird das Problem dadurch nicht, sondern nur umgangen. Das Problem währe weiterhin für FritzBox und lokalem Bluetooth-Ping relevant.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

iCure

Gibt es denn hierfür schon eine Lösung? Würde gerne den PC im Netzwerk erkennen, ob dieser an oder aus ist.

Danke!

ChrisD

Hallo,

Das Problem ist nicht wirklich gelöst, wenn du FHEM unter Windows laufen hast gibt es 2 Möglichkeiten:

- Cygwin Perl verwenden
- modifizierten presenced verwenden

Grüße,

ChrisD

Markus Bloch

Hallo zusammen,

das eigentliche Problem hierbei lautet "Windows" und lässt sich leider nicht wirklich beheben. Perl ist eine Sprache, die aus der Unix-Welt kommt und auch entsprechen auf Konzepte aus der Unix-Welt aufbaut (in diesem Fall das Forking). Windows ist jedoch ganz anders aufgebaut und unterstützt Unix-Konzepte nicht.

Entsprechende Perl-Interpreter für Windows implementieren daher die notwendigen Unix-Konzepte für Perl auf ihre eigene Weiße. Jeder Interpreter geht dabei einen anderen Weg.

Ich kann euch als Lösung nur empfehlen: Nehmt nicht Windows sondern Linux. Das ist die einzige wirklich dauerhaft brauchbare Lösung.

Im Hinblick dass das Forking über kurz oder lang in FHEM an mehreren Stellen zunehmen wird (meiner Meinung nach), führt dabei auch alsbald kein Weg dran vorbei.

Viele Grüße

Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

ChrisD

Hallo,

Ich verwende FHEM seit 2 Jahren unter Windows ohne Probleme mit der von Andre vorgeschlagenen Lösung.

Das Forken selbst ist übrigens nicht das Problem sondern das korrekte Beenden nach dem fork, hierbei wird nicht immer alles aufgeräumt (dies betrifft auch subprocess welches in der aktuellen Form unter Windows nicht funktioniert). Die Probleme mit fork betreffen nicht nur Windows, auch unter Linux, wie z.B. in diversen Threads bezüglich DbLog beschrieben, kommt es zu unerwünschten Effekten.

Einen Vorteil hat Linux auf jeden Fall: Wenn du Probleme mit FHEM hast wird nicht direkt die Schuld auf das Betriebssystem geschoben.

Grüße,

ChrisD

iCure

Danke für eure Antworten, ich habe allerdings keine Ahnung, was bei der Lösung von Andre zu tun ist.
Gibt es denn bereits irgendwo diese bearbeitete presenced?

Oder gibt es irgendwo außerhalb des Threads mehr dazu?

Grüße,
Marvin

ChrisD

Hallo,

Anbei findest du meine modifizierte Version von presenced. Sie muss getrennt von FHEM gestartet werden. Wenn du die .pl Erweiterung mit Perl verknüpft hast reicht ein Doppelklick auf die Datei, andernfalls musst du sie mit
perl presenceWin.pl
starten.

Da das PRESENCE-Modul presenced nur für Bluetooth verwenden kann und ich PRESENCE nicht verändern wollte, musst du die zu überwachenden Geräte als 'Bluetooth-Geräte' gegenüber PRESENCE deklarieren:
define P_meineFB PRESENCE lan-bluetooth 19:21:68:17:80:01 127.0.0.1:5111

Dabei muss du die IP-Adresse etwas anders angeben, aus 192.168.178.1 wird 19:21:68:17:80:01.

Grüße,

ChrisD



iCure

Hallo,

Vielen lieben Dank für das teilen und die Erklärung! Werde es morgen testen und freue mich schon drauf, dass fhem noch weitere Dinge für mich erledigt :)

Grüße,

Marvin

borzo83

Danke @ChrisD, mit deiner Lösung klappt es nun!

Spiff

Hi ChrisD,

ich bedanke mich auch für diese Lösung!

Gruß
Spiff

xotox91

Hallo Zusammen,

ich versuche FHEM unter Windows Server zum laufen zu bekommen. Mein selbst gebauter CUL macht mir dabei leider einen Strich durch die Rechnung. Nach dem Start von FHEM funktioniert er eine gewisse Zeit tadellos bis im LOG folgende Warnungen erscheinen:

2018.03.21 19:01:34 1: PERL WARNING: Error in PurgeComm at ./FHEM/DevIo.pm line 480.
Das Handle ist ung�ltig.

2018.03.21 19:01:34 1: PERL WARNING: Error in GetCommTimeouts at ./FHEM/DevIo.pm line 480.
Error Closing handle 460 for \\.\com2
Das Handle ist ung�ltig.

Error closing Read Event handle 444 for \\.\com2
Das Handle ist ung�ltig.


Kurze Zeit später lässt sich FHEM gar nicht mehr aufrufen. Nach meinen Recherchen ist der Betrieb von FHEM unter Windows die Ursache für dieses Übel. In diesem Thread wurde das ja bereits ein paar mal angesprochen. Meine Frage ist, hilft mir das modifizierte presenced Script von Chris um dieses Problem in den Griff zu bekommen? Falls ja könnt ihr mir in ein paar kurzen Stichpunkten erklären wie? Das Script einfach parallel zu FHEM laufen zu lassen hat nicht geholfen.
Tausend Dank für euer Hilfe!

ChrisD

Hallo,

Das Skript kann nur helfen wenn du das PRESENCE-Modul mit lan-ping im Einsatz hast und du die Definition so umänderst wie oben beschrieben. In allen anderen Fällen hilft es nicht.

Grüße,

ChrisD