Originally posted by: <email address deleted>
Hallo zusammen,
ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
PGM2 umzustellen ?
Gruß
M.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
ich habe ein ähnliches Problem, mit meinem selbst gebauten Webinterface.
Dort muss ich genau eine Minute warten, bis der Befehl ausgeführt wird.
Habe noch keinen Plan, was man da machen kann. Wie genau wird im PGM3 eine
Verbindung zum FHEM aufgebaut?
Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
>
> Hallo zusammen,
>
> ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
> es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
> Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
> überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
> PGM2 umzustellen ?
>
> Gruß
> M.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
als Autor des pgm3 kann ich dir sagen, dass pgm3 nach wie vor lebt.
Warum das jetzt bei dir 45sec dauert -- da fällt mir eben kein Grund ein.
Normal ist das natürlich nicht.
Die meisten User arbeiten mehrgleisig, setzen also mehrere Frontends
parallel ein.
Grüße,
Martin
Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
>
> Hallo zusammen,
>
> ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
> es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
> Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
> überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
> PGM2 umzustellen ?
>
> Gruß
> M.
>
Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
>
> Hallo zusammen,
>
> ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
> es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
> Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
> überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
> PGM2 umzustellen ?
>
> Gruß
> M.
>
Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
>
> Hallo zusammen,
>
> ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
> es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
> Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
> überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
> PGM2 umzustellen ?
>
> Gruß
> M.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hi,
ich fürchte, dass das kein lokales Problem ist, bei mir ist dasselbe
Phänomen :-/
Es dauert fast 1 min, bis das PGM3-Interface erscheint, dann aber
eigentlich ganz normal. Allerdings verfällt PGM3 bei Button-Klick in
weiteren Dornröschen-Schlaf.
Grosse Berechnungen gibt es aber nicht, laut htop langweilt sich der
Rechner geradezu (mein Server ist ein Atom, der sonst bei jeglicher
Arbeit gleich dicke Backen macht).
Wäre grossartig, wenn sich Martin oder ein anderer Berufener dem
Problem annehmen könnten, trotz Mehrgleisigkeit greife ich immer
wieder supergerne auf PGM3 zurück.
Danke & Grüsse
Udo
On Apr 22, 4:04 am, Martin Haas wrote:
> Hallo,
>
> als Autor des pgm3 kann ich dir sagen, dass pgm3 nach wie vor lebt.
>
> Warum das jetzt bei dir 45sec dauert -- da fällt mir eben kein Grund ein.
> Normal ist das natürlich nicht.
>
> Die meisten User arbeiten mehrgleisig, setzen also mehrere Frontends
> parallel ein.
>
> Grüße,
> Martin
>
> Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
>
>
>
> > Hallo zusammen,
>
> > ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> > braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
> > es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
> > Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
> > überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
> > PGM2 umzustellen ?
>
> > Gruß
> > M.
>
> Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
>
>
>
> > Hallo zusammen,
>
> > ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> > braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
> > es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
> > Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
> > überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
> > PGM2 umzustellen ?
>
> > Gruß
> > M.
>
> Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
>
>
>
>
>
>
>
>
>
> > Hallo zusammen,
>
> > ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> > braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
> > es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
> > Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
> > überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
> > PGM2 umzustellen ?
>
> > Gruß
> > M.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
ich habe gestern auch noch mal etwas rumgespielt. Ich habe ja sonst immer
eine telnet Verbindung mit PHP und FHEM aufgebaut. Gestern hatte ist es mal
mit einem Webrequest und JSON gestestet. Allerdings habe ich auch dort eine
Wartezeit von genau einer Minute.
Gruß
Gregor
Am Montag, 23. April 2012 08:52:25 UTC+2 schrieb ixi:
>
> Hi,
> ich fürchte, dass das kein lokales Problem ist, bei mir ist dasselbe
> Phänomen :-/
>
> Es dauert fast 1 min, bis das PGM3-Interface erscheint, dann aber
> eigentlich ganz normal. Allerdings verfällt PGM3 bei Button-Klick in
> weiteren Dornröschen-Schlaf.
>
> Grosse Berechnungen gibt es aber nicht, laut htop langweilt sich der
> Rechner geradezu (mein Server ist ein Atom, der sonst bei jeglicher
> Arbeit gleich dicke Backen macht).
>
> Wäre grossartig, wenn sich Martin oder ein anderer Berufener dem
> Problem annehmen könnten, trotz Mehrgleisigkeit greife ich immer
> wieder supergerne auf PGM3 zurück.
>
> Danke & Grüsse
> Udo
>
>
> On Apr 22, 4:04 am, Martin Haas wrote:
> > Hallo,
> >
> > als Autor des pgm3 kann ich dir sagen, dass pgm3 nach wie vor lebt.
> >
> > Warum das jetzt bei dir 45sec dauert -- da fällt mir eben kein Grund
> ein.
> > Normal ist das natürlich nicht.
> >
> > Die meisten User arbeiten mehrgleisig, setzen also mehrere Frontends
> > parallel ein.
> >
> > Grüße,
> > Martin
> >
> > Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
> >
> >
> >
> > > Hallo zusammen,
> >
> > > ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> > > braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor
> gabe
> > > es bereits Probleme beim Start (konnte ich selbst fixen) und
> periodische
> > > Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird
> PGM3
> > > überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich
> auf
> > > PGM2 umzustellen ?
> >
> > > Gruß
> > > M.
> >
> > Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
> >
> >
> >
> > > Hallo zusammen,
> >
> > > ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> > > braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor
> gabe
> > > es bereits Probleme beim Start (konnte ich selbst fixen) und
> periodische
> > > Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird
> PGM3
> > > überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich
> auf
> > > PGM2 umzustellen ?
> >
> > > Gruß
> > > M.
> >
> > Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > Hallo zusammen,
> >
> > > ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> > > braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor
> gabe
> > > es bereits Probleme beim Start (konnte ich selbst fixen) und
> periodische
> > > Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird
> PGM3
> > > überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich
> auf
> > > PGM2 umzustellen ?
> >
> > > Gruß
> > > M.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Montag, 23. April 2012 20:24:38 UTC+2 schrieb JörgB:
>
> Wenn Du Interesse an meinen Verbesserungen hast, kann ich Dir gerne
> die aktuelle Version schicken.
>
> Hab auch Interesse ... das trifft genau ... super ... habenwollen ...
LG M.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Jörg,
ich freue mich, wenn pgm3 auch von anderen weiter entwickelt wird. So ganz
up-to-date bin ich nicht, z.B. Homematic-Devices habe ich hier gar nicht.
Wäre toll, wenn aktuellere Geräte da einfliessen würden.
Gerne kannst du mir dein aktuelles pgm3-Paket schicken und ich sehe dann
zu, dass das in Subversion wandert.
Bzgl. Timeout von 45sec? Um ein Timeout zu checken, bitte mal auf einer
Konsole z.B. "echo xmllist | netcat -w3 localhost 7072" ausführen -- das
muss schnell gehen. So kann man schonmal Fehler ausgrenzen.
Aktuelle FHEM-Version? Bis auf den xmllist macht pgm3 da nicht viel, da
habe ich auf Anhieb keine Erklärung dafür.
Viele Grüße,
Martin
Am Montag, 23. April 2012 20:24:38 UTC+2 schrieb JörgB:
>
> On 22 Apr., 05:04, Martin Haas wrote:
> > Hallo,
> >
> > als Autor des pgm3 kann ich dir sagen, dass pgm3 nach wie vor lebt.
> >
>
> Hallo Martin,
> das hört sich gut an, denn in den letzten Tagen habe ich das PGM3 ein
> wenig aufgemöbelt. :D
> Wenn Du Interesse an meinen Verbesserungen hast, kann ich Dir gerne
> die aktuelle Version schicken.
> Ich muss nur noch an einigen Stellen etwas nachbessern.
> Denn warum das Rad zweimal erfinden?
>
> Zu den Verbesserungen:
> 1. HomeMatic Aktoren werden angezeigt.
> 2. Die Icons passen sich dem aktuellen Zustand der Aktoren an. (on,
> dim50%, ...)
> 3. on-for-timer und follow-on-for-timer werden unterstützt. Nach
> Ablauf des Timers wird das off-Icon angezeigt. (hab mir einen daran
> agebrochen)
> 4. Das Attribut "webCmd" ist auch mit von der Patie. Damit können
> spezielle Schaltbefehle auf die Buttons gelegt werden.
> 5. Optional: Umlautkonverter. Aus "Kueche" wird "Küche".
> 6. Optional: Filter für Unterstriche. Aus "Halogen_Decke" wird
> "Halogen Decke".
> 7. Optional: Deutsches Datum auf den Buttons (vorher 2012-04-23 -
> jetzt 23.04.2012)
> 8. Optional: Abschaltbare Anzeige des Raumnamens auf dem Aktor-Button.
> 9. Optional: Sortierfunktion für Raumnamen und der Aktor-Button.
>
>
> LG Jörg
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Setzte mal in der config.php die Variable $usenetcat auf 1. Besser?
Martin
Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
>
> Hallo zusammen,
>
> ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
> es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
> Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
> überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
> PGM2 umzustellen ?
>
> Gruß
> M.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Samstag, 21. April 2012 11:56:53 UTC+2 schrieb PoLe23:
>
> Hallo,
>
> ich habe ein ähnliches Problem, mit meinem selbst gebauten Webinterface.
> Dort muss ich genau eine Minute warten, bis der Befehl ausgeführt wird.
> Habe noch keinen Plan, was man da machen kann. Wie genau wird im PGM3 eine
> Verbindung zum FHEM aufgebaut?
>
>
Wie pgm3 die Verbindung aufbaut steht, in der index.php. Also entweder wie
früher auf Betriebssystemweise mit
$order="$echo xmllist | netcat -w3 $machine $port";
oder auf php-Weise:
$fp = stream_socket_client("tcp://$machine:$port", $errno, $errstr, 30);
Grüße,
Marin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ohhh das wäre toll... meeee tooooo please! ;)
Cheers
On 24 Apr., 10:53, MSB wrote:
> Am Montag, 23. April 2012 20:24:38 UTC+2 schrieb JörgB:
>
>
>
> > Wenn Du Interesse an meinen Verbesserungen hast, kann ich Dir gerne
> > die aktuelle Version schicken.
>
> > Hab auch Interesse ... das trifft genau ... super ... habenwollen ...
>
> LG M.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ich habe gerade "echo xmllist | netcat -w3 localhost 7072" ausprobiert, da
passiert nix, das aber schnell :-) Soll heissen, es kommt keine
Fehlermeldung oder sonst irgendwas, aber hängen tuts auch nicht.
$usenetcat auf 1 setzen hat es leider auch nicht gebracht... :-(
Cheers
Udo
On Friday, April 20, 2012 11:37:27 AM UTC+2, MSB wrote:
>
> Hallo zusammen,
>
> ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
> es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
> Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
> überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
> PGM2 umzustellen ?
>
> Gruß
> M.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ein "telnet localhost 7072" muss aber gehen. Dann mal "list" eingeben.
-- anstatt localhost oder 7072 natürlich die Werte aus der config.php
nehmen.
-- netcat muss natürlich installiert sein.
-- $usenetcat=1 führt übrigens genau diesen Befehl aus (echo xmllist |
netcat -w3 localhost 7072) (also sollte auch netcat installiert sein)
-- Ist es denn nicht die lokale Maschine, sondern eine Fritzbox o.ä.? Dann
localhost gegen den Namen oder die IP-Adresse austauschen.
-- sind die Problem durch den letzten FHEM-Update aufgetreten oder
Betriebssystemupdate oder hat sich noch etwas anderes geändert, z.B.
netzwerkseitig (IPv6 o.ä.)? Bitte mal in der config.php den Namen
localhost/fritzbox gegen die IPv4-Adresse tauschen ( 127.0.0.1/192.168....
.)
Grüße,
Martin
Am Dienstag, 24. April 2012 19:06:14 UTC+2 schrieb ixi:
>
> Ich habe gerade "echo xmllist | netcat -w3 localhost 7072" ausprobiert, da
> passiert nix, das aber schnell :-) Soll heissen, es kommt keine
> Fehlermeldung oder sonst irgendwas, aber hängen tuts auch nicht.
> $usenetcat auf 1 setzen hat es leider auch nicht gebracht... :-(
>
> Cheers
> Udo
>
> On Friday, April 20, 2012 11:37:27 AM UTC+2, MSB wrote:
>>
>> Hallo zusammen,
>>
>> ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
>> braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
>> es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
>> Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
>> überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
>> PGM2 umzustellen ?
>>
>> Gruß
>> M.
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
...sorry, für das nachhaken, aber das "echo xmllist | netcat -w3 localhost
7072" natürlich ohne Hochkommata ;-) und in einer Konsole/Shell.
Am Dienstag, 24. April 2012 19:06:14 UTC+2 schrieb ixi:
>
> Ich habe gerade "echo xmllist | netcat -w3 localhost 7072" ausprobiert, da
> passiert nix, das aber schnell :-) Soll heissen, es kommt keine
> Fehlermeldung oder sonst irgendwas, aber hängen tuts auch nicht.
> $usenetcat auf 1 setzen hat es leider auch nicht gebracht... :-(
>
> Cheers
> Udo
>
> On Friday, April 20, 2012 11:37:27 AM UTC+2, MSB wrote:
>>
>> Hallo zusammen,
>>
>> ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
>> braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
>> es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
>> Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
>> überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
>> PGM2 umzustellen ?
>>
>> Gruß
>> M.
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Einen wichtigen Debug-Schalter habe ich noch, um zu sehen, ob es Richtung
FHEM, Richtung Netzwerk/Proxy oder Richtung pgm3 ein Problem gibt:
In der index.php in den Zeilen 336 und 337 bitte die Zeilen
#print_r($stack);
#exit;
einkommentieren und speichern, also
print_r($stack);
exit;
Jetzt sollte nach jedem Reload von pgm3 sich blitzschnell das gesamte
pgm3-Array anstatt dem Frontend aufbauen.
Gibt es auch hier deutliche Verzögerungen????
Grüße,
Martin
Am Freitag, 20. April 2012 11:37:27 UTC+2 schrieb MSB:
>
> Hallo zusammen,
>
> ich nutze PGM3 mit dem aktuellen FHEM. Nach meinem letzten Update-Lauf
> braucht PGM3 fast 45 Sekunden, bis der Bildschirm aufgebaut ist. Zuvor gabe
> es bereits Probleme beim Start (konnte ich selbst fixen) und periodische
> Fehlermeldungen (XML-Fehler, habe ich durch html-Frame umgangen). Wird PGM3
> überhaupt noch weiter gepflegt ? Oder ist es sinnvoller, grundsätzlich auf
> PGM2 umzustellen ?
>
> Gruß
> M.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hi,
vielen Dank, Martin, dass Du Dich so ins Bugfixen wirfst!!!
Also:
1) Natürlich ohne Hochkommata, nahömmah! ;-)
2) netcat ist auf meinem fhem-Rechner (ubuntu) installiert und läuft
3) die Änderung von localhost (Zeile 10) zur IP-Adresse in der
config.php hat leider nix gebracht
4) telnet localhost 7072 funzt, list spuckt alles wie erwartet aus
5) die Änderung in der index.php war suboptimal, jetzt rattert nur
noch Text runter a la Array (
- => Array ( [name] => FHZINFO [attrs]
=> Array ( ) [children] => Array (
Global_LIST [attrs] => Array ( ) [children] => Array (
( [name] => Global [attrs] => Array ( [name] => global [state] =>
[sets] => [attrs] => room comment alias eventMap archivecmd allowfrom
apiversion archivedir configfile lastinclude logfile modpath nrarchive
pidfilename port statefile title userattr verbose:1,2,3,4,5 mseclog
version nofork logdir holiday2we autoload_undefined_devices dupTimeout
latitude longitude backupdir Heizungen RolloEssSchlafBuero RolloWohn
fp_Erdgeschoss fp_Obergeschoss icon structexclude webCmd ) [children]
=> Array (
etc..
Probleme habe ich mit PGM3 seit dem Upgrade von 5.1 auf 5.2, vor einer
Weile gab es sporadische XML-Fehlermeldungen (@Martin - der andere ;-)
Erinnerst Du Dich noch genau an den Wortlaut?), seit dem letzten
Update (leider weiss ich die genaue Version nicht mehr) gibts die
"Warteschlange"...
Cheers
Udo
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> 1) Natürlich ohne Hochkommata, nahömmah! ;-)
>
Sorry, habe erst später in einem deiner Artikel gesehen, dass du auch schon
lange bei Linux dabei bist (nslu2 und unslung etc.)
5) die Änderung in der index.php war suboptimal, jetzt rattert nur
> noch Text runter a la Array (
- => Array ( [name] => FHZINFO [attrs]
> => Array ( ) [children] => Array (
> Global_LIST [attrs] => Array ( ) [children] => Array (
> ( [name] => Global [attrs] => Array ( [name] => global [state] =>
> [sets] => [attrs] => room comment alias eventMap archivecmd allowfrom
> apiversion archivedir configfile lastinclude logfile modpath nrarchive
> pidfilename port statefile title userattr verbose:1,2,3,4,5 mseclog
> version nofork logdir holiday2we autoload_undefined_devices dupTimeout
> latitude longitude backupdir Heizungen RolloEssSchlafBuero RolloWohn
> fp_Erdgeschoss fp_Obergeschoss icon structexclude webCmd ) [children]
> => Array (
>
> etc..
>
> Das ist nicht suboptimal ;-), sondern ist nur der debug-Modus. Wenn das
alles sofort losrattert und auch bei Reload sofort alles wieder da ist,
dann ist der FHEM-Part erledigt (xmllist wurde vollständig eingelesen und
fehlerfrei in ein interenes Array von pgm3 eingelesen).
Jetzt müssen "nur" noch aus den internen Logfiles Grafiken erzeugt werden
und alles als html auf den Bildschirm geschrieben werden.
Ok, wo jetzt suchen, ohne das selbst nachvollziehen zu können... Auch wenn
sich was an der internen Struktur von 5.2 geändert haben sollte, dann
sollte es Fehlermeldungen geben und kein Timeout.
Weitere Debug-Schritte, die mir gerade so einfallen:
-- kommen diese 45sec (evtl. Timeout) bei allen Geräten/Räumen vor? Kann
man das mal einschränken und Geräte Schritt für Schritt einkreisen?
-- Ist das ein PC oder was altes wie eine NSLU2?
-- Sind die Logfiles zu groß geworden (wohl unwahrscheinlich, dann gäbe es
Grafikfehler)
-- sind die Logfile im Netz per NFS o.ä. verteilt oder liegt das alles
lokal?
Evtl. helfen würde mir deine fhem.cfg und so eine xmllist:
echo xmllist | netcat -w3 localhost 7072 >/tmp/xmllist (warum soll das
eigentlich nícht gehen?)
Außerdem eine pgm3-Seite:
cd /var/www//
php index.php >/tmp/pgm3php
und das gleiche noch mit den beiden einkommentieren debug-Schaltern
> Probleme habe ich mit PGM3 seit dem Upgrade von 5.1 auf 5.2, vor einer
> Weile gab es sporadische XML-Fehlermeldungen (@Martin - der andere ;-)
> Erinnerst Du Dich noch genau an den Wortlaut?), seit dem letzten
> Update (leider weiss ich die genaue Version nicht mehr) gibts die
> "Warteschlange"...
>
5.2 habe ich auch heute installiert, kann aber bei meiner Installation
keinen Unterschied feststellen.
Ansonsen wurmt mich das ja schon ;-) Läuft seit Jahren ohne Probleme und
verrät nicht, woran das liegt ;-)
Grüße,
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> Außerdem eine pgm3-Seite:
> cd /var/www//
> php index.php >/tmp/pgm3php
>
> Dauert das auch 45sec??? (wäre ein Hinweis auf die include-php-Dateien)
Wenn ja, "hängt" die Seite bei "php index.php" irgendwo oder baut sie sich
erst am Ende am Stück auf?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
(@Martin - der andere ;-)
> Erinnerst Du Dich noch genau an den Wortlaut?)
Es sind 2 Sachen:
Ich musste diese Abfrage auskommentieren (index.php):
##### Check Version of FHEM
## if (! ($stack[0][children][0][name]=='_internal__LIST'))
##older FHZ100 have no Internal_LIST
## {echo "Error!! There is no FHEM. You need at least FHEM-4.0
to run this pgm3!!";}
Und gelegentlich wird hier eine Fehlermeldung ausgeworfen (index.php):
foreach($output as $data) {
if (!xml_parse($xml_parser, $data)) {
die(sprintf("XML error: %s at line %d\n",
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
}
Hoffe, das hilft weiter.
Martin (der andere ;-))
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Dienstag, 24. April 2012 21:17:02 UTC+2 schrieb MSB:
>
>
> (@Martin - der andere ;-)
>
>> Erinnerst Du Dich noch genau an den Wortlaut?)
>
>
> Es sind 2 Sachen:
>
> Ich musste diese Abfrage auskommentieren (index.php):
>
> ##### Check Version of FHEM
> ## if (! ($stack[0][children][0][name]=='_internal__LIST'))
> ##older FHZ100 have no Internal_LIST
> ## {echo "Error!! There is no FHEM. You need at least
> FHEM-4.0 to run this pgm3!!";}
>
>
Ja, diese Zeilen sind seit 5.2 obsolet. Eine geänderte pgm3 ist bereits im
SVN engecheckt.
>
> Und gelegentlich wird hier eine Fehlermeldung ausgeworfen (index.php):
>
> foreach($output as $data) {
> if (!xml_parse($xml_parser, $data)) {
> die(sprintf("XML error: %s at line %d\n",
> xml_error_string(xml_get_error_code($xml_parser)),
> xml_get_current_line_number($xml_parser)));
> }
> }
>
>
Ja, das ist das "Herz" vom xmllist einlesen. Wenn pgm3 damit kein
korrektes xml einlesen kann, dann soll es Fehlermeldungen geben.
Bei sporadischem Auftreten tippe ich auf Übertragungsfehler. Regelmäßig
darf das nicht auftreten.
> Hoffe, das hilft weiter.
>
> Martin (der andere ;-))
>
...ich fürchte nicht wirklich ;-) Eine korrekte xmllist scheint ja
eingelesen worden zu sein.
Martin :-)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hm, das verstehe ich nicht. Es begann, nachdem ich fhem auf 5.2 upgedatet
hatte. Das Ganze läuft auf einem Primergy TX150 unter OpenSuse 11.3 und
funktionierte bis zum Update problemlos. Wodurch sollten denn diese
Übertragungsfehler zustande kommen ?
Fhem generiert übrigens auch sporadisch Fehlermeldungen a la "Argument "on"
isn't numeric in numeric gt (>) at /usr/local/lib/FHEM/13_KS300.pm line
132.". Diese werden auf der Konsole ausgegeben, nicht ins Log geschrieben.
Gibt es da vielleicht einen Zusammenhang ? Ich werde das Gefühl nicht los,
dass das alles mit einer bestimmten Konstellation zusammenhängt.
Martin d. a.
Am Dienstag, 24. April 2012 21:28:14 UTC+2 schrieb Martin Haas:
>
>
>
> Bei sporadischem Auftreten tippe ich auf Übertragungsfehler. Regelmäßig
> darf das nicht auftreten.
>
> Martin :-)
>
>
>
>
Am Dienstag, 24. April 2012 21:28:14 UTC+2 schrieb Martin Haas:
>
>
>
> Am Dienstag, 24. April 2012 21:17:02 UTC+2 schrieb MSB:
>>
>>
>> (@Martin - der andere ;-)
>>
>>> Erinnerst Du Dich noch genau an den Wortlaut?)
>>
>>
>> Es sind 2 Sachen:
>>
>> Ich musste diese Abfrage auskommentieren (index.php):
>>
>> ##### Check Version of FHEM
>> ## if (! ($stack[0][children][0][name]=='_internal__LIST'))
>> ##older FHZ100 have no Internal_LIST
>> ## {echo "Error!! There is no FHEM. You need at least
>> FHEM-4.0 to run this pgm3!!";}
>>
>>
> Ja, diese Zeilen sind seit 5.2 obsolet. Eine geänderte pgm3 ist bereits im
> SVN engecheckt.
>
>
>
>>
>> Und gelegentlich wird hier eine Fehlermeldung ausgeworfen (index.php):
>>
>> foreach($output as $data) {
>> if (!xml_parse($xml_parser, $data)) {
>> die(sprintf("XML error: %s at line %d\n",
>> xml_error_string(xml_get_error_code($xml_parser)),
>> xml_get_current_line_number($xml_parser)));
>> }
>> }
>>
>>
> Ja, das ist das "Herz" vom xmllist einlesen. Wenn pgm3 damit kein
> korrektes xml einlesen kann, dann soll es Fehlermeldungen geben.
> Bei sporadischem Auftreten tippe ich auf Übertragungsfehler. Regelmäßig
> darf das nicht auftreten.
>
>
>
>> Hoffe, das hilft weiter.
>>
>> Martin (der andere ;-))
>>
>
> ...ich fürchte nicht wirklich ;-) Eine korrekte xmllist scheint ja
> eingelesen worden zu sein.
>
> Martin :-)
>
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
ok, einleuchtend.
Am xmllist hat sich offenbar ja schon was geändert, was man ja alleine
schon an dem unten beschriebenen fehlenden '_internal__LIST' sieht.
Nur blöd, wenn man einen Fehler nicht reproduzieren kann und an eine
bestimmte Konstellation denkt. Das mit dem LOG hat wohl nichts damit zu
tun. Wie oft kommt denn der XML-Fehler in pgm3 vor?
Bzgl. 45sec-Problem ist die FHEM-Seite, wie man sieht, wie immer in
Sekundenbruchteilen abgearbeitet. Danach schickt pgm3 nichts mehr an FHEM.
Grüße,
Martin (der eine)
Am 24. April 2012 22:37 schrieb MSB :
> Hm, das verstehe ich nicht. Es begann, nachdem ich fhem auf 5.2 upgedatet
> hatte. Das Ganze läuft auf einem Primergy TX150 unter OpenSuse 11.3 und
> funktionierte bis zum Update problemlos. Wodurch sollten denn diese
> Übertragungsfehler zustande kommen ?
>
> Fhem generiert übrigens auch sporadisch Fehlermeldungen a la "Argument
> "on" isn't numeric in numeric gt (>) at /usr/local/lib/FHEM/13_KS300.pm
> line 132.". Diese werden auf der Konsole ausgegeben, nicht ins Log
> geschrieben. Gibt es da vielleicht einen Zusammenhang ? Ich werde das
> Gefühl nicht los, dass das alles mit einer bestimmten Konstellation
> zusammenhängt.
>
> Martin d. a.
>
> Am Dienstag, 24. April 2012 21:28:14 UTC+2 schrieb Martin Haas:
>>
>>
>>
>> Bei sporadischem Auftreten tippe ich auf Übertragungsfehler. Regelmäßig
>> darf das nicht auftreten.
>>
>> Martin :-)
>>
>>
>>
>>
>
> Am Dienstag, 24. April 2012 21:28:14 UTC+2 schrieb Martin Haas:
>>
>>
>>
>> Am Dienstag, 24. April 2012 21:17:02 UTC+2 schrieb MSB:
>>>
>>>
>>> (@Martin - der andere ;-)
>>>
>>>> Erinnerst Du Dich noch genau an den Wortlaut?)
>>>
>>>
>>> Es sind 2 Sachen:
>>>
>>> Ich musste diese Abfrage auskommentieren (index.php):
>>>
>>> ##### Check Version of FHEM
>>> ## if (! ($stack[0][children][0][name]=**='_internal__LIST'))
>>> ##older FHZ100 have no Internal_LIST
>>> ## {echo "Error!! There is no FHEM. You need at least
>>> FHEM-4.0 to run this pgm3!!";}
>>>
>>>
>> Ja, diese Zeilen sind seit 5.2 obsolet. Eine geänderte pgm3 ist bereits
>> im SVN engecheckt.
>>
>>
>>
>>>
>>> Und gelegentlich wird hier eine Fehlermeldung ausgeworfen (index.php):
>>>
>>> foreach($output as $data) {
>>> if (!xml_parse($xml_parser, $data)) {
>>> die(sprintf("XML error: %s at line %d\n",
>>> xml_error_string(xml_get_**error_code($xml_parser)),
>>> xml_get_current_line_number($**xml_parser)));
>>> }
>>> }
>>>
>>>
>> Ja, das ist das "Herz" vom xmllist einlesen. Wenn pgm3 damit kein
>> korrektes xml einlesen kann, dann soll es Fehlermeldungen geben.
>> Bei sporadischem Auftreten tippe ich auf Übertragungsfehler. Regelmäßig
>> darf das nicht auftreten.
>>
>>
>>
>>> Hoffe, das hilft weiter.
>>>
>>> Martin (der andere ;-))
>>>
>>
>> ...ich fürchte nicht wirklich ;-) Eine korrekte xmllist scheint ja
>> eingelesen worden zu sein.
>>
>> Martin :-)
>>
>>
>>
>>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hier noch mal der genaue Wortlaut der Fehlermeldung:
XML error: > required at line 90
Gruß
Martin d. a.
...ich fürchte nicht wirklich ;-) Eine korrekte xmllist scheint ja
> eingelesen worden zu sein.
>
> Martin :-)
>
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Mühsam ernährt sich das Eichhörnchen ;-)
Wenn man jetzt auch noch die dazu passende xmllist hätte, wäre man schon
einen riesen Schritt weiter. Hört sich für mich so an, als ob wirklich
irgendwo ein Bug von 5.1 zu 5.2 bei der xml-Verarbeitung aufgetreten wäre.
Evtl. ist pgm3 auch nur zu empfindlich bei evtl. eingebauten Neuerungen
(XML-Verarbeitung empfinde ich zumindest als nervig).
Die dazu passende xmllist (sollte sich binnen weniger Sekunden im Aufbau
nicht ändern) erzeugt man am einfachsen mit
echo xmllist | netcat -w3
Grüße,
Martin d.e.
Am 24. April 2012 22:50 schrieb MSB :
> Hier noch mal der genaue Wortlaut der Fehlermeldung:
>
> XML error: > required at line 90
>
> Gruß
>
> Martin d. a.
>
> ...ich fürchte nicht wirklich ;-) Eine korrekte xmllist scheint ja
>> eingelesen worden zu sein.
>>
>> Martin :-)
>>
>>
>>
>>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Wie heute geschrieben, bin ich heute auch auf FHEM 5.2 umgestiegen.
Und prompt habe ich auch diesen Fehler!!
XML error: > required at line 34
Es hat auf jeden Fall etwas mit 5.2 zu tun.
Die Zeile ist bei dem Aufruf allerdings unauffällig. Am besten ich baue das
Debugging direkt in die index.php ein und lasse es die Nacht durchlaufen --
morgen weiß ich dann evtl. mehr ....
Martin d.e.
Am 24. April 2012 22:50 schrieb MSB :
> Hier noch mal der genaue Wortlaut der Fehlermeldung:
>
> XML error: > required at line 90
>
> Gruß
>
> Martin d. a.
>
> ...ich fürchte nicht wirklich ;-) Eine korrekte xmllist scheint ja
>> eingelesen worden zu sein.
>>
>> Martin :-)
>>
>>
>>
>>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Um den sporadisch auftretenen Fehler einzukreisen, hat die index.php nun
eine verbesserte Debug-Funktion und speichert vor dem Abbruch die
verursachende xmllist ab.
Bisher habe ich den Fehler nicht erneut reproduzieren können :-(
Bitte die aktuelle Version der index.php aus dem SVN mal laufen lassen:
https://fhem.svn.sourceforge.net/svnroot/fhem/trunk/fhem/webfrontend/pgm3/
Grüße,
Martin d.e.
Am 24. April 2012 22:50 schrieb MSB :
> Hier noch mal der genaue Wortlaut der Fehlermeldung:
>
> XML error: > required at line 90
>
> Gruß
>
> Martin d. a.
>
> ...ich fürchte nicht wirklich ;-) Eine korrekte xmllist scheint ja
>> eingelesen worden zu sein.
>>
>> Martin :-)
>>
>>
>>
>>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hi,
sorry, dass ich mich gestern nicht mehr gemeldet hatte, da kam ein
Besuch dazwischen...
>Außerdem eine pgm3-Seite:
>cd /var/www//
>php index.php >/tmp/pgm3php
... dauert unabhängig vom Kommentier-Status in der index.php ca 1 min
zum kompletten Durchlauf.
Direkt nach Start kommen direkt Hinweise und eine Warnung, danach
dauerts.
PHP Deprecated: Comments starting with '#' are deprecated in /etc/
php5/cli/conf.d/idn.ini on line 1 in Unknown on line 0
PHP Deprecated: Comments starting with '#' are deprecated in /etc/
php5/cli/conf.d/imagick.ini on line 1 in Unknown on line 0
PHP Deprecated: Comments starting with '#' are deprecated in /etc/
php5/cli/conf.d/imap.ini on line 1 in Unknown on line 0
PHP Deprecated: Comments starting with '#' are deprecated in /etc/
php5/cli/conf.d/mcrypt.ini on line 1 in Unknown on line 0
PHP Deprecated: Comments starting with '#' are deprecated in /etc/
php5/cli/conf.d/ming.ini on line 1 in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/
php5/20090626+lfs/ps.so' - /usr/lib/php5/20090626+lfs/ps.so: cannot
open shared object file: No such file or directory in Unknown on line
0
Nachdem Du (Martin d.e., da hab ich ja was angefangen LOL) den Fehler
reproduzieren kannst, brauchst Du noch meine fhem.cfg o.ä.?
Nochmal vielen Dank für Deine Bemühungen
Udo
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Haah(!), die xmllist in 5.2 ist in die Falle gegangen ;-)
******************************output index.php of pgm3:
There is a xmllist file for debugging under
/var/www//tmp/debugxml25.04.2012 13:01:20
XML error: > required at line 34
'******************************
..siehe debugxml unter PARTIAL...
******************************* /var/www//tmp/debugxml25.04.2012 13:01:20:
value=":FS20:FHT:FHT8V:KS300:USF1000:BS:HMS:
:CUL_EM:CUL_WS:CUL_FHTTK:CUL_RFR:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX"/>
* *
Das sporadische und nur alle paar Stunden auftretene perl-mäßige ^@ in
"PARTIAL" (line 34) bringt pgm3 aus dem Tritt.
Mal überlegen, wie man diesen Bug am besten eintütet.
@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.
Evtl. sollte ich das in fhem-developers posten?
Das mit dem XML und den 45sec sind offenbar unterschiedliche Probleme.
45sec hat wohl eher etwas mit einer neuen eingesetzten PHP-Version zu tun.
Dazu erfolgt ein separates Posting.
Viele Grüße,
Martin
Am 25. April 2012 09:18 schrieb Martin Haas :
> Um den sporadisch auftretenen Fehler einzukreisen, hat die index.php nun
> eine verbesserte Debug-Funktion und speichert vor dem Abbruch die
> verursachende xmllist ab.
> Bisher habe ich den Fehler nicht erneut reproduzieren können :-(
>
> Bitte die aktuelle Version der index.php aus dem SVN mal laufen lassen:
> https://fhem.svn.sourceforge.net/svnroot/fhem/trunk/fhem/webfrontend/pgm3/
>
> Grüße,
> Martin d.e.
>
> Am 24. April 2012 22:50 schrieb MSB :
>
>> Hier noch mal der genaue Wortlaut der Fehlermeldung:
>>
>> XML error: > required at line 90
>>
>> Gruß
>>
>> Martin d. a.
>>
>> ...ich fürchte nicht wirklich ;-) Eine korrekte xmllist scheint ja
>>> eingelesen worden zu sein.
>>>
>>> Martin :-)
>>>
>>>
>>>
>>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> * *
>
Normalerweise sieht der Wert hier immer so aus:
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> Das mit dem XML und den 45sec sind offenbar unterschiedliche Probleme.
> 45sec hat wohl eher etwas mit einer neuen eingesetzten PHP-Version zu tun.
> Dazu erfolgt ein separates Posting.
>
>
> Ja, der XML-Fehler ist schon älter.
Neue PHP-Version ? Aber PGM3 habe ich gar nicht geändert. Ich habe eher das
Gefühl, dass sich etwas mit fhem geändert hat, denn ich habe auch Probleme
mit meinen Batchfiles. Da ich mich mit perl nicht so auskenne, habe ich
kurzerhand notifys nach folgendem Schema erzeugt:
define WohnenEin notify Wohnen:on {\
system "/var/log/fhem/wohnen_ein&" \
}
define WohnenAus notify Wohnen:off {\
system "/var/log/fhem/wohnen_aus&" \
}
wohnen_ein und wohnen_aus sind shell-scripte, die wiederum fhem-Befehle
beinhalten, etwa
fhem="/usr/bin/fhem.pl 7072 "
$fhem "set Dose1 on"
sleep 1
$fhem "set Dimmer1 dim50%"
sleep 1
$fhem "set Dimmer1 on"
sleep 1
$fhem "set Dose1 on"
sleep 1
$fhem "set Dimmer1 dim50%"
sleep 1
$fhem "set Dimmer1 on"
sleep 1
Ja, ja, ich weiß, das ist nicht elegant, aber es funktionierte bis zum
letzten Update. Seitdem bleiben immer wieder shell-scripte hängen. Um den
WAF nicht zu gefährden, werde ich die Shell-scripte beseitigen und meine
cfg Datei mit vernünftigen Perl-Kommandos ausrüsten. Die Frage bleibt aber,
warum plötzlich nicht mehr funktioniert, was 2+ Jahre anstandslos lief.
Gruß
Martin d. a.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 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.
> Seitdem bleiben immer wieder shell-scripte hängen.
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
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
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
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
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
> 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
> 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
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
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
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
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
> 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
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
> 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
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
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
Originally posted by: <email address deleted>
Am Montag, 30. April 2012 12:33:03 UTC+2 schrieb Rudolf Koenig:
*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.
*Beide Effekte traten jedenfalls zeitgleich auf, weshalb ich auch sofort
einen Zusammenhang vermutete.
> 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.
>
Der Befehl *wird* ausgeführt.
Der Befehl, bei dem es hängt, ist einer, der ein "notify" auslöst. Dieses
"notify" löst einen weiteren fhem Befehl aus, der *auch* ausgeführt wird.
Hoffe, das hilft weiter.
Gruß
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Huch, mein Post ist irgendwie verschwunden. Also nochmal:
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).
>
Diese Änderung zeigt keinen Unterschied im Verhalten.
>
>
>>
>> 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.
>
Hatte diese Vermutung, weil die unmodifizierte v100312 ja mit dem
aktuellen fhem nicht läuft. Man muss erst diese Abfrage auskommentieren.
Gruß
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
>>
>> 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 ...
>
Obwohl das wohl auch schon getestet wurde (aber evtl. noch nicht von dir)
und sehr wichtig ist:
Wenn du die folgenden Zeilen in der index.php (ab Zeile 340)
#print_r($stack);
#exit;
einkommentierst,
print_r($stack);
exit;
dann wird der Bildschirm mit dem internen Array von pgm3 augenblicklich
vollgeschrieben (auch bei reoload)?
Was sind denn die letzten Zeichen? Das sollte sowas wie ") ) ) ) ) ) ) ) )
" sein.
Wenn das so klappt, dann ist der FHEM-Part prinzipiell abgeschlossen...
Grüße,
Martin
>
>>
>>>
>>> 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
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Dienstag, 1. Mai 2012 09:18:43 UTC+2 schrieb Martin Haas:
>
>
>
> Obwohl das wohl auch schon getestet wurde (aber evtl. noch nicht von dir)
> und sehr wichtig ist:
> Wenn du die folgenden Zeilen in der index.php (ab Zeile 340)
> #print_r($stack);
> #exit;
> einkommentierst,
> print_r($stack);
> exit;
> dann wird der Bildschirm mit dem internen Array von pgm3 augenblicklich
> vollgeschrieben (auch bei reoload)?
> Was sind denn die letzten Zeichen? Das sollte sowas wie ") ) ) ) ) ) ) ) )
> " sein.
>
> Die Ausgabe kommt, wie von Dir beschrieben, aber auch hier muss man die
knappe Minute warten ...
Gruß
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin,
das ist insofern eine "gute" Nachricht, da wir die Ursache nun ziemlich gut
eingekreist haben.
Anbei eine spezielle debug-index.php-Datei. Setze doch diese entpackt bitte
mal anstatt deiner index.php ein und berichte was dann im Browser-Fenster
ausgegeben wird.
Danke.
Grüße,
Martin d.e.
Am 1. Mai 2012 11:58 schrieb MSB :
>
>
> Am Dienstag, 1. Mai 2012 09:18:43 UTC+2 schrieb Martin Haas:
>>
>>
>>
>> Obwohl das wohl auch schon getestet wurde (aber evtl. noch nicht von dir)
>> und sehr wichtig ist:
>> Wenn du die folgenden Zeilen in der index.php (ab Zeile 340)
>> #print_r($stack);
>> #exit;
>> einkommentierst,
>> print_r($stack);
>> exit;
>> dann wird der Bildschirm mit dem internen Array von pgm3 augenblicklich
>> vollgeschrieben (auch bei reoload)?
>> Was sind denn die letzten Zeichen? Das sollte sowas wie ") ) ) ) ) ) ) )
>> ) " sein.
>>
>> Die Ausgabe kommt, wie von Dir beschrieben, aber auch hier muss man die
> knappe Minute warten ...
>
> Gruß
> Martin
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Da ich auch ein "Betroffener" bin, folgendes wird im Browser-Fenster
ausgegeben:
debug: start: 02.05.2012 16:45:37
debug: stream_socket_client ok, reading xmllist: 02.05.2012 16:45:37
debug: end reading xmllist: 02.05.2012 16:46:38
debug: end parse xml: 02.05.2012 16:46:38
debug: pgm3 should be ready!: 02.05.2012 16:46:38
Hoffe es hilft.
HGO
Am Mittwoch, 2. Mai 2012 16:14:44 UTC+2 schrieb Martin Haas:
>
> Hallo Martin,
>
> das ist insofern eine "gute" Nachricht, da wir die Ursache nun ziemlich
> gut eingekreist haben.
> Anbei eine spezielle debug-index.php-Datei. Setze doch diese entpackt
> bitte mal anstatt deiner index.php ein und berichte was dann im
> Browser-Fenster ausgegeben wird.
>
> Danke.
>
> Grüße,
> Martin d.e.
>
>
> Am 1. Mai 2012 11:58 schrieb MSB :
>
>>
>>
>> Am Dienstag, 1. Mai 2012 09:18:43 UTC+2 schrieb Martin Haas:
>>>
>>>
>>>
>>> Obwohl das wohl auch schon getestet wurde (aber evtl. noch nicht von
>>> dir) und sehr wichtig ist:
>>> Wenn du die folgenden Zeilen in der index.php (ab Zeile 340)
>>> #print_r($stack);
>>> #exit;
>>> einkommentierst,
>>> print_r($stack);
>>> exit;
>>> dann wird der Bildschirm mit dem internen Array von pgm3 augenblicklich
>>> vollgeschrieben (auch bei reoload)?
>>> Was sind denn die letzten Zeichen? Das sollte sowas wie ") ) ) ) ) ) ) )
>>> ) " sein.
>>>
>>> Die Ausgabe kommt, wie von Dir beschrieben, aber auch hier muss man die
>> knappe Minute warten ...
>>
>> Gruß
>> Martin
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ja, das sieht gut aus. pgm3 braucht eine Minute, um die xml-Daten mit
dieser php-routine von fhem zu bekommen.
Das kann man in php sicher schöner machen, als das "damals" gemacht wurde.
Da werde ich mal schauen, wie man das "heutzutage" besser nacht.
Ändere doch bitte mal das hier ab (ca. Zeile 280):
alt:
# fwrite($fp, "xmllist\r\n;quit\r\n");
neu:
fwrite($fp, "xmllist;quit\n");
Martin
************************
# get the xmllist from fhem
$fp = stream_socket_client("tcp://$fhem:$fhemport", $errno,
$errstr, 30);
if (!$fp) {
echo "$errstr ($errno)\n";
} else {
#debug
$now=date($timeformat);
echo "debug: stream_socket_client ok, reading xmllist: $now
\n";
# fwrite($fp, "xmllist\r\n;quit\r\n");
fwrite($fp, "xmllist;quit\n");
$outputvar=stream_get_contents($fp);
array_push($output,$outputvar);
fclose($fp);
}
#debug
$now=date($timeformat);
echo "debug: end reading xmllist: $now
\n";
***************************************
Am 2. Mai 2012 16:48 schrieb hgo :
> Da ich auch ein "Betroffener" bin, folgendes wird im Browser-Fenster
> ausgegeben:
>
> debug: start: 02.05.2012 16:45:37
> debug: stream_socket_client ok, reading xmllist: 02.05.2012 16:45:37
> debug: end reading xmllist: 02.05.2012 16:46:38
> debug: end parse xml: 02.05.2012 16:46:38
> debug: pgm3 should be ready!: 02.05.2012 16:46:38
>
> Hoffe es hilft.
> HGO
>
> Am Mittwoch, 2. Mai 2012 16:14:44 UTC+2 schrieb Martin Haas:
>>
>> Hallo Martin,
>>
>> das ist insofern eine "gute" Nachricht, da wir die Ursache nun ziemlich
>> gut eingekreist haben.
>> Anbei eine spezielle debug-index.php-Datei. Setze doch diese entpackt
>> bitte mal anstatt deiner index.php ein und berichte was dann im
>> Browser-Fenster ausgegeben wird.
>>
>> Danke.
>>
>> Grüße,
>> Martin d.e.
>>
>>
>> Am 1. Mai 2012 11:58 schrieb MSB :
>>
>>>
>>>
>>> Am Dienstag, 1. Mai 2012 09:18:43 UTC+2 schrieb Martin Haas:
>>>>
>>>>
>>>>
>>>> Obwohl das wohl auch schon getestet wurde (aber evtl. noch nicht von
>>>> dir) und sehr wichtig ist:
>>>> Wenn du die folgenden Zeilen in der index.php (ab Zeile 340)
>>>> #print_r($stack);
>>>> #exit;
>>>> einkommentierst,
>>>> print_r($stack);
>>>> exit;
>>>> dann wird der Bildschirm mit dem internen Array von pgm3 augenblicklich
>>>> vollgeschrieben (auch bei reoload)?
>>>> Was sind denn die letzten Zeichen? Das sollte sowas wie ") ) ) ) ) ) )
>>>> ) ) " sein.
>>>>
>>>> Die Ausgabe kommt, wie von Dir beschrieben, aber auch hier muss man die
>>> knappe Minute warten ...
>>>
>>> Gruß
>>> Martin
>>>
>>>
>>> --
>>> To unsubscribe from this group, send email to
>>> fhem-users+unsubscribe@**googlegroups.com
>>>
>>
>> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
mich haben beide Bugs am Tag vor meinem längeren Urlaub ereilt (merke:
KEINE Updates direkt vor dem Urlaub! :-))
Das war am 30.3 oder 1.4.
Shell scripts habe ich dann schnell von
#/home/FHZ/fhem/fhem.pl 192.168.99.175:7072 "set Heizung off"
auf
echo "set Heizung off"|nc 192.168.99.175 7072
umgestellt.
Und pgm3 ignoriert....
Nun hatte ich etwas Zeit und habe fhem.pl Rev 1397 ausgecheckt => keine
Probleme
Rev: 1399 => pgm3 braucht 1 Minute....
Ich denke Rudis Änderung "made sleep nonblocking in at/notify/etc"
hat da irgendetwas durcheinander gebracht.
Nicht das ich das jetzt fixen könnte oder verstehe was geändert wurde ....
aber der Hinweis könnte helfen.
Peter
Am Mittwoch, 2. Mai 2012 18:03:31 UTC+2 schrieb Martin Haas:
>
> Ja, das sieht gut aus. pgm3 braucht eine Minute, um die xml-Daten mit
> dieser php-routine von fhem zu bekommen.
> Das kann man in php sicher schöner machen, als das "damals" gemacht
> wurde. Da werde ich mal schauen, wie man das "heutzutage" besser nacht.
>
> Ändere doch bitte mal das hier ab (ca. Zeile 280):
> alt:
> # fwrite($fp, "xmllist\r\n;quit\r\n");
> neu:
> fwrite($fp, "xmllist;quit\n");
>
> Martin
>
>
> ************************
> # get the xmllist from fhem
> $fp = stream_socket_client("tcp://$fhem:$fhemport", $errno,
> $errstr, 30);
> if (!$fp) {
> echo "$errstr ($errno)\n";
> } else {
> #debug
> $now=date($timeformat);
> echo "debug: stream_socket_client ok, reading xmllist: $now
\n";
> # fwrite($fp, "xmllist\r\n;quit\r\n");
> fwrite($fp, "xmllist;quit\n");
> $outputvar=stream_get_contents($fp);
> array_push($output,$outputvar);
> fclose($fp);
> }
> #debug
> $now=date($timeformat);
> echo "debug: end reading xmllist: $now
\n";
> ***************************************
>
>
> Am 2. Mai 2012 16:48 schrieb hgo :
>
>> Da ich auch ein "Betroffener" bin, folgendes wird im Browser-Fenster
>> ausgegeben:
>>
>> debug: start: 02.05.2012 16:45:37
>> debug: stream_socket_client ok, reading xmllist: 02.05.2012 16:45:37
>> debug: end reading xmllist: 02.05.2012 16:46:38
>> debug: end parse xml: 02.05.2012 16:46:38
>> debug: pgm3 should be ready!: 02.05.2012 16:46:38
>>
>> Hoffe es hilft.
>> HGO
>>
>> Am Mittwoch, 2. Mai 2012 16:14:44 UTC+2 schrieb Martin Haas:
>>>
>>> Hallo Martin,
>>>
>>> das ist insofern eine "gute" Nachricht, da wir die Ursache nun ziemlich
>>> gut eingekreist haben.
>>> Anbei eine spezielle debug-index.php-Datei. Setze doch diese entpackt
>>> bitte mal anstatt deiner index.php ein und berichte was dann im
>>> Browser-Fenster ausgegeben wird.
>>>
>>> Danke.
>>>
>>> Grüße,
>>> Martin d.e.
>>>
>>>
>>> Am 1. Mai 2012 11:58 schrieb MSB :
>>>
>>>>
>>>>
>>>> Am Dienstag, 1. Mai 2012 09:18:43 UTC+2 schrieb Martin Haas:
>>>>>
>>>>>
>>>>>
>>>>> Obwohl das wohl auch schon getestet wurde (aber evtl. noch nicht von
>>>>> dir) und sehr wichtig ist:
>>>>> Wenn du die folgenden Zeilen in der index.php (ab Zeile 340)
>>>>> #print_r($stack);
>>>>> #exit;
>>>>> einkommentierst,
>>>>> print_r($stack);
>>>>> exit;
>>>>> dann wird der Bildschirm mit dem internen Array von pgm3
>>>>> augenblicklich vollgeschrieben (auch bei reoload)?
>>>>> Was sind denn die letzten Zeichen? Das sollte sowas wie ") ) ) ) ) ) )
>>>>> ) ) " sein.
>>>>>
>>>>> Die Ausgabe kommt, wie von Dir beschrieben, aber auch hier muss man
>>>> die knappe Minute warten ...
>>>>
>>>> Gruß
>>>> Martin
>>>>
>>>>
>>>> --
>>>> To unsubscribe from this group, send email to
>>>> fhem-users+unsubscribe@**googlegroups.com
>>>>
>>>
>>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Jo, jetzt funzt es wieder ... super.
Es sieht aber wohl so aus, als ob die Ursache bei fhem läge ...
Gruß
Martin
Am Mittwoch, 2. Mai 2012 18:03:31 UTC+2 schrieb Martin Haas:
>
> Ja, das sieht gut aus. pgm3 braucht eine Minute, um die xml-Daten mit
> dieser php-routine von fhem zu bekommen.
> Das kann man in php sicher schöner machen, als das "damals" gemacht
> wurde. Da werde ich mal schauen, wie man das "heutzutage" besser nacht.
>
> Ändere doch bitte mal das hier ab (ca. Zeile 280):
> alt:
> # fwrite($fp, "xmllist\r\n;quit\r\n");
> neu:
> fwrite($fp, "xmllist;quit\n");
>
> Martin
>
>
> ************************
> # get the xmllist from fhem
> $fp = stream_socket_client("tcp://$fhem:$fhemport", $errno,
> $errstr, 30);
> if (!$fp) {
> echo "$errstr ($errno)\n";
> } else {
> #debug
> $now=date($timeformat);
> echo "debug: stream_socket_client ok, reading xmllist: $now
\n";
> # fwrite($fp, "xmllist\r\n;quit\r\n");
> fwrite($fp, "xmllist;quit\n");
> $outputvar=stream_get_contents($fp);
> array_push($output,$outputvar);
> fclose($fp);
> }
> #debug
> $now=date($timeformat);
> echo "debug: end reading xmllist: $now
\n";
> ***************************************
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Sicherlich hat eine Änderung in FHEM dazu geführt, dass pgm3 auf einigen
Rechnern/Rechnerkonfigurationen nicht mehr korrekt lief.
Aus heutiger Sicht habe ich mich schon gestern gewundert, dass das
überhaupt mal lief ;-)
**********************
Ändere doch bitte mal das hier ab (ca. Zeile 280):
alt:
# fwrite($fp, "xmllist\r\n;quit\r\n");
neu:
fwrite($fp, "xmllist;quit\n");
**********************
Dieses \r\n ist Carriage Return / Line Feed (CRLF), also eigentlich eher
eine Windows-Sache ;-))
Insofern ist das etwas was in pgm3 gefixt werden soll und nicht in FHEM.
Vielen Dank an alle für die Mithilfe beim Herausfinden dieser nicht ganz
einfach zu entdeckenden Ursache -- erst recht nicht, wenn man bei seiner
eigenen Rechnerkonfiguration das nicht nachvollziehen kann. Und nein, ich
arbeite nicht mit Windows ;-))))))
Auch in einer Windows-Konfiguration sollte das übrigens auch noch
funktionieren.
Eine neue pgm3-Version wird zeitnah eingestellt (poste ich hier noch). Von
Jörg (HGO) bekam ich erste vielversprechende Screenshots mit
HomeMatic-Unterstützung zugeschickt. Auch das soll so schnell wie möglich
integriert werden.
Viele Grüße,
Martin
Am Donnerstag, 3. Mai 2012 00:10:45 UTC+2 schrieb MSB:
>
> Jo, jetzt funzt es wieder ... super.
>
> Es sieht aber wohl so aus, als ob die Ursache bei fhem läge ...
>
> Gruß
>
> Martin
>
> Am Mittwoch, 2. Mai 2012 18:03:31 UTC+2 schrieb Martin Haas:
>>
>> Ja, das sieht gut aus. pgm3 braucht eine Minute, um die xml-Daten mit
>> dieser php-routine von fhem zu bekommen.
>> Das kann man in php sicher schöner machen, als das "damals" gemacht
>> wurde. Da werde ich mal schauen, wie man das "heutzutage" besser nacht.
>>
>> Ändere doch bitte mal das hier ab (ca. Zeile 280):
>> alt:
>> # fwrite($fp, "xmllist\r\n;quit\r\n");
>> neu:
>> fwrite($fp, "xmllist;quit\n");
>>
>> Martin
>>
>>
>> ************************
>> # get the xmllist from fhem
>> $fp = stream_socket_client("tcp://$fhem:$fhemport", $errno,
>> $errstr, 30);
>> if (!$fp) {
>> echo "$errstr ($errno)\n";
>> } else {
>> #debug
>> $now=date($timeformat);
>> echo "debug: stream_socket_client ok, reading xmllist:
>> $now
\n";
>> # fwrite($fp, "xmllist\r\n;quit\r\n");
>> fwrite($fp, "xmllist;quit\n");
>> $outputvar=stream_get_contents($fp);
>> array_push($output,$outputvar);
>> fclose($fp);
>> }
>> #debug
>> $now=date($timeformat);
>> echo "debug: end reading xmllist: $now
\n";
>> ***************************************
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> # fwrite($fp, "xmllist\r\n;quit\r\n");
das konnte ich auch reproduizieren, seit dem "sleep" Umbau wurden Befehle der
Art
;quit
generell nicht ausgefuehrt. Habs gefixed und eingecheckt.
Danke fuer die Eingrenzung.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Martin,
ich habe die Zeile geändert und dann sieht es so aus:
debug: start: 03.05.2012 08:02:22
debug: stream_socket_client ok, reading xmllist: 03.05.2012 08:02:22
debug: end reading xmllist: 03.05.2012 08:02:22
debug: end parse xml: 03.05.2012 08:02:23
debug: pgm3 should be ready!: 03.05.2012 08:02:23
Was mir aber noch aufgefallen ist, das anschliessend der Browser für einen
Moment "hängt".
HGO
Am Mittwoch, 2. Mai 2012 18:03:31 UTC+2 schrieb Martin Haas:
>
> Ja, das sieht gut aus. pgm3 braucht eine Minute, um die xml-Daten mit
> dieser php-routine von fhem zu bekommen.
> Das kann man in php sicher schöner machen, als das "damals" gemacht
> wurde. Da werde ich mal schauen, wie man das "heutzutage" besser nacht.
>
> Ändere doch bitte mal das hier ab (ca. Zeile 280):
> alt:
> # fwrite($fp, "xmllist\r\n;quit\r\n");
> neu:
> fwrite($fp, "xmllist;quit\n");
>
> Martin
>
>
> ************************
> # get the xmllist from fhem
> $fp = stream_socket_client("tcp://$fhem:$fhemport", $errno,
> $errstr, 30);
> if (!$fp) {
> echo "$errstr ($errno)\n";
> } else {
> #debug
> $now=date($timeformat);
> echo "debug: stream_socket_client ok, reading xmllist: $now
\n";
> # fwrite($fp, "xmllist\r\n;quit\r\n");
> fwrite($fp, "xmllist;quit\n");
> $outputvar=stream_get_contents($fp);
> array_push($output,$outputvar);
> fclose($fp);
> }
> #debug
> $now=date($timeformat);
> echo "debug: end reading xmllist: $now
\n";
> ***************************************
>
>
> Am 2. Mai 2012 16:48 schrieb hgo :
>
>> Da ich auch ein "Betroffener" bin, folgendes wird im Browser-Fenster
>> ausgegeben:
>>
>> debug: start: 02.05.2012 16:45:37
>> debug: stream_socket_client ok, reading xmllist: 02.05.2012 16:45:37
>> debug: end reading xmllist: 02.05.2012 16:46:38
>> debug: end parse xml: 02.05.2012 16:46:38
>> debug: pgm3 should be ready!: 02.05.2012 16:46:38
>>
>> Hoffe es hilft.
>> HGO
>>
>> Am Mittwoch, 2. Mai 2012 16:14:44 UTC+2 schrieb Martin Haas:
>>>
>>> Hallo Martin,
>>>
>>> das ist insofern eine "gute" Nachricht, da wir die Ursache nun ziemlich
>>> gut eingekreist haben.
>>> Anbei eine spezielle debug-index.php-Datei. Setze doch diese entpackt
>>> bitte mal anstatt deiner index.php ein und berichte was dann im
>>> Browser-Fenster ausgegeben wird.
>>>
>>> Danke.
>>>
>>> Grüße,
>>> Martin d.e.
>>>
>>>
>>> Am 1. Mai 2012 11:58 schrieb MSB :
>>>
>>>>
>>>>
>>>> Am Dienstag, 1. Mai 2012 09:18:43 UTC+2 schrieb Martin Haas:
>>>>>
>>>>>
>>>>>
>>>>> Obwohl das wohl auch schon getestet wurde (aber evtl. noch nicht von
>>>>> dir) und sehr wichtig ist:
>>>>> Wenn du die folgenden Zeilen in der index.php (ab Zeile 340)
>>>>> #print_r($stack);
>>>>> #exit;
>>>>> einkommentierst,
>>>>> print_r($stack);
>>>>> exit;
>>>>> dann wird der Bildschirm mit dem internen Array von pgm3
>>>>> augenblicklich vollgeschrieben (auch bei reoload)?
>>>>> Was sind denn die letzten Zeichen? Das sollte sowas wie ") ) ) ) ) ) )
>>>>> ) ) " sein.
>>>>>
>>>>> Die Ausgabe kommt, wie von Dir beschrieben, aber auch hier muss man
>>>> die knappe Minute warten ...
>>>>
>>>> Gruß
>>>> Martin
>>>>
>>>>
>>>> --
>>>> To unsubscribe from this group, send email to
>>>> fhem-users+unsubscribe@**googlegroups.com
>>>>
>>>
>>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com
>>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> Was mir aber noch aufgefallen ist, das anschliessend der Browser für einen
> Moment "hängt".
>
>
Anschliessend (nach dem Einlesen der xmllist) fängt die eigentliche Arbeit
für pgm3 erst an: Logfiles einlesen, Grafiken bauen, alles auf den
Bildschirm als html schreiben usw.
Insofern sehe ich es auf Anhieb als normal an, dass --je nach
Rechnerleistung-- es etwas dauert, bis der Bildschirmaufbau komplett ist.
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Dieser XML-Fehler wurde auch behoben. Die geänderte 99_XmlList.pm ist
eingecheckt.
Insofern sollten nun alle Probleme in diesem Thread hier gelöst sein ;-)
Martin
Am Dienstag, 24. April 2012 22:50:27 UTC+2 schrieb MSB:
>
> Hier noch mal der genaue Wortlaut der Fehlermeldung:
>
> XML error: > required at line 90
>
> Gruß
>
> Martin d. a.
>
> ...ich fürchte nicht wirklich ;-) Eine korrekte xmllist scheint ja
>> eingelesen worden zu sein.
>>
>> Martin :-)
>>
>>
>>
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Super,
von mir aus vielen Dank an alle, die sich zur Lösung der Probleme
eingebracht haben.
Gruß
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ist dann die Änderung aus Rev 1508 von fhem.pl
" shutdown($server, 1);"
noch notwendig?
Am Donnerstag, 3. Mai 2012 07:44:33 UTC+2 schrieb Rudolf Koenig:
> > # fwrite($fp, "xmllist\r\n;quit\r\n");
>
> das konnte ich auch reproduizieren, seit dem "sleep" Umbau wurden Befehle
> der
> Art
> ;quit
> generell nicht ausgefuehrt. Habs gefixed und eingecheckt.
>
> Danke fuer die Eingrenzung.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
On Thu, May 03, 2012 at 01:45:18AM -0700, PanTau wrote:
> Ist dann die Änderung aus Rev 1508 von fhem.pl
> " shutdown($server, 1);"
> noch notwendig?
Nein, aber es schadet nicht :). Wenn aendern, dann wuerde ich lieber das
";quit" sparen. Vmtl. war das urspruengliche Problem, dass im Shell die
Variable auch mit "\n" terminiert war.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hi,
hach, wie schön, bei mir funzt es auch wieder... Grosse Klasse, einen
Riesenapplaus für die Fehlersuche (und das Finden ;-) ). Der Thread
liest sich fast wie ein Thriller :-D
Thumbs up
Schöne Grüsse
Udo
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nein, aber es schadet nicht :). Wenn aendern, dann wuerde ich lieber das
> ";quit" sparen. Vmtl. war das urspruengliche Problem, dass im Shell die
> Variable auch mit "\n" terminiert war.
>
>
Bei
"xmllist\r\n;quit\r\n"
kam wohl ";quit" bei fhem an.
Nun schreibt pgm3 (die aktuelle Version v120503 ist nun im SVN)
"xmllist;quit\n" insofern kommt nun offenbar nur "quit" an und es
funktioniert auch ohne ";quit"
Insofern kannst du wegen mir das ";quit" sparen -- natürlich sollten sich
die User dazu die aktuelle pgm3-Version aus dem SVN laden.
...das liest sich schon lustig :-)
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Funktioniert jetzt wieder super!!!
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On 22 Apr., 05:04, Martin Haas wrote:
> Hallo,
>
> als Autor des pgm3 kann ich dir sagen, dass pgm3 nach wie vor lebt.
>
Hallo Martin,
das hört sich gut an, denn in den letzten Tagen habe ich das PGM3 ein
wenig aufgemöbelt. :D
Wenn Du Interesse an meinen Verbesserungen hast, kann ich Dir gerne
die aktuelle Version schicken.
Ich muss nur noch an einigen Stellen etwas nachbessern.
Denn warum das Rad zweimal erfinden?
Zu den Verbesserungen:
1. HomeMatic Aktoren werden angezeigt.
2. Die Icons passen sich dem aktuellen Zustand der Aktoren an. (on,
dim50%, ...)
3. on-for-timer und follow-on-for-timer werden unterstützt. Nach
Ablauf des Timers wird das off-Icon angezeigt. (hab mir einen daran
agebrochen)
4. Das Attribut "webCmd" ist auch mit von der Patie. Damit können
spezielle Schaltbefehle auf die Buttons gelegt werden.
5. Optional: Umlautkonverter. Aus "Kueche" wird "Küche".
6. Optional: Filter für Unterstriche. Aus "Halogen_Decke" wird
"Halogen Decke".
7. Optional: Deutsches Datum auf den Buttons (vorher 2012-04-23 -
jetzt 23.04.2012)
8. Optional: Abschaltbare Anzeige des Raumnamens auf dem Aktor-Button.
9. Optional: Sortierfunktion für Raumnamen und der Aktor-Button.
LG Jörg
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
H@i,
das Problem mit den 45 sec sollte doch auch noch zu lösen sein...
Die php-Meldungen sehe ich nicht als das Problem an. Das apache-php-Modul
verhält sich auch nicht exakt so wie php auf der shell.
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.
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??
Reproduzieren kann ich den Fehler leider (!) nicht. Das was du meinst, war
ein anderer Fehler.
Ansonsten würde mich der Inhalt deiner fhem.cfg interessieren. So Timouts
bei der Wetterabfrage oder bei der Webcam-Abfrage sind denkbar, haben aber
rein gar nichts mit fhem zu tun.
Grüße,
ein rätselnder Martin
2012/4/25 ixi
> Hi,
> sorry, dass ich mich gestern nicht mehr gemeldet hatte, da kam ein
> Besuch dazwischen...
>
> >Außerdem eine pgm3-Seite:
> >cd /var/www//
> >php index.php >/tmp/pgm3php
>
> ... dauert unabhängig vom Kommentier-Status in der index.php ca 1 min
> zum kompletten Durchlauf.
> Direkt nach Start kommen direkt Hinweise und eine Warnung, danach
> dauerts.
>
> PHP Deprecated: Comments starting with '#' are deprecated in /etc/
> php5/cli/conf.d/idn.ini on line 1 in Unknown on line 0
> PHP Deprecated: Comments starting with '#' are deprecated in /etc/
> php5/cli/conf.d/imagick.ini on line 1 in Unknown on line 0
> PHP Deprecated: Comments starting with '#' are deprecated in /etc/
> php5/cli/conf.d/imap.ini on line 1 in Unknown on line 0
> PHP Deprecated: Comments starting with '#' are deprecated in /etc/
> php5/cli/conf.d/mcrypt.ini on line 1 in Unknown on line 0
> PHP Deprecated: Comments starting with '#' are deprecated in /etc/
> php5/cli/conf.d/ming.ini on line 1 in Unknown on line 0
> PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/
> php5/20090626+lfs/ps.so' - /usr/lib/php5/20090626+lfs/ps.so: cannot
> open shared object file: No such file or directory in Unknown on line
> 0
>
>
> Nachdem Du (Martin d.e., da hab ich ja was angefangen LOL) den Fehler
> reproduzieren kannst, brauchst Du noch meine fhem.cfg o.ä.?
>
> Nochmal vielen Dank für Deine Bemühungen
> Udo
>
>
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> In der fhem.cfg nicht das global vergessen: attr global port 7072 global
>
Das braucht man bei localhost natürlich nicht.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com