PGM3 hängt 45 Sekunden

[Guest]

Originally posted by: <email address deleted>

Fhem funktioniert weiter, das Skript hängt genau bei Ausführung eines
fhem-Kommandos (set MySwitch On).
Manuelle Ausführung des Kommandos über PGM2 oder fhemobile funktioniert.

Am Mittwoch, 25. April 2012 19:46:25 UTC+2 schrieb Rudolf Koenig:
>
>
> Kannst Du feststellen ob immer das gleiche Skript ist, bzw. ob es
> mittendrin
> steckenbleibt, oder erst nach getaner Arbeit? Funktioniert fhem weiter?
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Kein Ampersand nötig ?

Am Mittwoch, 25. April 2012 19:46:25 UTC+2 schrieb Rudolf Koenig:
>
> > define WohnenEin notify Wohnen:on {\
> >         system "/var/log/fhem/wohnen_ein&" \
> > }
>
> Das sollte mit
>
>   define WohnenEin notify Wohnen:on "/var/log/fhem/wohnen_ein"
>
> equivalent sein, letzteres leitet stdin/stdout zusaetzlich nach fhem.log
> um.
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

On Wed, Apr 25, 2012 at 12:11:01PM -0700, MSB wrote:
> Kein Ampersand nötig ?

Nein, das war schon immer inklusive, sonst koennte kein shell-script fhem
aufrufen koennen (bzw. es waere deadlock).

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

On Wed, Apr 25, 2012 at 12:08:38PM -0700, MSB wrote:
> Fhem funktioniert weiter, das Skript hängt genau bei Ausführung eines
> fhem-Kommandos (set MySwitch On).

Ist das immer be "set MySwitch On" der Fall? Ist MySwitch auf "On"? Was ist das
fuer ein Betriebssystem?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Das sporadische und nur alle paar Stunden auftretene perl-mäßige ^@ in
> "PARTIAL" (line 34) bringt pgm3 aus dem Tritt.
...
> @Rudi, reicht dir das? Natürlich könnte pgm3 das auch filtern, aber da das
> in 5.1 noch nicht war, sehe ich das schon als Bug an.

Sehe ich eigentlich auch. Partial sind nicht unvollstaedige Daten (fhem wartet
noch auf das NewLine), deswegen tritt es nur sporadisch auf. Eigentlich sollte
CUL/CUN immer nur Hexdaten produzieren, d.h. das Problem liegt tiefer, es
stoert fhem halt nicht.
Komisch finde ich nur, dass es beim 5.1 nicht so war...
Und ich bin noch unentschlossen wo ich was fixen soll: XmlList.pm oder CUL.pm

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Partial sind nicht unvollstaedige Daten (fhem wartet

Will sagen "sind unvollstaedige Daten".

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hab' grade nochmal ps ax aufgerufen und u. a. folgendes gefunden:

*27815 pts/3    S      0:00 /bin/sh /var/log/fhem/wohnen_aus
27825 pts/3    S      0:00 /usr/bin/perl /usr/bin/fhem.pl 7072 set Rem1 off
*
Zur Erläuterung: wohnen_aus wird über ein Notify via Fernbedienung
ausgelöst (Auszug aus fhem.cfg):

*define WohnenAus notify Wohnen:off {\
        system "/var/log/fhem/wohnen_aus&" \
}*

wohnen_aus enthält folgende Befehle:

*fhem="/usr/bin/fhem.pl 7072 "

$fhem "set Dose1 off"
$fhem "set Dose2 off"
sleep 1
$fhem "set Dimmer1 off"
$fhem "set Dimmer2 off"
sleep 1
$fhem "set Dose3 off"
$fhem "set Dose4 off"
sleep 1
$fhem "set Rem1 off"
$fhem "set Rem2 off"
sleep 1
$fhem "set Dose1 off"
$fhem "set Dose2 off"
sleep 1
$fhem "set Dimmer1 off"
$fhem "set Dimmer2 off"
sleep 1
$fhem "set Dose3 off"
$fhem "set Dose4 off"
sleep 1
$fhem "set Rem1 off"
$fhem "set Rem2 off"*

Rem1 und Rem2 riefen früher ebenfalls vai notify shell-scripte auf, das
habe ich inzwischen geändert (ohne dass es etwas verbessert hätte) auf
(fhem.cfg):

*define Rem1Aus notify Rem1:off {\
        fhem ("set Aussen1 off") \
}
*
Aussen1 ist ein FS-20 Schalter.

Bis zum letzten Update vor ca. 1 - 2 Wochen funktionierte alles bestens.
Betätige ich Rem1 oder Rem2 via Frontend oder Fernbedienung, wird der
Befehl ausgeführt. Die anderen Befehle aus wohnen_aus werden offenbar
ausgeführt. OS ist Opensuse 11.3 auf Primergy Hardware.

Poste gern mehr Details, wenn nötig.

Gruß
Martin d. a.


Am Donnerstag, 26. April 2012 08:49:42 UTC+2 schrieb Rudolf Koenig:
>
> On Wed, Apr 25, 2012 at 12:08:38PM -0700, MSB wrote:
> > Fhem funktioniert weiter, das Skript h�ngt genau bei Ausf�hrung
> eines
> > fhem-Kommandos (set MySwitch On).
>
> Ist das immer be "set MySwitch On" der Fall? Ist MySwitch auf "On"? Was
> ist das
> fuer ein Betriebssystem?
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

Hallo Martin,

> Hab' grade nochmal ps ax aufgerufen und u. a. folgendes gefunden:

Kannst Du bitte in fhem.pl an die Zeile
  syswrite($server, "$ARGV[1] ; quit\n");
folgendes anhaengen:
  shutdown($server, 1);
und es nochmal testen? Antworten darauf bitte in einem neuen Thread, da Dein
Problem mit dem Problem in dieser Diskussion nichts zu tun hat.

Gruss,
  Rudi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

So ist es bei mir:

Am Montag, 30. April 2012 10:50:25 UTC+2 schrieb Martin Haas:
>
>
> Hast du jetzt eigentlich das mit der XML-Ausgabe per Shell lösen können?
> Also klappt jetzt ein
> echo xmllist | netcat -w3 localhost 7072
>
> Das ist das erste was klappen muss.
>

Das klappt problemlos, der Bildschirm wird sofort vollgeschrieben.

>
> Ansonsten eine sehr gute Methode, um auf mögliche Geräteursachen zu
> schliessen: Sichere doch deine fhem.cfg mal weg und lasse die original
> fhem.cfg mit autocreate (sollte Vorgabe sein) mal laufen.
> In der fhem.cfg nicht das global vergessen: attr global port 7072 global
> Stück für Stück sollte autocreate die fhem.cfg füllen.
> Dauert es dann schon von Anfang an 45sec??
>
> Habe folgende Dummy cfg verwendet:
*
#
# pgm2 / autocreate configfile. Take a look at the other examples for more.
#
attr global logfile /var/log/fhem/fhem-%Y-%m.log
attr global modpath /usr/local/lib                  # where our FHEM
directory is
attr global port 7072                  # our TCP/IP port (localhost only)
attr global statefile /var/log/fhem/fhem.save   # where to save the state
of the devices
attr global verbose 3                  # "normal" verbosity (min 1, max 5)

#define CUL CUL /dev/ttyACM0 1234
#define FHEM FHEM /dev/USB0

define WEB FHEMWEB 8083 global
attr WEB plotmode SVG
attr WEB plotsize 800,160

# Fake logfile, to access the global log
define Logfile FileLog /var/log/fhem/fhem-%Y-%m.log fakelog

define autocreate autocreate
attr autocreate autosave
attr autocreate device_room %TYPE
attr autocreate filelog /var/log/fhem/%NAME-%Y.log
attr autocreate weblink
attr autocreate weblink_room Plots*

Angezeigt wird nichts, aber trotzdem dauert es wieder die knappe Minute,
bis pgm3 sich auf dem Bildschirm zeigt. Ich habe sicherheitshalber die
originale config.php verwendet, aber auch das scheint nichts zu ändern.

Hilft das weiter ?

Kann es sein, dass unterschiedliche Versionen unterwegs sind ? Meine ist
v100312 mit der Modifikation wie im Post weiter oben beschrieben.

Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> Das klappt problemlos, der Bildschirm wird sofort vollgeschrieben.
>
>>
>> ok. Bei FHEM sehe ich da auf Anhieb keine Probleme. Aber warum soll nach
dem FHEM-Update nun die ungeänderte pgm3 -Version Probleme bekommen......
Und warum kann ich das nicht reproduzieren... PHP-Version oder
Betriebssystem haben sich bei dem Update auch nicht geändert (?!).... Warum
haben andere xmllist-User das Problem evtl. nicht und neue "selbst
geschriebene (siehe oben im Thread)" das Problem nach dem Update schon...

So leicht ist die "Nuss" nicht zu knacken, aber das wird schon -- so
kompliziert ist die ganze Materie eigentlich auch wieder nicht.


> Ansonsten eine sehr gute Methode, um auf mögliche Geräteursachen zu
>> schliessen: Sichere doch deine fhem.cfg mal weg und lasse die original
>> fhem.cfg mit autocreate (sollte Vorgabe sein) mal laufen.
>> In der fhem.cfg nicht das global vergessen: attr global port 7072 global
>> Stück für Stück sollte autocreate die fhem.cfg füllen.
>> Dauert es dann schon von Anfang an 45sec??
>>
>> Habe folgende Dummy cfg verwendet:
> *
> #
> # pgm2 / autocreate configfile. Take a look at the other examples for more.
> #
> *
> Angezeigt wird nichts, aber trotzdem dauert es wieder die knappe Minute,
> bis pgm3 sich auf dem Bildschirm zeigt. Ich habe sicherheitshalber die
> originale config.php verwendet, aber auch das scheint nichts zu ändern.
>
> Hilft das weiter ?
>

Danke erstmal.
Bitte auch mal testweise in der config.php $usenetcat auf 1 setzen (verhält
sich dann exakt wie das netcat auf shell-Ebene).


>
> Kann es sein, dass unterschiedliche Versionen unterwegs sind ? Meine ist
> v100312 mit der Modifikation wie im Post weiter oben beschrieben.
>

Bis vor diesem Thread gab es nur die v100312. Erst mit den hier eingebauten
Debug-Funktionen und committen in das SVN wurde das hochgezählt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Das klappt problemlos, der Bildschirm wird sofort vollgeschrieben.

netcat macht vermutlich direkt nach dem schreiben der Daten den Schreib-Kanal
zu, analog zu dem "shutdown" fix fuer den fhem-client von gestern.

Ich vermute das Problem haengt irgendwie mit dem anderen Problem zusammen (fhem
client haengt), verstehe aber nicht, wieso das jetzt auftritt, ich meine
diesbezueglich in den letzten Jahren nichts geaendert zu haben.

Es kann sein, das fhem wartet, weil er der Ansicht ist, das Kommando ist noch
nicht vollstaendig, oder aber wartet die andere Seite, weil fhem noch was
schreiben koennte.

Um das einzugrenzen haette ich gerne gewusst, ob beim haengenden Client das
bestellte Befehl ausgefuehrt wurde oder nicht, daraufhin habe ich (mWn) keine
Antwort bekommen.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,

bei meinem selbstgebauten Webzugriff mit PHP wird der Befehl nach der
Warteminute ausgeführt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> bei meinem selbstgebauten Webzugriff mit PHP wird der Befehl nach der
> Warteminute ausgeführt.

Kannst Du bitte in fhem.pl vor dem Aufruf von AnalyzeInput (etwa Zeile
483) $buf ausgeben, und berichten was da kommt?

Log 1, "ClientData: $buf";

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am 30. April 2012 12:33 schrieb Rudolf Koenig :

> > Das klappt problemlos, der Bildschirm wird sofort vollgeschrieben.
>
> netcat macht vermutlich direkt nach dem schreiben der Daten den
> Schreib-Kanal
> zu, analog zu dem "shutdown" fix fuer den fhem-client von gestern.
>
>
pgm3 nutzt optional netcat oder eben diesen php-stream_socket_client. Hier
wird ein "quit" explizit hinterhergeschoben.
PoLe23 arbeitet meines Wissens auch mit stream_socket_client

Bin mal auf die Antwort von Martin d.e. gespannt, ob $usenetcat etwas
bringt. Ich meine aber Udo hat das schon ohne Erfolg getestet.


if ($usenetcat=='1')
 {
        $order="$echo xmllist | netcat -w3 $machine $port";
        exec($order,$res);
        $errormessage = $res[0];
 }
 else
 {
 $fp = stream_socket_client("tcp://$machine:$port", $errno, $errstr, 30);
         if (!$fp) {
           echo "$errstr ($errno)\n";
        } else {
           fwrite($fp, "$order\n;quit\n");
                $errormessage= fgets($fp);
           fclose($fp);
        }
 }

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

>
>
Am Montag, 30. April 2012 12:16:02 UTC+2 schrieb Martin Haas:
>
>
>
> Bitte auch mal testweise in der config.php $usenetcat auf 1 setzen
> (verhält sich dann exakt wie das netcat auf shell-Ebene).
>


Die Modifikation ändert nichts am Verhalten. Es dauert ...

>  
>
>>
>> Kann es sein, dass unterschiedliche Versionen unterwegs sind ? Meine ist
>> v100312 mit der Modifikation wie im Post weiter oben beschrieben.
>>
>
> Bis vor diesem Thread gab es nur die v100312. Erst mit den hier
> eingebauten Debug-Funktionen und committen in das SVN wurde das hochgezählt.
>
>
War nur meine Vermutung, weil die unmodifizierte v100312 ja mit dem
aktuellen fhem gar nicht startet. Man muss erst diese Abfrage heraus nehmen.


Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com