Ankündigung

Einklappen
Keine Ankündigung bisher.

LBS 19000933 JSON-Abfrage

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • mfd
    antwortet
    Zitat von MrIcemanLE Beitrag anzeigen
    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
    Code:
    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
    Code:
    debug    EXE19000933 [v0.4]: LBS started
    debug    EXE19000933 [v0.4]: file_get_contents ```` $*
    debug    EXE19000933 [v0.4]: LBS stopped

    Einen Kommentar schreiben:


  • MrIcemanLE
    antwortet
    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

    Einen Kommentar schreiben:


  • mammut
    antwortet
    Mach ich, ist wirklich klüger. Danke.

    Einen Kommentar schreiben:


  • maque
    antwortet
    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.
    Zuletzt geändert von maque; 26.03.2022, 12:33.

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • maque
    antwortet
    Ü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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    Zitat von mammut Beitrag anzeigen
    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.
    Zuletzt geändert von jonofe; 26.03.2022, 09:37.

    Einen Kommentar schreiben:


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

    Gruesse
    Matthias

    Einen Kommentar schreiben:


  • mammut
    antwortet
    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?

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    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.

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • jonofe
    antwortet
    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.

    Einen Kommentar schreiben:


  • mammut
    hat ein Thema erstellt LBS 19000933 JSON-Abfrage.

    LBS 19000933 JSON-Abfrage

    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.
Lädt...
X