[gelöst] Verständnisfrage: exec versus http (GET)

[OliverIO]

@raspiuser

Httpget ist ein asynchroner Befehl.
D.h. javascript weiß nicht wie lange der Befehl dauern könnte. Time out gibt vor wie lange gewartet werden soll, bevor ein Fehler erzeugt wird. Wenn die Gegenstände sehr lang benötigt, kann man das Ding erhöhen. Wobei ein zwei oder 3 Sekunden in einem lokalen Netzwerk schon sehr lange sind
Die angezeigte Fehlermeldung liegt aber nicht am Time out, sondern wahrscheinlich auf der Gegenstelle wurde es abgebrochen.
Die Befehlszeile in der Fehlermeldung sieht auch ein wenig seltsam aus. Da endet der Link mit einem Sonderzeichen?

[RaspiUser]

@oliverio Danke für die Erklärungen ...

• ... d.h. "Timeout" ist es in meinem Fall egal, wie lang das eigentlich MP3-File dauert. Dann lass ich es bei der Voreinstellung 2000 ms
• Sonderzeichen ? ... die "%20" sind das Leerzeichen vor der Filenummer "1" für den TASMOTA MP-3 Player. Funktioniert im Browser ohne Kommentare, zickt nur im Blockly unregelmäßig ... ich beobachte weiter ...

[haus-automatisierung]

@raspiuser sagte in [gelöst] Verständnisfrage: exec versus http (GET):

... d.h. "Timeout" ist es in meinem Fall egal, wie lang das eigentlich MP3-File dauert.

Das kommt darauf an, wann die Gegenseite antwortet.

1. Sobald die Wiedergabe gestartet wurde = Timeout egal, weil sofort eine Antwort kommt
2. Sobald die Wiedergabe beendet ist = Timeout hängt von der Länge der mp3-Datei ab

@raspiuser sagte in [gelöst] Verständnisfrage: exec versus http (GET):

Sonderzeichen ? ... die "%20" sind das Leerzeichen vor der Filenummer "1"

Das ist ja ganz normales URL Encoding und sollte auch im Blockly nicht "zicken" (was auch immer das heißt).

[RaspiUser]

@haus-automatisierung

• Also doch eine Abhängigkeit zwischen der File-Länge und dem Timeout ? D.h. ich sollte es in meinem Fall an die "Länge des längsten Files + 1sek", also anpassen ?
  (Ich habe keine Ahnung, wie der TASMOTA MP-3-Player im Hintergrund arbeitet)
• "zicken" nicht wegen Sonderzeichen sondern Ausführung "Manchmal ohne Probleme, manchmal mit o.g. Fehlermeldung, manchmal garnicht" bei immer demselben File ... also dann wohl eher ein WLAN-Verbindungsproblem ?

[haus-automatisierung]

@raspiuser sagte in [gelöst] Verständnisfrage: exec versus http (GET):

also dann wohl eher ein WLAN-Verbindungsproblem ?

Mit Tasmota und HTTP hatten hier immer wieder Leute Probleme. Denke nicht dass es am WLAN liegt, sondern wie und wann Tasmota antwortet. Eventuell ist HTTP da nicht sauber implementiert.

[OliverIO]

@haus-automatisierung

Wenn das ein Player ist, kannst du dem nicht den link direkt geben?
Sonst ist dein blockly ja nur datenschaufler.
Sorry wegen dem link, wie gesagt das kann schon sein, hab nur kein mp3 als Dateierweiterung gesehen und weiß nicht was für eine Software an der Quelle ist.

[haus-automatisierung]

@oliverio sagte in [gelöst] Verständnisfrage: exec versus http (GET):

Wenn das ein Player ist, kannst du dem nicht den link direkt geben?

Das wird wohl ein DFPlayer sein, welcher mp3-Dateien von einer SD-Karte spielt

https://tasmota.github.io/docs/Commands/#mp3-player

[RaspiUser]

@haus-automatisierung stimmt ...

[RaspiUser]

@haus-automatisierung sagte in [gelöst] Verständnisfrage: exec versus http (GET):

Eventuell ist HTTP da nicht sauber implementiert.

... und da kann nur der Entwickler etwas tun, richtig?
Ansonsten wie schon gesagt: Ich beobachte weiter ..

[BananaJoe]

@raspiuser wie wäre es dann es per mqtt zu machen? Dann lauscht das Tasmota-Gerät und wird benachrichtigt und du brauchst dich um nichts zu kümmern.

[RaspiUser]

@bananajoe sagte in [gelöst] Verständnisfrage: exec versus http (GET):

per mqtt

... okay... schau ich mir an ...