Callmonitor: Anrufer finden (Rufnummernvergleich) Telefonbuch Fritzbox

Begonnen von Invers, 14 April 2015, 11:08:08

Vorheriges Thema - Nächstes Thema

Invers

Es klappt ja leider nicht immer, den Anrufer anhand der Rufnummer im Telefonbuch zu finden.
Beispiel: Anruf nach Thailand mit call by call = 01004000662374xxxx

Schon wegen der 010040 wäre das Ziel nicht mehr anzeigbar, weil nicht gefunden, obwohl abgespeichert.

Könnte man nicht generell einen Nummernvergleich nur der letzten 8 Stellen einer Telefonnummer durchführen? Das wäre dann hier: 2374xxxx.

Eine Fehlinterpretation dürfte da nur höchst selten auftreten, da die Gefahr der doppelten Nummer sehr gering ist. Wer sehr besorgt ist, könnte ja bei der Rückwärtssuche über andere Telefonbücher (also ausser dem Telefonbuch der Fritzbox) diese Art der Suche deaktivieren.

Leider bin ich zu doof, das selber zu Programmieren, daher hier meine Anfrage.
Ich möchte auch sichergehen, keinem Denkfehler unterlegen zu sein.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Markus Bloch

Nutzt du denn immer die selbe Call-By-Call Vorwahl?

Das nächste größere Update vom Callmonitor würde eine weitere Möglichkeit der Rückwärtssuche ermöglichen, wo man von Hand Rufnummern einem Namen zuweisen kann. Einen Teilmatch auf eine Rufnummer halte ich für gefährlich und möchte ich nicht so implementieren.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Invers

Nein, natürlich nicht. Dann hätte ich ja das Problem nicht. Aber das wäre alles egal, wenn man die letzten Stellen vergleichen würde. Auch für Billigvorwahl zum Handy wäre das gut. Die Anbietervorwahlen kann man ja nicht wirklich pflegen.

NACHTRAG:

Wo siehst du eine Gefährlichkeit?
Eine Gefährlichkeit kann ich in der Rückwärtssuche der Nummer nicht erkennen. Das würde ja nur die Nummern aus dem eigenen  Telefonbuch betreffen. Wer hat da schon so viele, dass eine Doppelung zu befürchten wäre. Und selbst, wenn es einmal ausnahmsweise passieren sollte, was kann denn dann geschehen? Man könnte z.B. einfach abfragen, welche Nummer genommen werden soll, oder man gibt  "doppelte Nummer" aus. Dann kann sich ja jeder kümmern.
Im Übrigen kann eine doppelte Nummer immer vorkommen, da  ich ja im wahren Leben auch meinen Bekanntgen die selbe Nummer zuweisen muss, wenn sie zusammen leben. 
Man könnte zur Sicherheit ja die Ziffernanzahl und die Option als solche optional gestalten.
Dass du es nicht Implementieren möchtest, kann ich wegen des Arbeitsaufwandes natürlich verstehen.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

JoWiemann

Hallo,

man könnte ja ein Attribut "ungenaue Suche" vorsehen und dann die hinterlegte Telefonnummer über regular Expression suchen. Damit würde die Nummernfolge, wenn sie im Suchstring vor kommt als gefunden gelten.

Beispiel:

16312345678 würde halt auch in 0101004816312345678 gefunden.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Markus Bloch

Hallo zusammen,

da die Call-By-Call-Anbieter feste Rufnummernbereiche haben (siehe Wiki: http://de.wikipedia.org/wiki/Call-by-Call), werde ich im FB_CALLMONITOR einfach bei der Event-Verarbeitung die entsprechenden Zifferstellen aus der Rufnummer entfernen, sofern es sich um ein ausgehendes Telefonat handelt.

Zitat von: WikipediaDiese Nummern sind in Deutschland nach dem Muster 010xy bzw. 0100xy, in Österreich 10xy und in der Schweiz 107xy und 108xy aufgebaut.

Würde ich in den nächsten Tagen zusammen mit weiteren Änderungen einchecken.

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)

Invers

Kann man sicher versuchen, obwohl AVM das Problem bisher nicht gelöst hat. Vielleicht klappt es ja auf diese Weise.
Vielen Dank. Bin schon gespannt.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Markus Bloch

Hi,

die neue Version habe ich soeben eingecheckt. Gibts ab morgen via update.

Für User aus der Schweiz oder Österreich ist es wichtig, dass sie ihre Landesvorwahl richtig in den Attributen gesetzt haben (Attribut: country-code). Da die Rufnummernbereiche für Call-By-Call in jedem Land anders sind werden die entsprechenden Regeln je nach country-code angewandt. Standardmäßig steht der auf "0049" (Deutschland).

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)

Invers

Vielen Dank für die schnelle Realisierung. Bin schon gespannt.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Invers

Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

JoWiemann

Hallo Markus,

danke für die Änderungen. Eine Frage: Wird zuerst der Cache durchsucht und dann das Phonebook? Oder könnte man das noch konfigurierbar machen. Das Phonebook ist ja eigentlich auch nur ein "Cache", der allerdings von der FritzBox kommt.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Markus Bloch

Hallo Jörg,

der Cache ist an die Internetanbieter gebunden. Das heißt der Cache wird befragt, sobald ein Internetanbieter in der Reihenfolge kommt. Falls der Cache einen Eintrag findet, wird dieser genommen. Falls nicht wird der Internetanbieter tatsächlich befragt.

Ich will den Cache nicht entkoppeln und in der Reihenfolge konfigurierbar machen, da er sonst den Sinn eines Caches für Internetanfragen verliert. Die API von klicktel.de als Beispiel die momentan im FB_CALLMONITOR integriert ist, erlaubt nur 1000 Anfragen am Tag. Daher werde ich demnächst den Cache fest aktiviert lassen. Die Datei zum Wegschreiben kann aber weiterhin optional gesetzt werden.

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)

JoWiemann

Hallo Markus,

danke für die Antwort. Ich glaube ich habe mich unklar ausgedrückt. Ich wollte eigentlich nur wissen, ob der Cache vor dem Phonebook der FB gelesen wird, oder nach dem Phonebook. Mir wäre es lieber, wenn das Phonebook die höhere Priorität hätte, also Phonebook, Cache und dann die INet-Anbieter.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Markus Bloch

Ich versteh dein Problem nicht. Die Reihenfolge kann der User jetzt selber einstellen. Je nach dem kann man dann das FritzBox Telefonbuch als erstes nehmen oder eben Internet-Anbieter (wo der Cache entsprechend geprüft wird)
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

JoWiemann

Dann versuche ich es präziser. Wenn ich als Reihenfolge angebe: Phonebook, INet1, INet2 wird dann gesucht in: Phonebook, Cache, INet1, INet2 oder Cache, Phonebook, INet1, INet2?


Grüße Jörg

Gesendet von iPhone mit Tapatalk
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Markus Bloch

In deinem Beispiel wird dann gesucht: Phonebook,(Cache,Inet1),(Cache,Inet2). Die doppelte Abfrage des Caches könnte man noch eliminieren, momentan mach ich es so weil es programmiertechnisch einfacher ist und zeitlich keinen nennenswerten Unterschied macht.

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)