Hauptmenü

Modul 96_SIP

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

Vorheriges Thema - Nächstes Thema

Wzut

#45
Zitat von: hartenthaler am 22 Februar 2017, 20:57:19
  • 2. und 3.: zwei verschiedene Zifferntasten
also #12 oder #13 oder ... #21 oder #23 oder ... oder #98.
ein klares jein  :) ... der * und die Null dürfen auch benutzt werden , nur  # ist immer das Startzeichen.
Hintergrund : Ich hatte massive doppel und dreifach Tasten erkannt, die eleganteste Lösung war für mich das die beiden Zeichen dann unbedingt unterschiedlich sein müssen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

onkeltom

Zitat von: Wzut am 22 Februar 2017, 20:56:19
Du bist auf dem Holzweg, wenn in dem Reading etwas stehen soll dann must du FHEM anrufen und nicht mit set call ein anders Telefon.
Ansonst : Lies bitte mal was ich direkt vor dir gepostet habe.

Das ist mir klar, habe mich aber wohl nicht eindeutig ausgedrückt.
Der erste Log-Auszug stammt von einem Anruf an FHEM.

Den zweiten vom Call an einem anderen Telefon hatte ich nur informativ angehängt.
Ich hatte kurz vor dem Post upgedatet, sodass ich die aktuelle Version haben sollte.
Deinen Post oben hatte ich auch bereits schon gelesen.
Leider funktioniert es trotzdem nicht.

Gruß,
Thomas

Wzut

Habe gerade die neue Version hochgeladen  also wenn es schnell gehen soll sofort direkt aus dem svn holen oder bis morgen um 8:00 warten und dann mit update.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

onkeltom

Vielen Dank,

ich werde es morgen früh testen und Dir dann eine Rückmeldung geben.

Gruß,
Thomad

onkeltom

Hallo,

das Update ist installiert.
Leider funktioniert es bei mir nicht reproduzierbar.

Hier hat es nach etlichen Versuchen funktioniert:
Zitat2017.02.23 09:58:33 5: fritz_call, SIP_filter : a:"Privat" <sip:**611@fritz.box>;tag=4E6DF6D8710E44D2 | b:Net::SIP::Request=HASH(0x3cd15a0)
2017.02.23 09:59:00 5: fritz_call : DTMF Event : #
2017.02.23 09:59:01 5: fritz_call : DTMF Event : 4
2017.02.23 09:59:01 5: fritz_call : DTMF Total: 4 , Anz: 2
2017.02.23 09:59:02 5: fritz_call : DTMF Event : 1
2017.02.23 09:59:02 5: fritz_call : DTMF Total: 41 , Anz: 3
2017.02.23 09:59:02 5: fritz_call, telnet : set fritz_call dtmf_event 41
2017.02.23 09:59:22 5: fritz_call, listen prozess 18913 found
2017.02.23 09:59:31 5: fritz_call, SIP_bye : HASH(0x30004a8)
2017.02.23 09:59:31 5: fritz_call, telnet : set fritz_call caller none
set fritz_call caller_state hangup
exit

Hier wird zwar registriert, dass die DTMF-Sequenz mit # anfängt, die zwei unterschiedlichen Zahlen, die darauf fogen, werden aber nicht registriert:
Zitat2017.02.23 10:24:07 5: fritz_call, SIP_filter : a:"Privat" <sip:**611@fritz.box>;tag=DD6E733ABF5018DA | b:Net::SIP::Request=HASH(0x40c3e00)
2017.02.23 10:24:12 5: fritz_call : DTMF Event : #
2017.02.23 10:25:25 5: fritz_call, listen prozess 1241 found
2017.02.23 10:25:36 5: fritz_call, SIP_bye : HASH(0x40e2168)
2017.02.23 10:25:36 5: fritz_call, telnet : set fritz_call caller none
set fritz_call caller_state hangup
exit

Hier wird gar nicht reagiert:
Zitat2017.02.23 10:28:29 5: fritz_call, SIP_filter : a:"Privat" <sip:**611@fritz.box>;tag=AA8813B385439C74 | b:Net::SIP::Request=HASH(0x40e1b60)
2017.02.23 10:29:48 5: fritz_call, SIP_bye : HASH(0x40e1428)
2017.02.23 10:29:48 5: fritz_call, telnet : set fritz_call caller none
set fritz_call caller_state hangup
exit

Ich hoffe, diese Infos helfen.

Gruß,
Thomas

Wzut

hmm, nun wird es schwer.  Du versucht es immer mit dem gleichen Telefon ?
Was ist das für ein Gerät ( DECT? , FritzPhone ? )  ?
Hast du die Möglichkeit es mal mit einem anderen Telefon zu testen oder sogar von extern ?

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

onkeltom

Zitat von: Wzut am 23 Februar 2017, 11:08:06
hmm, nun wird es schwer.  Du versucht es immer mit dem gleichen Telefon ?
Was ist das für ein Gerät ( DECT? , FritzPhone ? )  ?
Hast du die Möglichkeit es mal mit einem anderen Telefon zu testen oder sogar von extern ?

Hallo,

ich habe es bereits mit Fritz!Fon C5, Fritz!Fon MT-F, Fritz!App Fon und soeben von extern (Smartphone) probiert.
Das Ergebnis ist leider identisch.

Gruß,
Thomas

plin

Auf meinem Raspi2 läuft die DTMF-Erkennung auch noch nicht ganz rund. Sowohl mit der Fritzfon-App als auch einem Gigaset-DECT-Telefon kann ich DTMF-Töne senden, aber vozugsweise in der Kurzform anwählen->#nm->auflegen. Wenn man nach dem ersten Reading weitere #nm's absetzen will steigt die Fehlerquote deutlich.

VG plin
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

fred2412

Hi,
Danke, dass sich jemand um dieses Modul kümmert. Ich warte ja schon sehr lange auf die Möglichkeit mit diesem Modul auch DTMF-Sequenzen übertragen zu können. Ich habe mir bis dato mit einem "System-Aufruf" von linphone beholfen. Schöner wäre das natürlich über ein fhem-Modul.
Leider kann ich aber die "DTMF senden" Funktion des Moduls (noch) nicht für meine Zwecke nutzen, da die DTMF-Sequenz zu schnell nach dem Antworten/Abheben der Gegenstelle abgefeuert wird. Ich befürchte, dass dies einige Geräte wie z.B. Telefonschaltgeräte nicht mögen, da sie sich wie ein Telefax zuerst mit einem "Bestätigungston" melden.
Könnte man hier irgendwo eine Pause (sleep ?) im Modul einbauen oder vielleicht sogar als Attribut vorgeben?
Wenn mir jemand sagt wo, würde ich das sogar händisch in 96_SIP.pm eintragen  ;)

Ich bedank mich mal sicherheitshalber im Voraus!!!

SG

Fred
Banana Pro FHEM 5.8
CUNO 868, HM-CFG-LAN, HM-CFG-USB-2, HM-MOD-RPI-PCB
Intertechno, HomeMatic

frank

Zitat von: plin am 23 Februar 2017, 18:46:23
Auf meinem Raspi2 läuft die DTMF-Erkennung auch noch nicht ganz rund. Sowohl mit der Fritzfon-App als auch einem Gigaset-DECT-Telefon kann ich DTMF-Töne senden, aber vozugsweise in der Kurzform anwählen->#nm->auflegen. Wenn man nach dem ersten Reading weitere #nm's absetzen will steigt die Fehlerquote deutlich.
beim pi3 kann ich stundenlang, ohne aufzulegen, fehlerfrei dtmf erkennen (aktuelle version).  :)
registriert als türsprecheinrichtung in fb7490 mit MTF und C4.

beim attr sip_ip muss ich unbedingt die ip als zahl eingeben, sonst geht gar nichts.
bei sip_registrar und sip_from funktioniert auch fritz.box.

noch 2 hinweise:
1. das modul könnte noch eine versions ID vertragen.
2. im set-call-eingabefeld erscheint nach einem "set call x" immer der inhalt des readings call. also erst die rufnummer und zum schluss ein done.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wzut

#55
Zitat von: fred2412 am 23 Februar 2017, 20:10:35
Könnte man hier irgendwo eine Pause (sleep ?) im Modul einbauen oder vielleicht sogar als Attribut vorgeben?
die passende Stelle ist irgendwo in den Tiefen von Net::Sip vergraben :( , aber vllt lässt sich auch das wieder nur mit Bordmitteln lösen :
Die DTMF Zeichenfolge kennt noch das Minuszeichen (-) hier wird eine Pause von einem Ton gemacht. Versuche doch einfach mal deinen DTMF String statt nur einem Minus (das ist die Starterkennung ) mit 10 oder noch mehr beginnen zu lasssen und ggf. auch Pausen zwischen den Zeichen
set mySIP call 0815 10 -----------0-1--2---3
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Zitat von: frank am 23 Februar 2017, 20:22:07
beim attr sip_ip muss ich unbedingt die ip als zahl eingeben, sonst geht gar nichts.
bei sip_registrar und sip_from funktioniert auch fritz.box.
1. das modul könnte noch eine versions ID vertragen.
2. im set-call-eingabefeld erscheint nach einem "set call x" immer der inhalt des readings call. also erst die rufnummer und zum schluss ein done.
a. ja, Net::Sip will an dieser Stelle unbedingt die IP des passenden Interfaces (Bsp eth0) , Joker ala 0.0.0.0 wie z.B. beim Apache für beliebige Schnittstellen sind nicht zulässig !
b. das sollte so sein wenn der FHEM Server sein DNS im Griff hat
1. kommt auf die ToDo
2. ein Punkt der mich auch schon bei anderen Modulen gestört hat und seine Ursache wohl in fhemweb hat. Immer wenn ein set Befehl genauso heist wie ein  Reading wird einem der aktuelle Wert des Readings vorgelegt. Abhilfe würde z.B. schaffen den set call in set makecall zu ändern, aber ich denke doch das zu mehr als 90% der set call via Skript oder notify benutzt wird und nicht von Hand im Web Frontend. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

frank

Zitat von: Wzut am 24 Februar 2017, 11:01:20
a. ja, Net::Sip will an dieser Stelle unbedingt die IP des passenden Interfaces (Bsp eth0) , Joker ala 0.0.0.0 wie z.B. beim Apache für beliebige Schnittstellen sind nicht zulässig !
b. das sollte so sein wenn der FHEM Server sein DNS im Griff hat
ich hatte bei a. den hostnamen vom fhemserver probiert, da er über wlan/dhcp angebunden wird. zwar angeblich immer mit derselben ip, aber ich traue meinem wlan zur zeit nicht wirklich. sollte eigentlich nur ein deutlicher hinweis für die mitstreiter sein, die gerade probleme bei ihrer inbetriebnahme des sipdevices haben.

Zitat2. ein Punkt der mich auch schon bei anderen Modulen gestört hat und seine Ursache wohl in fhemweb hat. Immer wenn ein set Befehl genauso heist wie ein  Reading wird einem der aktuelle Wert des Readings vorgelegt. Abhilfe würde z.B. schaffen den set call in set makecall zu ändern, aber ich denke doch das zu mehr als 90% der set call via Skript oder notify benutzt wird und nicht von Hand im Web Frontend.
das kannte ich noch nicht, ist dann aber auch ok so.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

DerTom

Zitat von: Wzut am 22 Februar 2017, 20:34:56

@Der Tom , dtmf : siehe meine Antwort oben , verbose auf 5 , danach aber wieder auf 3 dann gibt es auch keine bew expire Meldungen mehr im Log :)

Ganz so einfach war es nicht. Nach einem Verbose auf 3 (oder delete) kamen die Einträge immernoch. Nach einem Restart dann nicht mehr...

Habe mittlerweile auch ein Update gemacht, bekomme aber weiterhin kein DTMF Reading...weder bei einem Anruf von extern (Handy) noch intern (MT-F oder C4). Reading "state" steht immernoch auf "listen_for_dtmf".

Auch gibt es ja jetzt das Reading "caller_state" allerdings hat die immer nur den Wert "hangup". Dieser wird immer wieder aktualsiert, wenn der Anruf aufgelegt wird. Einen anderen Wert sehe ich nie.

Im Log sehe ich bei verbose 5 nur die folgenden Einträge:


2017.02.25 10:23:37.253 5: FB_SIP, SIP_filter : a:"Mobilteil_1" <sip:**610@fritz.box>;tag=DBEC537E93AB3E25 | b:Net::SIP::Request=HASH(0x4c4d3c0)
2017.02.25 10:23:40.821 5: FB_SIP : DTMF Event : #
2017.02.25 10:23:41.876 5: FB_SIP : DTMF Event : #
2017.02.25 10:23:46.555 5: FB_SIP, SIP_bye : HASH(0x56d57d8)
2017.02.25 10:23:46.555 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit


Und damit keine Missverständnisse aufkommen: Ich habe nur einmal die Taste # gedrückt. Erkannt werden aber meist 2 oder sogar auch mal 3 mal #...

Von extern wird immer nur einmal die Taste # erkannt, weitere aber nicht...

2017.02.25 10:25:37.837 5: FB_SIP, SIP_filter : a:"xxx" <sip:xxxx@fritz.box>;tag=DBD7D0FFA96578BB | b:Net::SIP::Request=HASH(0x5747db8)
2017.02.25 10:25:46.971 5: FB_SIP : DTMF Event : #
2017.02.25 10:25:48.529 5: FB_SIP, SIP_bye : HASH(0x587d1b8)
2017.02.25 10:25:48.530 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit


jorge

Hallo,

mein FHEM läuft unter auf Rpi 2 (wheezy). Eine Verbindung soll zu einer Auerswald-Türsprechstelle via FB 7490 (FRITZ!OS: 06.80) hergestellt werden

Installation des SIP Modul hat geklappt, client wurde auf FB unter 621 registriert, Anruf (intern) wird auch in fhem caller_state:ringing bzw caller_state:hangup signalisiert. Eine Verbindung wird aber nicht aufgebaut.

Der Versuch  über set call eine Verbindung (intern oder extern) herzustellen, scheitert allerdings. Eintrag im Logfile (verbose 5:)

Can't use string ("**611") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
2017.02.25 12:39:40 4: SIP, DTMF : ABCD*#123--4567890
2017.02.25 12:39:40 4: SIP, register new expire : Sat Feb 25 12:44:40 2017
2017.02.25 12:39:38 5: SIP, call has pid 3737
2017.02.25 12:39:38 4: SIP, calling **611, ringtime: 10

Bin mit meinem Latein zu Ende...

LG

Jorge
FHEM.RaspberryPi 2 (HM, 1Wire, Callmonitor.FB 7490, GPIO, I2C, MQTT-Server, MCP23018)
FHEM.RaspberryPi  (FHEM2FHEM, CUL, FS20)
FHEM.RPiZeroW (I2C, 1Wire, python.api, XiaomiBTLESens.MQTT)
FHEM.Win7 (FHEM2FHEM,DBLOG.MySql)
ESPEasy (WEMOSD1, I2C, Analog, 1Wire), Sonoff_T1_3ch, Mobotix QM25, robonect