Modul 96_SIP

[Rewe2000]

Hallo Wzut,

ich teste heute noch sofort die von dir vorgeschlagenen Änderungen und berichte.

Ich habe jetzt den Störenfried ausgemacht, welcher (bei mir) mit SIP nicht kann oder will:
Stelle ich den HMCCURPC Server ab (HMCCU ohne ext. RPC Server), so kommt jeder Ruf (mit intern **52 gestestet) an.
Schalte ich diesen wieder ein, so kommt immer die Meldung mit dem belegten Port.

Was ich mir jedoch nicht erklären kann, der Ruf geht raus, ich höre aber DMTF Töne obwohl ich nur eine Nummer "set TelefonClient call **52 30" wählen will.
Im Log steht folgendes:

Code Auswählen Erweitern

2017.12.01 20:42:14 4: TelefonClient, calling **52, ringtime: 30 , no message
2017.12.01 20:42:14 4: TelefonClient, TelefonClient|**52|30||0
2017.12.01 20:42:14 4: TelefonClient, call -> TelefonClient|**52|30||0|0
2017.12.01 20:42:14 5: TelefonClient, call has pid 2573
2017.12.01 20:42:14 4: TelefonClient[2573], my parent is 2513
2017.12.01 20:42:14 4: TelefonClient[2573], using random port 44372
2017.12.01 20:42:15 4: TelefonClient[2573], register new expire : 2017-12-01 20:47:15
2017.12.01 20:42:15 5: TelefonClient[2573], telnet : set TelefonClient state calling exit
2017.12.01 20:42:15 4: TelefonClient[2573], CallStart DTMF : ABCD*#123--4567890
2017.12.01 20:42:15 4: TelefonClient[2573], calling : **52
2017.12.01 20:42:15 5: TelefonClient[2573], telnet : set TelefonClient call_state calling **52 exit
2017.12.01 20:42:15 4: TelefonClient[2573], cb_final - status : FAIL - final : 481
2017.12.01 20:42:15 5: TelefonClient[2573], telnet : set TelefonClient call_state ringing exit
2017.12.01 20:42:19 4: TelefonClient[2573], cb_final - Status : OK
2017.12.01 20:42:19 4: TelefonClient[2573], call established
2017.12.01 20:42:19 5: TelefonClient[2573], telnet : set TelefonClient call_state established exit
2017.12.01 20:42:29 5: TelefonClient[2573], 0. Ende des ersten Loops
2017.12.01 20:42:29 5: TelefonClient[2573], 1. rtp_done : OK
2017.12.01 20:42:29 5: TelefonClient[2573], 2. fi : 0
2017.12.01 20:42:29 5: TelefonClient[2573], 3. timeout : 0
2017.12.01 20:42:29 5: TelefonClient[2573], RTP done : OK
2017.12.01 20:42:29 5: TelefonClient[2573], Timeout  : 0
2017.12.01 20:42:29 5: TelefonClient[2573], while    : 0
2017.12.01 20:42:29 4: TelefonClient, CALLDone -> TelefonClient|1|ok
2017.12.01 20:42:29 5: TelefonClient, fifo is empty
2017.12.01 20:42:29 5: TelefonClient, no elbc

Hänge ich dagegen eine Textansage an, so höre ich nichts auch keine DMTF Töne und auch keinen Text. Logauszug gerne wenn du ihn brauchst.

Ich hoffe du kannst mit der Eingrenzung des Fehlers etwas anfangen, leider kann ich mangels guten Perl Kentnissen bei der Fehlersuche nicht viel helfen.

Danke und Gruß
Reinhard

[Rewe2000]

Hallo Wzut,

anbei meine, von dir vorgeschlagenen Versuche:
zu 1.

Das Gemecker wegen den ** Nummern passiert .....

Irgendwie ist bei mir alles komisch, momentan finde ich die gestern beschriebene Meldung nicht mehr im Log!
Warscheinlich habe ich gestern Nacht nur davon geträumt, nach der endlosen Suche des kuriosen Fehlers.

zu 2.

ändere dort die Zeile leg => $leg, in leg => $ip,  und lade das Modul mit "reload 96_SIP" neu.

Jeder Ruf geht raus, es werden aber immer DMTF Töne angehängt, genau wie von mir beschrieben. https://forum.fhem.de/index.php/topic,67443.msg724470.html#msg724470
Auch das Log sieht nahezu identisch aus. Kann mir nicht erklären, woher der DMTF Anhang "ABCD*#123--4567890" kommt.

Code Auswählen Erweitern

2017.12.01 21:11:52 4: TelefonClient, calling **52, ringtime: 30 , no message
2017.12.01 21:11:52 4: TelefonClient, TelefonClient|**52|30||0
2017.12.01 21:11:52 4: TelefonClient, call -> TelefonClient|**52|30||0|0
2017.12.01 21:11:52 5: TelefonClient, call has pid 2795
2017.12.01 21:11:52 4: TelefonClient[2795], my parent is 2513
2017.12.01 21:11:52 4: TelefonClient[2795], using random port 44031
2017.12.01 21:11:52 4: TelefonClient[2795], register new expire : 2017-12-01 21:16:52
2017.12.01 21:11:52 5: TelefonClient[2795], telnet : set TelefonClient state calling exit
2017.12.01 21:11:52 4: TelefonClient[2795], CallStart DTMF : ABCD*#123--4567890
2017.12.01 21:11:52 4: TelefonClient[2795], calling : **52
2017.12.01 21:11:52 5: TelefonClient[2795], telnet : set TelefonClient call_state calling **52 exit
2017.12.01 21:11:52 4: TelefonClient[2795], cb_final - status : FAIL - final : 481
2017.12.01 21:11:52 5: TelefonClient[2795], telnet : set TelefonClient call_state ringing exit
2017.12.01 21:11:58 4: TelefonClient[2795], cb_final - Status : OK
2017.12.01 21:11:58 4: TelefonClient[2795], call established
2017.12.01 21:11:58 5: TelefonClient[2795], telnet : set TelefonClient call_state established exit
2017.12.01 21:12:08 5: TelefonClient[2795], 0. Ende des ersten Loops
2017.12.01 21:12:08 5: TelefonClient[2795], 1. rtp_done : OK
2017.12.01 21:12:08 5: TelefonClient[2795], 2. fi : 0
2017.12.01 21:12:08 5: TelefonClient[2795], 3. timeout : 0
2017.12.01 21:12:08 5: TelefonClient[2795], RTP done : OK
2017.12.01 21:12:08 5: TelefonClient[2795], Timeout  : 0
2017.12.01 21:12:08 5: TelefonClient[2795], while    : 0
2017.12.01 21:12:08 4: TelefonClient, CALLDone -> TelefonClient|1|ok
2017.12.01 21:12:08 5: TelefonClient, fifo is empty
2017.12.01 21:12:08 5: TelefonClient, no elbc

Zu meiner Fhem Konfiguration:
Ich verwende viele HmIP Komponenten, die Anbindung an den Raspi zu Fhem erfolgt hier über eine CCU2 über ein HMCCU-Device und wegen der deutlich schnelleren Datenverbindung zur CCU2 habe ich den externen RPC-Server (HMCCURPC-Device) eingerichtet.
Ich kann diese jederzeit aktiv oder passiv schalten, ohne Beeinträchtigung der Funktion.

Wenn ich noch was testen soll, gerne.
Gruß Reinhard

[Wzut]

die ABCD*#123--4567890 sind hardgecodet im Modul, denn irgendetwas muss gesendet werden wenn der User schon so geizig ist und nichts übergibt !
Aber jetzt läuft auch dein Problemkind mit dem ändern von $leg auf $ip ?

Edit :

Stelle ich den HMCCURPC Server ab (HMCCU ohne ext. RPC Server), so kommt jeder Ruf (mit intern **52 gestestet) an.
Schalte ich diesen wieder ein, so kommt immer die Meldung mit dem belegten Port.

hatte ich übersehen !!! THX

[Wzut]

Hänge ich dagegen eine Textansage an, so höre ich nichts auch keine DMTF Töne und auch keinen Text. Logauszug gerne wenn du ihn brauchst.

Wie schaut denn dein Aufruf mit Textnachricht aus ? und ja Log hilft ungemein

[Rewe2000]

Hallo Wzut,

ich wollte gestern nicht das gesamte Forum mit irgend welchen ewig langen Loganhängen zumüllen, aber ohne grundlegende Infos kann kein Fehler gefunden werden, deshalb wollte ich eben verschiedene Versuche machen und dir die Fehlerlogs übermitteln.

Es ist aber Absolut kurios, jetzt geht SIP so wie er soll.
Ein Text im Anhang wird brav vorgelesen, DTMF im Anhang wird korrekt vorgespielt. Ich versteh die Welt nicht mehr, gestern war alles anders so wie ich es in meinen gestrigen Beitrag auch geschrieben habe.

Befehl: "set TelefonClient call **52 30"
In der aktuellen Konfiguration mit "leg => $ip" klingelt der Apparat und SIP spielt mir ungewollt die DMTF Töne vor.

Das mit den angehängten DTMF Tönen im obigen Ruf ist das von dir so gewollt?
Ich bin mir absolut sicher, dass in der Fhem Minimalkonfiguration nur das Telefon geklingelt und dann hat SIP nach dem abheben sofort wieder aufgelegt. So habe ich es auch gemäß des sehr gut und ausführlich geschriebenen Wiki-Beitrags auch erwartet.

Damit könnte ich aber prima leben, denn irgend eine Message soll ja durch einen Anruf übermittelt werden.

Ich habe schon fast die Vermutung das HMCCURPC Modul blockiert sporadisch irgend welche Ports für SIP, denn im meiner gestrigen Versuchsreihe, als ich Device um Device aus Fhem entfernt hatte, kamen auch sporadisch mal einzelne Rufe an. Erst als ich das HMCCURPC Device abgeschaltet (nicht gelöscht) hatte, kam zuverlässig jeder Ruf an, wenn auch mit den geschilderten Abweichungen bei den Anhängen.

Ich beobachte die Situation bei mir und melde mich wieder (mit Logauszügen) wenn die Fehler erneut auftreten sollten.

Bei dir und allen Helfern im Forum möchte ich mich für die Unterstützung bei der Fehlersuche bedanken.

Gruß Reinhard

[plin]

Es ist aber Absolut kurios, jetzt geht SIP so wie er soll.
Ein Text im Anhang wird brav vorgelesen, DTMF im Anhang wird korrekt vorgespielt. Ich versteh die Welt nicht mehr, gestern war alles anders so wie ich es in meinen gestrigen Beitrag auch geschrieben habe.

tja, ein Kollege nennt so etwas EDPM - electronic data processing mysteries

[Wzut]

Das mit den angehängten DTMF Tönen im obigen Ruf ist das von dir so gewollt?
Ich bin mir absolut sicher, dass in der Fhem Minimalkonfiguration nur das Telefon geklingelt und dann hat SIP nach dem abheben sofort wieder aufgelegt. So habe ich es auch gemäß des sehr gut und ausführlich geschriebenen Wiki-Beitrags auch erwartet.

Wie oben bereits geschrieben, ja das ist so gewollt ! damit der User direkt nach dem Einrichten einen Schnellschuss ala "set mySIP call Nummer" machen kann.

Im Wiki stand IMHO auch mal ein Satz wie "dann hört man ein Geräusch" inzwischen finde ich aber nur noch diese Stelle

Wird kein Audiofile angegeben, wird nur die Verbindung hergestellt und nach der Anrufdauer wieder unterbrochen.

und das ist in der Tat etwas irreführend, denn einen Call ganz ohne alles gibt es nicht. D.h. entweder DTMF oder Soundatei.

[Rewe2000]

Hallo,

nachdem nun meine größeren Startschwirigkeiten beseitigt sind, komme ich endlich dazu, das Device zu testen.
Ich muss echt sagen, ich bin begeistert was sich damit alles machen lässt.

Ich werde es derzeit nutzen, mich bei Störungen anrufen zu lassen, mangels des sehr schlechten GSM-Empfangs in der Arbeit geht Pushover nicht, was nutzt mir, wenn ich 10 Meldungen aufs Handy bekomme, wenn ich endlich mal wieder Netzempfang habe. Ein Anruf kommt eher an und es gibt ja auch noch Festnetztelefone.

Habe mal das sehr gut dokumentierte Wiki zum SIP-Device gelesen und einiges getestet (ohne einen einzigen Fehler)  ,
da stellt sich mir schon die erste Frage.

Es gibt im Device die Möglichkeit einen Anruf ein einziges Mal abzusenden oder diesen mit dem Anhang "&" als wichtig zu kennzeichnen. Setze ich nun das Attribut sip_force auf z.B. 300, wird der Anruf endlos (alle 5 Minuten) wiederholt, bis dieser angenommen wird.

Gibt es irgend eine Möglichkeit anzugeben, wie oft ein Anrufversuch unternommen werden soll, wenn der Anruf nicht angenommen wird?

Hintergrund:
Ich will mich über einen internen Rundruf, über die Fritz!Box, vor bei Kälte zu lang geöffneten Fenster warnen lassen. Da kann es schon mal beim Staubsaugen vorkommen, dass der Anruf im Lärm untergeht.
Die nächste "Eskalationsstufe" wäre der Anhang "&", wenn ich dann Tagsüber bei milderen Temperaturen ein gekipptes Fenster vergesse zu schließen, steinigen mich die Nachbarn wegen Telefonterror, wenn ich abends heimkomme.
Schön wäre da die Angabe, bei Nichterreichbarkeit nur x mal zu klingeln.

Ich denke aber das wird sich mit der "at" lösung im Modul nur sehr schwer umsetzen lassen.
Wenn es hier keine Möglichkeit mit SIP gibt, könnte ich dies auch Fhem intern umsetzen, indem ich die Readings von SIP auswerte und entsprechend reagiere.

Ich will euch mal fragen, bevor ich mir hier unnötige Arbeit mache.
Grundsätzlich sind ja aufgrund von Faulheit die besten Erfindungen entstanden.

Gruß Reinhard

[Wzut]

Grundsätzlich sind ja aufgrund von Faulheit die besten Erfindungen entstanden.

OT on
Ich war früher in der Instandhaltung und da hatten wir den Spruch das ein guter Instandhalter grundsätzlich faul sein muß, denn dann kümmert er sich so um seine Anlagen das er möglichst viel seine Ruhe vor ihnen hat
OT off
Das Thema Force kam hier noch nicht oft vor, daher habe ich auch keine Ahnung wie und wie oft es überhaupt bei den Usern zum Einsatz kommt.
Generell ist die heutige Umsetzung für dein Sezenario dann nur bedingt geeignet. Aber wenn schon Force beschneiden dann richtig.
Ich könne mir vorstellen das von Fall zu Fall vom Call abhängig zu machen, also auch ggf. das sip_force Attribut mit zu überschreiben
Bsp:
set mySIP call **1 10 !Fenster ist offen 2 & <--- Das hätten wir heute
set mySIP call **1 10 !Fenster ist offen 2 &5 <--- Force beschränkt auf max. 5 Versuche
set mySIP call **1 10 !Fenster ist offen 2 &0,30 <--- die 30 überschreibt zusätzlich das Attribut sip_force, die  0 steht für unendliche Versuche

Ich muss mal schauen ob zwischen Weihnachten und Neujahr etwas Luft zum basteln ist.

[plin]

Eine selbstprogrammierte Schleife in FHEM könnte die Readings call_state und call_success nutzen.

@wzut: Ich denke für Force fehlt noch ein Reading call_attempt, damit man die Anzahl Versuche auswerten kann.

[Rewe2000]

Hallo,

@Wzut
OT on
Irgendwie habe ich mich mit dem letzten Beitrag geoutet und du hast mich durchschaut, ich arbeite tatsächlich seit über 40 Jahren als Instandhalter. Ist diese Berufsgruppe wirklich fauler als andere? Oder intelligenter, das sie notwendige Arbeiten anderen erledigen lässt.
OT off
Solch eine Funktion mit der Angabe der Rufversuche wäre natürlich toll, wenn sich so etwas umsetzen lassen würde. Sollte sich mit dem Rufbefehl auch gleich noch individuell die Dauer der Pausen zwischen den Rufen überschreiben lassen, so wäre dies eine absolute Komfortlösung.

Ein Punkt würde mich noch interessieren, wirst du wegen dem "leg => $ip" irgend etwas an deinem Modul ändern?
Oder muss ich nach jedem Update deines Moduls, diese Zeile wieder von Hand anpassen?
Ich werde mal im Homematic Board nachfragen, wer auch noch HMCCURPC und SIP auf einem RASPI mit Stretch verwendet, eigentlich sollte es ja hier auch die gleichen Probleme wie bei mir gegeben haben.

@plin
Ich denke auch, dass bei einem Umbau des Device ein Reading in der Form "call_attempt" nicht verkehrt wäre, somit könnte die Anzahl der Rufversuche erkannt und auch ausgewertet werden.

Probleme könnte es ggf. nur mit sehr kurz aufeinander folgenden Rufen (gestackten Rufen) geben, die Zuordnung von "call_attempt" zum dazugehörigen call wird da schon eine Herausforderung.

Schönen ersten Advent, Gruß
Reinhard

[Wzut]

ich fang mal hinten an :
call_attempt -> klingt gut, das kleine Problem ist nur das Modul hat keinerlei Gedächnis über bereits gelaufende Versuche. Ich habe das damals aus "Faulheit" ja simpel über das temporäre at gelöst statt über eine eigene Queue zu jedem Call. D.h es ginge heute nur über zusäzliche Parameter im Callstring die dann beim at define quasi mit hochgezählt werden. Ich bin z.Z.noch am überlegen.

leg => $ip  -> ja das habe ich schon vorbereitet   

[plin]

call_attempt -> klingt gut, das kleine Problem ist nur das Modul hat keinerlei Gedächnis über bereits gelaufende Versuche.

keep it simple - reading call_attempt beim neuen SET CALL auf 0 setzen. Dann bei jedem erneuten Versuch reading auslesen, eins drauf, wieder zurückschreiben??? Da nicht allzuviele Nutzer die Force-Option zu nutzen scheinen ist der weltweite Gesamt-Overhead durch diese Lösung gering 

[Wzut]

ja ja  keep it simple - Das Modul ist inzwischen alles andere als Simple ....
Das merke ich immer wieder wenn ich in den Code schaue und feststelle "Huch da hast ja schon mal dies und das gemacht" , hatte da gerade wieder so ein Ah Ha Erlebnis :
Laut Wiki hängt der User ja heute nur ein einfaches & an , das Modul macht aber daraus beim Temp at definieren bereits ein &300  ( wenn sip_force_interval keinen anderen Wert hat. )
D.h. schon heute ist es machbar das  sip_force_interval schon direkt zu ersetzen in dem man die Wiederholzeit einfach an das & direkt anhängt !
Auf der Basis habe ich jetzt einfach mal weitergemacht und wandele das einfache & nicht in &300 sondern in &300,99,0
Die 99 sind die maximal Anzahl an Versuchen, die 0 die bisherigen. Sobald die Anzahl der Versuche größer als max ist wird einfach kein neues Temp at erzeugt und der Spuck hat ein Ende.
Die 99 schrie natürlich förmlich nach einem neuen Attribut sip_force_max , dadurch kann die Anzahl global im Attribut festgelegt werden oder halt vom User nach Bedarf
Bsp set mySIP call **1 5 !Test &120,10 -> maximal 10 Versuche mit einer Frequenz von 2 Minuten

[plin]

so geht's natürlich auch