Reverse Search dasoertliche.de

Begonnen von b0bic, 05 März 2018, 12:08:33

Vorheriges Thema - Nächstes Thema

b0bic

Hallo,

leider habe ich über die Suchfunktion keine Lösung gefunden.

Ich würde gerne die Reversefunktion nutzen. Mit meinem Telefonbuch funktioniert das auch prima, nur leider erkennt fhem keine neuen Nummern.

Im Logfile wird ein Anruf so protokolliert:

2018.03.05 11:37:13 3: FB_CALLMONITOR (Callmonitor) - the reverse search result for 06074XXXXX could not be extracted from dasoertliche.de. Please contact the FHEM community.


Callmonitor ist so in der Config hinterlegt:

define Callmonitor FB_CALLMONITOR 192.168.10.1
attr Callmonitor country-code 0049
attr Callmonitor fritzbox-remote-phonebook 1
attr Callmonitor local-area-code 06071
attr Callmonitor reverse-search dasoertliche.de,phonebook
attr Callmonitor reverse-search-cache 1
attr Callmonitor room 99_System


Habe selbst schon an den Attr versucht mit dem country-code und area-code zu spielen, hat aber leider nichts genutzt.

Vielleicht kann mir hier jemand helfen. Danke bereits im Voraus.

Gruß b0bic

Otto123

Hi,

so funktioniert es bei mir:
defmod FBMon FB_CALLMONITOR 192.168.90.1
attr FBMon fritzbox-remote-phonebook 1
attr FBMon fritzbox-remote-phonebook-via tr064
attr FBMon reverse-search phonebook,dasoertliche.de


Ich denke Du musst vor allem tr064 aktivieren ...

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

b0bic

@Otto123

vielen Dank für deine Antwort. Leider hat das nicht geholfen.

TomLee

Hallo,

vor einer Woche hab ich eine entfernte (LAN-LAN-Kopplung ) Fritzbox bei mir definiert rein aus Interesse ob das geht und natürlich auch eine Callmonitor-Definition. Und ja das geht. Allerdings stellte ich vorgestern ebenfalls fest das ich für dieses Callmonitor-Device die gleichen Meldungen im Log habe. Bei meiner eigenen Callmonitor-Definition hab ich das nicht. Obwohl beide gleich konfiguriert sind. Dachte das hat eventuell was mit der LAN-LAN Verbindung zu tun und jetzt les ich durch Zufall diesen Thread. Auf beiden Fritzboxen läuft noch 6.83 bei ein klappts bei der andern nicht.

defmod cm_Demm FB_CALLMONITOR 192.168.198.1
attr cm_Demm event-on-change-reading .*
attr cm_Demm event-on-update-reading event
attr cm_Demm fritzbox-remote-phonebook 1
attr cm_Demm fritzbox-remote-phonebook-via tr064
attr cm_Demm fritzbox-user Klaus
attr cm_Demm reverse-search phonebook,dasoertliche.de
attr cm_Demm room Fritzbox


Gruß

Thomas

b0bic

bei mir läuft FritzOs 06.92.

Wenn ich die Rückwärtssuche auf dasoertliche.de nehmen, bekomme ich die richtigen Infos.

Otto123

Der Rechner mit FHEM drauf kann ins Internet? Die Namensauflösung bei dem funktioniert?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

TomLee

ZitatBei meiner eigenen Callmonitor-Definition hab ich das nicht.

Ich geh mal stark davon aus sonst gäbs ja auch kein Wetter etc. . Namensauflösung ?!.? Sry,  bin schon überfordert, definiere was genau funktionieren soll.

Gruß

Thomas

Otto123

Es war eigentlich eine direkte Antwort auf #4  :o

Sorry, aber ich habe keine Ahnung was auf euren Rechnern geht oder nicht. Ich habe auch keine Ahnung was dieser Logeintrag als Ursache alles haben kann. Ich denke nur mit und liefere Ideen.  :-[

Damit FHEM eine Rückwärtssuche machen kann muss die Adresse dasoertliche.de vom FHEM Prozess netzwerktechnisch vollständig erreicht werden können.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

schon mal verbose=5 gesetzt, um ggf weitere infos zu bekommen?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wzut

IMHO hilft verbose 5 nicht wirklich etwas. Ich habe seit ein paar Tagen auch das Problem.
Schaut man direkt ins Modul sieht man das die Meldung  "the reverse search result for xyz could not be extracted from dasoertliche.de. Please contact the FHEM community"  lediglich besagt das eben kein Treffer gefunden wurde.
Suche ich allerdings die betroffene Nr. direkt im Webinterface von das-oertliche wird sie gefunden.
Ich habe jetzt versuchsweise dasoertliche.de durch klicktel.de im Attribut ersetzt und siehe da, die Nummern werden wieder gefunden. Allerdings wird doch irgendwann der Support für klicktel eingestellt ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

frank

ich weiss nicht wie callmonitor die daten anfordert. aber vielleicht will dasoertliche bot-anfragen verhindern und wertet zb im header den user-agent eintrag aus.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wzut

#11
72_FB_CALLMONITOR macht das recht simpel :
$result = GetFileFromURL("http://www1.dasoertliche.de/?form_name=search_inv&ph=".$number, 5, undef, 1);
setzt man das z.B. auf der Konsole direkt um (für einen Arzt in Rüsselsheim ) :
root@fhem2:/home/pi# wget http://www1.dasoertliche.de/?form_name=search_inv&ph=0614264161
[1] 2865
root@fhem2:/home/pi# --2018-03-06 09:52:44--  http://www1.dasoertliche.de/?form_name=search_inv
Auflösen des Hostnamens »www1.dasoertliche.de (www1.dasoertliche.de)« ... 82.98.79.52
Verbindungsaufbau zu www1.dasoertliche.de (www1.dasoertliche.de)|82.98.79.52|:80 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 301 Moved Permanently
Platz: https://www.dasoertliche.de/?form_name=search_inv [folgend]
--2018-03-06 09:52:44--  https://www.dasoertliche.de/?form_name=search_inv
Auflösen des Hostnamens »www.dasoertliche.de (www.dasoertliche.de)« ... 82.98.79.52
Verbindungsaufbau zu www.dasoertliche.de (www.dasoertliche.de)|82.98.79.52|:443 ... verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »»index.html?form_name=search_inv«« gespeichert.

index.html?form_name=search_inv           [ <=>                                                                     ]  30,23K  --.-KB/s    in 0,02s

2018-03-06 09:52:45 (1,31 MB/s) - »index.html?form_name=search_inv« gespeichert [30959]


[1]+  Fertig                  wget http://www1.dasoertliche.de/?form_name=search_inv

Dabei fallen zwei Dinge auf :
a. wget wird nicht selbständig fertig , ich musst es mit Control +C abbrechen
Ich denke das ist auch der eigentliche Grund für die o.g. Logmeldung.
b. der Inhalt der geholten index.html entspricht etwa der Webseite die man im Browser bekommt wenn kein Treffer erzielt wurde.

Edit : der TE b0bic sollte diesen Thread besser nach Unterstützende Dienste  verschieben , da gehört er laut Maintainer.txt hin und die Chancen werden steigen das Markus Bloch auch mitliest :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

frank

Zitat10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0 user agents
      will erroneously change it into a GET request.

scheinbar wurde die uri geändert und der browser leitet automatisch weiter.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

bei der eingabe in FF
http://www1.dasoertliche.de/?form_name=search_inv&ph=0614264161

zeigt firebug diesen antwort-header
Content-Length 275
Content-Type text/html; charset=iso-8859-1
Date         Tue, 06 Mar 2018 13:31:44 GMT
Location https://www.dasoertliche.de/?form_name=search_inv&ph=0614264161
Server          Apache


also müsste location die neue url sein.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wzut

ja klar das sieht man ja auch in meinem Mitschnitt von wget.
Was ich da nicht erwähnt habe ist : natürlich habe ich es auch direkt mit der https URL auf wget Ebene versucht, macht aber keinen Unterschied. Wenns nur das gewesen wäre hätte ich es auch gleich im Modul geändert.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher