72_FRITZBOX: Sperren/Entsperren von Netzwerkgeräten / DECT Telefonen u weiteres

Begonnen von JoWiemann, 25 Januar 2021, 10:30:32

Vorheriges Thema - Nächstes Thema

RalfRog

Hi Jo zurück vom TelegramBot

Zitat von: JoWiemann am 03 April 2023, 13:33:43...
es sieht so aus, als wenn non Blocking in non Blocking nicht funktioniert. Bei mir bleibt Telnet ebenfalls hängen. WhatsApp und DebianMail funktionieren.

Kleine Anmerkung die "12a Beta" hatten wie letzte Woche schon.

Habe die Version auf das Testsystem gebracht. Folgendes habe ich im Log:

  • myUtilsFritzLogExPostnb in 99_myUtil eingebaut
      2023.04.03 20:12:04.986 2: FRITZBOX!0000 [fritzzbox: Lua_Data.5530] - INFO: data.lua not supportet. Fritz!Box or Fritz!OS outdated.
      2023.04.03 20:12:04.993 2: FRITZBOX!0000 [fritzzbox: Run_fritzloginfo.4020] - ERROR: fritzLogInfo: data.lua not supportet

  • dann ein Aufruf get <name> fritzLog hash sys off
    2023.04.03 20:14:04.061 2: FRITZBOX!0000 [fritzzbox: Lua_Data.5530] - INFO: data.lua not supportet. Fritz!Box or Fritz!OS outdated.
    2023.04.03 20:14:04.069 2: FRITZBOX!0000 [fritzzbox: Run_fritzloginfo.4020] - ERROR: fritzLogInfo: data.lua not supportet
    2023.04.03 20:14:04.140 3: FRITZBOX!0000 [fritzzbox: Set_Cmd_Done.3805] - DEBUG: fritzLog to Sub: sys
    {"Error":"data.lua not supportet","Info":"Fritz!Box or Fritz!OS outdated"}
    2023.04.03 20:14:04.145 2: ERROR: fritzLogInfo: data.lua not supportet

Sind die Meldungen relevant?

Habe mir den TelegramBot auf mein Testsystem "geklont" - er funktioniert.

  • Aufruf get <name> fritzLog hash sys off
       2023.04.03 21:45:32.498 2: FRITZBOX!0000 [fritzzbox: Lua_Data.5530] - INFO: data.lua not supportet. Fritz!Box or Fritz!OS outdated.
       2023.04.03 21:45:32.507 2: FRITZBOX!0000 [fritzzbox: Run_fritzloginfo.4020] - ERROR: fritzLogInfo: data.lua not supportet
       2023.04.03 21:45:32.583 3: FRITZBOX!0000 [fritzzbox: Set_Cmd_Done.3805] - DEBUG: fritzLog to Sub: sys
    {"Error":"data.lua not supportet","Info":"Fritz!Box or Fritz!OS outdated"}
       2023.04.03 21:45:32.587 2: ERROR: fritzLogInfo: data.lua not supportet

    Hier passiert nichts weiter und keine der beiden Subs wird aufgerufen sollte ja myUtilsFritzLogExPost sein


  • Aufruf get <name> fritzLog hash sys
       2023.04.03 21:50:02.615 2: FRITZBOX!0000 [fritzzbox: Lua_Data.5530] - INFO: data.lua not supportet. Fritz!Box or Fritz!OS outdated.
       2023.04.03 21:50:02.623 2: FRITZBOX!0000 [fritzzbox: Run_fritzloginfo.4020] - ERROR: fritzLogInfo: data.lua not supportet
       2023.04.03 21:50:02.634 4: TelegramBot_Set teleBot: Processing TelegramBot_Set( message )
       ....

    Hier geht es in die myUtilsFritzLogExPostnb, die aber wie schon bekannt nicht zu Ende bearbeitet wird




FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

Elektrolurch

Seit dem letzen Update hat wohl meine 7390 ein sporadisches Zugriffsproblem:
2023.04.03 14:33:11 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 2158081
2023.04.03 14:33:11 1: FRITZBOX!7390 [fritzbox: Readout_Aborted.3477] - INFO: Error: Timeout when reading Fritz!Box data.
2023.04.03 15:33:11 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 2162134
2023.04.03 15:33:11 1: FRITZBOX!7390 [fritzbox: Readout_Aborted.3477] - INFO: Error: Timeout when reading Fritz!Box data.
2023.04.03 16:03:11 1: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 2164121

Dabei hatte ich um ca. 10:00 Uhr einen Neutstart nach dem Update durchgeführt und habe quasi für ca. 5 Stunden keine Fehlermeldung erhalten.
Kann man die "Toleranzzeit" für den asynchronen Prozess des Auslesens der Daten der FB erhöhren?


Internals:
Internals:
   APICHECKED 1
   DEF        192.168.1.254
   FUUID      640994c4-f33f-c8c3-897f-bc1e0e67b23f9826
   HOST       192.168.1.254
   INFO       The support for telnet and operation on a Fritz!Box has been discontinued. The functions are disabled.
   INFO2      The following attributes are not longer supported:
useGuiHack, ringWithIntern, defaultCallerName, allowTR064Command,
forceTelnetConnection, telnetUser, telnetTimeOut
Use deleteattr to delete from Attributes.
   INTERVAL   900
   LUADATA    1
   LUAQUERY   1
   M3U_LOCAL  ./www/images/fritzbox.m3u
   M3U_URL    http://192.168.1.16:8085/fhem/www/images/fritzbox.m3u
   MODEL      FRITZ!Box Fon WLAN 7390
   NAME       fritzbox
   NR         918
   SECPORT    49443
   STATE      WLAN: ein gWLAN: aus
   TR064      1
   TYPE       FRITZBOX
   UPNP       non-emu
   VERSION    07.50.12
   eventCount 58
   OLDREADINGS:
   READINGS:
     2023-04-03 22:03:09   box_cpuTemp     0
     2023-04-03 22:03:09   box_dect        on
     2023-04-03 22:03:09   box_dsl_downStream 22.439
     2023-04-03 22:03:09   box_dsl_upStream 11.136
     2023-04-03 22:03:09   box_fon_LogNewest 78 02.04.23 20:33:58
     2023-04-03 22:03:09   box_fwVersion   84.06.87
     2023-04-03 22:03:09   box_guestWlan   off
     2023-04-03 22:03:09   box_guestWlanCount 0
     2023-04-03 22:03:09   box_guestWlanRemain 0
     2023-04-03 22:03:09   box_macFilter_active off
     2023-04-03 09:17:07   box_model       FRITZ!Box Fon WLAN 7390 [avm]
     2023-04-03 22:03:09   box_moh         default
     2023-04-03 22:03:09   box_powerRate   46
     2023-04-03 22:03:09   box_rateDown    2.335
     2023-04-03 22:03:09   box_rateUp      0.790
     2023-04-03 22:03:09   box_stdDialPort allFons
     2023-04-03 22:03:09   box_sys_LogNewest 504 03.04.23 22:02:56
     2023-04-03 22:03:09   box_tr064       on
     2023-04-03 22:03:09   box_tr069       off
     2023-04-03 22:03:09   box_upnp        non-emu....


Was könnte  da schief laufen?

Elektrolurch

configDB und Windows befreite Zone!

RalfRog

Zitat von: RalfRog am 03 April 2023, 21:52:40...
  2023.04.03 21:50:02.623 2: FRITZBOX!0000 [fritzzbox: Run_fritzloginfo.4020] - ERROR: fritzLogInfo: data.lua not supportet
  2023.04.03 21:50:02.634 4: TelegramBot_Set teleBot: Processing TelegramBot_Set( message )
  ....

Ich mach morgen nochmal....
Bei disable = 1 ist "data.lua not supportet". War irgenwie zuviel heute  ???
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

LuckyDay

Zitat von: Elektrolurch am 03 April 2023, 22:09:342023-04-03 22:03:09  box_dsl_downStream 22.439
    2023-04-03 22:03:09  box_dsl_upStream 11.136

die 7390 hat das aller schlechteste Vdsl Modem das AVM jemals verkauft hat.
geh dir eine 7530 ohne AX kaufen, die ist vom Umfang gleichwertig.
und Firmware aktuell.

JoWiemann

Zitat von: Elektrolurch am 03 April 2023, 22:09:34Seit dem letzen Update hat wohl meine 7390 ein sporadisches Zugriffsproblem:
Dabei hatte ich um ca. 10:00 Uhr einen Neutstart nach dem Update durchgeführt und habe quasi für ca. 5 Stunden keine Fehlermeldung erhalten.
Kann man die "Toleranzzeit" für den asynchronen Prozess des Auslesens der Daten der FB erhöhren?

Was könnte  da schief laufen?

Elektrolurch


Hallo Elektrolurch,

mir ist das gestern bei meiner 7272 mit Fritz!OS 6.88 auch aufgefallen. Zwei Tage nichts im Log gesehen und gestern dann zwei Einträge. Danach nichts mehr. Ich muss mir das in Ruhe mal ansehen.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

JoWiemann

Zitat von: RalfRog am 04 April 2023, 00:33:25Bei disable = 1 ist "data.lua not supportet". War irgenwie zuviel heute  ???

Das ist ein guter Hinweis. Das schaue ich mir mal an.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

JoWiemann

Zitat von: RalfRog am 04 April 2023, 00:33:25Ich mach morgen nochmal....
Bei disable = 1 ist "data.lua not supportet". War irgenwie zuviel heute  ???

Hallo Ralf,

wenn Du mit disable das Modul hoch fährst, findet kein API-Check statt. Somit weiß das Modul noch nicht, was die FritzBox kann. Rufst Du nun fritzLog auf kommt es zu den Hinweisen. Ich muss mal überlegen, ob ich den API-Check noch laufen lasse und dann auf das disable prüfen, um nur den Automatismus anzuhalten. Aktuell ist das seit Ewigkeiten so.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

JoWiemann

Hallo Ralf, hallo Elektrolurch,

im Anhang eine neue Beta: 07.50.13a BETA

- das handling von disable habe ich überarbeitet.
- neues Attribut nonblockingTimeOut <50|75|100|125> mit dem das Timeout für das Intervall holen der Daten von der FritzBox verändert werden kann.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

RalfRog

Zitat von: JoWiemann am 04 April 2023, 12:08:25- das handling von disable habe ich überarbeitet.
Ist ja eigentlich ein Sonderfall wegen der ganzen Testerei auf dem Testsystem um die Logeinträge schön geordnet zu bekommen.


Zitat von: JoWiemann am 04 April 2023, 12:08:25- neues Attribut nonblockingTimeOut <50|75|100|125> mit dem das Timeout für das Intervall holen der Daten von der FritzBox verändert werden kann.
Interessant. Sind das Sekunden (Minuten?).
Reduzierst Du dadurch die Datenmenge aus dem Log durch seltenere Abfragen? Würde sich dann auf die *Newest-Readings auswirken,korrekt? Das ist ok!


TelegramBot

Hatte einen kurzen Test und die Meldung ist angekommen  ;)

Wenn bisher nur ich mit der Sub bzw. "get Log" arbeite (sehr wahrscheinlich, da keine Rückfragen) gibt es kein Problem. Wenn man den Beitrag nicht komplett verfolgt fällt man eventuell darauf rein, dass der Aufruf (wenn man off weglässt) nun eine andere Sub aufruft die ggfs. noch nicht existiert.

Ich werde es bei Finalisierung dann auch in den Codeschnipseln korrigieren.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

JoWiemann

Zitat von: RalfRog am 04 April 2023, 12:26:33Ist ja eigentlich ein Sonderfall wegen der ganzen Testerei auf dem Testsystem um die Logeinträge schön geordnet zu bekommen.

Nicht ganz. Das war einfach nicht mehr konsequent durch dekliniert.

Zitat von: RalfRog am 04 April 2023, 12:26:33Interessant. Sind das Sekunden (Minuten?).
Reduzierst Du dadurch die Datenmenge aus dem Log durch seltenere Abfragen? Würde sich dann auf die *Newest-Readings auswirken,korrekt? Das ist ok!

Es ist die Zeit in Sekunden in der der non Blocking Prozess für die regelmäßige Abfrage der FritzBox Daten fertig werden muss. Überschreitet er diese Zeit, wird er abgebrochen. Dieses Timeout gilt nur für das durch INTERVAL gesteuerte regelmäßige Update.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

JoWiemann

Zitat von: JoWiemann am 04 April 2023, 12:08:25Hallo Ralf, hallo Elektrolurch,

im Anhang eine neue Beta: 07.50.13a BETA

Es gibt ja Sachen, die seit Ewigkeiten nicht aufgefallen sind. Hier, dass Löschen des Attributs INTERVAL. Wirkte immer erst mit Neustart.

Anbei eine neue Beta: 07.50.13b BETA bei der ich das gefixt habe.

Ich habe bei meiner 7272 das nonblockingTimeOut auf 75 gesetzt. Bis jetzt keine Log Einträge. Mal sehen.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

RalfRog

Zitat von: JoWiemann am 04 April 2023, 15:44:28im Anhang eine neue Beta: 07.50.13a BETA

Ich habe bei meiner 7272 das nonblockingTimeOut auf 75 gesetzt. Bis jetzt keine Log Einträge. Mal sehen.

Ein Glück, dass ich noch nicht mit der 13a probiert habe  ;)


Wenn für die Hänger die Abfrage der Logs innerhalb der INTERVALL-Zeit verantwortlich ist - ohne wäre für mich nicht wirklich tragisch.
Die bei jedem Abfrge-Inervall aktualisierten *Newest sind ne tolle Sache (auch als Trigger für DOIF/NOTIFY) aber eine per AT aufgerufene "mannuelle" Abfrage tut es auch. Hauptsache der Hash (ggfs. Array) ist da  8)
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

RalfRog

VERSION  07.50.13b BETA

Schönheitsfehler im Log unmittelbar nach Aktivierung durch disable = 0
2023.04.04 16:26:00.868 1: PERL WARNING: Use of uninitialized value $list in concatenation (.) or string at ./FHEM/72_FRITZBOX.pm line 1468.

  • Im Vergleich VERSION  07.50.10 (Intervall ändert sich nicht) tut es das in VERSION  07.50.13b BETA jetzt  :)

  • Bei mir braucht der get fritzLog sys knapp 20 Sekunden. Ich denke da brauch ich das Attribut nonblockingTimeOut nicht testen.


  • Test mit Aufruf des TelegramBot aus sub myUtilsFritzLogExPost sehen auch gut aus.  :)
    Kämpfe mit einem Sekundärproblem Umlaute in HTTPUTILS (hattest du auch mitgelesen) ???

Edit:
Habe es zwar nicht verstanden aber zumindest ne leichte Ahnung --> das Attribut utf8Special 0 / 1 im TelegramBot hilft (https://forum.fhem.de/index.php?msg=1256479)
Meldungen mit Umlauten werden jetzt ohne Fehlermeldung verschickt. Da kommen im FritzBox-Log ja einige vor.


FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

JoWiemann

Zitat von: RalfRog am 04 April 2023, 17:40:48VERSION  07.50.13b BETA

Schönheitsfehler im Log unmittelbar nach Aktivierung durch disable = 0
2023.04.04 16:26:00.868 1: PERL WARNING: Use of uninitialized value $list in concatenation (.) or string at ./FHEM/72_FRITZBOX.pm line 1468.

Habe ich gefixed. Meine 7272 ist mit 75 Sekunden weiterhin unauffällig. Damit wären dann auch ältere und langsamere FB's mit den Erweiterungen abgedeckt.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

RalfRog

Hi Jörg
Wenn ein altes nicht mehr unterstütztes Attribut (fritzBoxIP) in der fhem.cfg gesetzt war hattest du INFO3 eingeblendet.
Nach dem Löschen verschwindet die Info3.

Soll das bei der Info2 auch so sein? Alle dort aufgeführten Attribute habe ich nicht. INFO2 bleibt.

Kein Problem nur ne Frage wie du es dir gedacht hattest.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder