Ich verwende NonblockingGet um einen URL Aufruf mit anschließenden Datenerhalt zu machen.
Leider bekomme ich immer nur ein Timeout. Es wird wohl am Zusammenspiel von NonblockingGet und dem Webserver der Gegenstelle sein. Ein stink normaler curl Aufruf klappt ohne Probleme. Kann mir einer einen Tip geben wie ich das ganze Testen kann.
Interessant wäre wohl noch das ein
http://ip:port/info?token=1234
super funktioniert, wo gegen ein
http://ip:port/list?token=1234
jeweils mit einem Timeout abbricht. Ich habe schon so einige Optionen durch
noshutdown => 1 oder 0
keepalive => 0 oder 1
httpversion => "1.1" oder 1.0
Wie kann ich da am besten testen um zu erfahren was die Gegenstelle für Probleme hat?
In beiden Fällen wird als Antwort ein JSON String geliefert.
Danke Euch
Grüße
Kannst du mir die Differenz zwischen den beiden URLs verdeutlichen? Ich bin blind...
Sonst tippe ich auf fehlende Headerdaten im Request.
Sorry. Mein Fehler. Eines davon ist /list das andere /info
Vielleicht musst du noch einen User-Agent setzen, der eher wie ein Browser heißt?
Hatte ich meines Erachtens schon gehabt. Aber ich probiere gerne noch mal.
Hast du da vielleicht eine Header Zeile für mich die nachweislich funktioniert?
Nimm im Zweifel doch den User-Agent deines Browsers wie z.B. hier einzusehen:
http://www.whoishostingthis.com/tools/user-agent/
Wichtig ist dabei glaube ich aber nur am Anfang sowas wie "Mozilla/5.0" stehen zu haben.
Hallo Julian,
Vielen Dank für Deine Anwort. Habe ich mal probiert, hilft aber auch nichts. Ich denke es hat was mit der Hersteller API zu tun. Die wollten das ich denen ein funktionierendes Perl Script mit den Aufrufen und der Verwendung von http Utils gebe. Also einen originalen Aufruf nur ohne FHEM. Mal sehen ob ich das so einfach hin bekomme.
Grüße
Leon
Habe soeben einen Hinweis vom Hersteller bekommen.
Zitat
Die Vermutung ist, dass das httputils irgendwie mit den responses nicht klar kommt (längere responses werden als mehrere sequentielle pakete geschickt)
Kann ich das irgendwie abfangen? Das selbe Problem habe ich auch wenn ich Blocking_Get verwende um zum Beispiel ein Log Auszug von der Nuki Bridge zu holen.
Protokolliere bitte ein Versuch im Browser/wget/etc mit allen Headerdaten, und dann ein HttpNonblockingGet mit maximalen verbose, und gib danach die headerdaten aus ($hash->{httpheader}). Ich versuche dann aus diesen Daten zu verstehen, was schiefgeht.
Mache ich.
Eventuell wäre das hier ein Ansatz
https://forum.fhem.de/index.php?topic=43377.0
Melde mich wenn ich getestet habe.
So ich habe mich da mal versucht
Das hier ist mit curl aufgerufen
curl -v http://10.6.34.46:8080/list?token=FX0dQQ
* Hostname was NOT found in DNS cache
* Trying 10.6.34.46...
* Connected to 10.6.34.46 (10.6.34.46) port 8080 (#0)
> GET /list?token=FX0dQQ HTTP/1.1
> User-Agent: curl/7.38.0
> Host: 10.6.34.46:8080
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: Close
< Content-Type: application/json;charset=utf-8
< Transfer-Encoding: chunked
<
* Closing connection 0
[{"nukiId": 1, "name": "CobraTuer", "lastKnownState": {"state": 255, "stateName": "undefined", "batteryCritical": false, "timestamp": "2016-12-06T13:02:08+00:00"}}]
Und hier mit HttpUtils_nonBlockingGet
2016.12.08 10:29:10 4: WEB_10.6.9.2_54710 POST /fhem&detail=NukiBridge&dev.setNukiBridge=NukiBridge&cmd.setNukiBridge=set&arg.setNukiBridge=autocreate&val.setNukiBridge=; BUFLEN:0
2016.12.08 10:29:10 5: Cmd: >set NukiBridge autocreate<
2016.12.08 10:29:10 5: HttpUtils url=http://10.6.34.46:8080/list?token=FX0dQQ
2016.12.08 10:29:10 4: NUKIBridge (NukiBridge) - Send HTTP POST with URL http://10.6.34.46:8080/list?token=FX0dQQ
2016.12.08 10:29:10 5: Triggering NukiBridge (1 changes)
2016.12.08 10:29:10 5: Starting notify loop for NukiBridge, 1 event(s), first is autocreate
2016.12.08 10:29:10 4: WEB_10.6.9.2_54710 GET /fhem?detail=NukiBridge&fw_id=; BUFLEN:0
2016.12.08 10:29:10 4: name: /fhem?detail=NukiBridge&fw_id= / RL:3028 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.08 10:29:10 4: Connection closed for WEB_10.6.9.2_54704: EOF
2016.12.08 10:29:10 4: WEB_10.6.9.2_54716 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54716 => 304 Not Modified
2016.12.08 10:29:10 4: WEB_10.6.9.2_54714 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54714 => 304 Not Modified
2016.12.08 10:29:10 4: Connection accepted from WEB_10.6.9.2_54718
2016.12.08 10:29:10 4: WEB_10.6.9.2_54710 GET /fhem/pgm2/style.css?v=1481024918; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54710 => 304 Not Modified
2016.12.08 10:29:10 4: WEB_10.6.9.2_54712 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54712 => 304 Not Modified
2016.12.08 10:29:10 4: WEB_10.6.9.2_54708 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54708 => 304 Not Modified
2016.12.08 10:29:10 4: WEB_10.6.9.2_54710 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54710 => 304 Not Modified
2016.12.08 10:29:10 4: WEB_10.6.9.2_54718 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54718 => 304 Not Modified
2016.12.08 10:29:10 4: WEB_10.6.9.2_54712 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54712 => 304 Not Modified
2016.12.08 10:29:10 4: WEB_10.6.9.2_54716 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54716 => 304 Not Modified
2016.12.08 10:29:10 4: WEB_10.6.9.2_54714 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54714 => 304 Not Modified
2016.12.08 10:29:10 4: WEB_10.6.9.2_54708 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54708 => 304 Not Modified
2016.12.08 10:29:10 4: WEB_10.6.9.2_54710 GET /fhem/pgm2/fhemweb_weekprofile.js; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54710 => 304 Not Modified
2016.12.08 10:29:10 4: WEB_10.6.9.2_54718 GET /fhem/codemirror/fhem_codemirror.js; BUFLEN:0
2016.12.08 10:29:10 4: WEB_10.6.9.2_54718 => 304 Not Modified
2016.12.08 10:29:11 4: WEB_10.6.9.2_54712 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2016.12.08 10:29:11 4: WEB_10.6.9.2_54712 => 304 Not Modified
2016.12.08 10:29:11 4: WEB_10.6.9.2_54718 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2016.12.08 10:29:11 4: WEB_10.6.9.2_54718 => 304 Not Modified
2016.12.08 10:29:11 4: WEB_10.6.9.2_54718 GET /fhem/images/default/fhemicon.png; BUFLEN:0
2016.12.08 10:29:11 4: WEB_10.6.9.2_54718 => 304 Not Modified
2016.12.08 10:29:11 4: WEB_10.6.9.2_54710 GET /fhem?cmd={AttrVal(%22NukiBridge%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.08 10:29:11 5: Cmd: >{AttrVal("NukiBridge","room","")}<
2016.12.08 10:29:11 4: name: /fhem?cmd={AttrVal(%22NukiBridge%22,%22room%22,%22%22)}&XHR=1 / RL:25 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.08 10:29:11 4: WEB_10.6.9.2_54712 GET /fhem?cmd={ReadingsVal(%22NukiBridge%22,%22autocreate%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.08 10:29:11 5: Cmd: >{ReadingsVal("NukiBridge","autocreate","")}<
2016.12.08 10:29:11 4: name: /fhem?cmd={ReadingsVal(%22NukiBridge%22,%22autocreate%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.08 10:29:11 4: WEB_10.6.9.2_54712 GET /fhem?XHR=1&inform=type=status;filter=NukiBridge;since=1481189349;fmt=JSON&fw_id=3131×tamp=1481189351101; BUFLEN:0
2016.12.08 10:29:40 3: NUKIBridge (NukiBridge) - Param Alive:
2016.12.08 10:29:40 3: NUKIBridge (NukiBridge) - Param Code:
2016.12.08 10:29:40 3: NUKIBridge (NukiBridge) - Error: read from http://10.6.34.46:8080 timed out
2016.12.08 10:29:40 3: NUKIBridge (NukiBridge) - PATH: /list?token=FX0dQQ
2016.12.08 10:29:40 3: NUKIBridge (NukiBridge) - httpheader:
2016.12.08 10:29:40 4: NUKIBridge (NukiBridge) - error while requesting: read from http://10.6.34.46:8080 timed out
2016.12.08 10:29:40 5: Triggering NukiBridge (1 changes)
2016.12.08 10:29:40 5: Starting notify loop for NukiBridge, 1 event(s), first is lastError: read from http://10.6.34.46:8080 timed out
Ich bekomme erst gar keinen HttpHeader zurück würde ich sagen.
HttpUtils unterstuetzt (noch) kein "Transfer-Encoding: chunked".
Das kann ich gerne implementieren, allerdings brauche ich etwas zum Testen, und ich habe auf die Schnelle nichts gefunden.
Kann ich auch testen? Schick mir einfach irgendwie die Datei und ich teste ob es mit der Nuki Bridge klappt. Das wäre super.
Nee, andersherum. Ich brauche einen Server, den ich anzapfen kann, der die Daten mit chunked schickt.
Fuer die "posten/fragen/fixen" Methode habe ich z.Zt. keine Energie.
Ok ich überlege mir was. Wäre ein VPN Zugang für Dich ok? Dann gebe ich Dir Zugang zur Bridge u d Du kannst die Anfragen machen.
Ich habe da einen Testserver gefunden.
Hier ein Link für chunked encoding
https://jigsaw.w3.org/HTTP/ChunkedScript
Korrektur: HttpUtils hat auch bisher TransferEncoding: chunked beherrscht, aber nur dann, falls der Server mit "Connection: close" konfiguriert ist. Damit ist die angegebene Seite kein echter Test, weil sie mit "Connection: close" konfiguriert ist, und damit HttpUtils prima funktioniert.
Ich habe die Chunked-Erkennung/Dekodierung in HttpUtils trotzdem umgebaut (d.h. von ParseAnswer ins DataComplete geschoben), hoffentlich ohne Nebeneffekte, damit sollte auch "Connection: keep-alive" tun. Ich habe danach mit update getestet, das lief durch. Ein TabletUI-update-Test nicht (mit https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt), andererseits behaupte ich, dass daran nicht ich schuld bin, das bricht auch mit der alten Version der HttpUtils.pm ab. Weiss jemand da genaueres?
Habe gerade gesehen das es bereits im svn ist. Ich werde es nachher gleich mal testen. Schon mal vielen Dank für Deine Mühe.
Grüße
verträgt sich keep-alive wirklich mt DataComplete?
chunked und keep-alive würde man ja verwenden wenn über eine lange zeit immer mal
wieder daten kommen.
sollte man dann nicht für jedes häppchen den callback aufrufen und nicht erst nach einer potentiell langen zeit mit allen daten?
Das mag sein, aber so wie es bisher war, war eher schlechter als jetzt.
Hallo Rudi,
Ich habe die aktuelle svn HttpUtils Version eingespielt.
Leider bekomme ich immer noch Timeouts. Anbei was mein Log dazu sagt
2016.12.09 20:46:34 4: NUKIBridge (NukiBridge) - Send HTTP POST with URL http://10.6.34.46:8080/list?token=XXXXXX
2016.12.09 20:47:04 3: NUKIBridge (NukiBridge) - Param Alive:
2016.12.09 20:47:04 3: NUKIBridge (NukiBridge) - Param Code:
2016.12.09 20:47:04 3: NUKIBridge (NukiBridge) - Error: read from http://10.6.34.46:8080 timed out
2016.12.09 20:47:04 3: NUKIBridge (NukiBridge) - PATH: /list?token=XXXXX
2016.12.09 20:47:04 3: NUKIBridge (NukiBridge) - httpheader: HTTP/1.1 200 OK
Connection: Close
Content-Type: application/json;charset=utf-8
Transfer-Encoding: chunked
2016.12.09 20:47:04 4: NUKIBridge (NukiBridge) - error while requesting: read from http://10.6.34.46:8080 timed out
Ich kann mir daraus aber keinen Reim bilden.
Grüße
Kannst du bitte nach Zeile 413 der letzten Version von HttpUtils.pm (nach sysread) Folgendes einbauen
Log 1, "GOT $buf";
und die Ausgabe hier posten?
Interessant. Daten kommen wohl an.
2016.12.10 09:53:22 4: NUKIBridge (NukiBridge) - Send HTTP POST with URL http://10.6.34.46:8080/list?token=FX0dQQ
2016.12.10 09:53:22 1: GOT HTTP/1.1 200 OK
Connection: Close
Content-Type: application/json;charset=utf-8
Transfer-Encoding: chunked
1
[
2016.12.10 09:53:22 1: GOT A6
{"nukiId": 123456, "name": "CobraTuer", "lastKnownState": {"state": 1, "stateName": "locked", "batteryCritical": false, "timestamp": "2016-12-08T14:14:52+00:00"}}]
0
2016.12.10 09:53:52 3: NUKIBridge (NukiBridge) - Param Alive:
2016.12.10 09:53:52 3: NUKIBridge (NukiBridge) - Param Code:
2016.12.10 09:53:52 3: NUKIBridge (NukiBridge) - Error: read from http://10.6.34.46:8080 timed out
2016.12.10 09:53:52 3: NUKIBridge (NukiBridge) - PATH: /list?token=FX0dQQ
2016.12.10 09:53:52 3: NUKIBridge (NukiBridge) - httpheader: HTTP/1.1 200 OK
Connection: Close
Content-Type: application/json;charset=utf-8
Transfer-Encoding: chunked
2016.12.10 09:53:52 4: NUKIBridge (NukiBridge) - error while requesting: read from http://10.6.34.46:8080 timed out
kann es sein das hier genau das im anderen thread angesprochene problem auftritt?
d.h. die gegenstelle hält die verbindung offen weil sie nach und nach noch mehr daten senden will und fhem wartet auf ein ende das nicht kommt. statt dessen wird nach dem timeout zu gemacht.
falls das so ist müsste das vorgeschlagenen aufrufen des callback für jeden chunk helfen.
Da die Aenderung wohl mehrere Module zum Absturz bringt, habe ich sie zurueckgedreht, und fuer update aktualisiert.
Wenn jemand was einfach Nachstellbares hat, bitte melden, will die Aenderung eigentlich behalten.
@CoolTux:
Sorry, habe 0 vergessen, deswegen braucht man einen richtigen Test-Server. Habe eine angepasste Version hier angehaengt.
@justme1968: welchen Thread meinst du?
Sorry Rudi das ich da nicht so einfach mit dienen kann. Habe hier nur die Nuki Bridge.
Ich danke Dir jedenfalls sehr für Deine Mühen. Werde es nachher gleich testen. Muss erstmal meinen Junior ins Bett bringen :D
Grüße
@rudi: sorry. es war natürlich der gleiche thread. nur etwas weiter oben.
@Rudi
Ich bereite am We einen VPN für Dich vor mit Zugang zur Bridge. Dann kannst die Aufruf nachstellen und testen.
Hoffe das hilft Dir.
Hallo Rudi,
Es geht nun.
2016.12.10 13:40:39 4: NUKIBridge (NukiBridge) - Send HTTP POST with URL http://10.6.34.46:8080/list?token=ABCDE
2016.12.10 13:40:39 1: C: 1
2016.12.10 13:40:39 1: C: 166
2016.12.10 13:40:39 1: C: 0
2016.12.10 13:40:39 3: NUKIBridge (NukiBridge) - Param Alive:
2016.12.10 13:40:39 3: NUKIBridge (NukiBridge) - Param Code: 200
2016.12.10 13:40:39 3: NUKIBridge (NukiBridge) - Error:
2016.12.10 13:40:39 3: NUKIBridge (NukiBridge) - PATH: /list?token=ABCD
2016.12.10 13:40:39 3: NUKIBridge (NukiBridge) - httpheader: HTTP/1.1 200 OK
Connection: Close
Content-Type: application/json;charset=utf-8
Transfer-Encoding: chunked
2016.12.10 13:40:39 5: NUKIDevice (NukiBridge) - create new device 'NUKIDevice1234567' for address '1234567'
2016.12.10 13:40:39 3: NUKIDevice1234567: I/O device is NukiBridge
2016.12.10 13:40:39 3: NUKIDevice (NUKIDevice1234567) - defined with Code: NukiBridge-1234567
2016.12.10 13:40:39 2: NUKIDevice (NukiBridge) - autocreated 1 devices
Wie können wir nun die Fehler bei den anderen rausfinden. Oder könnte das auch wegen der Fehlenden 0 gewesen sein?
Das ist auch geloest (siehe https://forum.fhem.de/index.php/topic,62260.msg536901.html#msg536901) und die neue Version ist eingecheckt, kommt morgen per update.
Super. Vielen lieben Dank Rudi für das schnelle Umsetzen und Deine Geduld. Nun kann ich endlich nach Wochen am Modul weiter machen. Man bin ich erleichtert.
Wünsche einen ruhigen Samstag und einen schönen 3 Advent Morgen.
Grüße