Hauptmenü

Modul 96_SIP

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

Vorheriges Thema - Nächstes Thema

Wzut

Zitat von: Heuberg am 26 Mai 2017, 08:25:08
Bizarre copy of ARRAY in scalar assignment at /usr/share/perl/5.14/Carp.pm line 140.
Keine Ahnung welches Modul Carp.pm nutzt, aber vermutlich führt der Fehler dazu das dein FHEM Hauptprozess stirbt !
Als Folge davon dann :
Zitat von: Heuberg am 26 Mai 2017, 08:25:08
2017.05.26 05:29:08 1: FritzSIP[2292], can´t find my parent 2115 in process list !
Died at ./FHEM/96_SIP.pm line 353.
Der (Kind) Listen Prozess 2292 findet seinen Haupt (Eltern)  Prozess 2115 nicht mehr (vermutlich weil er gerade wegen Carp gestorben ist) und beendet sich nun selbst, da er als armes Waisenkind nutzlos geworden ist. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Heuberg

Hallo,

die Ursache für den Fehler:
ZitatBizarre copy of ARRAY in scalar assignment at /usr/share/perl/5.14/Carp.pm line 140.

ist gefunden. Es liegt am Modul 32_mailcheck.pm.
Identisch:
https://forum.fhem.de/index.php/topic,47457.msg391777.html#msg391777

Viele Grüße
Rainer
HM, MAX, MySensors, Fronius, Conbee II, ZigBee, VCONTROL, Modbus, RPi, AVM

Wzut

Zitat von: matschig4711 am 26 Mai 2017, 07:56:48
Vielleicht hilft das auch jemand anderem, denn ein einfaches "set Fritzbox call #883**" über das FRITZBOX-Modul brachte mich auch nicht weiter.
Ja, das hatte ich befürchtet. Mit der Smartphone App klappt es auch nicht den Wecker so ein oder aus zu schalten.
D.h. Das SIP Modul hat kein Problem mit den Rufnummern #881** oder #881# , die FB mag das aber wohl nur von Festnetz oder DECT Telefonen :(
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Tomk

Hallo, ich wundere mich warum bei mir die Anrufe machmal nach 12 s beendet werden und ok zurückgemeldet wird, obwohl die Textmeldung 2mal wiederholt werden soll. der angerufene hört nur noch das Anrufende wenn er schnell genug dran geht:
2017.06.09 21:04:18 3: mySIP, force call
2017.06.09 21:04:18 4: mySIP, msg will be repeat -2 times
2017.06.09 21:04:18 4: mySIP, audio file cache/b478fa7d0c514de07c2fa071a807ab88.alaw found
2017.06.09 21:04:18 4: mySIP, mySIP|xxxx|45|cache/b478fa7d0c514de07c2fa071a807ab88.alaw|-2
2017.06.09 21:04:18 4: mySIP, call -> mySIP|xxxx|45|cache/b478fa7d0c514de07c2fa071a807ab88.alaw|-2|&60
2017.06.09 21:04:18 5: mySIP, call has pid 1744
2017.06.09 21:04:18 4: mySIP[1744], my parent is 10863
2017.06.09 21:04:18 4: mySIP[1744], using random port 44425
2017.06.09 21:04:18 4: mySIP[1744], register new expire : Fri Jun  9 21:09:18 2017
2017.06.09 21:04:18 5: mySIP[1744], telnet : set mySIP state calling exit
2017.06.09 21:04:18 4: mySIP[1744], CallStart with 3 files - first file : cache/b478fa7d0c514de07c2fa071a807ab88.alaw - PCMA/8000 , repeat 2
2017.06.09 21:04:18 4: mySIP[1744], calling : xxxx
2017.06.09 21:04:18 5: mySIP[1744], telnet : set mySIP call_state calling xxxx exit
2017.06.09 21:04:18 4: mySIP[1744], cb_final - status : FAIL - final : 481
2017.06.09 21:04:18 5: mySIP[1744], telnet : set mySIP call_state ringing exit
2017.06.09 21:04:25 4: mySIP[1744], cb_final - status : OK
2017.06.09 21:04:25 4: mySIP[1744], call established
2017.06.09 21:04:25 5: mySIP[1744], telnet : set mySIP call_state established exit
2017.06.09 21:04:26 5: mySIP[1744], 0. Ende des ersten Loops
2017.06.09 21:04:26 5: mySIP[1744], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:26 5: mySIP[1744], 2. fi : 0
2017.06.09 21:04:26 5: mySIP[1744], 3. timeout : 0
2017.06.09 21:04:26 4: mySIP[1744], next file : cache/b478fa7d0c514de07c2fa071a807ab88.alaw
2017.06.09 21:04:26 4: mySIP[1744], cb_final - status : OK
2017.06.09 21:04:28 4: mySIP[1744], loop rtp_done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:28 4: mySIP[1744], next file : cache/b478fa7d0c514de07c2fa071a807ab88.alaw
2017.06.09 21:04:28 4: mySIP[1744], cb_final - status : OK
2017.06.09 21:04:30 4: mySIP[1744], loop rtp_done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:30 5: mySIP[1744], RTP done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:30 5: mySIP[1744], Timeout  : 0
2017.06.09 21:04:30 5: mySIP[1744], while    : 2
2017.06.09 21:04:30 5: mySIP[1744], Status   : OK
2017.06.09 21:04:30 4: mySIP, CALLDone -> mySIP|1|ok
2017.06.09 21:04:30 5: mySIP, fifo is empty
2017.06.09 21:04:30 5: mySIP, no elbc


Hat jemand ne idee?

F.R.

Hallo,
Ich habe mit dem Sip-Client eine Funktion realisiert, dass das Klingeln der Türe auch das Telefon klingeln lässt. schalten. Nun habe ich noch realisiert, dass ich durch Anrufen des Sip-Clients die Funktion ein und ausschalte indem ich über einen notify einen Dummy schalte. Was mir nun noch fehlt ist ein Feedback, ob ich gerade ein oder ausgeschalten habe. Das würde ich gerne per Text2Speech realisieren. Kann mir jemand einen Hinweis geben, wie ich das realisieren könnten, dass der SIP-Client beim angerufen werden abhängig vom Status eines Dummys etwas anders per Text2Speech antwortet?
Vielen Dank schon mal
Florian

Wzut

@Tomk, dein Log sieht gut aus und lässt sich in fünf Abschnitte einteilen :
1. Schritt , Übergabe der Parameter und klingeln des Telefons
2017.06.09 21:04:18 5: mySIP[1744], telnet : set mySIP call_state ringing exit
2. Schritt , es klingelte 7 Sekunden dann wurde der Hörer abgenommen :
2017.06.09 21:04:25 5: mySIP[1744], telnet : set mySIP call_state established exit
die nächsten drei Schritte sind in 5 Sekunden durch und dort wird 3x mal deine Audio Datei abgespielt :
cache/b478fa7d0c514de07c2fa071a807ab88.alaw
D.h. alles wie es sein soll. Wenn du allerdings die Nachricht nur bei der zweiten Wiederholung und davon auch nur das Ende hörst, dann vergeht dir zuviel Zeit vom abheben des Hörers bis zum heranführen ans Ohr.  Abhilfe laut Wiki -> https://wiki.fhem.de/wiki/SIP-Client
Zitatsip_call_audio_delay
    Damit wird festgelegt wie lange bei einem Call mit dem abspielen des Audiofiles gewartet werden soll nachdem man den Anruf angenommen hat. Gültige Werte sind 0 - 3 in 0.25 (1/4) Sekunden Schritten.


Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Tomk

@Wzut: danke für die Erklärung. Ich finde auch das das log file sehr gut aussieht, allerdings passt das Verhalten nicht zu dem was ich erlebe. Ich habe den Hörer gar nicht rechtzeitig abgenommen. D.h. es klingelt dreimal und bevor ich zum abheben komme ist es auch schon vorbei.

Woran kann das liegen? Es hatte auch vor einigen Wochen schon mal funktioniert.



Gesendet von iPad mit Tapatalk

Wzut

Das klingt nach Rufumleitung , Rufgruppe oder AB der nach 3x Klingeln abhebt, also irgendwas nimmt bei dir den Ruf tatsächlich an.
K.A. wie dein Gesammtaufbau aussieht.
Nur so als Tipp : Ich hatte beim proggen auch oft mehere Instanzen des Moduls laufen und irgendwann kamen die Beschwerden das der Sammelruf **9 nicht mehr ginge.
Ursache war eine Insatanz die immer sofort abgehoben hat so das die anderen Telefone nicht mehr klingelten.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Tomk

#278
Ich rufe mein Handy an. Wenn der Anrufbeantworter abheben würde bekäme ich ja einen Nachricht das was auf dem ab ist. Kann es an der Multisim liegen? Ich habe noch eine SIM im Auto mit der gleichen Nummer, aber die reagiert ja auch nicht wenn das Auto aus ist...

Wenn ich mein Handy normal Anrufe kann ich ewig klingeln lassen ohne das ein ab oder sonst was abhebt. Ich denke das Modul erkennt fälschlicherweise das  die Verbindung aufgebaut ist.


Wie funktioniert denn die Erkennung ob jemand abgehoben hat?

F.R.

Zitat von: F.R. am 10 Juni 2017, 08:03:49
Hallo,
Ich habe mit dem Sip-Client eine Funktion realisiert, dass das Klingeln der Türe auch das Telefon klingeln lässt. schalten. Nun habe ich noch realisiert, dass ich durch Anrufen des Sip-Clients die Funktion ein und ausschalte indem ich über einen notify einen Dummy schalte. Was mir nun noch fehlt ist ein Feedback, ob ich gerade ein oder ausgeschalten habe. Das würde ich gerne per Text2Speech realisieren. Kann mir jemand einen Hinweis geben, wie ich das realisieren könnten, dass der SIP-Client beim angerufen werden abhängig vom Status eines Dummys etwas anders per Text2Speech antwortet?
Vielen Dank schon mal
Florian
Hallo,
Ich habe inzwischen weiter rumprobiert und folgenden Absatz gefunden, der leider noch nicht funktioniert:
Ich habe mit Text2Speech zwei Dateien erstellt, die dir gewünschten Ansagen enthalten. Nun habe ich ein notify  erstellt, das auf das caller Reading triggert und dann zunächst den eigentlichen Schaltbefehl ausführt, dann das Attribut sip_audiofile_wfp auf die entsprechende Datei ändert und dann den Anruf entgegen nimmt. Leider bleibt der SIP-Client auf "fetching" stehen und ich höre am Telefon gar nichts.
So sieht das notify aus:

define Klingel_An_Aus_notify notify SIPClient:caller:.* IF ([Klingel_Umleitung:state] eq "off") (set Klingel_Umleitung on,attr SIPClient sip_audiofile_wfp cache/KlingelAN.alaw,Set SIPClient fetch) ELSE (set Klingel_Umleitung off,attr SIPClient sip_audiofile_wfp cache/KlingelAUS.alaw,set SIPClient fetch)


Folgendes sehe ich im Eventmonitor:

2017-06-11 20:13:59 SIP SIPClient listen_wfp
2017-06-11 20:14:08 dummy Klingel_Umleitung off
2017-06-11 20:14:08 Global global ATTR SIPClient sip_audiofile_wfp cache/KlingelAUS.alaw
2017-06-11 20:14:08 SIP SIPClient caller: Telefon sip:**1@fritz.box
2017-06-11 20:14:08 SIP SIPClient caller: fetch
2017-06-11 20:14:08 SIP SIPClient caller_state: ringing_1
2017-06-11 20:14:09 SIP SIPClient caller_state: fetching
2017-06-11 20:14:09 SIP SIPClient listen_wfp


Und so sieht das Log mit verbose 5 aus:

2017.06.11 20:14:09 4: BlockingCall (SIP_ListenStart): created child (3024), uses telnetPort to connect back
2017.06.11 20:14:09 4: SIPClient, Listen new PID : 3024
2017.06.11 20:14:09 4: SIPClient[3024], my parent is 2962
2017.06.11 20:14:09 4: SIPClient[3024], register new expire : Sun Jun 11 20:19:09 2017
2017.06.11 20:14:09 5: SIPClient[3024], telnet : set SIPClient state listen_wfp exit
2017.06.11 20:14:09 4: Connection accepted from telnetPort_127.0.0.1_51316
2017.06.11 20:14:09 5: Cmd: >set SIPClient state listen_wfp<
2017.06.11 20:14:09 5: Starting notify loop for SIPClient, 1 event(s), first is listen_wfp
Notify.266 Notification of 'SIPClient' received. Device not monitored.
2017.06.11 20:14:09 5: End notify loop for SIPClient
2017.06.11 20:14:09 5: Cmd: >exit<
2017.06.11 20:14:09 4: SIPClient[3024], using cache/KlingelAUS.alaw for audio_wfp
2017.06.11 20:14:12 4: Connection


Hat jemand eine Idee, was hier nicht stimmt?

plin

Das Problem ist der asynchrone listen-Prozess. Beim Start holt er sich einmalig die Informationen aus den Attributen. Du müsstest also eine Art "Audiofile vom Dienst" angeben und je nach Situation das erste oder zweite Audiofile auf dieses File kopieren. Wenn der SIP-Client dann abhebt wird das "Audiofile vom Dienst" mit dem aktuellen Inhalt abgespielt.
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

F.R.

Puh, das klingt kompliziert. Hast du eine Idee wie ich das umsetzen könnte?

plin

habe gerade mal nach "fhem system command" gegoogelt und einen Hinweis auf
{system ("/fhem/elro_1_on.sh &")}
gefunden.

Also müsstest du mit
{system ("cp /fhem/..../file1  /fhem/..../actfile")}
das jeweilige File kopieren können.
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

Zitat von: Tomk am 11 Juni 2017, 09:11:49
Ich denke das Modul erkennt fälschlicherweise das  die Verbindung aufgebaut ist.
Wie funktioniert denn die Erkennung ob jemand abgehoben hat?
Das denke ich nicht :) Das Modul ist "dumm" was gerade Sache ist bekommt es vom SIP Server ( FritzBox ?) gesagt.
D.h. da würde ich ansetzen mit der Suche, bzw. ruf doch mal ein internes Telefon oder das Handy von jemand ganz andrem an zum Test.

@F.R. du hast zwei Alternativen :
a. die schwere , Attribut im notify ändern und den Client restten. FHEM wird dir aber die Attribut Änderung mit dem roten Fragezeichen danken.
b. die einfache Variante : zwei SIP Clients im SIP Server und FHEM definieren. Client 1 mit dem Attribut der Nachricht 1 und Client 2 mit er anderen Nachricht. Im notify dann einfach entscheiden ob Client 1 oder 2 aktiv werden soll.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

F.R.

Hallo,

vielen Dank für die Tipps. Ich habe es jetzt wie von Wzut vorgeschlagen mit den zwei  SIP-Clients hinbekommen. Es kann so einfach sein, wenn man nur drauf kommt  :D

Vielen Dank!