LBS 19000933 JSON-Abfrage

[mammut]

Hallo zusammen

Auch mit LogLevel=0 erzeugt dieser Baustein einen Eintrag ins Fehlerprotokoll. Kann man den Eintrag und den Fehlerstatus vermeiden? Er ist in meinem Fall unwichtig und störend.

[jonofe]

Im DL Portal sehe ich gar keinen LBS mit der Nummer 1091.

Fehler haben mit dem Loglevel nicht zu tun, die werden zentral geloggt.

Ich würde versuchen die Ursache des Fehlers zu ermitteln und abzuschalten.
Falls es ein Fehler im LBS ist, am besten den Autor kontaktieren.

[mammut]

Sorry, ich habe mich verschrieben. Richtig ist 19000933.
Ich kann leider nicht alle Fälle abfangen, so gerne ich es tun würde.

[jonofe]

Der LBS offensichtlich auch nicht.
was ist es denn für ein Fehler?
wenn die Ursache nicht im LBS sondern in deiner Eingabe liegt, dann musst du damit leben oder den Autor kontaktieren.
Eine andere Möglichkeit Fehler umzuleiten gibt es nicht. Wäre ja auch nicht sinnvoll, denn grundsätzlich sollte man Fehler ja sehen.

[mammut]

Ich erhalte sporadisch folgende Meldungen:

... lbs/EXE19000933.php | Fehlercode: 2 | Zeile: 37 | file_get_contents(http://...): failed to open stream: HTTP request failed!;ERROR
oder
... lbs/EXE19000933.php | Fehlercode: 2 | Zeile: 37 | file_get_contents(http://...): failed to open stream: No route to host;ERROR

Der Auslöser ist eine http-Abfrage mit Resultat eines JSON-Strings bei einem über WLAN angebundenen Gerät. Die WLAN-Verbindung ist nicht immer aktiv. In der Regel funktioniert der LBS korrekt und wenn eine Abfrage nicht durchkommt, ist allerhöchstens - wenn überhaupt - eine Warnung sinnvoll, das Setzen des Systemfehlers ist masslos übertrieben. Übrigens kontrolliere ich minütlich die Verfügbarkeit der Verbindung mit LBS 19000101, noch engmaschiger zu kontrollieren wäre kaum sinnvoll.

Entsteht der Fehler im LBS oder im System?

[maque]

Warum auch immer kann der LBS zu diesem Zeitpunkt die URL nicht abrufen. Das kann aber im LBS abgefangen werden.

Gruesse
Matthias

[jonofe]

das Setzen des Systemfehlers ist masslos übertrieben.

In diesem konkreten Fall vielleicht. Aber der Fehler wird ja von PHP erzeugt und mit dem gültigen ErrorHandler abgearbeitet. Daran kann man grundsätzlich nichts ändern. LBSe können nur in CustomLogs schreiben. Um solche Fehler in ein CustomLog umzuleiten muss man im LBS den ErrorHandler umbiegen und das idealerweise auch nur für den bestimmten Code-Abschnitt. Da kommt dann wieder der Autor des LBS ins Spiel...
Evtl. funktioniert auch der @-Operator beim Aufruf von file_get_contents(). Meine mich aber zu erinnern, dass der in EDOMI ignoriert wird. Warum weiss ich nicht.

[mammut]

maque Hallo Matthias
Wie denn? Ich habe Diverses erfolglos versucht.
Dank+Grüsse, Csaba

[maque]

Über die Funktion set_error_handler("exception_error_handler", E_ALL);

Das kannst Du Dir in meinem Baustein 19000828 anschauen. Der ruft die openweather URL ab.

Gruesse
Matthias

[mammut]

Sorry, ich bin PHP-Laie. Kann ich die Funktion und den Parameter E_ALL 1:1 übernehmen?

[maque]

Ich würde an Deiner Stelle versuchen, den Entwickler des Bausteins zu bitten, den Fehler entsprechend anzufangen. Das ist bei solchen Anfragen aus jeden Fall sinnvoll.

[mammut]

Mach ich, ist wirklich klüger. Danke.

[MrIcemanLE]

Da will ich mal als "Entwickler" hier melden. 🙃 ... bin auch kein php Profi und mache das hier nur nebenbei 😇


Die "einzige" Möglichkeit war tatsächlich den error_handler temporär zu ändern. Hier bleibt natürlich die Frage wie problematisch der fehlerhafte Request für den einzelnen ist. Wenn es sich um wichtige Systeme handelt ist eine Systemmeldung sicher sinnvoll. Wenn damit aber das System-Log vollläuft hilft das auch keinem.

Sauberer wäre wahrscheinlich eine Abfrage über CURL und dann eine Auswertung des Return-Status mit Fehlerausgabe auf einem Ausgang, sodass man sich ggf. auch informieren lassen kann. Naja...

In der neuen v0.3 sollte jetzt der Fehler jetzt im CustomLog landen.

Gruß
Stefan

[mfd]

In der neuen v0.3 sollte jetzt der Fehler jetzt im CustomLog landen.

Ich habe gerade die v0.4 mit Loglevel von 1 bis 8 ausprobiert. Bei Loglevel 1, 5 oder 7 passiert nichts. Nur bei Loglevel 8 wird bei mir eine Logdatei geschrieben.
Die Ausgabe ist dann

debug    EXE19000933 [v0.4]: LBS started
debug    EXE19000933 [v0.4]: $result
debug    EXE19000933 [v0.4]: LBS stopped

Wenn die IP-Adresse für den LBS nicht erreichbar ist bekomme ich

debug    EXE19000933 [v0.4]: LBS started
debug    EXE19000933 [v0.4]: file_get_contents ```` $*
debug    EXE19000933 [v0.4]: LBS stopped