Skip to content
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Skripten / Logik
  4. JavaScript
  5. Fehlerbehandlung httpGet/httPost

NEWS

  • Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨
    BluefoxB
    Bluefox
    16
    1
    1.9k

  • Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
    BluefoxB
    Bluefox
    13
    1
    900

  • Weihnachtsangebot 2025! 🎄
    BluefoxB
    Bluefox
    25
    1
    2.2k

Fehlerbehandlung httpGet/httPost

Geplant Angeheftet Gesperrt Verschoben JavaScript
33 Beiträge 13 Kommentatoren 4.0k Aufrufe 12 Watching
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • haus-automatisierungH haus-automatisierung

    @diwoma Du wirfst gerade zwei Themen zusammen. Die Log-Meldung hat ja erstmal nichts mit einem try/catch oder einer unhandled exception zu tun. Die wird es bei den Varianten mit Callback auch nicht geben. Dann nutze die Varianten mit Promises (also httpGetAsync). Dann kannst mit .catch(..) des Promises arbeiten oder halt mit await und einem try/catch.

    T Offline
    T Offline
    tobi19
    schrieb am zuletzt editiert von
    #23

    @haus-automatisierung sagte in Fehlerbehandlung httpGet/httPost:

    Die wird es bei den Varianten mit Callback auch nicht geben. Dann nutze die Varianten mit Promises (also httpGetAsync). Dann kannst mit .catch(..) des Promises arbeiten oder halt mit await und einem try/catch.

    Mein Missverständnis liegt wohl in meiner Unkenntnis der Möglichkeiten von Javascript.
    Wenn es eine anderen Funktionsaufruf gibt (z.B. httpGetAsync), welche die explizite Fehlerbehandlung erlaubt, ist das mit Blockly unverändert ja prima.
    Dann bitte ich als JavaScript Anfänger um Hilfe.
    Mit geht es darum, bei einem Timeout keinen expliziten Logeintrag zu bekommen, da mein WLAN leider nicht sehr stabil ist.
    Einen Code mit httpGetAsync und Promise kann ich leider noch nicht generieren.

    Mein Versuch mit

    try {
        let response =  await httpGetAsync('http://192.168.178.127/status');
        if (response.statusCode = 200) {
            console.log(response.data);
        }
        else {
            console.log(response.responseTime)
        }
    } 
    catch (error) {
            console.warn(error);
    }
    

    führt auch zu einer implizite generierten Timeout Fehlermeldung.

    Danke

    P B 2 Antworten Letzte Antwort
    0
    • T tobi19

      @haus-automatisierung sagte in Fehlerbehandlung httpGet/httPost:

      Die wird es bei den Varianten mit Callback auch nicht geben. Dann nutze die Varianten mit Promises (also httpGetAsync). Dann kannst mit .catch(..) des Promises arbeiten oder halt mit await und einem try/catch.

      Mein Missverständnis liegt wohl in meiner Unkenntnis der Möglichkeiten von Javascript.
      Wenn es eine anderen Funktionsaufruf gibt (z.B. httpGetAsync), welche die explizite Fehlerbehandlung erlaubt, ist das mit Blockly unverändert ja prima.
      Dann bitte ich als JavaScript Anfänger um Hilfe.
      Mit geht es darum, bei einem Timeout keinen expliziten Logeintrag zu bekommen, da mein WLAN leider nicht sehr stabil ist.
      Einen Code mit httpGetAsync und Promise kann ich leider noch nicht generieren.

      Mein Versuch mit

      try {
          let response =  await httpGetAsync('http://192.168.178.127/status');
          if (response.statusCode = 200) {
              console.log(response.data);
          }
          else {
              console.log(response.responseTime)
          }
      } 
      catch (error) {
              console.warn(error);
      }
      

      führt auch zu einer implizite generierten Timeout Fehlermeldung.

      Danke

      P Offline
      P Offline
      peterfido
      schrieb am zuletzt editiert von peterfido
      #24

      @tobi19 Der Fehler an sich ist ja vorhanden. Wenn das WLAN mies ist, dann den Timeout erhöhen, oder, wenn es regelmäßig auftritt, vorher per Ping checken, ob die Verbindung da ist.

      Gruß

      Peterfido


      Proxmox auf Intel NUC12WSHi5
      ioBroker: Debian (VM)
      CCU: Debmatic (VM)
      Influx: Debian (VM)
      Grafana: Debian (VM)
      eBus: Debian (VM)
      Zigbee: Debian (VM) mit zigbee2mqtt

      1 Antwort Letzte Antwort
      0
      • T tobi19

        @haus-automatisierung sagte in Fehlerbehandlung httpGet/httPost:

        Die wird es bei den Varianten mit Callback auch nicht geben. Dann nutze die Varianten mit Promises (also httpGetAsync). Dann kannst mit .catch(..) des Promises arbeiten oder halt mit await und einem try/catch.

        Mein Missverständnis liegt wohl in meiner Unkenntnis der Möglichkeiten von Javascript.
        Wenn es eine anderen Funktionsaufruf gibt (z.B. httpGetAsync), welche die explizite Fehlerbehandlung erlaubt, ist das mit Blockly unverändert ja prima.
        Dann bitte ich als JavaScript Anfänger um Hilfe.
        Mit geht es darum, bei einem Timeout keinen expliziten Logeintrag zu bekommen, da mein WLAN leider nicht sehr stabil ist.
        Einen Code mit httpGetAsync und Promise kann ich leider noch nicht generieren.

        Mein Versuch mit

        try {
            let response =  await httpGetAsync('http://192.168.178.127/status');
            if (response.statusCode = 200) {
                console.log(response.data);
            }
            else {
                console.log(response.responseTime)
            }
        } 
        catch (error) {
                console.warn(error);
        }
        

        führt auch zu einer implizite generierten Timeout Fehlermeldung.

        Danke

        B Offline
        B Offline
        Blockmove
        schrieb am zuletzt editiert von
        #25

        @tobi19 said in Fehlerbehandlung httpGet/httPost:

        Mit geht es darum, bei einem Timeout keinen expliziten Logeintrag zu bekommen, da mein WLAN leider nicht sehr stabil ist.

        Ich schließ mich da einfach mal an.
        Mir gefallen die expliziten Logeinträge auch nicht. Egal ob nun Blockly oder Javascript.
        Mag vielleicht sein, dass es für Anfänger etwas einfacher ist.
        Aber wenn ich httpGet das erstemal verwende, dann muss ich mir sowieso die Beschreibung und / oder Beispiele anschauen.
        Gibt es einen Fehlerhandler, dann programmiere ich ihn entsprechend und gut ist's.

        The difference beetween Man and Boys:
        The price of their toys 😀

        haus-automatisierungH 1 Antwort Letzte Antwort
        0
        • B Blockmove

          @tobi19 said in Fehlerbehandlung httpGet/httPost:

          Mit geht es darum, bei einem Timeout keinen expliziten Logeintrag zu bekommen, da mein WLAN leider nicht sehr stabil ist.

          Ich schließ mich da einfach mal an.
          Mir gefallen die expliziten Logeinträge auch nicht. Egal ob nun Blockly oder Javascript.
          Mag vielleicht sein, dass es für Anfänger etwas einfacher ist.
          Aber wenn ich httpGet das erstemal verwende, dann muss ich mir sowieso die Beschreibung und / oder Beispiele anschauen.
          Gibt es einen Fehlerhandler, dann programmiere ich ihn entsprechend und gut ist's.

          haus-automatisierungH Online
          haus-automatisierungH Online
          haus-automatisierung
          Developer Most Active
          schrieb am zuletzt editiert von
          #26

          @blockmove sagte in Fehlerbehandlung httpGet/httPost:

          Aber wenn ich httpGet das erstemal verwende, dann muss ich mir sowieso die Beschreibung und / oder Beispiele anschauen.

          Und wenn Du nur den Blockly-Baustein nutzt, musst Du vorher gar keine Doku oder Signaturen der Funktionen anschauen.

          Erstelle gerne einen PR mit Deinem Vorschlag (für JS und neuem Blockly-Code) und dann diskutieren wir gerne die Lösung.

          🧑‍🎓 Autor des beliebten ioBroker-Master-Kurses
          🎥 Tutorials rund um das Thema DIY-Smart-Home: https://haus-automatisierung.com/
          📚 Meine inoffizielle ioBroker Dokumentation

          B 2 Antworten Letzte Antwort
          0
          • haus-automatisierungH haus-automatisierung

            @blockmove sagte in Fehlerbehandlung httpGet/httPost:

            Aber wenn ich httpGet das erstemal verwende, dann muss ich mir sowieso die Beschreibung und / oder Beispiele anschauen.

            Und wenn Du nur den Blockly-Baustein nutzt, musst Du vorher gar keine Doku oder Signaturen der Funktionen anschauen.

            Erstelle gerne einen PR mit Deinem Vorschlag (für JS und neuem Blockly-Code) und dann diskutieren wir gerne die Lösung.

            B Offline
            B Offline
            Blockmove
            schrieb am zuletzt editiert von
            #27

            @haus-automatisierung said in Fehlerbehandlung httpGet/httPost:

            Erstelle gerne einen PR mit Deinem Vorschlag (für JS und neuem Blockly-Code) und dann diskutieren wir gerne die Lösung.
            Ich fand eigentlich die Umsetzung des alten request gar nicht so schlecht. Im Script mit try - catch und im Blockly mit dem wählbaren Loglevel.

            Vielleicht kannst du ja die interne Fehlermeldung des httpGet deaktivieren und das Blockly so gestalten wie beim request.
            Im Script funktioniert ja try - catch heute schon. Nur kommt die interne Fehlermeldung halt immer.

            Das ganze ist aber eher ein kosmetisches Thema und aus meiner Sicht keine hohe Prio.

            The difference beetween Man and Boys:
            The price of their toys 😀

            1 Antwort Letzte Antwort
            1
            • haus-automatisierungH haus-automatisierung

              @blockmove sagte in Fehlerbehandlung httpGet/httPost:

              Aber wenn ich httpGet das erstemal verwende, dann muss ich mir sowieso die Beschreibung und / oder Beispiele anschauen.

              Und wenn Du nur den Blockly-Baustein nutzt, musst Du vorher gar keine Doku oder Signaturen der Funktionen anschauen.

              Erstelle gerne einen PR mit Deinem Vorschlag (für JS und neuem Blockly-Code) und dann diskutieren wir gerne die Lösung.

              B Offline
              B Offline
              Blockmove
              schrieb am zuletzt editiert von Blockmove
              #28

              @haus-automatisierung said in Fehlerbehandlung httpGet/httPost:

              @blockmove sagte in Fehlerbehandlung httpGet/httPost:

              Aber wenn ich httpGet das erstemal verwende, dann muss ich mir sowieso die Beschreibung und / oder Beispiele anschauen.

              Und wenn Du nur den Blockly-Baustein nutzt, musst Du vorher gar keine Doku oder Signaturen der Funktionen anschauen.

              Erstelle gerne einen PR mit Deinem Vorschlag (für JS und neuem Blockly-Code) und dann diskutieren wir gerne die Lösung.

              Ich hab dazu mal ein Github-Issue angelegt:
              Github Issue

              The difference beetween Man and Boys:
              The price of their toys 😀

              1 Antwort Letzte Antwort
              0
              • V Online
                V Online
                viper4iob
                schrieb am zuletzt editiert von
                #29

                Könnte jemand mal einen Code-Schnipsel zur Verfügung stellen, wie man httpGetAsync mit selbst definierten Timeout aufruft und bei nicht erreichen der URL den timeout error mittels .catch() oder await/try/catch abfangen kann, so dass dieser nicht im iobroker log als error auftaucht.
                Das wäre super, danke.

                1 Antwort Letzte Antwort
                0
                • P Offline
                  P Offline
                  peterfido
                  schrieb am zuletzt editiert von peterfido
                  #30

                  Schnipsel. writeFile gegen eigene Weiterverarbeitung ersetzen

                          httpGet( URL, { validateCertificate: false, timeout: 2000, responseType: 'arraybuffer' }, async (err, response) => {
                          if (err) {
                              console.error(err);
                          }
                              fs.writeFile(img_path + 'cam4.jpg',  response.data, 'binary', function(err) {
                                  if (err) {
                                      log('Fehler beim Speichern von Bild 4: ' + err, 'warn');
                                  } else {
                                      log('Bild 4 gespeichert.');
                                  }
                              });         
                          });
                  
                  

                  Gruß

                  Peterfido


                  Proxmox auf Intel NUC12WSHi5
                  ioBroker: Debian (VM)
                  CCU: Debmatic (VM)
                  Influx: Debian (VM)
                  Grafana: Debian (VM)
                  eBus: Debian (VM)
                  Zigbee: Debian (VM) mit zigbee2mqtt

                  1 Antwort Letzte Antwort
                  0
                  • V Online
                    V Online
                    viper4iob
                    schrieb zuletzt editiert von viper4iob
                    #31

                    @peterfido
                    Danke für die Rückmeldung.
                    Es kommt aber auch mit entfernen der zusätzlichen log-Zeilen im Code weiterhin der Standard-Error im Log, wenn das Zielsystem nicht erreichbar ist:

                    javascript.0	10:14:37.420	error	httpGet(url=http:****************, error=timeout of 3000ms exceeded)
                    

                    Und genau den will ich los werden.

                    Alle Varianten, die ich bis jetzt mit httpGet oder httpGetAsync inkl. try/catch, async/await oder .catch() probiert habe, waren erfolglos. Ich bin allerdings auch kein Javascript Profi ;-)

                    Ich möchte alle 5 Sekunden eine URL abfragen, um Statusdaten zu erhalten, die aber nur für die Visualisierung relevant sind, aber nicht lebensnotwendig.
                    Wenn das Zielsystem aber mal eine halbe Stunde weg ist, bekomme ich alle 5 Sekunden eine Fehlermeldung, und müllt so das Log zu.

                    Ich benötige also eine Code-Variante von httpGet oder httpGetAsync, die bei nicht erreichen des Zielsystems keinen Error im iobroker Standard-Log erzeugt und ich den Fehler im Code selbst verarbeiten kann (z.B. nach einer gewissen Zeit erst einen Fehler ausgeben oder das Log-Level festlegen).

                    haus-automatisierungH 1 Antwort Letzte Antwort
                    0
                    • V viper4iob

                      @peterfido
                      Danke für die Rückmeldung.
                      Es kommt aber auch mit entfernen der zusätzlichen log-Zeilen im Code weiterhin der Standard-Error im Log, wenn das Zielsystem nicht erreichbar ist:

                      javascript.0	10:14:37.420	error	httpGet(url=http:****************, error=timeout of 3000ms exceeded)
                      

                      Und genau den will ich los werden.

                      Alle Varianten, die ich bis jetzt mit httpGet oder httpGetAsync inkl. try/catch, async/await oder .catch() probiert habe, waren erfolglos. Ich bin allerdings auch kein Javascript Profi ;-)

                      Ich möchte alle 5 Sekunden eine URL abfragen, um Statusdaten zu erhalten, die aber nur für die Visualisierung relevant sind, aber nicht lebensnotwendig.
                      Wenn das Zielsystem aber mal eine halbe Stunde weg ist, bekomme ich alle 5 Sekunden eine Fehlermeldung, und müllt so das Log zu.

                      Ich benötige also eine Code-Variante von httpGet oder httpGetAsync, die bei nicht erreichen des Zielsystems keinen Error im iobroker Standard-Log erzeugt und ich den Fehler im Code selbst verarbeiten kann (z.B. nach einer gewissen Zeit erst einen Fehler ausgeben oder das Log-Level festlegen).

                      haus-automatisierungH Online
                      haus-automatisierungH Online
                      haus-automatisierung
                      Developer Most Active
                      schrieb zuletzt editiert von
                      #32

                      @viper4iob sagte in Fehlerbehandlung httpGet/httPost:

                      Und genau den will ich los werden.

                      Alle Varianten, die ich bis jetzt mit httpGet oder httpGetAsync inkl. try/catch, async/await oder .catch() probiert habe, waren erfolglos.

                      Aktuell ist es so, dass die Meldung immer geschrieben wird:

                      https://github.com/ioBroker/ioBroker.javascript/blob/1d1c2c69e12a28dc52527751bc882347005278ee/src/lib/sandbox.ts#L1443

                      Es ist also egal ob es einen Callback gibt oder mit Promises gearbeitet wird.

                      @viper4iob sagte in Fehlerbehandlung httpGet/httPost:

                      Ich benötige also eine Code-Variante von httpGet oder httpGetAsync, die bei nicht erreichen des Zielsystems keinen Error im iobroker Standard-Log erzeugt

                      Dazu gibt es glaube ich sogar schon einen Feature Request.

                      🧑‍🎓 Autor des beliebten ioBroker-Master-Kurses
                      🎥 Tutorials rund um das Thema DIY-Smart-Home: https://haus-automatisierung.com/
                      📚 Meine inoffizielle ioBroker Dokumentation

                      CodierknechtC 1 Antwort Letzte Antwort
                      0
                      • haus-automatisierungH haus-automatisierung

                        @viper4iob sagte in Fehlerbehandlung httpGet/httPost:

                        Und genau den will ich los werden.

                        Alle Varianten, die ich bis jetzt mit httpGet oder httpGetAsync inkl. try/catch, async/await oder .catch() probiert habe, waren erfolglos.

                        Aktuell ist es so, dass die Meldung immer geschrieben wird:

                        https://github.com/ioBroker/ioBroker.javascript/blob/1d1c2c69e12a28dc52527751bc882347005278ee/src/lib/sandbox.ts#L1443

                        Es ist also egal ob es einen Callback gibt oder mit Promises gearbeitet wird.

                        @viper4iob sagte in Fehlerbehandlung httpGet/httPost:

                        Ich benötige also eine Code-Variante von httpGet oder httpGetAsync, die bei nicht erreichen des Zielsystems keinen Error im iobroker Standard-Log erzeugt

                        Dazu gibt es glaube ich sogar schon einen Feature Request.

                        CodierknechtC Online
                        CodierknechtC Online
                        Codierknecht
                        Developer Most Active
                        schrieb zuletzt editiert von
                        #33

                        @haus-automatisierung sagte in Fehlerbehandlung httpGet/httPost:

                        Dazu gibt es glaube ich sogar schon einen Feature Request.

                        https://github.com/ioBroker/ioBroker.javascript/issues/1599

                        "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")

                        Proxmox 9.1.1 LXC|8 GB|Core i7-6700
                        HmIP|ZigBee|Tasmota|Unifi
                        Zabbix Certified Specialist
                        Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag

                        1 Antwort Letzte Antwort
                        0
                        Antworten
                        • In einem neuen Thema antworten
                        Anmelden zum Antworten
                        • Älteste zuerst
                        • Neuste zuerst
                        • Meiste Stimmen


                        Support us

                        ioBroker
                        Community Adapters
                        Donate

                        737

                        Online

                        32.6k

                        Benutzer

                        82.2k

                        Themen

                        1.3m

                        Beiträge
                        Community
                        Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
                        ioBroker Community 2014-2025
                        logo
                        • Anmelden

                        • Du hast noch kein Konto? Registrieren

                        • Anmelden oder registrieren, um zu suchen
                        • Erster Beitrag
                          Letzter Beitrag
                        0
                        • Home
                        • Aktuell
                        • Tags
                        • Ungelesen 0
                        • Kategorien
                        • Unreplied
                        • Beliebt
                        • GitHub
                        • Docu
                        • Hilfe