Hallo,
seit dem 21.09. habe ich Probleme mit dem Ein- und Ausschalten meiner Ruflumleitung mittels 72_FRITZBOX.pm. Im Log steht:2018.10.19 20:25:34 3: FRITZBOX: set FB_Unten diversity 1 on
2018.10.19 20:25:34 4: FRITZBOX FB_Unten: TR064_Cmd.4301 Perform TR-064 call - service='X_AVM-DE_OnTel:1', control='x_contact', action='SetDeflectionEnable', parameter1='NewEnable' => '1', parameter2='NewDeflectionId' => '0'
2018.10.19 20:25:35 2: FRITZBOX FB_Unten: TR064_Cmd.4322 TR064-Error 402:Invalid Args (service='X_AVM-DE_OnTel:1', control='x_contact', action='SetDeflectionEnable', parameter1='NewEnable' => '1', parameter2='NewDeflectionId' => '0')
Erst jetzt ist mir aufgefallen, dass offensichtlich die Reihenfolge der Parameter nicht zu stimmen scheint.
Sollte es nicht eher in dieser Reiehfolge laufen?
(service='X_AVM-DE_OnTel:1', control='x_contact', action='SetDeflectionEnable', parameter1='NewDeflectionId' => '0', parameter2='NewEnable' => '1')
Kann es sich dabei um einen Fehler im Modul handeln?
Pappn
Versuch mal ohne Leerzeichen zwischen diversity und 1.
LG
Andreas
Leerzeichen ist Pflicht und entspricht auch der CommandRef.
Sonst kommt Please define diversity1 first
Kann es vielleicht mit der neuen Frimware der FB zu tun haben? Habe nämlich zum gleichen Zeitpunkt FritzOS 07.01 installiert.
Hast Recht, war ein Fehler bei mir. Funktioniert bei mir allerdings auch nur manchmal.
LG
Andreas
Wenn ich etwas Zeit zwischen den Schaltvorgängen lasse, funktioniert es. Zumindest wenn ich in der Kommandozeile
set MeinFritz diversity 1 on bzw. off
eingebe.
Das macht bei mir keinen Unterschied. Rufumleitung wird morgens, wenn ich gehe, eingeschaltet und dann Abends, wenn ich zurück komme, wieder ausgeschaltet. Das hat auch bis September prima und fehlerfrei funktioniert.
Was mich halt wirklich wundert ist, dass die Reihenfolge der Parameter für den Aufruf nicht stimmt, wenn ich mir das mit verbose 4 im log ansehe.....
Dann bin ich leider raus. Bei mir läuft es auf der 7590 mit FW 7.01
LG
Andreas
Hab gerade noch mal das log durchforstet.
Wie kann es sein, dass die Reihenfolge der Aufrufparameter einmal stimmt und dann nicht mehr?
2018.10.19 19:38:05 3: FRITZBOX: set FB_Unten diversity 1 on
2018.10.19 19:38:05 5: FRITZBOX FB_Unten: readPassword.4737 Read FritzBox password from file
2018.10.19 19:38:05 4: FRITZBOX FB_Unten: TR064_Cmd.4301 Perform TR-064 call - service='X_AVM-DE_OnTel:1', control='x_contact', action='SetDeflectionEnable', parameter1='NewDeflectionId' => '0', parameter2='NewEnable' => '1'
2018.10.19 19:38:53 3: FRITZBOX: set FB_Unten diversity 1 off
2018.10.19 19:38:53 4: FRITZBOX FB_Unten: TR064_Cmd.4301 Perform TR-064 call - service='X_AVM-DE_OnTel:1', control='x_contact', action='SetDeflectionEnable', parameter1='NewEnable' => '0', parameter2='NewDeflectionId' => '0'
2018.10.19 19:38:54 2: FRITZBOX FB_Unten: TR064_Cmd.4322 TR064-Error 402:Invalid Args (service='X_AVM-DE_OnTel:1', control='x_contact', action='SetDeflectionEnable', parameter1='NewEnable' => '0', parameter2='NewDeflectionId' => '0')
Einschalten ist OK mit richtiger Reihenfolge der Parameter
Perform TR-064 call - service='X_AVM-DE_OnTel:1', control='x_contact', action='SetDeflectionEnable', parameter1='NewDeflectionId' => '0', parameter2='NewEnable' => '1'
50 sec später wieder ausschalten Reihenfolger der Parameter vertauscht
Perform TR-064 call - service='X_AVM-DE_OnTel:1', control='x_contact', action='SetDeflectionEnable', parameter1='NewEnable' => '0', parameter2='NewDeflectionId' => '0'
mit entsprechender Fehlermeldung von der Fritzbox.
TR064-Error 402:Invalid Args (service='X_AVM-DE_OnTel:1', control='x_contact', action='SetDeflectionEnable', parameter1='NewEnable' => '0', parameter2='NewDeflectionId' => '0'
Habe jetzt auch noch mal hier gelesen: https://forum.fhem.de/index.php/topic,90106.0.html
Wenn ich nach demselben Muster die Befehle manuell absetzte funktioniert es.
RUL ein
get FB_Unten tr064Command X_AVM-DE_OnTel:1 x_contact SetDeflectionEnable NewEnable 1 NewDeflectionId 0
RUL aus
get FB_Unten tr064Command X_AVM-DE_OnTel:1 x_contact SetDeflectionEnable NewEnable 0 NewDeflectionId 0
Großes Fragezeichen
Interessanterweise lässt sich so auch die zweite RUL schalten, die mittels Modul nicht schaltbar ist, da nicht als Reading verfügbar.
Hallo zusammen.
Ich habe das Problem vermutlich auch auf einer 7490 mit FW 7.01. Da sich die FW gerade erst selbst installiert, hat es wohl was damit zu tun nehme ich an.
In geschätzt 25% der Fälle funktioniert es mit den beiden Befehlen von pappn, egal ob an oder aus.
Meist kommt aber
Service='X_AVM-DE_OnTel:1' Control='x_contact' Action='SetDeflectionEnable'
Parameter1='NewEnable' => '1'
Parameter2='NewDeflectionId' => '0'
----------------------------------------------------------------------
$VAR1 = {
'UPnPError' => {
'errorCode' => '402',
'errorDescription' => 'Invalid Args'
}
};
Hat jemand sonst schon was rausgefunden?
Vielen Dank und beste Grüße,
Andreas.
Bei mir funktioniert es leider auch nicht zuverlässig. Quote ist vielleicht etwas besser als 25% aber alles andere als zuverlässig.
Habe leider die gleichen Probleme mit der 7490. Gibt es schon Ideen?
Gruß,
SteRa
Wollte nochmal nachfragen.. Hat jemand schon eine Lösung?
Schöne Grüße,
SteRa
Ich benutze diese Funktion relativ selten, aber heute ist mir das gleiche Problem mit der FB7490 FW 7.01 aufgefallen:
2018.11.30 23:18:37.682 3: FRITZBOX: set Fritzbox diversity 1 on
2018.11.30 23:18:38.684 2: FRITZBOX Fritzbox: TR064_Cmd.4322 TR064-Error 402:Invalid Args (service='X_AVM-DE_OnTel:1', control='x_contact', action='SetDeflectionEnable', parameter1='NewEnable' => '1', parameter2='NewDeflectionId' => '0')
Nur in ca. 50% der Fälle wird der Befehl korrekt ausgeführt. Das scheint wohl ein grundsätzlicheres Problem zu sein.
Ja das ist echt schade. Benutze die Funktion sehr oft. Klingel ausschalten und automatisch Rufumleitung an. Dann schlafen die Kinder auch ruhig ein 8)
Überprüfe nun immer mit einem 3min Timer, ob die Zustände übereinstimmen, ansonsten schalte ich nochmal. Beim 2-3 Mal klappt es denn.
Gruß SteRa
Ich habe mir letztes Wochenende das FRITZBOX-Modul angeschaut. Mit ist aufgefallen, dass der Fehler nur dann auftritt, wenn die beiden Aufrufargumente für das Setzen der Rufumleitung 'NewDeflectionId' und 'NewEnable' der Action 'SetDeflectionEnable' in der Reihenfolge vertauscht werden. Die älteren Fritz!OS-Versionen konnten damit umgehen, seit v7 funktioniert der Aufruf nur in der Reihenfolge 'NewDeflectionId' und dann 'NewEnable' fehlerfrei. Der Grund, warum das FHEM-Modul die Argumente manchmal vertauscht, liegt darin, dass die Zeichenkette aus einem Hash zusammengebaut wird. Mit dieser Methode ist die Reihenfolge zufällig. Andererseits gibt die TR-064-Spezifikation keine Reihenfolge der Argumente vor.
Ich habe dann Anfang dieser Woche ein Ticket bei AVM aufgemacht. Vom Produktmanagement habe ich heute folgende Nachricht bekommen:
ZitatBei dem Verhalten handelt es sich in der Tat um einen ein Defect, der durch ein neues Feature im FRITZ!OS entstanden ist.
- der Code geht, davon aus, dass die Reihenfolge festgelegt ist.
- laut Spezifikation TR064 muss das aber nicht sein
Wir haben hierzu einen Defect angelegt. Es lässt sich Stand heute allerdings noch nicht sagen, wann es für die Fragestellung eine Lösung gibt. Erfahrungsgemäß wird diese in einer kommenden Laborversion umgesetzt.
Wer nicht solange auf die Lösung warten möchte, kann im aktuellen Modul 72_FRITZBOX.pm die Zeile 4296
von
foreach (keys %params) {auf
foreach (sort keys %params) {ändern.
Damit läuft bei mir die Rufumschaltung mit "set diviserty ..." wieder fehlerfrei.
Die Änderung sollte keine Auswirkungen auf andere TR-064-Kommandos haben. Dafür lege ich aber nicht meine Hände ins Feuer. Das kann der Betreuer des FRITZBOX-Modul wesentlich besser beurteilen. Vielleicht kann tupol als Maintainer dann die Änderung im Code übernehmen.
Viele Grüße
Das scheint sehr gut zu funktionieren. Danke für die Analyse und den Tip.
Hallo,
ich habe auch eine FB7490 mit FW 7.01 und ähnliche Probleme beim Aktivieren eines Portforwarding.
Eingetragen sind die Parameter laut Spezifikation AVM in der beschriebenen Reihenfolge. Trotzdem kommt am Ende Error 402, Invalid arguments.
Die Argumente stimmen aber, der Zugriff ist per TR064 möglich, weil andere Kommandos gehen.
Ideen?
Gruss
Habe ein neues Thema geöffnet:
https://forum.fhem.de/index.php/topic,95160.0.html
Zitat von: Romoker am 06 Dezember 2018, 20:42:15
Ich habe mir letztes Wochenende das FRITZBOX-Modul angeschaut. Mit ist aufgefallen, dass der Fehler nur dann auftritt, wenn die beiden Aufrufargumente für das Setzen der Rufumleitung 'NewDeflectionId' und 'NewEnable' der Action 'SetDeflectionEnable' in der Reihenfolge vertauscht werden. Die älteren Fritz!OS-Versionen konnten damit umgehen, seit v7 funktioniert der Aufruf nur in der Reihenfolge 'NewDeflectionId' und dann 'NewEnable' fehlerfrei. Der Grund, warum das FHEM-Modul die Argumente manchmal vertauscht, liegt darin, dass die Zeichenkette aus einem Hash zusammengebaut wird. Mit dieser Methode ist die Reihenfolge zufällig. Andererseits gibt die TR-064-Spezifikation keine Reihenfolge der Argumente vor.
Ich habe dann Anfang dieser Woche ein Ticket bei AVM aufgemacht. Vom Produktmanagement habe ich heute folgende Nachricht bekommen:
Wer nicht solange auf die Lösung warten möchte, kann im aktuellen Modul 72_FRITZBOX.pm die Zeile 4296
von
foreach (keys %params) {
auf
foreach (sort keys %params) {
ändern.
Damit läuft bei mir die Rufumschaltung mit "set diviserty ..." wieder fehlerfrei.
Die Änderung sollte keine Auswirkungen auf andere TR-064-Kommandos haben. Dafür lege ich aber nicht meine Hände ins Feuer. Das kann der Betreuer des FRITZBOX-Modul wesentlich besser beurteilen. Vielleicht kann tupol als Maintainer dann die Änderung im Code übernehmen.
Hallo Romoker,
ich hab das Modul 72_FRITZBOX.pm vom update in Fhem ausgeschlossen, da ich damals festgestellt habe, dass nach einem Fhem-update der Fehler wieder vorhanden war.
Wie stellt sich die Situation heute bei diesem Modul dar?
Viele Grüße Gisbert
ZitatWie stellt sich die Situation heute bei diesem Modul dar?
Es hat sich noch nichts geändert. Es gibt bisher keine Updates vom 72_FRITZBOX.pm oder vom Fritz-OS. AVM hat zwar den Fehler anerkannt, aber offen gelassen, wann er behoben wird. Es bleibt nichts anderes übrig als zu warten, bis die nächste Fritz-OS-Version (> v7.01) verfügbar ist und getestet werden kann.
Viele Grüße
Auf Fritzbox 7490 mit Labor 07.08-66226 BETA keine Probleme bei 5x Umschalten diversity on/off.
Grüße,
Norberto
Ich habe den gleichen Fehler bei meiner FB 6490 mit OS:7.10 und vorher 7.02. Nach dem Update funktionierte set diversity... für ca. 20 Minuten, danach erschien dieselbe Fehlermeldung wieder. Auch die "sort"-Ergänzung in der 72_FRITZBOX.pm brachte keine Verbesserung. Ich bin ratlos!
@longo
Für Dein beschriebenes Verhalten habe ich auch erstmal keine plausible Erklärung. Hast Du nach der Code-Änderung ein Reload des Moduls oder ein FHEM-Neustart durchgeführt?
Ich habe heute ein Update auf v7.11 für meine FB 4970 gemacht, meine sort-Änderung aus dem 72_FRITZBOX.pm Modul wieder herausgenommen und die diviserty-Funktion getestet. Das mehrfache Ein- und Ausschalten funktionierte immer korrekt. Ich gehe davon aus, dass der Fehler für meine FB in dieser FW-Version behoben wurde.
Viele Grüße
Ich habe mehrfache Neustarts von FHEM, raspi und FB durchgeführt - leider keine Veränderung. Nun habe ich das Fritzboxmodul deaktiviert. Jetzt ist endlich Ruhe im Log.
Grüße