Fritzbox SIP Fehler: already a call active for target

Begonnen von Max_Schoen, 02 März 2020, 08:25:35

Vorheriges Thema - Nächstes Thema

Max_Schoen

Hallo,

ich automatisiere bei mir zuhause die Klingel über FHEM. Dazu habe ich einen Funkknopf der das Drücken der Klingel registriert und ein notify auslöst. Das notify macht ein "set SIP_GERÄT call ..." auf einen an der Fritzbox, die für das Hausnetzt zuständig ist, angemeldeten SIP Client. FHEM selbst läuft nicht auf der Fritzbox sondern auf einem eigenen Raspberry Pi.

Meistens funktioniert diese Schaltung sehr gut, aber ich habe immer wieder folgendes Problem: manchmal geht nach dem Betätigen der Klingel das ganze nicht mehr. Im Logfile befindet sich folgende Fehlermeldung: "there is already a call activ for target NUMMER_IM_HEIMNETZ" wobei NUMMER_IM_HEIMNETZ die Rufgruppe ist, die vom SIP Client angerufen werden soll, wenn geklingelt wird.

Es ist so, dass der Funkknopf in der Zeit in der man die Klingel drückt mehrfach auslöst und mehrfach den Call absetzt. Der erste Call geht dann aber normalerweise durch, während die anderen mit der selben Fehlermeldung abgewiesen werden. Wenn dieser erste Anruf dann aber vorbei ist geht es eigentlich wieder. Meine Vermutung ist, dass sich das manchmal aufhängt und dann eben gar nicht mehr geht.

Hat jemand ähnliche Erfahrungen gemacht und das Problem lösen können? Oder hat jemand auch einfach so eine Idee woran es liegt bzw. was ich dagegen machen kann?

Mit freundlichen Grüßen
Max

Wzut

a. falsches Forum , der Thread zum SIP Modul befindet sich hier : https://forum.fhem.de/index.php/topic,67443.0.html
b. dafür sorgen das eben keine Calls abgesetzt werden solange noch ein anderer aktiv ist, gerade bei Klingelknöpfen muss man unbedingt die Dinger entprellen bzw. die Strumklingler etwas im Zaum halten.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wernieman

Oder eben nur "1 Klingeln pro X Minute" zulassen ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Max_Schoen

Ok, tut mir leid, dass das im falschen Teil des Forums ist.

Habt ihr denn einen Vorschlag wie ich das machen könnte? Weil so Sachen wie mit einem Watchdog 5 Sekunden oder so warten klingt halt auch nicht sehr zuverlässig.

frank

wie wäre es mit attr disabledAfterTrigger beim notify?
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

und zusätzlich solltest du uns noch verraten wie genau dein set call ausschaut in Bezug auf den gesetzten Timeout.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Max_Schoen

disabledAfterTrigger habe ich beim notify schon eingestellt. Aber es kommt immer noch ca. 2-3 mal die Fehlermeldung.

Der Befehl ist einfach "set SIP_Client call NUMMER 30"

Wzut

und auf welchen Wert hast du disabledAfterTrigger  gesetzt ?
du lässt das Telefon stur 30 Sekunden durchklingeln bis zum Timeout ?
Keine Abbruch Kriterium ? oder hebst du irgendwann den Hörer ab ?

Was mich stutzig macht ist das es sich ab und an "erhängt".
Zitat von: Max_Schoen am 02 März 2020, 08:25:35
Der erste Call geht dann aber normalerweise durch, während die anderen mit der selben Fehlermeldung abgewiesen werden. Wenn dieser erste Anruf dann aber vorbei ist geht es eigentlich wieder.
da werde ich nicht ganz schlau draus , zum einen "normalerweise" d.h. es gibt auch abnormal ? und was machst du dann um wieder normal zu werden ?
Und was bedeutet "eigentlich wieder" ? gibt auch ein uneigentlich nicht ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

frank

vielleicht ist die regex vom notify "schlecht" und fängt sich manchmal etwas nicht gewolltes ein.

da könnte man zb eine logausgabe einbauen, die die trigger "sichtbar" 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

Max_Schoen

disabledAfterTrigger ist auf 60 gesetzt.

Ich hebe das Telefon normalerweise selber ab, es kann aber auch passieren, dass mal keiner ran geht und es 30 Sekunden lang durchläutet.

Das normalerweise und das eigentlich bezieht sich auf das "erhängen". Im Logfile sieht dann nichts anders aus, außer dass eben gar kein Anruf mehr geht (auch nicht wenn ich manuell set call mache). Die Nummer ist aber nicht blockiert, denn mit den physischen Geräten kann ich ganz normal die interne Nummer anrufen.

Zum "wieder normal werden" boote ich normalerweise den Raspberry Pi neu.

Würde mich sehr wundern, wenn das notify ungewolltes mit aufnimmt weil das Regex nur der Name vom jeweiligen Button des Funkknopfes ist (der hat insgesamt 4, von denen sind 2 benannt und auf die läuft jeweils das Regex für eine der beiden Klingeln). Beide Klingeln haben auch ein eigenes SIP Gerät in FHEM rufen aber die gleiche Nummer an. Wenn es sich "erhängt" dann gehen beide nicht mehr, egal welche Klingel es verursacht hat.

Wzut

OK, reboot ist zwar nicht schön aber dann liegt es vermutlich am SIP Modul selbst und nicht an der FB.
Mal schauen ob ich via Dauerfeuer das Problem nachstellen kann. Nur noch eine Info :
Welches Rasbian läuft auf deinem RasPI ? bzw welche Version von Net:: SIP ? 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wernieman

Die Frage wäre auch:
Wirklich reboot des PIs oder reicht reboot von FHEM?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Wzut

na schauen wir mal was ich herrausfinde :)
Ich verstehe halt nur nicht wenn das notify für 60 Sekunden weitere Calls blockt und ein Call maximal 30 Sekunden dauern kann wie es überhaupt dazu kommt das ständig versucht wird einen Ruf zu starten obwohl bereits einer aktiv ist. IMHO stimmt da etwas mit dem notify nicht, aber anyway das SIP Modul darf auch durch solche Aktionen nicht aus dem Tritt kommen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Max_Schoen

Auf dem Raspberry läuft jessie 8.0 und installiert ist Net::SIP 0.687.

Ich bin mir ehrlich gesagt gerade nicht sicher ob ein FHEM Neustart ausgereicht hat oder nicht. Wenn es das nächste mal auftritt probiere ich das auf jeden Fall aus.

Wzut

oha , noch so ein Old School Fan  ... da hast aber Glück das ich da mithalten kann :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher