Fritzbox - tr064Command userreadings blockieren FHEM

Begonnen von Jamo, 09 November 2019, 14:40:56

Vorheriges Thema - Nächstes Thema

Jamo

Ich hatte mich immer gewundert, warum mein FHEM manchmal so stockend läuft (e.g warum der Seitenaufbau mit dem Browser beim blättern durch die verschiedene Räume so langsam ist), der Google Browser hat dann manchmal für mehrere Sekunden lang 'gedreht'. Das war jetzt schon ein paar Jahre so, selbst nach Umzug auf potente Hardware. Ich dachte immer, dass es vielleicht am Sonos Modul liegt.

Nach langem suchen, habe ich in der Fritzbox dieses attribut 'attr userreadings' gefunden und gelöscht. Jetzt ist alles richtig gut, der Seitenaufbau läuft echt geschmeidig und alles ist rasend  schnell, auch nach einer Woche. Es hat also wirklich an diesem userreading gelegen, trotz event-on-change-reading, da die FB regelmässig mit dem 'attr INTERVAL' ein update macht.

Falls jemand anderes hier auch mit langsamen Seitenaufbau Probleme hat.

Die userreadings hatte ich übrigens aus dem FHEM Forum, ich kann den Thread aber jetzt nicht mehr finden. Und ob man die wirklich braucht?



defmod FritzBox FRITZBOX MEI.NE.I.P
attr FritzBox INTERVAL 60
attr FritzBox allowTR064Command 1
attr FritzBox devStateIcon 5.off:ios-off:wlan5+on 5.on:ios-on-green:wlan5+off 2.off:ios-off:wlan2.4+on 2.on:ios-on-green:wlan2.4+off Guest.off:ios-off:guestWlan+on Guest.on:ios-on-green:guestWlan+off
attr FritzBox event-on-change-reading gsm_internet,box_ipExtern
attr FritzBox forceTelnetConnection 0
attr FritzBox group SERVER
attr FritzBox room FritzBox,Favourites
attr FritzBox sortby 09
attr FritzBox stateFormat 5:box_wlan_5GHz 2:box_wlan_2.4GHz Guest:box_guestWlan
attr FritzBox userReadings
urMobilteil_1       {my $resp=fhem("get FritzBox tr064Command X_AVM-DE_OnTel:1 x_contact GetDECTHandsetInfo NewDectID 1",1);$resp =~/'NewHandsetName' => '(.*)'/;return $1;},
urDownstreamDSLRate {my $resp=fhem("get FritzBox tr064Command WANDSLInterfaceConfig:1 wandslifconfig1 GetInfo",1);$resp =~/'NewDownstreamCurrRate' => '(.*)'/;return $1;},
urUpstreamDSLRate   {my $resp=fhem("get FritzBox tr064Command WANDSLInterfaceConfig:1 wandslifconfig1 GetInfo",1);$resp =~/'NewUpstreamCurrRate' => '(.*)'/;return $1;},
DSL_internet        {my $resp=fhem("get FritzBox tr064Command WANIPConnection:1 wanipconnection1 getInfo",1);$resp =~/'NewConnectionStatus' => '(.*)'/;return $1;},
DSL_PPPLinkStatus   {my $resp=fhem("get FritzBox tr064Command WANPPPConnection:1 wanpppconn1 GetInfo",1);$resp =~/'NewConnectionStatus' => '(.*)'/;return $1;},
DSL_PPPLink_Uptime  {my $resp=fhem("get FritzBox tr064Command WANPPPConnection:1 wanpppconn1 GetInfo",1);$resp =~/'NewUptime' => '(.*)'/;return $1;},
DSL_Link_Status     {my $resp=fhem("get FritzBox tr064Command WANDSLLinkConfig:1 wandsllinkconfig1 GetInfo",1);$resp=~/'NewLinkStatus' => '(.*)'/;return $1;},
DSL_Link_Uptime     {my $resp=fhem("get FritzBox tr064Command WANPPPConnection:1 wanpppconn1 GetInfo",1);$resp =~/'NewUptime' => '(.*)'/;return $1;},
DSL_IF_Status       {my $resp=fhem("get FritzBox tr064Command WANDSLInterfaceConfig:1 wandslifconfig1 GetInfo",1);$resp =~/'NewStatus' => '(.*)'/;return $1;}
attr FritzBox verbose 0
attr FritzBox webCmd update:checkAPIs
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

JoWiemann

Hm, Du übernimmst ein userReading und weißt nicht wofür es ist? ,,Kopf schütteln"

Dann kannst Du es auch getrost löschen, da es nur ein AddOn ist und kein funktionaler Bestandteil.

Grüße Jörg


Gesendet von iPhone mit Tapatalk
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

CoolTux

Das userReading ist einfach nur schlecht angewendet. Es reagiert auf alle Events des Fritzboxdevices. Bei schlechter Event Konfig sind das 30 und mehr. Kein Wunder das da was blockiert.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Otto123

ich habe mal ein bisschen experimentiert. Einfach die zweite tr064 Zeile gegriffen -> meine FB7412 braucht dafür ca. 2 sec!
unnötigerweise werden 9 tr064 Aufrufe gemacht (5 hätten gereicht) -> 18 sec
Meine FB7412 liest 146 Werte pro Durchgang, wenn da event-on-change-reading nicht gesetzt ist wird 146 mal getriggert. Damit wäre FHEM 2628 sec beschäftigt. Per default steht das Interval auf 300 sec. Das userReading ist also ein Dauerläufer :)

Meine FB7490 ist nicht schneller, liefert aber 246 Werte :)
Selbst wenn nur ein paar Werte einen Event liefern und das Abfrageinterval auf 60 sec steht ist es ein Dauerläufer.

Also bitte: Nicht copy & paste machen!

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Jamo

Doch, event-on-change-reading war gesetzt, FHEM ist aber trotzdem stockend gelaufen.

Ich habe oben mal die komplette Definition ergänzt, wie gesagt ich hatte nur das userreading gelöscht. Deswegen verstehe ich es auch nicht, dass das aufgetreten ist trotz event-on-change-reading.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Otto123

#5
Ich verstehe es, du hast 2 Werte pro Runde (Intervall 60sec) damit ist dein FHEM 2636 sec pro Minute beschäftigt!
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

amenomade

#6
Na dann bleibt noch Puffer ;)

EDIT: übrigens, 2x18 = 36 :D
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Jamo

Gut, dann wurden alle userreadings (tr064 commands) bei jedem FB update getriggered, trotz event-on-change-reading. OK, da muss man erst mal drauf kommen. Danke für die Erklärungen.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

dora71

@Jamo:

Danke für den Hinweis. Den alten Thread kenne ich auch nicht mehr, aber auch ich hatte 2 von den userreadings in Benutzung und habe mich gewundert, alle 2 Minuten einen Freeze zu bekommen. Dabei brauche ich die Daten nicht mehr, seit das DSL bei uns hochgerüstet wurde  8)

Man sollte öfters aufräumen, nicht nur in der Wohnung  :D

Gruß Rainer


Jamo

#9
Ja, drei dieser userreadings stehen auch genau so im FHEM Fritzbox WIKI, https://wiki.fhem.de/wiki/FRITZBOX#userReadings_per_get_tr064Command_oder_get_luaQuery

Vielleicht sollte man das im WIKI erwähnen, das die im 'attr INTERVAL' blockierend sind.

Ich freu mich das es Dir auch geholfen hat. Gruss, Jamo

Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

amenomade

Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus