Hallo zusammen,
bei Shell Kommandos kann man ja ein Blockieren des Systems mittels "&" am Befehlsende quasi verhindern.
Ich habe das in folgendem qx Aufruf probiert, jedoch blockiert mein FHEM trotzdem und perfmon schlägt an:
my $smstext = qx(sudo /usr/bin/gnokii --getsms SM 0 2>&1 &)
(mit gnokii sende und empfange ich SMS; in diesem Fall wird der SMS Speicherplatz 1 ausgelesen.)
Gibt es bei qx() auch einen Parameter, der trotz Rückgabewert ein Blockieren verhindert? Bevor ich auf eine zweite FHEM Instanz ausweiche, wollte ich die Frage hier lieber noch einmal stellen..
Danke für eure Hilfe
Ronny
rückgabewert und non blocking lässt sich so nicht kombinieren.
entweder kompliziert mit NonBlocking.pm oder einfach in dem man nicht direkt die rückgabe abwartet sondern auf shell seite nach dem das kommando durch ist das ergebnis zurück an fhem meldet. mit nc oder fhem aufruf.
dann kann man auch das qx durch "..." ersetzen und hat auch gleich noch die log ausgaben im fhem log.
gruss
andre
Hallo Andre,
meinst du das so, dass ich dann aus FHEM heraus eine .sh Script Datei aufrufe, die alles enthält, unter anderem auch
/opt/fhem/fhem.pl 7072 "setreading sms $smstext"
?
Aber es wird dann doch trotzdem auf die Rückgabe vom gnokii Aufruf gewartet?
Hast du evtl. ein konkreteres Beispiel für mich? Oder ein paar Wortfetzen, nach denen ich hier forumsuchen kann? ("nc" war nicht so wirklich ergiebig)
Gruß
Ronny
genau so. oder statt fhem.pl mit echo "setreading sms $smstext" | nc <ip> 7072
das script rufst du in fhem mit "xxx.sh" auf (inklusive der " ). da wird nicht gewartet sondern es passiert asynchron im hintergrund.
gruss
andre
Ich benötige noch einen Schritt davor: Wie bekomme ich den Output in eine Variable?
SMSINBOX=`sudo /usr/bin/gnokii --getsms SM 0 2>&1 &` oder SMSINBOX="sudo /usr/bin/gnokii --getsms SM 0 2>&1 &" mit oder ohne & oder &1 am Ende funktioniert irgendwie nicht.
//edit: OK, ich habs, das 2>&1 gehörte scheinbar zusammen. Ohne dem geht es nun.
Argh, für einen Linux Noob sind hier aber auch ein paar Hürden versteckt... ich wollte nun mit fhem.pl das cmd absetzen
sudo /opt/fhem/fhem.pl 7072 setreading sms rawdata 12345
Auch wie in der Commandref beschrieben mit doppelten "" wird das Reading nicht geändert. Es gibt aber auch keine Fehlermeldung in der Shell.
Argh!
Ja, man könnte in der Commandref noch erwähnen, dass bei gesetzten Telnet Passwort der Aufruf so aussehen muss:
sudo /opt/fhem/fhem.pl 7072 PASSWORT setreading sms rawdata 12345
So weit, so trial and error. Das nächste Ding ist nicht, dass das Ganze scheinbar noch in `` gesetzt werden muss, sonder mein Rückgabewert kann nicht in ein Reading transformiert werden - aufgrund mehrerer Zeilen? Ich weiß gerade nicht, wo ich anfangen soll, das Problem genauer zu beschreiben. Für heute habe ich eh erstmal die ** voll. Hoch lebe Windows!! :D
Zitatmein Rückgabewert kann nicht in ein Reading transformiert werden - aufgrund mehrerer Zeilen?
Dazu kann man alles mit einer zweiten SMSINBOX=`echo $SMSINBOX` auf eine Zeile umbauen. Oder man versieht das Zeilenende mit \ mit SMSINBOX=`echo "$a" | sed 's/$/\\/'`.
Die zweite Variante ueberlebt erst ab dem update morgen einen FHEM-Restart, da mehrzeilige Readings bzw. Events unerwuenscht sind. Benutzer sollen Attribute setzen, z.Bsp. comment
ZitatHoch lebe Windows!!
Frei nach dem Motto: wozu Grundlagen lernen um Probleme selbst loesen zu koennen, lieber ist man dem Hersteller ausgesetzt. Mag je nach Aufgabe sogar die richtige Loesung sein.
ZitatHoch lebe Windows!!
Nun ja, jeder so, wie er kann.
LG
pah
Ja mei.. immer drauf auf die Windows User! Mit der Powershell wäre ich ganz sicher schneller. Die Linux Shell ist für mich eher ein kleines Mysterium. Was ich in den letzten Monaten wirklich schönes auf diversen Einplatinencomputern durch Zusammenklauben installiert und konfiguriert habe... 1-2 Jahre später schaue ich hier bestimmt wie ein Schwein ins Uhrwerk :o aber back to topic.
Danke, Rudi, für den Tipp samt Implementierung; dann teste ich deine zweite Variante gerne morgen einmal.
...und bin gespannt auf die nächsten Baustellen. Aber dank der netten User, die auch zur Thematik antworten :P, schaffe ich das bestimmt.
Du kannst doch fhem auf Windows laufen lassen, oder Windows auf dem Pi installieren. Soll wohl angeblich gehen. Und "die Linux Shell" gibt es nicht. Es gibt eine Menge Kommandozeileninterpreter für nix basierte Systeme. Darunter auch die Bourne-again shell die Du wohl meinst.
Auch wenn es sicherlich sogar headless ginge, es ist schon gut so, wie es ist (mit Linux) (kriege ich jetzt auch ein paar Likes?? ;))
Jedenfalls ist genau das der Grund, weswegen ich nur ungern auf sh Scripte und cronjobs etc. auf OS Ebene ausweiche, sondern weitestgehend alles in FHEM löse. Das ist für mich besser verständlich, überschaubar und transportabel. ...Um mal den Kreis der Bourne Verschwörung mal wieder zum Thema zu schließen, ob man einen shell Befehl in ein FHEM Konstrukt inkl. nonblocking.pm verpacken kann.
Bin da wohl mal wieder der einzige oder keiner will seine Insellösung preisgeben?
ZitatBin da wohl mal wieder der einzige oder keiner will seine Insellösung preisgeben?
Ich vermute Du bist der Erste, der die mehrzeiligen Rueckgabewerte eines laenger laufenden Shell-Programmes in einem Reading haben will. Als Beweis habe ich, dass bis gestern fhem.pl mehrzeilige Readings nicht unterstuetzt hat. Ich meine, in dieser Diskussion sind alle Zutaten fuer die Umsetzung beschrieben. Ueblicherweise fasst der Thread-Ersteller dann die Loesung zusammen, manche machen sogar einen fhemwiki Eintrag.
Und ich habe meine Insellösung hier im Forum mal kunt getan. War im Zusammenhang mit lepresence und gatttool zum Batterie auslesen von G-Tags.
Ich schau mal im Laufe des Tages.
Bittel schön
https://forum.fhem.de/index.php/topic,28753.msg501336.html#msg501336
Bei Fragen einfach fragen.
Ein mehrzeiliges Reading macht ungefähr soviel Sinn wie ein Klotz am Bein. Das ist nämlich nur extrem umständlich weiter zu verarbeiten.
Also schlage ich doch vor, sich einmal, statt über Linux herumzumeckern und Windows hoch leben zu lassen, die Frage zu stellen: Warum ist diese Vorgehensweise so ungewöhnlich ? Könnte es vielleicht daran liegen, dass diejenigen, die mehr von Linux und Shells oder Programmierung im Allgemeinen verstehen, das für schlecht halten ?
LG
pah
Zitat von: CoolTux am 12 November 2016, 07:21:33
Bittel schön
https://forum.fhem.de/index.php/topic,28753.msg501336.html#msg501336
Bei Fragen einfach fragen.
Hallo CoolTux, das sieht gut aus, hab vielen Dank. Bevor ich weitere Fragen stelle, teste ich damit mal ein bißchen rum.
Ich habe inzwischen zwar herausgefunden, dass mein SMSInbox Aufruf doch nicht bei perfmon anschlägt. Aber auch wenn es knapp unter 1 Sek. dauert, wäre es verbesserungswürdig. Außerdem lungern noch diverse andere qx() Aufrufe in meinen Funktionen.
Sollte ich am Ende eine halbwegs generische Lösung haben, stelle ich die natürlich gern allen zur Verfügung.
Gruß
Ronny
Ich habe Cooltux' Funktion nun ein wenig umgestrickt, so dass ein System Aufruf nun folgendermaßen möglich ist:
systemCommand(COMMAND, [{DEVICE READING}])
COMMAND: Systemkommando, bspw. "sendEmail -f 'smarthome\@mailbox.org' -t ..."
DEVICE READING: Optionales Devicereading, in welches ein eventueller Rückgabewert geschrieben wird, bspw. "Lampe state" oder "SMS inbox"
Ein vollständiges Beispiel für den non-blocking E-Mail Versand:
systemCommand("sendEmail -f 'smarthome\@gmx.net' -t 'fhemuser\@mailbox.org' -u 'Subject' -m 'Subject Text ' -s 'mail.gmx.net:25' -xu 'smarthome\@gmx.net' -xp 'p@ssw0rd' -o tls=yes -o message-charset=utf-8", "Mail sent");
Danke nochmal an Cooltux für den wertvollen Input!
Ich frage mich, ob man bei fehlendem Rückgabewert SystemCommand_Done nicht überspringen könnte?
Es wäre schön, wenn es noch jemand anders testen könnte.
Gruß
Ronny
Code
package main;
use strict;
use warnings;
use POSIX;
use Blocking;
sub myUtils_SystemCommands_Initialize($;$) {
my ($hash) = @_;
}
sub systemCommand($;$) {
my ($command, $reading) = @_;
$command = encode_base64($command,"");
$reading //= 0;
$reading = encode_base64($reading,"");
$command .= "|".$reading;
my $hash = $defs{$command};
Log3 "SystemCommand", 4, "Sub systemCommand - START: $command";
BlockingKill($hash->{helper}{RUNNING_PID}) if(defined($hash->{helper}{RUNNING_PID}));
$hash->{helper}{RUNNING_PID} = BlockingCall("systemCommand_Run", $command, "systemCommand_Done", 60, "systemCommand_Aborted", $hash) unless(exists($hash->{helper}{RUNNING_PID}));
Log3 "SystemCommand", 4, "Sub systemCommand - START BLOCKING CALL - $command";
}
sub systemCommand_Run($) {
my ($string) = @_;
my ( $command, $reading ) = split("\\|", $string);
my $result;
Log3 "SystemCommand", 4, "Sub systemCommand - BEGIN SystemCommand: $command";
my $cmd = decode_base64($command);
$result = qx($cmd);
Log3 "SystemCommand", 4, "Sub systemCommand - END SystemCommand: $command, Result: $result";
if (!$result) {
$result = 0;
}
$result = encode_base64($result,"");
return "$command|$reading|$result";
}
sub systemCommand_Done($) {
my ($string) = @_;
my @a = split("\\|",$string);
my $hash = $defs{$a[0]};
my $name = $hash->{NAME};
my $reading = $a[1];
my $result = $a[2];
delete($hash->{helper}{RUNNING_PID});
Log3 "SystemCommand", 3, "Sub systemCommand_Done - $name) - Der Helper ist disabled. Daher wird hier abgebrochen" if($hash->{helper}{DISABLED});
return if($hash->{helper}{DISABLED});
$reading = decode_base64($reading);
if ($reading) {
if ((split(" ",$reading)) == 2 && $defs{(split(" ",$reading))[0]}) {
$result = decode_base64($result);
# add slashes at the end of lines for valid multiline readings
$result =~ s/\n/\\/g;
# $result =~ /(Sender:\s)(\+\d*)\s/;
fhem "setreading " . (split("\\|",$reading))[0] . " " . (split("\\|",$reading))[1] . " " . $result;
Log3 "SystemCommand", 4, "Sub systemCommand_Done - Result: $result, Reading: $reading";
} else {
Log3 "SystemCommand", 3, "Sub systemCommand_Done ERROR - device reading '$reading' not valid or device does not exist. Use setreading syntax like 'Device MyReading'";
}
} elsif ($result) {
Log3 "SystemCommand", 4, "Sub systemCommand_Done INFO - existing system command result has been ignored because you did not specify a device reading.";
}
}
sub systemCommand_Aborted($) {
my ($hash) = @_;
my $name = $hash->{NAME};
delete($hash->{helper}{RUNNING_PID});
Log3 "SystemCommand", 3, "Sub systemCommand_Aborted - $name - The BlockingCall Process terminated unexpectedly. Timedout.";
}
1;
//edit: Code robuster gemacht bei den Device Readings
Hallo Ronny,
Eine Rückgabefunktion muss es immer geben und in diese muss auch bei erfolgreichen Ausführen gesprungen werden. Schließlich muss ja der Fork auch sauber beendet werden ;)
Grüße
Alles klar, es sah mir ja auch danach aus, als würde da noch ein bisschen Magic passieren..
Ich habe die Funktion jetzt problemlos beim E-Mail Versand und dem aus den Eingangsthreat beschriebenen SMS Inbox Szenario eingesetzt.
Das Thema mit den Backslashes am Zeilenende habe ich zwar eingebaut, verstehe ich aber doch noch nicht ganz. Denn das Reading frisst auch mehrzeiligen Input ohne "\" !?
Gruß
Ronny
Noch etwas zum Thema:
Führt ein grep auf Perl Ebene innerhalb von FHEM auch zu Freezes?
Ich hole mir diverse Gerätschaften via
my @devs = grep { $defs{$_}{NAME} =~ m/^Licht.Aussen.*$/ } keys %defs;
Dort, wo perfmon wegen Freezes anschlägt, folgt dann noch ein Logging der Status der Geräte mittels "trigger $dev $status" (addLog). Aber das Logging wird es doch wohl erst recht nicht sein?
FHEM arbeitet generell single threaded. Vereinfacht gesagt ist FHEM für x Sekunden blockiert, wenn eine Routine x Sekunden läuft. Das Durchsuchen eines Hash dauert nicht lange, das Schreiben (auch von logs) kann, abhängig vom I/O System und der Datenmenge, schon etwas länger dauern. Apptime hilft beim Suchen des "Übeltäters".
Ist es denn geplant, zumindest solche arbeitsintensiven Prozesse in FHEM auf non-blocking umzustellen? Immerhin leben wir ja gerade in einer Zeit voll billiger Multi Core CPUs.
Das Einfachste wäre dann wohl die erwähnte zweite FHEM Instanz samt FHEM2FHEM? Oder frisst der Verwaltungsoverhead (bei fhem und beim Anwender) die Vorteile wieder auf?
Da sich das bei 15 TFKs sich auf 1,3 Sek. Freezes summiert und das Logging absolut zeitunkritisch ist, habe ich mir nun mit einem vorangestellten sleep beholfen:
fhem("sleep 0.1 ; trigger $dev $logentry << addLog");
Ich frage mich nur, ob die 0,1 Sekunden Ausführungszeit zwar perfmon genügen, aber ein Tastendruck zu diesem Zeitpunkt dann doch wieder verzögert ausgeführt wird.
ZitatIst es denn geplant, zumindest solche arbeitsintensiven Prozesse in FHEM auf non-blocking umzustellen?
Welche arbeitsintensive Prozesse meinst du?
Ich plane keine Umstellung auf Multithreaded, da vieles dagegen spricht:
- perl is mAn nicht dafuer gebaut
- viel "legacy" FHEM-Code, was auch nicht dafuer gebaut wurde, und angepasst werden muesste
- Race-Conditions zu debuggen ist nicht lustig, und in FHEM koennte so einiges Nebenlaeufig sein.
- Locking wird nicht von jedem verstanden bzw. wenn irgendwo fehlt, sieht man das nicht auf Anhieb. Vmtl. haben die meisten FHEM-Modul-Autoren keine Erfahrung mit Multithreading.
ZitatDa sich das bei 15 TFKs sich auf 1,3 Sek. Freezes summiert und das Logging absolut zeitunkritisch ist, habe ich mir nun mit einem vorangestellten sleep beholfen:
Und was hat das gebracht?
Zitat von: rudolfkoenig am 19 November 2016, 15:30:33
Welche arbeitsintensive Prozesse meinst du?
Die erwähnten IO Zugriffe beispielsweise. Vielleicht könnte man das für sinnvolle Funktionalitäten ohne Rückgabewert additiv bereitstellen mittels des an anderer Stelle schon verwendeten extra Attributs "nonblocking"?
Ich plane keine Umstellung auf Multithreaded, da vieles dagegen spricht:
- perl is mAn nicht dafuer gebaut
- viel "legacy" FHEM-Code, was auch nicht dafuer gebaut wurde, und angepasst werden muesste
- Race-Conditions zu debuggen ist nicht lustig, und in FHEM koennte so einiges Nebenlaeufig sein.
- Locking wird nicht von jedem verstanden bzw. wenn irgendwo fehlt, sieht man das nicht auf Anhieb. Vmtl. haben die meisten FHEM-Modul-Autoren keine Erfahrung mit Multithreading.
Ich verstehe, der Schmerz ist scheinbar nicht groß genug für den Aufwand. Ist aus meiner Sicht absolut legitim. Ich kann mit gelegentlichen Aussetzern bestimmt auch leben. Aber perspektivisch - selbst unabhängig von den anderen Smarthome Systemen - wäre dies mMn eine sinnvolle Eigenschaft.
Zitat
Und was hat das gebracht?
Tatsächlich leider nur einmalig kein Freeze. Ich hoffte, es wäre so eine Art Application.ProcessMessages.
Gruß
Ronny
ZitatVielleicht könnte man das für sinnvolle Funktionalitäten ohne Rückgabewert additiv bereitstellen
Das gibt es seit 10 Jahren (d.h. von Anfang an), indem man ein Befehl mit "" ausfuehrt (Siehe auch http://fhem.de/commandref.html#command (http://fhem.de/commandref.html#command)). Falls man Rueckgabewerte auswerten will, dann packt man das Parsen/Auswerten in einem Shellskript, der die Aktionen in fhem per "perl fhem.pl localhost:7072 'set myDummy Value'" bzw. Vergleichbares ausloest. Scheinbar haben aber die meisten Angst von Shellskripten, oder meinen, das waere unordentlich, jedenfalls wird diese Methode sehr selten eingesetzt.
Falls man sowas in der Schleife braucht, dann gehoert das externe Programm als Daemon (Windows Benutzer sagen Service dazu), den man z.Bsp. per HTTP abfragen kann, und fuer die HTTP-Abfrage gibt es HTTPMOD.
Genau das will ich möglichst vermeiden. Ich will den FHEM Kontext für normale FHEM Aufgaben nicht verlassen. Natürlich auch, da es für mich Windows Fanboy (;)) umständlicher ist zu handhaben.
Ich frage mich gerade, ob ich nicht die SystemCommand Funktion genau dafür aufbohren kann.
PS:
Zitat von: rudolfkoenig am 20 November 2016, 08:23:10
(Siehe auch http://fhem.de/commandref.html#command (http://fhem.de/commandref.html#command))
Ist das merkwürdige Favicon normal oder wurde die Seite gehackt?
Ich habe die Funktion nochmal erweitert, um manch langwierige, aber zeitunkritische FHEM Aktionen nicht-blockierend auszuführen.
//edit: entfernt, da es so nicht funktioniert.
Sehe ich das richtig das du einen fhem Befehl innerhalb einer NonBlocking Routine ausführen willst?
Wüsste nicht das das geht. Da du dich in einem FHEM Fork bewegst der am Ende ohne Einfluss auf das Eltern FHEM beendet. Du schaltest eine Holographie.
was genau versprichst du dir davon?
für jedes kommando forkst du fhem, startest noch mal ein fhem das dann das ursprüngliche kommando wieder zurück an den haupt prozess gibt und diesen dort ausführt.
kurz:
- wenn das kommando blockiert, blockiert es immer noch
- du hast zwei zusätzliche fhem prozesse als overhead
ich weiss nicht was du dir davon versprichst, aber es gibt kein problem das sich auf diese weise lösen lässt. ausser du hast ein system das sich langweilt und beschäftig werden muss.
entschuldige, aber so ist das kompletter blödsinn.
wenn das ganze überhaupt sinn haben soll musst du das langsame kommando im kontext des ersten geforkten prozesses ausführen und nur das ergebniss zurück liefern. ob das generell möglich ist bezweifle ich. bzw. es wird deutlich komplizierter und ist nicht ohne eingriff in die fhem innereien möglich. schau dir den sandbox vorschlag im developer bereich an. da ist aber noch viel dran zu machen damit es problemlos und für alle fälle funktioniert.
gruss
andre
Ich denke, mit /opt/fhem/fhem.pl 7072 '$command' blockiere ich FHEM nicht?
wenn du damit einen wert zurück gibst nicht. wenn du das komplette kommando zurück gibst und im haupt prozess ausführst gibt es keinen unterschied zum gleich dort ausführen.
schau dir noch mal die grundlagen und den kontrollfluss an. das was du machst ist komplett sinnlos.
Auch auf die Gefahr das hier keiner antwortet schreib ich mal meine Frage ... eigentlich wollte ich das gleiche wie FHEMAN und einfach ein Script nicht blockierend aus FHEM aufrufen. Nach Stunden suchen bin ich hier gelandet und dachte ich nehme die Lösung von CoolTux bis ich gelesen habe was Rudolf schreibt:
Zitat von: rudolfkoenig am 20 November 2016, 08:23:10
Das gibt es seit 10 Jahren (d.h. von Anfang an), indem man ein Befehl mit "" ausfuehrt (Siehe auch http://fhem.de/commandref.html#command (http://fhem.de/commandref.html#command)). Falls man Rueckgabewerte auswerten will, dann packt man das Parsen/Auswerten in einem Shellskript, der die Aktionen in fhem per "perl fhem.pl localhost:7072 'set myDummy Value'" bzw. Vergleichbares ausloest. Scheinbar haben aber die meisten Angst von Shellskripten, oder meinen, das waere unordentlich, jedenfalls wird diese Methode sehr selten eingesetzt.
Falls man sowas in der Schleife braucht, dann gehoert das externe Programm als Daemon (Windows Benutzer sagen Service dazu), den man z.Bsp. per HTTP abfragen kann, und fuer die HTTP-Abfrage gibt es HTTPMOD.
Wenn ich das richtig verstehe dann sollte das einfach mit "path/script.sh" (mit " eingegeben in die FHEM commando Zeile) gehen?
Ich brauch keine Antwort vom Script bzw. kann ich das gut über telnet lösen. Nur bleibt bei mir FHEM immer stecken. Selbst wenn ich sowas einfaches mache wie "ls". Die Ausgabe von "ls" steht dann im Log aber erst nach Neustart (killall perl, perl fhem.pl fhem.cfg).
Was mach ich falsch? Könnt ihr mir helfen.
LG Ben
Nachtrag ... mein FHEM läuft auf OSX ...
bei meiner zweiten FHEM Instanz die ich auf einem PasPi W habe geht das "ls" ... keine Ahnung warum.
Das hat mir natürlich keine Ruhe gelassen und ich kam auf die Idee mein config systematisch zu halbieren und konnte tatsächlich ein Modul identifizieren welches den Fehler verursacht.
Ich habe SMARTMON laufen für meine view Festplatten. Wenn ich das Modul aus meiner config nehme geht alls. "sh" und auch mein Script laufen wunderbar ...
Ich schreib morgen mal dem SMARTMON Entwickler ... vielleicht kann der helfen
Ich hab zwar kein OSX sondern laufe auf einem PI...
...aber habe auch das SMARTMON-Modul im Einsatz (2x "remote-Platte", also ssh) und bei mir gehen Aufrufe mittels "irgendwas.sh" (rufe einige per at zyklisch auf)...
Aber ich bin grad dabei SMARTMON auf non-Blocking umzubauen (bzw. habe ich es grad fertig :) ), werde das auch mal im SMARTMON-Thread vorstellen...
Weil so eine SMARTMON-Abfrage (per ssh) schon mal auch gerne bis zu 6s dauern kann, wenn die Platte "schläft"...
Aber ich bin gespannt, ob es tatsächlich einen "Zusammenhang" mit SMARTMON und "irgendwas.sh"-Aufrufen (auf OSX)...
Gruß, Joachim
Danke MadMax,
Bin auch gespannt ... vielleicht brauch ich auch nur ein update des Moduls.
Non blocking wäre auch für micht gut. Wie hast du das gemacht?
Naja die Implementierung auf non-Blocking "umgestellt" ;)
https://wiki.fhem.de/wiki/Blocking_Call
Ist aber etwas viel "Umbau" um das hier einfach zu erläutern...
Ich werde im anderen Thread einfach mal anbieten das zu übernehmen...
Also hier: https://forum.fhem.de/index.php/topic,30491.msg231098.html#msg231098
(aber erst morgen oder so / will noch ein wenig testen und auch noch mal über den Code schauen bevor ich das anbiete/poste)
Gruß, Joachim
Klingt gut ich lese einfach mit :-).
Update hat nix gebracht - Schreib jetzt mal Hexenmeister vielleicht kann der helfen.
Gruss, Ben