Hauptmenü

Modul 96_SIP

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

Vorheriges Thema - Nächstes Thema

plin

@tklein,
die Registrierungsprobleme hatte ich am Anfang auch, deshalb habe ich denen im Wiki schon einen eigenen Abschnitt gegönnt.
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

frank

ich habe heute auch mal ein update gemacht.
grundsätzlich funktioniert das sip modul bei mir weiterhin als virtuelle sip-türsprechanlage. allerdings liefert der state nun am ende der verbindung ein "FAIL call done". ein log sieht so aus:

2017.02.21 14:32:46.292 4: triggerLiveCam, calling 7, ringtime: 15
2017.02.21 14:32:46.304 5: triggerLiveCam, call has pid 18852
2017.02.21 14:32:46.392 4: triggerLiveCam, register new expire : Tue Feb 21 14:37:46 2017
2017.02.21 14:32:46.448 4: triggerLiveCam, DTMF : ABCD*#123--4567890
2017.02.21 14:33:02.775 4: triggerLiveCam, CALLDone -> triggerLiveCam|1|FAIL|HASH(0x37a8bf0)


etwas irritierend, aber das livebild wird korrekt am fritzfon ein- und wieder ausgeschaltet.
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

tklein

@Wzut
Besten Dank!! Hat jetzt geklappt.  :D

Jetzt kann ich mich dem eigentlichen Problem widmen:
Per Sip/Fhem die interne Türsprechanlage in einer Auerswald (per S0 and die FB angeschlossen) anrufen, um dann mit ##R7 den Türöffner zu aktivieren.
FHEM auf Pi 3, Echo (Plus, Dot und Connect), CUL868/433, HM Komponenten, Broadlink, Enigma (VU DUO2), Alexa/Homebridge, Sonoffs (POW, RF, Basic), Wemos D1 (IR, DHT, BH1750, OLED, BMP180), IT/Steckdosen, Fritzbox mit SIP, Wifilight, MQTT, Pilight, Xiaomi Flower Sensor, Spotify, Dooya, Shelly, Conbee2

betateilchen

Zitat von: plin am 21 Februar 2017, 18:38:28
die Registrierungsprobleme hatte ich am Anfang auch,

Nur mal so zur Info: Das SIP Protokoll verlangt keine vorherige Registrierung, um einen abgehenden Anruf tätigen zu können. Die Registrierung ist eigentlich nur dafür notwendig, dass der SIP Server weiß, wohin er einen eingehenden Anruf zustellen soll.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

plin

#34
@betateilchen: Es waren "Registrierungsprobleme" beim listen-Start, weil die sip_Parameter nicht passten :-(

Als gebranntes Kind weiß man dann direkt was man unter "bekannte Probleme" schreiben könnte.
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: frank am 21 Februar 2017, 18:50:14
2017.02.21 14:33:02.775 4: triggerLiveCam, CALLDone -> triggerLiveCam|1|FAIL|HASH(0x37a8bf0)
Dem Thema Türsprechanlage und Livebild von der Webcam werde ich mich die nächsten Tage widmen, konnte die letzten Wochen etwas Erfahrung sammeln beim Testen von pahs Doorpi Projekts. Mal schauen ob ich den Fehler auch so hinbekomme und dann gleich noch den HASH in lesbare Bestandteile zerlege.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

hartenthaler

So, habe heute endlich mal wieder getestet, nachdem ihr hier ja mächtig viel geleistet habt. Danke!

Meine Umgebung: RaspberryPi und FritzBox; 96_SIP.pm 13479 2017-02-21.


  • Lokal (FritzFon) hat das Abspielen von DTMF funktioniert, beim Anruf auf mein iPhone habe ich nur Klackgeräusche gehört, aber kein DTMF.
  • Die Eingabe von DTMF am Telefon hat nur einmal am FritzFon funktioniert; nachfolgende Versuche führten zwar zu einer Verbindung, aber das Reading "dtmf" hat sich nicht mehr geändert.
  • Das Attribut ringtime in "set <name> call <nummer> [<ringtime>] [<nachricht>]" ist unklar. Die commandref spricht auch in der Erklärung nur von Ringtime, was ich mal als maximale Dauer des Klingelns (also vor Zustandekommen der Verbindung) interpretieren würde. Im wiki wird bei den Anwendungsbeispielen dieser Parameter dann umdefiniert in <dauer> und bezeichnet die Anrufdauer, also die Dauer für die das zustandegekommene Gespräch gehalten wird. Was stimmt?
  • Aus der Beschreibung geht hervor, dass die Angabe des Parameters "ringtime" bei "set <name> call <nummer> [<ringtime>] [<nachricht>]" nicht optional sei, wenn eine Nachricht als Audiofile ausgegeben werden soll. Im wiki steht unter "Anruf tätigen und DTMF-Töne senden", dass eine Nachricht in Form von DTMF-Tönen ohne "ringtime" erfolgen muss ("**1 -#23). Klingt irgendwie inkonsistent bzw. widersprüchlich.
  • In der commandref wird das nötige Format des Audiofiles nicht beschrieben. Im wiki wird das Format zumindest in den Anwendungsbeispielen genannt: PCM/8000. Ein Hinweis auf die Installation von sox per "sudo apt-get install sox" wäre hilfreich.
  • Bei einem set ... reset" hätte ich erwartet, dass das SIP-Device zurück gesetzt wird und ein eventuell vorhandener listen-Prozess gestoppt wird. Aber wenn ich nach einem "set ... reset" ein "set ... listen" mache, dann bekomme ich die Info, dass der listen-Prozess noch läuft. Ist das so beabsichtigt?
  • Im Logfile habe ich später zwei Meldungen gefunden: "Timeout for SIP_ListenStart reached, terminated process 5395"
  • Wenn ich das Attribut "sip_listen" auf "wfp" ändere, ändert sich das Reading state erst einmal nicht, erst nach einem "set ... reset" ändert es sich in "listen_for_wfp". Aber der Listen-Prozess bekommt davon wohl nichts mit. Er nimmt bei einem nachfolgenden Anruf die Verbindung sofort an und wartet nicht auf ein "fetch".
  • Ich fände es schön, wenn das "sip_password" nicht im Klartext als Attribut gespeichert wäre, sondern wie bei etlichen anderen FHEM-Modulen versteckt wäre.

Alle Verbindungsaufbauten an sich haben einwandfrei geklappt. Sehr schön.

Was mir vorschwebt: FHEM baut für mich eine Telefonverbindung etwa zum Hausmeister auf. Also ich gebe das Kommando auf das ein notify triggered und damit dann ruft das SIP-Device erst mich auf einem internen Handy an. Ich nehme die Verbindung an und bekomme die Sprachansage: "Nun baue ich die gewünschte Verbindung zum Hausmeister auf". Dann ruft SIP den Hausmeister an und verbindet mich sofort. Wie könnte man das hinbekommen?
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, ...

plin

@hartenthaler: Danke fürs Feedback

Das Modul ist nicht recht jung und erfährt derzeit sein "Feintuning". Die Doku hinkt dann im Ping-Pong hinterher. Mal liegt das Wiki vorn, mal die command.ref. Inkosistenzen aufzeigen und die eigene Erwartungshaltung posten hilft uns aber das Ding rund zu kriegen.

Bzgl. der Nutzung des SIP-Clients als Telefonvermittlung sehe ich schwarz, dass ist das eher ein Fall für Asterisk.
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

DerTom

Hallihallo,

habe heute mit Begeisterung dieses neue Modul installiert und konfiguriert. Ich würde es, neben der Funktion, dass FHEM damit Statusmeldungen per Audiofile abspielen kann, auch zum Ausführen von Befehlen in Abhängigkeit von DTMF Codes nutzen wollen. Leider funktioniert es aber nicht, mit # gefolgt von 2 Ziffern das Reading DTMF zu befüllen. Es erscheint gar nicht. Der Caller wird angezeigt und der State steht auf "listen_for_dtmf".

Ausgehende Anrufe funktionieren tadellos.

Hardware: FHEM auf Cubietruck; Fritzbox 7390 mit OS 7.80 --> 96_SIP.pm  13479 2017-02-21 06:38:37Z

DerTom

...ausserdem habe ich jetzt im Logfile alle paar Minuten folgende Einträge:



2017.02.22 19:27:08.327 4: FB_SIP, register new expire : Wed Feb 22 19:32:08 2017
2017.02.22 19:29:38.438 4: FB_SIP, register new expire : Wed Feb 22 19:34:38 2017
2017.02.22 19:32:08.548 4: FB_SIP, register new expire : Wed Feb 22 19:37:08 2017
2017.02.22 19:34:38.658 4: FB_SIP, register new expire : Wed Feb 22 19:39:38 2017


Wzut

    Zitat von: hartenthaler am 22 Februar 2017, 18:39:06
    • Lokal (FritzFon) hat das Abspielen von DTMF funktioniert, beim Anruf auf mein iPhone habe ich nur Klackgeräusche gehört, aber kein DTMF.
    werde ich testen

    • Die Eingabe von DTMF am Telefon hat nur einmal am FritzFon funktioniert; nachfolgende Versuche führten zwar zu einer Verbindung, aber das Reading "dtmf" hat sich nicht mehr geändert.
    verbose auf 5 und Log beobachten, wichtig : # ist das Starkommando , danach müssen zwei unterschiedliche Tasten gedrückt werden , d.h. in Summe sind immer drei Tasten zu drücken.

    • Bei einem set ... reset" hätte ich erwartet, dass das SIP-Device zurück gesetzt wird und ein eventuell vorhandener listen-Prozess gestoppt wird. Aber wenn ich nach einem "set ... reset" ein "set ... listen" mache, dann bekomme ich die Info, dass der listen-Prozess noch läuft. Ist das so beabsichtigt?
    ja denn er läuft nicht noch sondern schon wieder , siehe dein Log (geänderte PID)
    Ändert mal allerdings das attr sip_listen zuvor auf none dann ist wirklich kein Prozess aktiv nach dem reset.

    • Im Logfile habe ich später zwei Meldungen gefunden: "Timeout for SIP_ListenStart reached, terminated process 5395"
    siehe oben

    • Wenn ich das Attribut "sip_listen" auf "wfp" ändere, ändert sich das Reading state erst einmal nicht, erst nach einem "set ... reset" ändert es sich in "listen_for_wfp". Aber der Listen-Prozess bekommt davon wohl nichts mit. Er nimmt bei einem nachfolgenden Anruf die Verbindung sofort an und wartet nicht auf ein "fetch".
    Wenn du bei einem laufenden Listen das attr änderst bekommt der Listen das nicht mit richtig. Dazu muss er erst gestoppt und wieder neu gestartet werden -> set reset. state sollte eigentlich immer die aktuelle Betriebsart des Listen Prozess anzeigen. Werde nochmal die Wechsel im laufendne Betrieb testen.

    • Ich fände es schön, wenn das "sip_password" nicht im Klartext als Attribut gespeichert wäre, sondern wie bei etlichen anderen FHEM-Modulen versteckt wäre.
    kommt auf die ToDo
    meine Anmerkungen im Zitat in kurisv

    @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 :)
    Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

    Wzut

    Nachtrag,  wer Probleme mit DTMF hat : welche Version des Moduls benutzt ihr ?
    Die erste Version vom Sonntag hatte da einen Fehler den ich gestern Morgen noch vor 7:45 Uhr gefixt habe.
    Ich werde aber heute Abend noch eine neuere Version einchecken die dann bei verbose 5 zum Thema DTMF noch etwas mehr Infos liefert.
    Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

    onkeltom

    Hallo,

    beim Listening kommt bei den dmft-Readings fast nie etwas an (bei 40 Versuchen vielleicht 1 x).
    Im Log steht nur:
    fritz_call, listen prozess 3900 found

    Beim Call erscheint im Log:
    2017.02.22 19:59:22 4: fritz_call, calling **611, ringtime: 10
    2017.02.22 19:59:22 4: fritz_call, register new expire : Wed Feb 22 20:04:22 2017
    2017.02.22 19:59:22 4: fritz_call, DTMF : ABCD*#123--4567890
    2017.02.22 19:59:32 4: fritz_call, CALLDone -> fritz_call|1|FAIL|HASH(0x3ea2240)


    Konfiguration:
    define fritz_call SIP
    attr fritz_call sip_from sip:621@fritz.box
    attr fritz_call sip_ip 192.168.188.30
    attr fritz_call sip_listen dtmf
    attr fritz_call sip_password my_password
    attr fritz_call sip_port 5060
    attr fritz_call sip_registrar fritz.box
    attr fritz_call sip_ringtime 10
    attr fritz_call sip_user 621
    attr fritz_call verbose 5



    Hardware: Pi 2 mit Jessie, Fritzbox 7390 + Fritzbox 7490

    Hat jemand eine Idee?

    Gruß,
    OnkelTom

    Wzut

    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.
    Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

    hartenthaler

    #44
    @Wzut: Danke für Deine Analyse. Den Fehler warum ich bei der Eingabe von DTMF-Tönen am Handy keine Änderung im Reading beobachten konnte, habe ich wohl gefunden. Ich hatte erst auf dem Testsystem eine Installation, und als das zumindest stabil lief, habe ich auf dem Produktivsystem nachgezogen und hatte damit zwei Clients mit identischen Einstellungen am laufen. Eigenartigerweise habe ich dennoch keine Fehlermeldungen und keine nicht zustande kommenden Verbindungen beobachtet. Aber seit ich die Testinstallation ausgeschaltet habe, funktioniert die DTMF-Erkennung einwandfrei.

    In der commandref und im wiki müsste noch erwähnt werden: Es müssen auf dem anrufenden Telefon genau drei Tasten gedrückt werden:

    • 1. #
    • 2. und 3.: zwei verschiedene Zifferntasten
    also #12 oder #13 oder ... #21 oder #23 oder ... oder #98.
    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, ...