Hauptmenü

Modul 96_SIP

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

Vorheriges Thema - Nächstes Thema

amehl

Danke für die Info. Ich hab noch einen alten Raspi rumliegen, vielleicht löse ich es auch so.

Grüße
Andi

amehl

Ich hab mir jetzt einen Leck Sensor installiert und will mich am Handy anrufen lassen wenn Wasser austritt. Ich kriege das mit dem TS2 leider nicht in den Griff. TS2 ist als SERVER angelegt.

Evtl. irgend ein Rechte Problem - ich komme aber nicht drauf. Für Hilfe wäre ich dankbar.
Exiting... (End of file)
2022.10.15 21:52:53 4: TS2: Es wurden alle Teile ausgegeben und der Befehl ist abgearbeitet.
2022.10.15 21:56:54 4: TS2: ermittelte CodePage: ascii , konvertiere nach UTF-8
2022.10.15 21:56:54 4: TS2: MaxChar = 200, Delimiter = (?<=[\.!?])\s*, ForceSplit = 0, AddDelimiter =
2022.10.15 21:56:54 4: TS2: Auflistung der Textbausteine nach Aufbereitung:
2022.10.15 21:56:54 4: TS2: 0 => Wasserschaden
2022.10.15 21:56:54 4: TS2: Verwende TTS Spracheinstellung: Deutsch
2022.10.15 21:56:54 2: TS2: Angegebenes Verzeichnis cache konnte erstmalig nicht angelegt werden.
2022.10.15 21:56:54 1: ERROR evaluating {Text2Speech_Done()}: Not enough arguments for main::Text2Speech_Done at (eval 2814) line 1, near "()"

2022.10.15 21:56:59 3: Melder, timeout waiting for T2S
2022.10.15 21:57:01 4: TS2: ermittelte CodePage: ascii , konvertiere nach UTF-8
2022.10.15 21:57:01 4: TS2: MaxChar = 200, Delimiter = (?<=[\.!?])\s*, ForceSplit = 0, AddDelimiter =
2022.10.15 21:57:01 4: TS2: Auflistung der Textbausteine nach Aufbereitung:
2022.10.15 21:57:01 4: TS2: 0 => Wasserschaden

plin

Klingt so, als ob es das Verzeichnis /opt/fhem/cache/ nicht gibt, TTS dieses anlegen wollte aber nicht konnte. Wer ist der owner von /opt/fhem? Das sollte dem fhem-User gehören.
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

amehl

Vielen Dank das war es - frage mich nur warum der Ordner nur auf owner pi war???

FHEMAN

#1219
Zitat von: Wzut am 10 Mai 2018, 18:49:19
Lustig ... geht bei mir auch nicht. Allerdings schafft verbose 5 da etwas mehr Klarheit :
sox : /usr/bin/sox WARN rate: rate clipped 1 samples; decrease volume?
Was auch immer sox da an dem mp3 File auszusetzen hat :(
Bzw. das würde eigentlich bedeuten das Google da schon Mist zurückliefert ? Werde mich die Tage wohl mal näher damit beschäftigen müssen.
Das Problem ist wohl, dass der sox Converter glaubt, der Sound sei übersteuert.
Das habe ich gerade bei ein paar krassen Halloween Sounds für unseren Klingellautsprecher eben auch bemerkt.

2022.10.30 21:01:43.894 4 : SIP, audio file /opt/fhem/audio/Halloween55.mp3 found
2022.10.30 21:01:43.894 5 : SIP, /usr/bin/sox /opt/fhem/audio/Halloween55.mp3 -t raw -r 8000 -c 1 -e a-law /opt/fhem/audio/Halloween55.alaw 2>&1
2022.10.30 21:01:43.931 5 : SIP, sox output : /usr/bin/sox WARN rate: rate clipped 1875 samples; decrease volume?/usr/bin/sox WARN dither: dither clipped 1666 samples; decrease volume?


Hier hilft der sox Schalter -G, um Clipping zu vermeiden. --norm wäre noch besser, da auch zu leise Sounds korrigiert werden, hat bei mir aber nicht funktioniert. Es wurde dann gar kein Output generiert.

Um nun wenigsten automatisch "nach unten" zu normalisieren, habe ich mal das Attribut audio_normalize eingebaut. 
Die Datei befindet sich im Anhang. Ggf. könnte das ja mit in den Standard.
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

Gisbert

Hallo Wzut,

mein SIP-Device will nicht mehr.
Interne Anrufe von einem Telefon zu einem anderen funktionieren, was mich veranlasst zu vermuten, dass die Telefoniegeräte in der Fritzbox an sich funktionieren.

Wenn ich einen Anruf im SIP-Device absetze, kommt es zu einem Fehler, siehe das list:
Internals:
   CFGFN      ./FHEM/FritzboxUniFiAnwesenheit.cfg
   FUUID      5c93df13-f33f-e986-0dbd-b8d6ee5046144693
   NAME       Tuerklingel
   NOTIFYDEV  global
   NR         109
   NTFY_ORDER 50-Tuerklingel
   STATE      initialized
   TYPE       SIP
   VERSION    V1.92 / 21.03.2020
   eventCount 11
   READINGS:
     2022-11-22 20:53:14   call            done
     2022-11-22 20:53:14   call_attempt    0
     2022-11-22 20:53:14   call_state      fail
     2022-11-22 20:53:14   call_success    0
     2022-11-22 20:53:14   call_time       0
     2022-11-22 20:53:14   last_error      CallRegister: Failed with code 401
     2022-11-22 19:52:00   listen_alive    no
     2022-11-22 20:53:14   state           initialized
   helper:
     CALL_BYE   CallRegister: Failed with code 401
     CALL_ERROR 0
     CALL_NAME  unknown
     CALL_NR    **611
     CALL_START 1669146794.60982
     CALL_TIME  0
     CALL_TYPE  out
     bm:
       SIP_Attr:
         cnt        19
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        22.11. 19:51:42
         max        7.58171081542969e-05
         tot        0.00032353401184082
         mAr:
           set
           Tuerklingel
           alias
           Türklingel
       SIP_Define:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        22.11. 19:51:42
         max        0.000669002532958984
         tot        0.000669002532958984
         mAr:
           HASH(0x55bdae4103e0)
           Tuerklingel SIP
       SIP_Notify:
         cnt        2
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        22.11. 21:08:32
         max        7.70092010498047e-05
         tot        0.00011897087097168
         mAr:
           HASH(0x55bdae4103e0)
           HASH(0x55bdcaa91fc8)
       SIP_Set:
         cnt        39
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        22.11. 19:53:43
         max        0.151061058044434
         tot        0.680599212646484
         mAr:
           HASH(0x55bdae4103e0)
           Tuerklingel
           call
           **701
           6
Attributes:
   alias      Türklingel
   devStateIcon .*:fts_shutter_1w_0
   group      FRITZBOX
   history_file ./log/Tuerklingel.sip
   history_size 0
   icon       it_telephone
   room       Network
   sip_dtmf_loop once
   sip_dtmf_send audio
   sip_dtmf_size 2
   sip_elbc   yes
   sip_from   sip:blockCallcenter@fritz.box
   sip_ip     192.168.1.46
   sip_listen none
   sip_port   5060
   sip_registrar 192.168.178.1
   sip_ringtime 30
   sip_user   blockCallcenter

Das ganze hat schonmal funktioniert, 100%ig Ende August, als ich es eingerichtet hab. Ab wann ich die jetzige Situation hab, weiß ich allerdings nicht.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

plin

Hallo Gisbert,

Kannst Du bitte mal verbose auf 5 setzen, den Vorgang wiederholen und den Log-Auszug posten.

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

SIP Fehler 401 = Unauthorized ! D.h hier würde ich mir Username und Passwort auf beiden Seiten mal zur Brust nehmen. FB will nur "starke" PWs !
Das FHEM und die FB in unterschiedlichen Netzen liegen (192.168.1.x / 192.168.178.x) ist bekannt und eine passende Layer 3 Routing Instanz ist auch vorhanden ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Gisbert

Hallo plin,
hallo Wzut,

ich habe gerade etwas getestet und wollte schreiben, dass ich das Problem gelöst habe.
Gestern war es wohl schon zu spät, so dass ich nicht bemerkt habe, dass die beiden Attribute sip_from und sip_user ein anderes Telefoniegerät anzeigten. Das habe ich geändert (d.h. das richtige Telefoniegerät eingetragen), und nun läuft es wieder wie erwartet.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

schenkl

Hi,

ich habe mir am Wochenende das SIP Modul mit meiner Fritzbos und Text2Speech eingerichtet. Funktioniert auch einwandfrei mit dem Telefonanruf. Allerdings wird die Nachricht (unmittelbar vor dem Anruf) auch an meinem lokal an dem Raspberry PI angeschlossenem Lautsprecher ausgegeben. Letzteren Nutze ich für allgemeine Hinweise z.B. Wetterbericht.

d.h. der Aufruf:
set mySip call 081547111 30 !Hier ist dein FHEM Server
bzw. bei mir
set FritzPhone call 01792293579 60 !Hier ist dein FHEM Server

Gibt "Hier ist dein FHEM Server" unmittelbar vor dem Anruf auch auf meinem Lokalen Lautsprecher aus. Letzteres würde ich gerne unterbinden. Aber wie? Der -Lautsprecher soll natürlich für alle weitere Text2Speech ausgaben funktionieren

Danke
MArk





rob

Du benötigst 2 Text2Speech Devices: eines mit none als Audio-Gerät für die Sip-Calls und eines mit Angabe d. Audio-Hardware für die lokale Ausgabe.
Nur das erste Device wird im SipCaller angegeben im Attribut T2S_Device.

VG
rob

schenkl

Danke Rob, genau das hat funktioniert.

Homalix99

#1227
Hallo,
ich benutze das Modul , damit Fhem soch tel. meldet, wenn bestimmte Ereignisse wie Wasser/Feuer/etc. Alarm eintritt. Die Anrufe gehen bis zum B-Teilnehmer (hier Mobiltelefon) durch, und es sollte die Art des Alarms per TTS als Audio zum Angerufenen übertragen werden.
Das Modul hat, bevor ich fhem in einen Docker-Container umgezogen habe, einwandfrei funktioniert, inkl. Audio Übertragung.
Im Docker funktioniert der Verbindungsaufbau, aber Sprache geht nicht durch.
Erstmal die SIP Def.:

Internals:
   AC         /usr/bin/sox
   CFGFN      ./FHEM/00_config_Alarmanlage.conf
   FUUID      5cdeb681-f33f-5615-f5c1-bae975633b2af415
   NAME       SIP_call
   NOTIFYDEV  SIP_TTS
   NR         887
   NTFY_ORDER 50-SIP_call
   STATE      initialized
   TYPE       SIP
   VERSION    V1.92 / 21.03.2020
   eventCount 52
   forcecall  0
   repeat     0
   READINGS:
     2023-03-04 17:09:24   call            done
     2023-03-04 17:09:24   call_attempt    0
     2023-03-04 17:09:24   call_state      ok
     2023-03-04 17:09:24   call_success    1
     2023-03-04 17:09:24   call_time       2
     2023-03-04 16:57:08   last_error     
     2023-03-04 14:16:50   listen_alive    no
     2023-03-04 17:09:24   state           initialized
   helper:
     CALL_BYE   ok
     CALL_ERROR 0
     CALL_NAME  unknown
     CALL_NR    0151XXXXXXX
     CALL_START 1677946157.82772
     CALL_TIME  2
     CALL_TYPE  out
Attributes:
   DbLogExclude .*
   T2S_Device SIP_TTS
   T2S_Timeout 8
   audio_converter sox
   history_file ./log/SIP_call.sip
   history_size 0
   icon       phone_call_out
   room       System
   sip_dtmf_loop once
   sip_dtmf_send audio
   sip_dtmf_size 2
   sip_elbc   yes
   sip_force_interval 4
   sip_from   sip:620ipfhem@fritz.box
   sip_ip     172.19.0.6
   sip_listen none
   sip_port   5060
   sip_registrar fritz.box
   sip_ringtime 3
   sip_user   620ipfhem
   verbose    5


Das Log sieht m. E. okay aus:

2023.03.04 18:13:10.343 5: SIP_call, MD5: Hier spricht fhem -> c0cebea98dd40d2671d733bc27787431.mp3
2023.03.04 18:13:10.344 5: SIP_call, mp3 File file not found in cache
2023.03.04 18:13:10.408 4: SIP_call, wait_for_t2s file : cache/7406ae8c4853550fde3149a9a364d94d.mp3
2023.03.04 18:13:10.408 4: SIP_call, new T2S file cache/7406ae8c4853550fde3149a9a364d94d.mp3
2023.03.04 18:13:10.409 5: SIP_call, not converted - using cache/7406ae8c4853550fde3149a9a364d94d.alaw from cache
2023.03.04 18:13:10.410 4: SIP_call, audio file cache/7406ae8c4853550fde3149a9a364d94d.alaw found
2023.03.04 18:13:10.410 4: SIP_call, SIP_call|015120177388|40|cache/7406ae8c4853550fde3149a9a364d94d.alaw|0
2023.03.04 18:13:10.427 4: SIP_call, call -> SIP_call|015120177388|40|cache/7406ae8c4853550fde3149a9a364d94d.alaw|0|0
2023.03.04 18:13:10.428 5: SIP_call, call has pid 276034
2023.03.04 18:13:10.454 4: SIP_call[276034], my parent is 6384
2023.03.04 18:13:10.455 4: SIP_call[276034], trying to use port 5070
2023.03.04 18:13:10.672 4: SIP_call[276034], register new expire : 2023-03-04 18:18:10
2023.03.04 18:13:10.676 5: SIP_call, readingS:state Val:calling
2023.03.04 18:13:10.729 4: SIP_call[276034], CallStart with 1 files - first file : cache/7406ae8c4853550fde3149a9a364d94d.alaw - PCMA/8000 , repeat 0
2023.03.04 18:13:10.735 4: SIP_call[276034], calling : 015120177388
2023.03.04 18:13:10.737 5: SIP_call, readingS:call_state Val:calling 015120177388
2023.03.04 18:13:18.862 4: SIP_call[276034], cb_final - status : OK
2023.03.04 18:13:18.862 4: SIP_call[276034], call established
2023.03.04 18:13:18.870 5: SIP_call, readingS:call_state Val:established
2023.03.04 18:13:21.618 5: SIP_call[276034], 0. Ende des ersten Loops
2023.03.04 18:13:21.619 5: SIP_call[276034], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x5576b36360)
2023.03.04 18:13:21.619 5: SIP_call[276034], 2. fi : 0
2023.03.04 18:13:21.619 5: SIP_call[276034], 4. timeout : 0
2023.03.04 18:13:21.619 5: SIP_call[276034], 6. call_established : 1
2023.03.04 18:13:21.619 5: SIP_call[276034], call->bye
2023.03.04 18:13:21.633 5: SIP_call[276034], RTP done : Net::SIP::Simple::Call=HASH(0x5576b36360)
2023.03.04 18:13:21.634 5: SIP_call[276034], Timeout  : 0
2023.03.04 18:13:21.634 5: SIP_call[276034], while    : 0
2023.03.04 18:13:21.634 5: SIP_call[276034], Status   : OK
2023.03.04 18:13:21.634 4: SIP_call[276034], Calltime : 2
2023.03.04 18:13:21.643 4: SIP_call, CALLDone -> SIP_call|1|ok|2
2023.03.04 18:13:21.658 5: SIP_call, fifo is empty
2023.03.04 18:13:21.658 5: SIP_call, no elbc



Die interne IP des fhem Containers ist 172.19.0.6
In der yaml-Def. vom fhem docker-container sind die Ports 5060 -5080 definiert, wie gesagt, Anruf funktioniert, aber ohne Ton.
Ich habe irgendwo gelesen, dass man eine statische Route in der FB eintragen muss, was ich getan habe.
Die stat. Route in der FB sieht so aus: (Anlage).
Ein Paketmitschnitt der FB lässt RTP-Pakete erkennen, die vom SIP-Client stammen (Anlage).
So und jetzt bin ich mit meinem Latein am Ende. Vielleicht hat jemand noch eine Idee.

Danke und
VG

Alex
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

Wzut

Bitte Wiki lesen, da steht schon lange die Lösung für Docker und RTP Ports !



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

Homalix99

Hallo,
okay ich habe das mit den RTP-Ports gestern übersehen und gemäß WIKI durchgeführt.
Ich habe die Ports 2000-2019  gewählt:
Auszug aus Utils.pm

our %EXPORT_TAGS = ( all => [ @EXPORT_OK, @EXPORT ] );

our $RTP_MIN_PORT = 2000;
our $RTP_MAX_PORT = 2019;

und das Docker-composefile angepasst und den Container neu gestartet.
Auszug Ports aus yml-Dockerfile:

image: fhem/fhem:latest
        restart: always
        container_name: fhem
        hostname: FHEM-Docker
        privileged: true
        ports:
            - "8083:8083"
            - "8084:8084"
            - "7072:7072"
            - "5987:5987"
            - "5060:5060"
            - "5070:5070"
            - "5080:5080"
            - "139:139"
            - "445:445"
            - "1000:1000"
            - "3033:3033"
            - "55054:55054"
            - "9522:9522"
            - "2000-2019:2000-2019"

Und ebenfalls nochmals die statische Route in der FB überprüft:

Netzwerk: 172.19.0.0
Subnetzmaske: 255.255.0.0
Gateway: 192.168.3.20

Um auszuschließen dass "Fritz.box" nicht richtig aufgelöst werden, habe ich die IP der FB in der Def. genommen.
List:

Internals:
   AC         /usr/bin/sox
   CFGFN      ./FHEM/00_config_Alarmanlage.conf
   FUUID      5cdeb681-f33f-5615-f5c1-bae975633b2af415
   NAME       SIP_call
   NOTIFYDEV  SIP_TTS
   NR         887
   NTFY_ORDER 50-SIP_call
   STATE      initialized
   TYPE       SIP
   VERSION    V1.92 / 21.03.2020
   eventCount 71
   OLDREADINGS:
   READINGS:
     2023-03-06 20:15:35   call            done
     2023-03-06 20:15:35   call_attempt    0
     2023-03-06 20:15:35   call_state      ok
     2023-03-06 20:15:35   call_success    1
     2023-03-06 20:15:35   call_time       1
     2023-03-06 12:30:51   listen_alive    no
     2023-03-06 20:15:35   state           initialized
   helper:
     CALL_BYE   ok
     CALL_ERROR 1
     CALL_NAME  unknown
     CALL_NR    0151201XXXX
     CALL_START 1678130127.02571
     CALL_TIME  1
     CALL_TYPE  out
Attributes:
   DbLogExclude .*
   T2S_Device SIP_TTS
   T2S_Timeout 8
   audio_converter sox
   comment    Objekt zur Realisierung von Alarm-Telefonanfufen aus fhem heraus via Fritzbox.
Als SIP Adresse muss die Fhem-Container Adresse angegeben werden.
Damit die Sprachansagen am Telefon abgespielt werden, muss eine statische Route in der FB eingetragen werden:
Subnetz: 172.19.0.0/16
Mask: 255.255.0.0
Gateway: 192.168.3.20
   group      SIP
   history_file ./log/SIP_call.sip
   history_size 0
   icon       phone_call_out
   room       System
   sip_dtmf_loop once
   sip_dtmf_send rfc2833
   sip_dtmf_size 2
   sip_elbc   yes
   sip_force_interval 4
   sip_from   sip:620ipfhem@192.168.3.1
   sip_ip     172.19.0.5
   sip_listen none
   sip_port   5060
   sip_registrar 192.168.3.1
   sip_ringtime 3
   sip_user   620ipfhem
   verbose    5


Leider funktioniert die Audioübertragung immer noch nicht.
Hat vielleicht noch jemand eine Idee?

Vielen Dank vorab!

Gruß

Alex
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)