Hauptmenü

Modul 96_SIP

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

Vorheriges Thema - Nächstes Thema

Wzut

Zitat von: jorge am 25 Februar 2017, 12:43:58
mein FHEM läuft unter auf Rpi 2 (wheezy).
hast dir mal den Ur Thread https://forum.fhem.de/index.php/topic,40219.0.html durchgelesen ?
Wheezy installiert mit apt-get install eine uralte Version von Net::Sip die eigentlich bei allen immer nur Probleme machte.
Daher wurde damals meist das Paket direkt mit cpan installiert. (Ist im FB Thread beschrieben)

Zitat von: DerTom am 25 Februar 2017, 10:27:08
Nach einem Verbose auf 3 (oder delete) kamen die Einträge immernoch. Nach einem Restart dann nicht mehr...
klar weil der Listen Prozess noch immer 5 hatte , ein set FB_SIP reset hätte es auch getan

Zitat von: DerTom am 25 Februar 2017, 10:27:08
Reading "state" steht immernoch auf "listen_for_dtmf".
Das soll auch so sein :)


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)

Das Startzeichen wurde schon mal erkannt - gut. Das es gedoppelt hat kommt vor ist aber nicht tragisch da wie ich schon schrieb diese Wiederholungen verworfen werden. Tipp : Ich sehe das du recht schnell ( 5 Sekunden ) aufgegeben hast. Nimm dir mal etwas mehr Zeit, setzte attr_ringtime auf z.B. 30 und drücke nach dem Anruf bzw dem # ruhig mal alle Zahlentasten langsam durch, ist ein event im Event Monitor erschienen , wieder mit dem # beginnen und probieren. (natürlich wieder mit verbose 5) Das Modul trennt dir erst die Verbindung wenn ringtime abgelaufen ist , hast also viel Zeit zum Tasten drücken.   

ich habe auch versucht im Netz etwas mehr Hintergrundinfos zu DTMF zu bekommen.  Fragen :
a. gibt es die Probleme auch beim Anrufen con Call Centern wo man div Tasten drücken muss um durch die Menüs zu kommen ?
b. läuft der Anschlus zum Provider auch via VoIP -VDSL oder noch DSL, ISDN, analog ? 

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

Bastelbernd

Hallo

mußte es auch so installieren wie von YellowBall geschrieben

Zitat
2. Die Datei Net-SIP-0.687.tar.gz herunterladen und in ein Verzeichnis auf dem Pi ablegen
3. Entpacken mit sudo gunzip Net-SIP-0.687.tar.gz
4. tar-ball entpacken mit sudo tar -xvf Net-SIP-0.687.tar.gz
5. in das enstandene Verzeichnis Net-SIP-0.687 wechseln
5. folgende Befehle nacheinander eingeben
    sudo perl Makefile.PL
    sudo make
    sudo make test
    sudo make install
    sync
    sudo reboot
6. Nach dem Reboot sollte es funzen - so war es jedenfalls bei mir

Gruß Bernd
FHEM auf Server mit Mainboard ASRock J3160B,Gehause Mini ITX E-3002+ SSD
Viessmann(optolink) HM-CFG-USB(HMLAN), PoKeys57E
Jeelik(Arduino)+LaCrosse, Nextion
Firmata+Arduino+1Wire+2xDS2423+IN+OUT
Electrolama zig-a-zig-ah!,Zigbee2MQTT

jorge

Zitat von: Bastelbernd am 25 Februar 2017, 14:18:15
Hallo

mußte es auch so installieren wie von YellowBall geschrieben

Gruß Bernd

@ Bastelbernd Mußte ich auch. Dann ging es. Hatte leider den alten Thread nicht gelesen, sonst wär ich wohl selber darauf gekommen.
@ Wzut Danke für den gedulidigen Hinweis.

Bin gespannt, was da noch kommt...

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

Wzut

Zitat von: jorge am 25 Februar 2017, 15:00:05
Bin gespannt, was da noch kommt...
och , plin und ich haben da schon noch ein paar offene Punkte auf unsere Liste .....
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

f-zappa

Läuft auf Anhieb - spitze!
Hat schon jemand eine Sprachausgabe dazu gebastelt? Ich fände interessant, wenn FHEM mich mit dynamisch generierten Texten über Ereignisse informieren würde...

DerTom

#65
Hallo Wzut,

Zitat von: Wzut am 25 Februar 2017, 13:53:53

Das Startzeichen wurde schon mal erkannt - gut. Das es gedoppelt hat kommt vor ist aber nicht tragisch da wie ich schon schrieb diese Wiederholungen verworfen werden. Tipp : Ich sehe das du recht schnell ( 5 Sekunden ) aufgegeben hast. Nimm dir mal etwas mehr Zeit, setzte attr_ringtime auf z.B. 30 und drücke nach dem Anruf bzw dem # ruhig mal alle Zahlentasten langsam durch, ist ein event im Event Monitor erschienen , wieder mit dem # beginnen und probieren. (natürlich wieder mit verbose 5) Das Modul trennt dir erst die Verbindung wenn ringtime abgelaufen ist , hast also viel Zeit zum Tasten drücken.   

Ich habe das Attr. ringtime auf 30 gesetzt. Getrennt wird da aber nichts. Habe sogar mehrfach versucht mal ne Minute oder auch 2 auf die Testen zu drücken. Bei einem mal kam dann folgendes raus...

2017.02.25 19:20:13.234 5: FB_SIP, SIP_filter : a:"xxxxxx" <sip:yyyyyy@fritz.box>;tag=251CF4EE518145DE | b:Net::SIP::Request=HASH(0x4d71e78)
2017.02.25 19:20:25.289 5: FB_SIP : DTMF Event : #
2017.02.25 19:20:25.939 5: FB_SIP : DTMF Event : 6
2017.02.25 19:20:25.940 5: FB_SIP : DTMF Total: 66 , Anz: 2
2017.02.25 19:20:27.275 5: FB_SIP, listen prozess 14799 found
2017.02.25 19:20:32.359 5: FB_SIP : DTMF Event : 9
2017.02.25 19:20:32.360 5: FB_SIP : DTMF Total: 669 , Anz: 3
2017.02.25 19:20:32.360 5: FB_SIP, telnet : set FB_SIP dtmf_event 669

2017.02.25 19:20:43.607 5: FB_SIP : DTMF Event : 6
2017.02.25 19:20:56.574 5: FB_SIP : DTMF Event : 6
2017.02.25 19:21:01.658 5: FB_SIP, SIP_bye : HASH(0x5574928)
2017.02.25 19:21:01.659 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit


bei den anderen manchmal nur ein "#", machmal auch gar nichts oder nur eine 6 oder eine 9 ...

Lustig ist ja, daß immer nur die 6 und die 9 erkannt wird, auch wenn ich die gar nicht drücke!!

2017.02.25 19:29:30.824 5: FB_SIP, SIP_filter : a:"xxxx" <sip:yyyyy@fritz.box>;tag=B5AA4F89FAB08532 | b:Net::SIP::Request=HASH(0x56ccd88)
2017.02.25 19:29:40.658 5: FB_SIP : DTMF Event : #
2017.02.25 19:29:41.779 5: FB_SIP : DTMF Event : #
2017.02.25 19:29:43.852 5: FB_SIP : DTMF Event : 6
2017.02.25 19:29:43.853 5: FB_SIP : DTMF Total: 66 , Anz: 2
2017.02.25 19:29:44.106 5: FB_SIP : DTMF Event : #
2017.02.25 19:29:53.824 5: FB_SIP, SIP_bye : HASH(0x5841680)
2017.02.25 19:29:53.825 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit


Bei diesem Beispiel habe ich die Zahlenfolge #12#35#12#23#34#45# gedrückt. ... weder eine noch 2 mal die 6. Ist doch eher komisch, oder?

Zitat
ich habe auch versucht im Netz etwas mehr Hintergrundinfos zu DTMF zu bekommen.  Fragen :
a. gibt es die Probleme auch beim Anrufen con Call Centern wo man div Tasten drücken muss um durch die Menüs zu kommen ?
b. läuft der Anschlus zum Provider auch via VoIP -VDSL oder noch DSL, ISDN, analog ?

zu a: nein
zu b: Ich habe hier einen Magenta Tarif, was ja ein VoIP Anschluss ist (in meinem Fall VDSL).

Nebenbei: Kann es sein, daß der CallMonitor, der bei mir parallel dazu läuft, Probleme verursacht?

Wzut

Zitat von: f-zappa am 25 Februar 2017, 18:24:19
Hat schon jemand eine Sprachausgabe dazu gebastelt? Ich fände interessant, wenn FHEM mich mit dynamisch generierten Texten über Ereignisse informieren würde...
ich hatte bisher nie Bedarf für Sprachausgabe. Wenn ich die command.ref zu Text2Speech richtig verstehe, geht das Audiofile immer direkt zum Alsadevice via mplayer.
Wenn es aber einen Weg gibt das zu unterdrücken und die mp3 unter einem definierten Namen abzuspeichern könnte man die vermutlich on-the-fly mit sox konvertieren und dem call Befehl übergeben.  Dafür müsste mir aber jemand Nachhilfestunden in Sachen TTS geben.

@DerTom, z.Z. stehe ich da auch auf dem Schlauch. Bis jetzt ist mir nur klar das es für DTMF zwei verschiedene Übertragungsarten gibt (rfc2833 & audio).
Fritzbox User können da Parameter ändern , siehe :
https://avm.de/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/361_Fernsteuerung-von-Telefoniegeraeten-und-Sprachcomputern-nicht-moeglich/
da ich kein VoIP Anschluss habe kann ich da auch nichts ändern und testen. Ich habe auch keine Ahnung ob die Änderungen dann nur für externe Übertragungen gelten oder auch im eigenen Netz.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DerTom

Zitat von: Wzut am 25 Februar 2017, 19:45:43

@DerTom, z.Z. stehe ich da auch auf dem Schlauch. Bis jetzt ist mir nur klar das es für DTMF zwei verschiedene Übertragungsarten gibt (rfc2833 & audio).
Fritzbox User können da Parameter ändern , siehe :
https://avm.de/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/361_Fernsteuerung-von-Telefoniegeraeten-und-Sprachcomputern-nicht-moeglich/

Ich gehe davon aus, daß dies maximal die ausgehenden DTMF-Töne beeinflusst, nicht die eingehenden. Jegliche Änderung der Einstellungen in meiner FB bringt keinen Unterschied im Ergebnis.

Zitat
da ich kein VoIP Anschluss habe kann ich da auch nichts ändern und testen.

Nun, das wird sich ändern, da ja bekanntlich bis Ende 2018 alle Anschlüsse auf IP umgestellt werden. ISDN - basierte Anschlüsse gehören dann der Vergangenheit an.
Zitat
Ich habe auch keine Ahnung ob die Änderungen dann nur für externe Übertragungen gelten oder auch im eigenen Netz.

Wenn man Einstellungen bei der Registriegung der Internrufnummer in der FB macht, können diese ja nur extern gelten. Da es intern bei mir allerdings auch nicht geht, liegt es vermutlich nicht an der Fritzbox oder zumindest an den Einstellungen, die im KB Artikel von AVM genannt sind.

Auf jeden Fall, vielen Dank für die Idee und die bisherige Umsetzung, auch wenn sie derzeit für micht nichts bringt, da es weiterhin nicht funktioniert...Schade.

frank

@DerTom
probiere doch mal die registrierung als sip türsprecheinrichtung in der fritzbox.
damit komme ich auf 100% erkennung.
in der fritzbox habe ich unter dect-monitor einen bitfehlertest. hast du dort auffälligkeiten?
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

@frank:

Vielen Dank für den Tipp. Allerdings habe ich ein Problem. Ich kann ja keine Türsprechanlage anrufen...Ich will ja die DTMF-Töne in FHEM auswerten und damit Aktionen auslösen. Nicht umgekehrt, also FHEM DTMF-Töne senden lassen.

Da Du es ja scheinbar erfolgreich eingerichtet hast, kannst Du mir erklären wie? Von extern geht es meiner Meinung nach nicht, da die IP-Türsprechanlage keine externe Nummer für Anrufe von Aussen haben kann. Oder sehe ich das falsch?

Der Bitfehlertest zeigt keinerlei Probleme an.

frank

ich habe auch keine physische türsprecheinrichtung, nur das sip-device als solche registriert. sozusagen eine virtuelle.

telefonie -> telefoniegeräte -> neues gerät einrichten -> türsprechanlage -> weiter -> lan/wlan -> weiter
benutzer und passwort (wie im sipdevice) -> weiter -> weiter -> übernehmen. fertig.
unter telefoniegeräte siehst du dann die interne nummer.

ZitatVon extern geht es meiner Meinung nach nicht, da die IP-Türsprechanlage keine externe Nummer für Anrufe von Aussen haben kann. Oder sehe ich das falsch?
das stimmt wohl.

aber vielleicht mal einen versuch wert, ob es einen unterschied macht.
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

Also ich habs jetzt intern probiert. die interne Nummer ist jetzt wieder die **620. Kann ich von meinen Telefonen (MT-F und C4) anrufen. OK soweit. Allerdings gibt es auch hier die gleichen Probleme, wie der Anruf von extern. Von ca. 10 Versuchen hat es nur ein mal funktioniert, die eigegebene Zeichenfolge in das DTMF-Reading zu übergeben.


2017.02.26 16:05:57.230 5: FB_SIP, SIP_filter : a:"Mobilteil_1" <sip:**610@fritz.box>;tag=8406EB7AFA155E65 | b:Net::SIP::Request=HASH(0x588c430)
2017.02.26 16:06:03.233 5: FB_SIP : DTMF Event : #
2017.02.26 16:06:13.135 5: FB_SIP : DTMF Event : 2
2017.02.26 16:06:13.136 5: FB_SIP : DTMF Total: 2 , Anz: 2
2017.02.26 16:06:13.226 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:06:43.492 2: HMCCU: Received no events from CCU since 300 seconds
2017.02.26 16:07:05.467 5: FB_SIP : DTMF Event : #
2017.02.26 16:07:12.022 5: FB_SIP : DTMF Event : 7
2017.02.26 16:07:12.022 5: FB_SIP : DTMF Total: 27 , Anz: 2
2017.02.26 16:07:13.294 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:07:28.382 5: FB_SIP : DTMF Event : 4
2017.02.26 16:07:28.382 5: FB_SIP : DTMF Total: 274 , Anz: 3
2017.02.26 16:07:28.383 5: FB_SIP, telnet : set FB_SIP dtmf_event 274 --> HIER HATTE ICH MEHRFACH #27 PROBIERT - ABER NIEMALS DIE 4
2017.02.26 16:07:45.409 5: FB_SIP : DTMF Event : 7
2017.02.26 16:07:54.359 5: FB_SIP : DTMF Event : 1
2017.02.26 16:08:09.188 5: FB_SIP : DTMF Event : #
2017.02.26 16:08:13.362 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:08:37.373 5: FB_SIP : DTMF Event : 5
2017.02.26 16:08:37.373 5: FB_SIP : DTMF Total: 5 , Anz: 2
2017.02.26 16:08:53.415 5: FB_SIP : DTMF Event : 8
2017.02.26 16:08:53.416 5: FB_SIP : DTMF Total: 58 , Anz: 3
2017.02.26 16:08:53.416 5: FB_SIP, telnet : set FB_SIP dtmf_event 58 --> HIER HATTE ICH NICHT 58 GETIPPT, SONDERN ###555888
2017.02.26 16:09:13.429 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:09:26.020 5: FB_SIP, SIP_bye : HASH(0x588e018)
2017.02.26 16:09:26.021 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit
2017.02.26 16:09:26.156 4: FB_SIP, register new expire : Sun Feb 26 16:14:26 2017
2017.02.26 16:09:43.120 5: FB_SIP, telnet : set FB_SIP caller Mobilteil_1 sip:**610@fritz.box
exit
2017.02.26 16:09:43.123 5: FB_SIP, SIP_filter : a:"Mobilteil_1" <sip:**610@fritz.box>;tag=2646A33E08AA71DA | b:Net::SIP::Request=HASH(0x31b77a8)
2017.02.26 16:09:48.629 5: FB_SIP : DTMF Event : #
2017.02.26 16:09:52.484 5: FB_SIP : DTMF Event : 4
2017.02.26 16:09:52.485 5: FB_SIP : DTMF Total: 4 , Anz: 2
2017.02.26 16:09:52.659 5: FB_SIP : DTMF Event : 5
2017.02.26 16:09:52.659 5: FB_SIP : DTMF Total: 45 , Anz: 3
2017.02.26 16:09:52.660 5: FB_SIP, telnet : set FB_SIP dtmf_event 45 --> HIER HATTE ICH #45 GETIPPT , DAS EINZIGE MAL, DAß ES FUNKTIONIERT HAT...

2017.02.26 16:10:13.496 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:10:27.034 5: FB_SIP : DTMF Event : 8
2017.02.26 16:10:48.145 5: FB_SIP : DTMF Event : 7
2017.02.26 16:11:13.566 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:11:16.468 5: FB_SIP, SIP_bye : HASH(0x56d51a8)
2017.02.26 16:11:16.469 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit


Es ist einfach zu instabil...warum auch immer.

Mir will auch nicht in den Kopf, warum er manchmal 3 Ziffern in das DTMF Reading schreibt, es aber eigentlich laut Beschreibung nur 2 Ziffern sein sollen...Im nachfolgenden Beispiel habe ich immer nur 2 Ziffern gesendet immer getrennt mit #. Und niemals 2 gleiche Ziffern hintereinander.


2017.02.26 16:22:03.238 5: FB_SIP, SIP_filter : a:"Mobilteil_2" <sip:**612@fritz.box>;tag=E06C8C6E87C985B6 | b:Net::SIP::Request=HASH(0x588d560)
2017.02.26 16:22:10.423 5: FB_SIP : DTMF Event : 2
2017.02.26 16:22:14.563 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:22:27.185 5: FB_SIP : DTMF Event : 2
2017.02.26 16:22:27.717 5: FB_SIP : DTMF Event : 5
2017.02.26 16:22:35.206 5: FB_SIP : DTMF Event : #
2017.02.26 16:22:36.965 5: FB_SIP : DTMF Event : 2
2017.02.26 16:22:36.966 5: FB_SIP : DTMF Total: 2 , Anz: 2
2017.02.26 16:22:38.332 5: FB_SIP : DTMF Event : 5
2017.02.26 16:22:38.333 5: FB_SIP : DTMF Total: 25 , Anz: 3
2017.02.26 16:22:38.333 5: FB_SIP, telnet : set FB_SIP dtmf_event 25

2017.02.26 16:22:50.968 5: FB_SIP : DTMF Event : 1
2017.02.26 16:22:58.795 5: FB_SIP : DTMF Event : #
2017.02.26 16:23:00.541 5: FB_SIP : DTMF Event : 1
2017.02.26 16:23:00.542 5: FB_SIP : DTMF Total: 1 , Anz: 2
2017.02.26 16:23:09.534 5: FB_SIP : DTMF Event : #
2017.02.26 16:23:11.543 5: FB_SIP : DTMF Event : 1
2017.02.26 16:23:11.543 5: FB_SIP : DTMF Total: 11 , Anz: 2
2017.02.26 16:23:13.399 5: FB_SIP : DTMF Event : 4
2017.02.26 16:23:13.399 5: FB_SIP : DTMF Total: 114 , Anz: 3
2017.02.26 16:23:13.400 5: FB_SIP, telnet : set FB_SIP dtmf_event 114

2017.02.26 16:23:14.631 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:23:27.691 5: FB_SIP : DTMF Event : #
2017.02.26 16:23:31.983 5: FB_SIP : DTMF Event : 7
2017.02.26 16:23:31.983 5: FB_SIP : DTMF Total: 7 , Anz: 2
2017.02.26 16:23:41.435 5: FB_SIP : DTMF Event : #
2017.02.26 16:23:43.674 5: FB_SIP : DTMF Event : 6
2017.02.26 16:23:43.675 5: FB_SIP : DTMF Total: 76 , Anz: 2
2017.02.26 16:24:03.135 5: FB_SIP : DTMF Event : 9
2017.02.26 16:24:03.136 5: FB_SIP : DTMF Total: 769 , Anz: 3
2017.02.26 16:24:03.136 5: FB_SIP, telnet : set FB_SIP dtmf_event 769

hartenthaler

Zitat von: DerTom am 26 Februar 2017, 13:30:38
Allerdings habe ich ein Problem. Ich kann ja keine Türsprechanlage anrufen...

Ich habe es wie Frank eingerichtet. Intern kann ich die Türsprechstelle **628 anrufen. Und von extern geht es duch eine Rufumleitung auch. Ich habe eine externe MSN dafür hergenommen und diese in der Fritzbox auf die 628 umgeleitet. Damit ist FHEM von extern anrufbar und empfängt die DTMF, die ich dann per notify auswerte.

Zumindest im Prinzip. Manchmal, so wie gerade eben, bekomme ich bei der Eingabe von #89 als Reading 898. Ich vermute mal ein Problem mit dem Echo. Wenn ich die 8 drücke höre ich einige Zeit später ein Echo dieses Tastendrucks. Wahrscheinlich dringt das dann wieder zum Empfänger durch und wird gleich nochmal ausgewertet. Kann man diesen Bestätigungston unterdrücken? Oder kann man die Erkennung so programmieren, dass nach zwei verschiedenen erkannten Zahlen generell Schluß ist und das Reading gesetzt wird, d.h. dass das Reading garantiert immer aus genau zwei verschiedenen Ziffern besteht. Diese Vielfalt sollte ja erst mal reichen.

Um die Liste der wünschenswerten Dinge zu erweitern: wie wäre es mit einem Sprachdialogsystem? Also man ruft FHEM an, bekommt eine Begrüßung per Sprache und ein paar Menüpunkte: Wählen Sie eine 1 für Lichtsteuerung, eine 2 um die Haustür zu öffnen, etc. Natürlich nur nachdem man sich authentifiziert hat (per PIN-Code, per Stimmmuster, Geheimwort, ...). Und dann eben die zweite Stufe des Dialogs: "Wählen Sie eine 1 für die Deckenlampe, eine 2 für den Deckenfluter, ...".

Oder gleich wie bei Alexa: man ruft FHEM/SIP an sagt "mache das Licht im Wohnzimmer an." Dieses Sprachkommando wird, sobald man eine Pause macht, an den Alexa-Voice-Service geschickt, dort bearbeitet und löst dann die gewünschte die Aktion aus. Die Antwort/Qittung wird dann wieder in die Telefonverbindung eingespielt, so dass man als Anrufer weiß, dass man verstanden worden ist.
fhem 5.8 auf RaspberryPi 3 mit HMLAN und CCU2, ZWave, JeeLink, FHZ1000 für FS20, HMS, Fritz!Box, Fritz!DECT200, Harmony, Sonos, hue, netatmo, SSCam, Wetter- und Verkehrsmodule, Chat-Bot mit RiveScript/Telegram, IFTTT, pushover, ...

DerTom

Ja, OK. Ne Rufumleitung geht. Hier habe ich aber die gleichen Probleme wie intern...

Allerdings würde ich mich freuen, wenn es nur manchmal nicht funktioniert. Bei mir ist es der Regelfall. Was mache ich denn anders als Ihr? Habe mich strikt an das Wiki und die Commandref gehalten...


Internals:
   LPID       21119
   NAME       FB_SIP
   NR         606
   STATE      listen_for_dtmf
   TYPE       SIP
   Readings:
     2017-02-25 13:17:05   call            done
     2017-02-25 13:17:05   call_state      ok
     2017-02-26 17:08:10   caller          none
     2017-02-26 17:08:10   caller_state    hangup
     2017-02-26 16:44:40   dtmf            5823
     2017-02-26 16:30:30   state           listen_for_dtmf
   Helper:
     Listen_pid:
       abortArg
       abortFn
       arg        FB_SIP
       bc_pid     4054
       finishFn   SIP_ListenDone
       fn         SIP_ListenStart
       pid        21119
       timeout
Attributes:
   room       Fritzbox
   sip_from   sip:620@fritz.box
   sip_ip     192.168.xxx.zzz
   sip_listen dtmf
   sip_password <password>
   sip_port   5060
   sip_registrar 192.168.xxx.yyy
   sip_ringtime 30
   sip_user   620
   verbose    5

Wzut

Zitat von: hartenthaler am 26 Februar 2017, 16:41:56
Kann man diesen Bestätigungston unterdrücken? Oder kann man die Erkennung so programmieren, dass nach zwei verschiedenen erkannten Zahlen generell Schluß ist und das Reading gesetzt wird, d.h. dass das Reading garantiert immer aus genau zwei verschiedenen Ziffern besteht. Diese Vielfalt sollte ja erst mal reichen.
Kann man ? Ja, Mann kann fast alles :)
Im Ernst : meine aktuelle Version hat ein neues Attr dtmf_size (Bereich von 1 bis 4) damit lege ich fest ab wann der Event erzeugt werden soll.
In der aktuellen Version ist die Abfrage auf größer 2 (der # wird mit gerechnet) , daher kann es zum oben beschrieben Effekt mit den drei Ziffern kommen.
Ich muss mal schauen was passiert wenn ich das Echo rausnehme.   

Zitat von: DerTom am 26 Februar 2017, 17:15:34
Was mache ich denn anders als Ihr?
Vermutlich nichts , die Frage ist vllt welches FB Modell mit welcher Firmware du benutzt.
Bzw. auf welchem Unterbau läuft das SIP Modul und welche Version von Net::Sip ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher