72_FRITZBOX.pm ab Version 08.00.00

[JoWiemann]

Hallo,

ich habe die neue Version 08.03.01 ins SVN hochgeladen. Morgen dann mit dem Update.

Danke an alle Tester.

Grüße Jörg

[frank]

ich habe die neue Version 08.03.01 ins SVN hochgeladen.

die neuen readingnamen sind zumindestens besser und funktionieren auch, danke.

[DonJuan]

Moin Jörg,
Moin Jamo,

danke für eure Beiträge. Ich hatte bisher immer WLAN und Gast-Wlan direkt hinter einander geschaltet. Vermutlich sind mir nur dann keine Meldungen im Log aufgefallen. Auch der Zusammenhang von Gast-WLAN aus ? WLAN aus ist mir so nie bewusst gewesen.
Aber egal. Ich habe nun 10 Sek. Verzögerung und es funktioniert.

Trotzdem danke ich euch für die ganzen Infos.

Gruss Dennis

[caldir65]

Moin,

was soll mit diesem Eintrag bzw. der auslösenden Routine bewirkt werden?

Code Auswählen Erweitern

2025.05.04 20:33:52.070 3: [Shelly_Set:startTimer] ShellyPlusPlugS_Buero_NAS: (Re-)Starting cyclic timers: status-timer=60
2025.05.04 20:34:55.229 3: (Shelly_HttpResponse:err) calling Shelly_Set for restarting timer(s) caused by network-error of device ShellyPlusPlugS_Buero_NAS
Anscheinend verhalten sich alte Gen1-Geräte dabei anders (PlugS z,B. geht ggf. aus und dann an), als neuere Geräte (PlusPlugS geht anscheinend nur aus)

Modul-Version 72_FRITZBOX.pm:0.298340/2025-04-08

Gruß, Christoph

[RalfRog]

Hi Christoph
Geht es um die FritzBox oder um Shelly?

 

[JoWiemann]

Hallo,

in der Diskussion https://forum.fhem.de/index.php?msg=1343430 ist ein Fehler im FritzBox-Modul bei der Ermittlung der IP Adressen für die Cable Boxen festgestellt worden. Noch weiß ich nicht, ob AVM etwas in der TR064 geändert hat, oder ob es immer schon ein Fehler im Code war. Bin ich aktuell auf der Suche.

Grüße Jörg

[passibe]

Hab mir mal den Code angeschaut – wieso benutzt man da eigentlich diese SOAP-Geschichte? Man kriegt die Werte doch auch alle ganz normal per TR069.

Ansonsten ist mir aufgefallen, dass da überall WANIPConn1 steht, richtig wäre aber WANIPConnection1, siehe hier.

Naja, ich habe das jetzt jedenfalls mal auf TR069 umgestellt, siehe .patch/.pm anbei. Das ist aber jetzt ziemlich "gebutchered":
1. Ich habe die ganzen IPv6 Sachen rausgeschmissen, weil ich die mit meiner Box nicht testen kann.
2. Das box_ipv4_Extern-Reading zeigt jetzt natürlich meine IPv6 GUA an, weil da NewExternalIPAddress abgefragt wird, was bei mir aber eine IPv6 ist. Das Modul geht aber in der aktuellen Form immer davon aus, dass es bei NewExternalIPAddress nur IPv4 geben kann.
Ist also insgesamt nur ein proof of concept.

Zeigt aber, dass man auf diese ganze SOAP-Sache verzichten kann.
Folgende Readings, die ich vorher nicht hatte, habe ich jetzt: box_ipv4_Extern, box_connection_Type, box_connect, box_last_connect_err, box_last_auth_err, box_mac_Address, box_uptimeConnect und box_wan_AccessType.

[JoWiemann]

Hallo passibe,

danke für den Patch. Schaue ich mir an und werde das mal mit meinem FritzBox Zoo testen.

Grüße Jörg

[JoWiemann]

Hallo passibe,

warum hast Du eigentlich in Deinem Patch die weiteren SOAP Abfragen nach der Kommentarzeile:

Code Auswählen Erweitern

       # box_ipv6 ->  NewPreferedLifetime, NewExternalIPv6Address, NewValidLifetime, NewPrefixLengthentfernt?

Grüße Jörg

[passibe]

Weil bei mir alle SOAP-Abfragen einen 500er generiert haben und weil es bei mir diese

Code Auswählen Erweitern

NewPreferedLifetime, NewExternalIPv6Address, NewValidLifetime, NewPrefixLengthstateVariables (heißt das so?) nicht gibt. Sonst hätte ich das auch auf TR-064 umgestellt.

Sieht bei mir dann so aus:

Code Auswählen Erweitern

get <NAME> tr064Command WANIPConnection:1 wanipconnection1 X_AVM_DE_GetExternalIPv6Address
---
$VAR1 = {
          'UPnPError' => {
                           'errorCode' => '401',
                           'errorDescription' => 'Invalid Action'
                         }
        };
Ich hänge dir mal die relevanten XML-Dateien an.
Bei VF im Ex-Unitymedia/Kabel-Bw-Gebiet scheint es einfach nicht möglich zu sein, den IPv6-Prefix, usw. per TR-064 auszulesen, jedenfalls mit der Mietbox. Kann natürlich sein, dass das mit einer gekauften Box wieder anders ist.

[juemuc]

Hallo zusammen,

auch bei einer gekauften FB6690 liefert der Befehl

Code Auswählen Erweitern

get <NAME> tr064Command WANIPConnection:1 wanipconnection1 X_AVM_DE_GetExternalIPv6Addressnur

Code Auswählen Erweitern

Service='WANIPConnection:1'   Control='wanipconnection1'   Action='X_AVM_DE_GetExternalIPv6Address'
----------------------------------------------------------------------
{
  'UPnPError' => {
                   'errorDescription' => 'Invalid Action',
                   'errorCode' => '401'
                 }
}

Viele Grüße
Jürgen

[RalfRog]

Hi
Auf meiner 7590 (fw 154.08.03) ebenfalls mit Vodafone DSLite:

Code Auswählen Erweitern

Service='WANIPConnection:1'   Control='wanipconnection1'   Action='X_AVM_DE_GetExternalIPv6Address'
----------------------------------------------------------------------
$VAR1 = {
          'UPnPError' => {
                           'errorDescription' => 'Invalid Action',
                           'errorCode' => '401'
                         }
        };
Gruß Ralf

Edit:
Die Readings:

Code Auswählen Erweitern

box_ipv4_Extern   2a00:1e:8682:bxy0:dx34:1y0b:z069:b3xc   2025-06-23 16:06:19
box_ipv6_Extern   2a00:1e:8682:bxy0:dx34:1y0b:z069:b3xc   2025-06-23 16:06:19
box_ipv6_Prefix    2a00:1e:8682:bxy00::
Modul nicht ganz aktuell glaub ich =>    08.03.01

[JoWiemann]

Hallo,

die Ermittlung über X_AVM_DE_GetExternalIPv6Address läuft nicht über: get <name> tr064Command

Die get-Funktion ruf über die Sub FRITZBOX_call_TR064_Cmd den SOAP-Request: upnp/control auf.

Für X_AVM_DE_GetExternalIPv6Address muss der SOAP-Request: igdupnp/control/ genutzt werden. Deswegen erfolgt die SOAP Abfrage auch nicht über die Sub FRITZBOX_call_TR064_Cmd. Somit könnt das also so nicht testen. Außerdem ist die ServiceId WANIPConn1 und nicht wanipconnection1.

Solange ihr die Readings:

Code Auswählen Erweitern

box_ipv4_Extern   2a00:1e:8682:bxy0:dx34:1y0b:z069:b3xc   2025-06-23 16:06:19
box_ipv6_Extern   2a00:1e:8682:bxy0:dx34:1y0b:z069:b3xc   2025-06-23 16:06:19
box_ipv6_Prefix    2a00:1e:8682:bxy00::
habt, funktioniert der Aufruf.

@passibe: Was bekommst Du denn bei http://IP-FB:49000/igddesc.xml bzw http://IP-FB:49000/igdconnSCPD.xml

Grüße Jörg

[passibe]

Ah! Ok, verstehe!

Da liegt auch das Problem: Ich hatte unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen "Statusinformationen über UPnP übertragen" deaktiviert. Als ich das nicht aktiviert hatte, hab ich bei igddesc.xml einen 404 zurückgekriegt (wobei igdconnSCPD.xml funktioniert hat).
Nachdem ich es aktiviert habe, geht igddesc.xml problemlos.

Hab das Modul jetzt auf die "normale" Version umgestellt und kriege alle Readings, außer box_connection_Type, box_last_auth_err und box_mac_Address, die aber soweit ich sehe, ohnehin nur bei WANPPPConnection abgefragt werden.

Dann war das hier wohl ein klassischer Anwenderfehler Also großes sorry für die ganze Verwirrung!

Vielleicht lohnt es sich ja, im Wiki darauf hinzuweisen, dass "Statusinformationen über UPnP übertragen" aktiviert sein muss?

[JoWiemann]

Hallo passibe,

danke für das Erforschen. Da habe ich nicht aufgepasst. Ich prüfe ja, ob UPNP aktiviert ist. Werde nun die Abfrage für igddesc Services/Actions entsprechend abgrenzen. In der Liste der Readings in der commandRef kommt dann ein entsprechender Hinweis.

Grüße Jörg