FB_Callmonitor Fehlermeldung bei Reversesuche

Begonnen von Wolle02, 29 Januar 2019, 12:01:24

Vorheriges Thema - Nächstes Thema

butschek

Hi Thomas

ich muss es noch einmal ausprobieren. Er hatte mir den Callmonitor total zerschossen und die Datei nicht mehr geladen. Auch Notepad++ hatte mir irgendwie einer fehlerhafte Syntax angezeigt. Ich probiere es noch einmal aus und melde mich wieder.

VG
Holger

butschek

Hi Thomas

es funktioniert noch immer nicht. Zwar stürzt damit mein Callmonitor in sich nicht mehr ab. (Ich denke ich hatte beim Kopieren ein nicht-sichtbares Zeichen mit kopiert) Aber die Inverssuche geht immer noch nicht.

Beim Betrachten des Quellcodes von "das Örtliche" ist mir aber aufgefallen, dass es "st-treff-name" dort nicht mehr gibt. Kann es sein, dass die Jungs schon wieder ihren Code geändert haben und daher wir unsere RegEXP anpassen müssen?

Einerseits scheint der Anzeigename nun im Title-Attribut zu stecken:
<title>XXXXX Erwin Univ.Prof. Dr.phil. in XXXXX&rArr; in Das Örtliche</title>

und andererseits natürlich im Bereich:
<!-- Immer bei privaten Detailseiten -->
    <div class="det_topbox clearfix">
       
   
   
   

<!-- ########## "normale" Variante ########## -->
<!--  Adressblock  -->
<div class="addressblock clearfix">
<div class="name">
<!--  h1 wg. SEO!  -->
<h1>XXXXX Erwin Univ.Prof. Dr.phil.  </h1>
</div>
<div class="det_addrcont clearfix">
<div class="left">


Wie müßte man denn darauf zielend die folgende Zeile anpassen?

                        #Debug($result);
                        if($result =~ m,<span class="st-treff-name">(.+?)</span>,)
#if($result =~ m,<a href="[^"]*form_name=detail[^"]*".+?class="name ".+?><span class="">(.+?)</span>,)

butschek

Klappt genauso wie beschrieben. Danke für die Unterstützung.

isy

Moin zusammen,

heute ist mir das erste Mal aufgefallen, dass die Rückwärtssuche mit dasortliche.de bei mir auch nicht mehr funktioniert.
Wird es ein offizielles Update geben?

VG Helmut
Ein Weg wird erst zu einem Weg, wenn man ihn geht

Svnm

Hallo,
gibt es nun schon eine Lösung, die funktioniert? Also was müsste man konkret anpassen, damit die Rückwärtssuche wieder funktioniert?
Ich fand die Funktionalität immer super, aber jetzt klappt es nicht mehr.  :-[

Fakenius

Funktioniert nach meiner Erfahrung wieder, wenn man das macht, was hier unter #12 beschrieben wurde.
FS20, Homematic (RaspberryMatic), Zigbee (deCONZ), LaCrosse, selbstgebaute Sensoren und Aktoren via MQTT
 (CUL, HB-RF-USB-2, Jeelink, SIGNALDuino)

Markus Bloch

Hallo zusammen,

ich hatte es bei mir in meiner Umgebung nicht verifizieren können, da meine SSL-Bibliothek auf dem NAS veraltet ist und offenbar die verwendeten Ciphers nicht unterstützt die aktuell als sicher gelten.

Ich werde die Änderung einchecken. Sollte es Probleme damit geben, bitte hier Bescheid sagen.

VG
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

TomLee

Zitat- the reverse search result for 0xxxxxxxxx could not be extracted from dasoertliche.de. Please contact the FHEM community.

Hallo,

hab mich nicht näher mit beschäftigt und frag einfach mal, bin ich mit der Meldung alleine oder muss was an dem Regexp angepasst werden ?


Thomas

rob

#23
Hallo Thomas.

Bist nicht damit alleine und ich meine ja, es müssten die Regex und imho auch die URL angepasst werden, weil DasOertliche ein paar Dinge geändert hat. Wobei die "alte" URL noch funktioniert. Das Regex leider nicht  :o

a) Treffer
Aktuell steht im Modul zu dasoertliche.de diese Regex:

if($result =~ m,<span class="st-treff-name">(.+?)</span>,)


Die Trefferliste enthält leider kein solches HTML mehr. Am Beispiel "083316090" kommt stattdessen solches:

<a href="https://www.dasoertliche.de/?form_name=detail&amp;id=0485213150899512770747&amp;recuid=B3H46FYFOSOH5LT4PSZRXSKAAA23EUWG3XTXV7BAZT2QE&amp;niceid=Sparkasse-Memmingen-Lindau-Mindelheim-Memmingen-St-Josefs-Kirchplatz&amp;buc=485&amp;showbuc=0&amp;verlNr=485&amp;kw=&amp;ph=083316090&amp;sb_form=search_inv&amp;recFrom=1&amp;pagePos=1&amp;lastFormName=search_inv&amp;hitno=0" class="hitlnk_name" target="_self">

                Sparkasse Memmingen-Lindau-Mindelheim
                </a>

Schick, oder?

Bin kein Regex-Profi, laut https://regex101.com/ kriege ich obigen Treffer z.B. so abgegriffen:

class="hitlnk_name" target="_self">

                (.+?)
                <\/a>

(siehe auch Screenshot). Auch nicht schön. Kriege testweise das carriage return nicht in den Griff (\r oder \r\n wollen net)  ::)

b) kein Treffer
Zusätzlich ist auch die Meldung anders, wenn kein Treffer vorhanden. Bisher:
elsif(not $result =~ /wir konnten keine Treffer finden/)
Angezeigt wird nun im HTML:
<strong>Leider konnten wir keinen Eintrag zu dieser Telefonnummer finden.</strong>
Ich meine, erst dadurch fällt auf, dass es gar kein Matching gab, weil man "unknown" oder "-" in der Calllist nicht so leicht wahrnimmt wie die von Dir gezeigte Log-Message.

c) die URL
lautet anstatt
https://www.dasoertliche.de/?form_name=search_inv&ph=083316090
nun
https://www.dasoertliche.de/rueckwaertssuche/?ph=083316090
Es funktionieren aber aktuell beide.

EDIT: Sehe grad, wenn ich über die alte URL gehe, kommt obiges unschöne HTML raus. Über die neue URL schaut es etwas besser aus:

<div class="addressblock">
                                   
            <div class="name">
                             
                <!--  h1 wg. SEO! -->
                <h1>Sparkasse Memmingen-Lindau-Mindelheim  </h1>               
               
            </div> 



Leider weiß ich nicht, wie ich vernünftig testen kann. Ich müsste irgendwie die eingehende Nummer simulieren ...

@Markus: Magst Du bitte bei Gelegenheit mal schauen, was sich machen lässt?

Vielen Dank und beste Grüße
rob

PS: Soll die Meldung wirklich lauten "Please contact the FHEM community."? Man weiß ja nicht auf Anhieb wo genau/ welchem Bereich  ???

rob

Vergesst bitte die Sache mit "neuer URL" und so. Die hatte ich aus dem Browser hergenommen. Dort wird man hingeleitet und nach Sucheingabe nochmals weitergeleitet. In Perl bekomme ich allerdings nur eine Fehlerseite zurück "Die angeforderte Seite kann leider nicht angezeigt werden. blabla" und so kann nix gemachted werden.

Bin also beim Testen bei der ursprünglichen URL laut Modul geblieben. Damit bleibt dann auch die Meldung gleich, wenn keine Treffer. Also doch nur die eine Regex anpassen.
Hab es mir so zusammengereimt:

if($result =~ m,<div class="hit " id="entry_1">\s+.*\s+.*class="hitlnk_name" target="_self">\s+(.+?)\s+<\/a>,)

Damit bekomme ich das gewünschte Ergebnis. Fraglich wie stabil das ist, wg. z.B. dem Leerzeichen in --> class="hit "
Na mal schauen :)

VG
rob


butschek

#25
Hallo

ich habe es mit folgender RegExp probiert. Im regex101 funktioniert diese einwandfrei. Irgendetwas mache ich aber in FHEM noch falsch

if($result =~ m,"@type":.+?"name":"(.+?)")


Er nimmt dies Perl-seitisch nicht einfach als String sondern interpretiert @type usw und wirft daher ohne Ende Fehlermeldungen. Hier fehlt mir das Perl Wissen. Vielleicht einer einen schnellen Tipp?

Otto123

#26
falls @type kein Perl Array ist -> escapen / schützen -> \@type
und zumindest hinten fehlt der Trenner, Du hast das , gewählt :)

Hier hat DS_Starter mal noch eine kleine Einführung angehängt: https://forum.fhem.de/index.php/topic,52727.msg1220593.html#msg1220593
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

butschek

#27
Das Komma am Ende war es. Das Escapen hatte ich früher schon einmal probiert. Nun mit beiden Korrekturen klappt es wieder  :) :) :) :)

Habe den RegEx für das Örtliche wie folgt ausgetauscht.

if($result =~ m,\@type":.+?"name":"(.+?)",)

Ansonsten habe ich keine Änderungen vorgenommen.
Ob dies in den Fhem Standard übernommen werden kann? Oder ich exklude die Datei vom Update.

VG
Holger

rob

Hallo Holger.

Du lässt also im Script-Teil suchen. Mein Vorschlag oben sucht stattdessen in der Trefferliste. Hat den Vorteil, dass exakt der erste Treffer hergenommen wird, wenn mehrere Treffer vorhanden sind.
Das @type scheint nicht eindeutig, weil es im Script-Teil mehrmals vorkommt, sobald es mehr als einen Treffer gibt. Beispiel diese Nr.: 082132510
Result bekommt dadurch imho ein Array zurück. Möchtest Du das trotzdem so haben? Wahrscheinlich führen wieder viele Wege nach Rom :)

VG
rob

butschek

Hallo Rob

an den use-case habe ich gar nicht gedacht, dass eine Nummer mehrere Treffer haben könnte.
Daher habe ich die von Dir angegebene Nummer doch gleich mal ausprobiert.

Als Ergebnis erhalte ich offensichtlich mit meiner RegEx die "Kreissparkasse Augsburg". Auch dies ist der erste Eintrag der Trefferliste der Webseite.
Ja @type ist nicht eindeutig. Da gibt es mindestens 2 Einträge drin --> Person und LocalBusiness. Vielleicht noch mehr.

Ja, ich denke die Lösung ist gut so und würde es gerne so behalten. Ich vermute, dass eher an der Ausgabe etwas geändert wirrd als am Businessobjekt.
Aber klar, viele Wege führen nach Rom. Da gibt es kein gut oder schlecht.

Wäre über eine Info froh, wenn es in den Standard kommt. Dann nehme ich das Exclude wieder weg.

LG aus Koblenz
Holger