Hauptmenü

Modul 96_SIP

Begonnen von Wzut, 19 Februar 2017, 19:10:09

Vorheriges Thema - Nächstes Thema

Wzut

nun gehen mir allerdings die Ideen aus. Flaches Netz, kein Docker, keine FW.
Entweder kann die FB nicht mit dem Raspi reden oder sie will nicht, das ist jetzt so ein Punkt wo einem vermutlich nur Wireshark mehr sagen könnte.
Wie ist denn das SIP Telefon 621 in der FB eingerichtet, als normales IP Phone oder als Türsprechstelle ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

plin

Zitat von: Wzut am 21 August 2020, 14:19:58
Wie ist denn das SIP Telefon 621 in der FB eingerichtet, als normales IP Phone oder als Türsprechstelle ?
Ein paar Fragen habe ich gerade eben in meinem letzten Post vor Deinem gestellt https://forum.fhem.de/index.php/topic,67443.msg1079684.html#msg1079684  ;)
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Kurt77

Hallo Wzut,
Normales IP Phone.

Gruß Kurt

plin

Das sieht netzwerktechnisch alles gut aus. Also müssen wir mal auf die andere Seite schauen - die FritzBox.

Finden sich unter System->Ereignsse irgendwelche Fehlermeldungen? Ich habe eben mit einem falschen Passwort getestet und die Meldung "Anmeldung für IP-Telefoniegerät "fhemsipt" von IP-Adresse 192.168.3.33 nicht erfolgreich." erhalten.

Unter Telefonie-> Telefoniegeräte ist Dein SIP-Client an Anschluss LAN/WLAN mit der internen Nummer **621 gelistet?

Wenn Du dieses Gerät editierst ist dem auch der User fhemsip1 zugeordnet?

Ist unter System->FRITZ!Box-Benutzer->fhemsip1 -> Berechtigungen
a) das Benutzerkonto aktiv
b) der Bullit
"Sprachnachrichten, Faxnachrichten, FRITZ!App Fon und Anrufliste
Sprachnachrichten, empfangene Faxe und die Anrufliste können abgehört bzw. angesehen werden. FRITZ!App Fon kann genutzt werden."
getickert?
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Kurt77

Zitat von: plin am 21 August 2020, 16:15:56
Das sieht netzwerktechnisch alles gut aus. Also müssen wir mal auf die andere Seite schauen - die FritzBox.

Finden sich unter System->Ereignsse irgendwelche Fehlermeldungen? Ich habe eben mit einem falschen Passwort getestet und die Meldung "Anmeldung für IP-Telefoniegerät "fhemsipt" von IP-Adresse 192.168.3.33 nicht erfolgreich." erhalten.

Plin, mich trifft der schlag!

Code:
--------------------------------------------------------
Anmeldung für IP-Telefoniegerät "621" von IP-Adresse 192.168.178.33 nicht erfolgreich. [10 Meldungen seit 20.08.20 08:59:31]
----------------------------------------------------------------

Kann ich mir nicht wirklich erklären. Das zugehörige PW steht in einer Textdatei und wurde über die Zwischenablage sowohl in der FB als auch in Fhem eingefügt.
Also lösche ich dieses Telefon jetzt und stelle es wieder neu hin.
Was aber erzwingt nach der Neueinrichtung die Anmeldung von 192.168.178.33 an der FB?

Danke und Gruß,
Kurt

Kurt77

Hallo Plin,
Telefon fhemsip1 neu eingerichtet, PW erneut in fhem eingegeben ("Successfully") und danach einen reset in fhem durchgeführt.
Du glaubst es nicht: Set MysipClient call **611 lässt das Gerät klingeln!

Ganz herzlichen Dank! Ich tüftele weiter.
Also erstmal kein weiterer Handlungsbedarf von Dir und Wzut.

Danke nochmal und Gruß,
Kurt

Wzut

schön, ein zuriedener Kunde mehr :)
Zitat von: Kurt77 am 21 August 2020, 16:42:27
Das zugehörige PW steht in einer Textdatei und wurde über die Zwischenablage sowohl in der FB als auch in Fhem eingefügt.
ohne dir da jetzt zu nahe treten zu wollen, aber vermutlich ging dabei etwas schief. Ein Zeichen zu wenig eines zuviel, was auch immer, aber du wirst da genug Erfahrung mit deinen Hilfsmitteln haben und das bestimmt öfters/immer so handhaben.
Mich wundert es aber schon, da am Anfang ja eine 400er Fehlermeldung kam und dann die relativ versteckte 110.
Mal schauen ob wir zukünftig nicht die einfachen nachstellbaren Fehler besser im Modul abfangen können und direkte Klartext Fehlerausgaben einbauen. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Kurt77

Sorry, ich schon wieder.
leider gibt es bei mir kein Reading "dtmf" und ich bekomme schon wieder einen fehler 404.
Im Logfile sehe ich aber in 2 aufeinander folgenden Zeilen dtmf Events.
Gebe ich z.B. ein "#45", erscheint in den Zeilen "#" und danach "4". Bei eingabe von "45" (also ohne #) sehe ich im log "4" und "5".

Code:
-----------------------------------
Internals:
   FUUID      5f3d5a11-f33f-7695-cdae-b046c5875ba9a078
   LPID       20956
   NAME       MySipClient
   NOTIFYDEV  mytext2speech
   NR         141
   NTFY_ORDER 50-MySipClient
   STATE      listen_dtmf
   TYPE       SIP
   VERSION    V1.92 / 21.03.2020
   READINGS:
     2020-08-21 17:05:11   call            done
     2020-08-21 17:05:11   call_attempt    0
     2020-08-21 17:05:11   call_state      no answer
     2020-08-21 17:05:11   call_success    0
     2020-08-21 17:05:11   call_time       0
     2020-08-21 21:09:47   caller          none
     2020-08-21 21:09:47   caller_name     ---
     2020-08-21 21:09:47   caller_nr       ---
     2020-08-21 21:09:47   caller_state    hangup
     2020-08-21 21:09:47   caller_time     9
     2020-08-21 21:11:32   expire          300
     2020-08-21 16:53:41   last_error      ListenRegister: Failed with code 404
     2020-08-21 21:11:32   listen_alive    20956
     2020-08-21 21:11:32   state           listen_dtmf
   helper:
     LISTEN_PID:
       abortArg   
       abortFn   
       arg        MySipClient
       bc_pid     7
       finishFn   SIP_ListenDone
       fn         SIP_ListenStart
       pid        20956
       timeout   
Attributes:
   T2S_Device mytext2speech
   disabled   0
   history_file ./log/MySipClient.sip
   history_size 0
   sip_dtmf_loop once
   sip_dtmf_send audio
   sip_dtmf_size 2
   sip_elbc   yes
   sip_from   sip:fhemsip1@fritz.box
   sip_ip     192.168.178.33
   sip_listen dtmf
   sip_port   5070
   sip_registrar 192.168.178.1
   sip_ringtime 3
   sip_user   fhemsip1
   verbose    5
-------------------------

Danke und Gruß,
Kurt

Wzut

#968
Zitat von: Kurt77 am 21 August 2020, 21:23:26
leider gibt es bei mir kein Reading "dtmf" und ich bekomme schon wieder einen fehler 404.
Im Logfile sehe ich aber in 2 aufeinander folgenden Zeilen dtmf Events.
Gebe ich z.B. ein "#45", erscheint in den Zeilen "#" und danach "4". Bei eingabe von "45" (also ohne #) sehe ich im log "4" und "5".
a. dein  Fehler 404 ist aber schon etwas älter laut Timestamp, wäre der noch aktuell könntest du das SIP Device gar nicht anrufen, bzw. du hättest gar keine Chance Tasten einzugeben.
b. die Raute # ist das Startzeichen und wird zur Auswertung nicht mitgezählt (siehe Wiki) , wenn nach der 4 die 5 nicht im Log erscheint wurde sie nicht erkannt. In diesem Fall die Eingabe wiederholen oder mal eine andere Taste probieren. Sobald die zweite Taste erkannt wurde gibt es auch das Reading DTMF und für dich vllt. besonders wichtig eine akustische Quittung (siehe Attribut sip_audiofile_dtmf). Generell hatten wir (bzw die User) von Anfang an Probleme mit der DTMF Erkennung auf dem Raspberry. Versuch zu Beginn ersteinmal mit sip_dtmf_size 1 zu arbeiten, dann benötigst du nur eine erkannte Taste nach der Raute. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

plin

Zitat von: Wzut am 22 August 2020, 07:09:16
Generell hatten wir (bzw die User) von Anfang an Probleme mit der DTMF Erkennung auf dem Raspberry.
@wzut: Das war beim Raspberry Pi 1 der Fall, ab dem 2er sollte es gehen. Ich habe gerade auf meinem BananaPi in Verbindung mit der FritzFon App getestet, da gab es keine Probleme
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Kurt77

Hallo,
ich sehe jetzt tatsächlich ein Reading dtmf_event, das sich aber nicht ändert.
Ich glaube, dass das nicht zuverlässig funktioniert, weil ich nach Eingabe # + Ziffer keinen Quittungston höre.

Gruß Kurt

plin

Was nutzt Du als Device für den Anruf?
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Kurt77

Hallo Plin,
ein Fritzfon M2. Übrigens wird immer ein dtmf_event erkannt. Das sehe ich daran, dass die Zeit nach # gefolgt von Ziffer immer aktualisiert wird.

Danke und Gruß,
Kurt

plin

#973
Bei meinem FritzFON C5 höre ich weder die Ansage noch den Quittungston am Ende.

Wenn ich ein T2S Device anlege und die Attribute

  • sip_audiofile_dtmf    !Ihre Eingabe bitte
  • sip_audiofile_ok       !Danke
belege kriege ich auch Ansagen.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Wzut

attribut sip_audiofile_dtmf =  !Das ist Test ergibt bei mir auch nur einen kurzen Pfeifton (warum auch immer)
aber attribut sip_audiofile_ok = !alles klar ist das zu hören - getestet mit FRITZ DECT mit dem bunten Display
@Kurt77 wie hast du denn die beiden Attribute vorbesetzt ? Bzw. wenn du wie wir Text einsetzt muß sowohl sox als auch Text2Speach installiert sein !
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher