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.
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.
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.
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
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
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.
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
Vielen Dank für die schnelle Realisierung. Bin schon gespannt.
Funktioniert hervorragend. Nochmals vielen Dank.
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
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
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
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)
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
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
Hallo Markus,
Ok und Danke. Könntest Du die Info noch in die command.ref übernehmen?! Oder habe ich es da nur übersehen.
Grüße Jörg
Hallo Markus,
habe gerade festgestellt, dass das Textfile beim Setzen des Attributes nicht angelegt wird. Ein Anlegen wäre natürlich schick.
Grüße Jörg
siehe auch: http://forum.fhem.de/index.php/topic,35625.msg288065.html#msg288065
Hallo Markus,
hier noch ein Fehlerbild bei der Rückwärtssuche:
Irgendwie verstehe ich die Sub FB_CALLMONITOR_normalizePhoneNumber nicht. Wenn ich über set search suche erhalte ich folgende Logeinträge (Habe einen entsprechenden Log3 Aufruf eingebaut):
Mein local-area-code: 02234
+49 (1234) 5678912 -> FB_CALLMONITOR (FBTel) - normalized phone number: 022344912345678912 -> Suchergebnis: unknown
+4912345678912 -> FB_CALLMONITOR (FBTel) - normalized phone number: 022344912345678912 -> Suchergebnis: unknown
Lösche ich nun die Attribute: local-area-code und country-code erhalte ich folgende Ergebnisse:
+49 (1234) 5678912 -> FB_CALLMONITOR (FBTel) - normalized phone number: 4912345678912 -> Suchergebnis: unknown
+4912345678912 -> FB_CALLMONITOR (FBTel) - normalized phone number: 4912345678912 -> Suchergebnis: unknown
Grüße Jörg
Hallo Markus,
habe die sub FB_CALLMONITOR_normalizePhoneNumber mal wie folgt geändert:
sub FB_CALLMONITOR_normalizePhoneNumber($$)
{
my ($hash, $number) = @_;
my $name = $hash->{NAME};
my $area_code = AttrVal($name, "local-area-code", "");
my $country_code = AttrVal($name, "country-code", "0049");
# Alle 0 nach einem Leerzeichen werden gelöscht
# | |
# | |
# | | Alle Zeichen, ausser 0-9 und + werden gelöscht
# | | | |
# | | | |
# | | | | Alle +, die nicht am Anfang stehen werden gelöscht
# | | | | | |
# | | | | | |
$number =~ s/((?<= )0)|[^0-9\\+]|((?<!\A)\+)//g;
# Steht keine Null, kein NullNUll oder kein + am Anfang, dann fehlt wohl der Local Area Code und dieser wird ergänzt
$number = $area_code.$number if(!($number =~ m/((?<=\A)00)|((?<=\A)0)|((?<=\A)\+)/g));
# Steht nur eine Null am Anfang oder weiterhin keine, dann fehlt wohl der Country Code und die Null wird ersetzt
$number =~ s/((?<=\A)0)/$country_code/g;
$number = $country_code.$number if(!($number =~ m/((?<=\A)0)/g));
# Jetzt wird noch das + am Anfang durch 00 ersetzt
$number =~ s/((?<=\A)\+)/00/g;
# $number =~ s/[^*\d]//g if(not $number =~ /@/); # Remove anything else isn't a number if it is no VoIP number
Log3 $name, 4, "FB_CALLMONITOR ($name) - normalized phone number: $number";
return $number;
}
Außerdem habe ich noch Zeile 164 in FB_CALLMONITOR_Get geändert:
# Leerzeichen, anstatt "nichts" im join
return FB_CALLMONITOR_reverseSearch($hash, FB_CALLMONITOR_normalizePhoneNumber($hash, join ' ', @arguments[2..$#arguments]));
Bei mir funktionieren nun ne ganze Menge Telefonnummern-Notationen. Was ich noch nicht verstanden habe ist folgende Zeile bezüglich Voip:
# $number =~ s/[^*\d]//g if(not $number =~ /@/); # Remove anything else isn't a number if it is no VoIP number
Angehängt habe ich auch noch mal das geänderte Modul.
Grüße Jörg
Hallo Jörg,
zu deinen Änderungen.
Zitat von: JoWiemann am 22 April 2015, 15:04:12
Außerdem habe ich noch Zeile 164 in FB_CALLMONITOR_Get geändert:
# Leerzeichen, anstatt "nichts" im join
return FB_CALLMONITOR_reverseSearch($hash, FB_CALLMONITOR_normalizePhoneNumber($hash, join ' ', @arguments[2..$#arguments]));
Was soll das bringen? Die Leerzeichen müssen letztlich sowieso wieder entfernt werden. Warum also künstlich Leerzeichen wieder einfügen?
Zitat von: JoWiemann am 22 April 2015, 15:04:12
Bei mir funktionieren nun ne ganze Menge Telefonnummern-Notationen. Was ich noch nicht verstanden habe ist folgende Zeile bezüglich Voip:
# $number =~ s/[^*\d]//g if(not $number =~ /@/); # Remove anything else isn't a number if it is no VoIP number
Denk an die vorkonfigurierten AVM VoIP-Nummern im FritzBox-Telefonbuch:
200@hd-telefonie.avm.de - HD-Musik
100@hd-telefonie.avm.de - HD-Sprache
500@hdtelefonie.avm.de - AVM Ansage (HD)
Das sind VoIP Nummern und da ist der Teil hinter dem @ durchaus Teil der Rufnummer.
Zu deinem Änderungsvorschlag bevorzuge ich die weniger aufwändige und dennoch funktionierende Variante:
$number =~ s/\s//g; # Remove spaces
$number =~ s/^(\#[0-9]{1,10}\#)//g; # Remove phone control codes
$number =~ s/^\+/00/g; # Convert leading + to 00 country extension
$number =~ s/[^*\d]//g if(not $number =~ /@/); # Remove anything else isn't a number if it is no VoIP number
$number =~ s/^$country_code/0/g; # Replace own country code with leading 0Ich hab lediglich zwei Zeilen vertauscht und schon funktionieren alle deine Beispiele die du oben genannt hast korrekt. ;-)
Viele Grüße
Markus
Na gut. Gewonnen
Grüße Jörg
Gesendet von iPhone mit Tapatalk
Hab eine neue Version im SVN eingecheckt. Sollte alles dabei sein, was du angesprochen hattest.
Gruß
Markus
Ich hatte mir dem noch heutigem Repository das Problem, dass die Ortsvorwahl vor allen Rufnummern stand. Mit der PM-Datei von oben stand plötzlich überall ein +49 vor den Nummern.
Ich habe das gesehen, als ich mir die Einträge der Adressbücher anzeigen lassen habe.
Ich schaue mir morgen mal das heutige Commit an.
---
Nachtrag 1:
Es hat sich leider nichts geändert. Führe ich ein
showPhonebookEntries durch, dann erscheint eine Liste mit falschen Rufnummern. Beispiel:
- 0049+49150123456 - Max Müller
- 0049+49251234567 - Homer Simpsons
- 0049+49231123456 - Lucky Luke
Nachtrag 2:
Ach, verdammt. Ich hatte in der Hektik nach dem 'update' ein 'shutdown restart' vergessen. Nun ist alles perfekt. Danke.
Kann ich bestätigen, Namensauflösung funzt nun auch bei mir einwandfrei. Vielen Dank! :)