Hallo Gemeinde,
ich habe mal wieder ein Phänomen. Auf meinem Raspi läuft FHEM. An meinem Heizöltank werkelt ein ESP8266 der einige Daten erfasst nacheinander per setreading an ein dummy device in FHEM per HTTP überträgt.
GET /fhem?cmd=setreading%20oil%20liter%206433&XHR=1 HTTP/1.1
Host: 192.168.0.210:8083
Connection: keep-alive
Accept: */*
Seit dem 22.01.2017 wird der erste Wert noch übertragen, aber die restlichen Werte nicht mehr. Die Definition des Dummy device hänge ich als Bild an.
Der Mitschnitt mit Wireshark ergab ein "OK" von FHEM für den ersten Eintrag und ein "405 Method Not Allowed" für alle übrigen Daten die direkt im Anschluß ohne neuen Verbindungsaufbau übertragen werden.
Hat Jemand eine Idee was sich geändert hat und ob ich das auf FHEM Seite anpassen kann ?
Den Wireshark Mitschnitt habe ich ausch als Bild angehangen.
Auch ja, am ESP8266 habe ich nichts geändert und auch ein Neustart aller Beteiligten hat nichts geändert.
Danke
Peter
Hi,
kann es sein, dass das mal wieder eine Ausprägung des csrf-Problems ist?
Schalt das mal ab (csrfToken in FHEMWEB auf none setzen) und schau nach, ob's dann geht.
Falls ja, musst Du das anpassen oder das Risiko eingehen.
Gruß,
Thorsten
Hallo Thorsten,
aus zwei Gründen nein:
- Es trat ja schon vor der Änderung auf (im Januar)
- zur Sicherheit habe ich das Attribut doch vor der Anfrage hier auf non gesetzt, man kann ja nie wissen ;)
Trotzdem vielen Dank für die Idee.
Über kurz oder lang wirst du aber (spätestens wenn man das Token nicht mehr abschalten kann) in die Token-Problematik kommen...
Ich habe auch einen ESP für meinen Wassertank.
Dafür habe ich ein simples Web-Serverbeispiel als Basis genommen und frage die Werte dann per HTTPMOD-Modul aus fhem ab...
Zwar keine Lösung für dein Problem bzw. eine sehr aufwendige ;)
Aber ich dachte ich werfe mal eine andere Möglichkeit in den Raum...
Gruß, Joachim
Hallo Joachim,
natürlich wollte ich auf meinem derzeit schön laufenden ESP möglichst nichts ändern :-[.
Außerdem hat die Kommunikationsrichtung den Vorteil, dass der ESP nur dann Daten an FHEM weitergibt wenn es sich lohnt.
von pollen halte ich auch nichts, kostet nur vermeidbare fhemzeit!
komisch ist, dass bei dir das setreading%20oil%20liter%206433&XHR=1 HTTP/1.1
durchgeht , die anderen nicht.
vorallem "Method Not Allowed"
du kannst aucch nur verbose bei deinem Fhemweb auf 5 setzten und auch mal deine Meldungen direkt mit dem browser absetzten
http//192... :8083/fhem?cmd=setreading%20oil%20liter%206433&XHR=1
und mal mit denen testen die nicht mehr gehen.
abgesehen davon würde ich einen neuen fhemport dazu benutzen und das allowfrom attribut benützen und die entsprechenden ip's eintragen
das csrfToken Problem seh ich gerade bei dir nicht
Hallo Hary,
ich habe es via browser abgesetzt:
Die erste Variante
http://192.168.0.210:8083/fhem?cmd=setreading%20oil%20liter%206433&XHR=1
2017.02.23 20:52:46.403 4: Connection accepted from WEB_192.168.0.38_58926
2017.02.23 20:52:46.406 4: WEB_192.168.0.38_58926 GET /fhem?cmd=setreading%20oil%20liter%206433&XHR=1; BUFLEN:0
2017.02.23 20:52:46.428 4: name: /fhem?cmd=setreading%20oil%20liter%206433&XHR=1 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.02.23 20:52:46.644 4: WEB_192.168.0.38_58926 GET /favicon.ico; BUFLEN:0
2017.02.23 20:52:46.644 4: WEB: redirecting /favicon.ico to /fhem
2017.02.23 20:52:46.698 4: WEB_192.168.0.38_58926 GET /fhem; BUFLEN:0
2017.02.23 20:52:46.711 4: name: /fhem / RL:1715 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2017.02.23 20:53:52.004 4: Closing inactive connection WEB_192.168.0.38_58926
Dann die zweite Variante:
http://192.168.0.210:8083/fhem?cmd=setreading%20oil%20humidity%2055.9&XHR=1
2017.02.23 20:56:32.617 4: Connection accepted from WEB_192.168.0.38_58976
2017.02.23 20:56:32.619 4: WEB_192.168.0.38_58976 GET /fhem?cmd=setreading%20oil%20humidity%2055.9&XHR=1; BUFLEN:0
2017.02.23 20:56:32.643 4: name: /fhem?cmd=setreading%20oil%20humidity%2055.9&XHR=1 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.02.23 20:56:32.859 4: WEB_192.168.0.38_58976 GET /favicon.ico; BUFLEN:0
2017.02.23 20:56:32.860 4: WEB: redirecting /favicon.ico to /fhem
2017.02.23 20:56:32.924 4: WEB_192.168.0.38_58976 GET /fhem; BUFLEN:0
2017.02.23 20:56:32.938 4: name: /fhem / RL:1715 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2017.02.23 20:57:52.247 4: Closing inactive connection WEB_192.168.0.38_58976
Frag mich bitte nicht warum es per Browser geht.
Und jetzt Log File und Wireshark vom entfernten Knoten:
Im Log ist nur die 1. Anfrage sichtbar die funktioniert:
2017.02.23 21:20:47.880 4: Connection accepted from WEB_192.168.0.24_43014
2017.02.23 21:20:47.882 4: WEB_192.168.0.24_43014 GET /fhem?cmd=setreading%20oil%20liter%206434&XHR=1; BUFLEN:2
2017.02.23 21:20:47.904 4: name: /fhem?cmd=setreading%20oil%20liter%206434&XHR=1 / RL:0 / text/plain; charset=UTF-8 / /
2017.02.23 21:20:47.934 4: Connection closed for WEB_192.168.0.24_43014: EOF
Wireshark hat folgendes gesehen:
GET /fhem?cmd=setreading%20oil%20liter%206434&XHR=1 HTTP/1.1
Host: 192.168.0.210:8083
Connection: keep-alive
Accept: */*
')HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/plain; charset=UTF-8
GET /fhem?cmd=setreading%20oil%20entfernung%2059.457585&XHR=1 HTTP/1.1
Host: 192.168.0.210:8083
Connection: keep-alive
Accept: */*
')HTTP/1.1 405 Method Not Allowed
Content-Length: 0
GET /fhem?cmd=setreading%20oil%20fuellhoehe%2088.542415&XHR=1 HTTP/1.1
Host: 192.168.0.210:8083
Connection: keep-alive
Accept: */*
')HTTP/1.1 405 Method Not Allowed
Content-Length: 0
GET /fhem?cmd=setreading%20oil%20temperature%2016.2&XHR=1 HTTP/1.1
Host: 192.168.0.210:8083
Connection: keep-alive
Accept: */*
')HTTP/1.1 405 Method Not Allowed
Content-Length: 0
GET /fhem?cmd=setreading%20oil%20humidity%2049.1&XHR=1 HTTP/1.1
Host: 192.168.0.210:8083
Connection: keep-alive
Accept: */*
')HTTP/1.1 405 Method Not Allowed
Content-Length: 0
In Wireshark habe ich mir das Telegramm anzeigen lassen was abgewiesen wurde dort wurde mir die URI als Link angeboten (siehe Bild). Draufgeklickt und es ging >:(
2017.02.23 21:30:02.263 4: Connection accepted from WEB_192.168.0.38_59536
2017.02.23 21:30:02.266 4: WEB_192.168.0.38_59536 GET /fhem?cmd=setreading%20oil%20fuellhoehe%2088.542415&XHR=1; BUFLEN:0
2017.02.23 21:30:02.293 4: name: /fhem?cmd=setreading%20oil%20fuellhoehe%2088.542415&XHR=1 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.02.23 21:30:02.574 4: WEB_192.168.0.38_59536 GET /favicon.ico; BUFLEN:0
2017.02.23 21:30:02.575 4: WEB: redirecting /favicon.ico to /fhem
2017.02.23 21:30:02.641 4: WEB_192.168.0.38_59536 GET /fhem; BUFLEN:0
2017.02.23 21:30:02.684 4: name: /fhem / RL:1715 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2017.02.23 21:31:07.003 4: Closing inactive connection WEB_192.168.0.38_59536
Also spricht doch irgendetwas für ein Timingproblem.
Hi,
kann es sein, dass es etwas damit zu tun hat, dass der Browser bei aufeinander folgenden GET die Verbindung immer wieder zumacht, aber Dein Gerät nicht?
Gruß,
Thorsten
Das könnte daran liegen. Ist das denn jetzt ein FHEM Bug oder ein neues Feature ? Mein ESP läuft ja seit langem damit unverändert.
Keine Ahnung, das war nur so eine Vermutung.
Vielleicht verschiebst Du das besser mal in den FHEMWEB-Bereich, da könnte jemand mitlesen, der es weiß.
Gruß,
Thorsten
Den Ratschlag von Thorsten befolgend suche ich hier mal mein Glück.