reverse search phonebook - phonebook-Einträge mit *

Begonnen von KölnSolar, 15 März 2018, 13:08:12

Vorheriges Thema - Nächstes Thema

KölnSolar

Hallo tupol,
mir ist jetzt ein "Problemchen" aufgefallen, was ich über get FB search no. nun auch konkretisieren kann. Scheinbar werden Telefonbucheinträge mit * nicht aufgelöst, der * wird ignoriert.

Bsp.:
Telefonbucheintrag: 0899999*
Anrufer:                  0899999123

Gebe ich beim search nur 0899999 ein, wird der Eintrag gefunden und der Name aufgelöst. Gebe ich aber die volle Nr. 0899999123
ein, passiert nichts. Das "passiert nichts" ist übrigens wörtlich zu nehmen. Könnte man vielleicht auch mit ein pop-up "not found" schöner lösen(Hab ein paar mal gedacht, ich hätte nicht richtig auf get geklickt).

Ich denke, dass die Infos genügen. Wenn Du aber weitere Infos brauchst oder etwas getestet haben möchtest, bitte melden.

Danke&Grüße Markus

Edit: Die Fritzbox löst so auf: Anrufer + 123, also Anrufer123.
Edit2: Und gerade im Log gesehen, dass das Einlesen(TR064) meiner beiden Telefonbücher(gesamt 880 Einträge) einen freeze von knapp 7 Sek. verursacht hat. Ließe sich das evtl. auf non-blocking umstellen ?
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

BroPi

Ich würde mich hier gerne mit meinem Problem reinhängen. Es ist ähnlich geartet.
In meinem Netzwerk habe ich 2 Fritzboxen hintereinander geschaltet. Das hat den Vorteil, das interne Anrufe der ersten FB an der zweiten in der Anruferliste auftauchen und auch der Callmonitor darauf reagiert. Diese Anrufe werden mit ***11#*#**2 signalisiert. Der Callmonitor erkennt dieses natürlich nicht und macht daraus ***11. Im internen phonebook,textfile lassen sich solche Eingaben auch nicht sinnvoll verwenden.
Es wäre schön, wenn diese Sonderzeichen #,* mit berücksichtigt werden könnten.

Danke und Gruß

Markus Bloch

Hallo zusammen,

da euch tupol bei dem Problem vermutlich nicht helfen kann, versuch ich es mal als Maintainer von FB_CALLMONITOR. Das Entfernen von Raute und allen nachfolgenden Zeichen hat den Hintergrund bei Telefonanlagen direkt mitgewählte Steuercodes zu entfernen. Zum Beispiel ein Zugangscode oder PIN für einen Anrufbeantworter der direkt mitgewählt als <Rufnummer>#<PIN>. Damit nur die Rufnummer erkannt wird und nicht die Steuercodes als Bestandteil der Rufnummer verwendet werden.

Ich habe das Entfernen von Steuercodes daher nun für Rufnummern, welche mit einem Stern beginnen unterbunden. Gibt es ab morgen via update.

@KölnSolar: Das Feature von Telefonbucheinträgen mit Sternchen als Rufnummernbereich ist mir neu und kannte ich so noch garnicht. Habe es gerade mal ausprobiert und funktioniert in meiner FritzBox durchaus. Diese Funktion müsste ich hier analog in FB_CALLMONITOR implementieren. Aktuell werden nur 1:1-Matches gemacht.

Eine entsprechende "not found"-Meldung habe ich ebenfalls noch hinzugefügt.

Das Einlesen der Telefonbücher könnte man natürlich auch non-blocking durchführen. Da der Umbau jedoch recht kompliziert ist, da es ja nicht immer nur ein einziges Telefonbuch ist, sondern mehrere und auch die ganzen vorherigen Abfragen um überhaupt bis zum Telefonbuch zu kommen auch entsprechend non-blocking sein müssten, habe ich das bisher nicht angegangen. Das Telefonbuch wird ja üblicherweise nur einmal beim FHEM-Start eingelesen und da kann man das denke ich verkraften.

Viele Grüße

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)

BroPi

Hallo Markus,

danke für das schnelle Einbauen in den Callmonitor.
Jetzt wird die vollständige Nummer z.B.: ***11#*#**2 auch im Logfile gespeichert und Calllist zeigt sie auch richtig an. Trotzdem wird sie als "external_name: unknown" gekennzeichnet. Gibt man diese Nummer jedoch manuell im search-Feld des Callmonitors ein, wird der richtige Name aus dem FB-Telefonbuch zugeordnet und angezeigt z.B.: Türsprechstelle.
Da scheint es einen Unterschied zu geben, ob der Callmonitor von sich aus sucht oder ob der Suchvorgang manuell angestossen wird.

Gruß, B.

KölnSolar

Hallo Markus,
erstmal sorry, dass ich das Modul tupol zugeordnet hatte  :-[

Habs nun auch getestet(nach shutdown/restart).
- Pop-up not found funktioniert bestens.  ;)
- bei der manuellen Suche mit der vollständigen Nr. wird der unvollständig* Eintrag immer noch nicht gefunden. Wie es bei der "automatischen" Suche aussieht, sehe ich erst, wenn ein entsprechender Anrufer sich mal wieder meldet.
- Ich denke auch, dass eine Umstellung auf non-blocking nicht notwendig ist. War lediglich so ein Gedanke, weil ich eigene Module dank freezemon als Bremse entlarvt hatte und die umgestellt habe. Nimms vielleicht einfach auf eine lange Liste der "wenn mal Zeit ist" Dinge  ;)
Danke&Grüße
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Markus Bloch

Hallo zusammen,

ich hoffe das Problem soeben behoben zu haben mit der Rückwärtssuche bei eine entsprechenden weitergeleiteten Anruf. Gibts ab morgen via update.

Die Telefoneinträge, welche mit einem Stern enden, habe ich noch nicht in FB_CALLMONITOR implementiert. Das wird wahrscheinlich erst am Wochenende passieren.

Viele Grüße

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)

BroPi

Hallo Markus,

habe soeben das Update des Callmonitors eingespielt. Es hat sich aber am Verhalten leider nichts geändert. Manuelle Suche ist OK. Die automatische Suche ohne Ergebnis.
Hier mal der Log-Auszug dazu:

2018-03-29_19:26:47 FB2_Callmonitor event: ring
2018-03-29_19:26:47 FB2_Callmonitor external_number: ***11#*#**2
2018-03-29_19:26:47 FB2_Callmonitor direction: incoming
2018-03-29_19:26:47 FB2_Callmonitor external_connection: ISDN
2018-03-29_19:26:47 FB2_Callmonitor external_name: unknown
2018-03-29_19:26:47 FB2_Callmonitor internal_number: 08154711
2018-03-29_19:26:47 FB2_Callmonitor call_id: 3a553524df3e8c071a9a003c39645b73
2018-03-29_19:27:08 FB2_Callmonitor event: disconnect
2018-03-29_19:27:08 FB2_Callmonitor call_id: 3a553524df3e8c071a9a003c39645b73
2018-03-29_19:27:08 FB2_Callmonitor missed_call: ***11#*#**2
2018-03-29_19:27:08 FB2_Callmonitor call_duration: 0
2018-03-29_19:27:08 FB2_Callmonitor external_name: unknown
2018-03-29_19:27:08 FB2_Callmonitor internal_number: 08154711
2018-03-29_19:27:08 FB2_Callmonitor external_connection: ISDN
2018-03-29_19:27:08 FB2_Callmonitor external_number: ***11#*#**2
2018-03-29_19:27:08 FB2_Callmonitor direction: incoming

Falls du noch andere Daten brauchst, so kann ich dir diese sicherlich liefern.

Gruß, B.

Markus Bloch

Hallo zusammen,

könnt ihr bitte mal die angehangene Version von FB_CALLMONITOR benutzen, FHEM neu starten oder ein "reload 72_FB_CALLMONITOR" ausführen und dann nochmal einen solchen Anruf tätigen? Im FHEM-Log sollten dann mehrere Ausgaben mit dem Präfix "DEBUG>" auftauchen, die bräuchte ich dann einmal, da sie die verschiedenen Umformungen aufzeigen, die mit der Nummer durchgeführt werden, bevor sie in die Rückwärtssuche gegeben wird.

Vielen Dank

Gruß
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)

BroPi

Hallo Markus,

hier die gewünschten Meldungen (und noch einige mehr):

2018.04.04 22:43:07 1: DEBUG>external_number (directly from FB): ***11#*#**2
2018.04.04 22:43:07 1: DEBUG>is_deflected: 0
2018.04.04 22:43:07 1: DEBUG>external_number (after deleting leading zero): ***11#*#**2
2018.04.04 22:43:07 1: DEBUG>external_number (after deleting call-by-call): ***11#*#**2
2018.04.04 22:43:07 1: DEBUG>external_number (after adding local area code): ***11#*#**2
2018.04.04 22:43:07 1: DEBUG>external_number (after removing control codes): ***11#*#**2
2018.04.04 22:43:07 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,
2018.04.04 22:43:07 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,
2018.04.04 22:43:07 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,
2018.04.04 22:43:07 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,
2018.04.04 22:43:23 1: PERL WARNING: Use of uninitialized value $external_number in concatenation (.) or string at ./FHEM/72_FB_CALLMONITOR.pm line 392, <GEN50> line 3.
2018.04.04 22:43:23 1: DEBUG>external_number (directly from FB):
2018.04.04 22:43:23 1: PERL WARNING: Use of uninitialized value $is_deflected in concatenation (.) or string at ./FHEM/72_FB_CALLMONITOR.pm line 396, <GEN50> line 3.
2018.04.04 22:43:23 1: DEBUG>is_deflected:
2018.04.04 22:43:31 1: DEBUG>external_number (directly from FB):
2018.04.04 22:43:31 1: DEBUG>is_deflected:

Vielen Dank im Voraus,
Bronco

Markus Bloch

Hallo Bronco,

wie schauen denn deine Attribute deiner FB_CALLMONITOR-Definition aus?

Danke

Gruß
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)

BroPi

Hallo Markus,

hier die Attribute:

define FB2_Callmonitor FB_CALLMONITOR 192.168.181.1
attr FB2_Callmonitor country-code 0049
attr FB2_Callmonitor fritzbox-remote-phonebook 1
attr FB2_Callmonitor fritzbox-remote-phonebook-via tr064
attr FB2_Callmonitor fritzbox-user Bronco
attr FB2_Callmonitor icon it_router
attr FB2_Callmonitor local-area-code 03834
attr FB2_Callmonitor reverse-search phonebook,11880.com,dasoertliche.de,dasschnelle.at,textfile
attr FB2_Callmonitor reverse-search-text-file TB.cfg
attr FB2_Callmonitor room 0_Haus,Callverarbeitung,FritzBox
attr FB2_Callmonitor unique-call-ids 1

Gruß,
Bronco

Markus Bloch

Hallo Bronco,

ich kann keine Probleme erkennen,

Die Nummer (***11#*#**2) wird im Rahmen der Umformungen nicht geändert und geht so direkt in die Rückwärtssuche rein.

Was mich jedoch wundert sind die folgenden Logzeilen:

2018.04.04 22:43:07 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,
2018.04.04 22:43:07 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,
2018.04.04 22:43:07 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,
2018.04.04 22:43:07 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,


Diese Meldung kann ich mir so nicht erklären. Kannst Du bitte nochmal so einen Anruf machen und in deiner FB_CALLMONITOR-Defintion bitte mal das Attribut verbose auf 5 setzen.

Die nachfolgenden Perl-Warnungen sind normal aufgrund meiner diletantischen Debug-Ausgaben in deiner Version  8)

Danke

Gruß
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)

BroPi

Hallo Markus,

hier das Log mit verbose 5:
2018.04.11 11:02:08 5: FB_CALLMONITOR (FB2_Callmonitor) - received data: 11.04.18 11:02:08;RING;0;***11#*#**2;501826;ISDN;
2018.04.11 11:02:08 1: DEBUG>external_number (directly from FB): ***11#*#**2
2018.04.11 11:02:08 1: DEBUG>is_deflected: 0
2018.04.11 11:02:08 1: DEBUG>external_number (after deleting leading zero): ***11#*#**2
2018.04.11 11:02:08 1: DEBUG>external_number (after deleting call-by-call): ***11#*#**2
2018.04.11 11:02:08 1: DEBUG>external_number (after adding local area code): ***11#*#**2
2018.04.11 11:02:08 1: DEBUG>external_number (after removing control codes): ***11#*#**2
2018.04.11 11:02:08 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,
2018.04.11 11:02:08 4: FB_CALLMONITOR (FB2_Callmonitor) - skip using 11880.com for reverse search of ***11#*#**2 because of non-german number
2018.04.11 11:02:08 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,
2018.04.11 11:02:08 4: FB_CALLMONITOR (FB2_Callmonitor) - skip using dasoertliche.de for reverse search of ***11#*#**2 because of non-german number
2018.04.11 11:02:08 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,
2018.04.11 11:02:08 4: FB_CALLMONITOR (FB2_Callmonitor) - skip using dasschnelle.at for reverse search of ***11#*#**2 because of non-austrian number
2018.04.11 11:02:08 3: FB_CALLMONITOR (FB2_Callmonitor) - unknown reverse search method ,
2018.04.11 11:02:30 5: FB_CALLMONITOR (FB2_Callmonitor) - received data: 11.04.18 11:02:30;DISCONNECT;0;0;
2018.04.11 11:02:30 1: PERL WARNING: Use of uninitialized value $external_number in concatenation (.) or string at ./FHEM/72_FB_CALLMONITOR.pm line 392, <GEN34> line 4.
2018.04.11 11:02:30 1: DEBUG>external_number (directly from FB):
2018.04.11 11:02:30 1: PERL WARNING: Use of uninitialized value $is_deflected in concatenation (.) or string at ./FHEM/72_FB_CALLMONITOR.pm line 396, <GEN34> line 4.
2018.04.11 11:02:30 1: DEBUG>is_deflected:


Danke und Gruß,
Bronco

Markus Bloch

Hallo Bronco,

bist Du dir sicher, dass diese Nummer auch genauso im Telefonbuch drin steht? Wenn Du in der FHEM-Befehlszeile den Befehl "list FB2_Callmonitor" eingibst, taucht dann diese Rufnummer genauso mit dem zugehörigen Namen auf? Die Ausgabe des Befehls bitte NICHT hier posten, da sonst dein Telefonbuch hier öffentlich einsehbar wäre ;-)

Die Logmeldungen zu "unknown reverse search method ," werde ich fixen.

Viele Grüße

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)

BroPi

Hallo Markus,

ich glaube wir kommen jetzt der Lösung näher. Mit List taucht nur:

112        Türsprechstelle

auf und nicht:

***11#*#**2        Türsprechstelle.

 
Der Import des Telefonbuchs scheint die Sonderzeichen zu entfernen. Nun verstehe ich aber nicht den Unterschied zur manuellen Suche, wo Türsprechstelle richtig gefunden wird.

Danke und Gruß,
Bronco

Markus Bloch

Hallo Bronco,

bitte probier mal die angehangene Version von FB_CALLMONITOR. Dort habe ich die Normalisierung von Rufnummer abgeändert. Diese Normalisierung wird beim Importieren des Telefonbuchs immer durchgeführt um eine einheitliche Rufnummer zu erhalten, wie sie auch von der FritzBox zurückgegeben wird.

Viele Grüße

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)

BroPi

Hallo Markus,

vielen Dank, dass du hierran noch weitergearbeitet hast.
Deine neueste Version funktioniert, so wie ich mir das gewünscht hatte. Beim Import des Telefonbuchs kommen die #* mit rüber. Und die Rufnummernauflösung bei eingehenden Anrufen klappt jetzt exakt.

Einen kleinen Wunsch hätte ich aber noch, der aber wirklich nicht wichtig ist. Das Textfile-TB kann keine #* verarbeiten. Dort werden diese einfach ignoriert. Vielleicht lässt sich da noch etwas nachrüsten?

Gruß,
Bronco

KölnSolar

Das ist ja schön, dass das jetzt klappt, wo Du Dich in meinen Thread geschoben hattest. ::)

Dann könnte Markus sich ja jetzt meinem Ausgangsthema dieses Threads widmen.  ;) (Nach dem herrlichen Wochenende)

Grüße
Makus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Markus Bloch

Zitat von: BroPi am 05 Mai 2018, 16:56:36
Einen kleinen Wunsch hätte ich aber noch, der aber wirklich nicht wichtig ist. Das Textfile-TB kann keine #* verarbeiten. Dort werden diese einfach ignoriert. Vielleicht lässt sich da noch etwas nachrüsten?

Habe ich gefixt und zusammen mit der Version aus meinem letzten Beitrag eingecheckt. Gibts ab morgen via update.

Zitat von: KölnSolar am 05 Mai 2018, 18:54:51
Dann könnte Markus sich ja jetzt meinem Ausgangsthema dieses Threads widmen.  ;) (Nach dem herrlichen Wochenende)

Das werde ich auch ;) Ist nur leider nicht so trivial wie die Sache von Bronco.

Viele Grüße

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)

Markus Bloch

Hallo Markus,

im Anhang nun eine Version, die auch die Wildcards unterstützen sollte. Ich habe es mit einem Beispieleintrag in meinem Telefonbuch erfolgreich getestet. Ich bin aber noch unschlüssig, ob das nicht mit einem Attribut optional aktiviert werden sollte, da bei jedem Suchvorgang jedes Telefonbuch mit einer Schleife gecheckt werden muss, ob es einen Wildcard-Eintrag gibt und ob der auch passt. Auf langsamer Hardware könnte das bei großen Telefonbüchern merklich verzögern. Bisher waren keine Schleifendurchläufe über alle Einträge notwendig.

Teste das bitte mal bei dir.

Viele Grüße

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)

KölnSolar

Hallo Markus,
danke. Und das bei dem Wetter.  :-*
Websearch funktioniert wie es soll. Hab freezemon mal auf 0.2s eingestellt auf nem Rpi3. Keine Reaktion. Bei 2 Telefonbüchern mit gesamt knapp 900 Einträgen. Scheint also recht flink zu sein.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Markus Bloch

Hallo Markus,

hab die Änderungen nun offiziell eingecheckt.

Viele Grüße

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)