Hi, ich habe nach dem Update bemerkt, dass mein fhem sehr träge die Seiten öffnet. Das wird durch das Modul
AttrTemplate.pm 18845 2019-03-10 11:32:58Z rudolfkoenig
ausgelöst. Spiele ich die Vorgängerversion wieder ein, läuft es wieder schnell.
Ich weiss nun nicht, was ich für eine Eingrenzung der Ursache tun könnte.
Ich vermute, dass es etwas mit den Diagrammen zu tun hat. Seiten ohne Grafik laufen problemlos.
Was könnte ich tun, um die Ursachenforschung zu unterstützen? Bin ich denn wirklich der Einzigste, der diese Probleme hat?
Ich könnte vorübergehend ein Update des Moduls verhindern.
Danke im Voraus für die Hilfe.
Was sind "Seiten ohne Grafik"?
Kannst du bitte die Ausgabe von fheminfo hier anhaengen?
Hallo,
ich habe genau das selbe Problem, jedoch auf allen Seiten auch ohne Diagramm:
https://forum.fhem.de/index.php/topic,98466.0.html (https://forum.fhem.de/index.php/topic,98466.0.html)
:-\
Seiten Ohne Grafik sind Seiten, die keine Diagramme enthalten und auch keine Farbauswahl-Grafik.
Seiten, die nur Icons als Grafik enthalten, sind kein Problem.
System Info
ConfigType: configDB
SVN rev: 15670
OS: linux
Perl: 5.24.1
uniqueId: 5d4...
Modules Model Count
AMADCommBridge 1
AMADDevice 5
Astro 1
CUL 2
CUL_FHTTK
FHT80TF-2 3
CUL_HM
CCU-FHEM 1
HM-RC-Key4-2 3
HM-RC-Key4-3 1
HM-PB-2-WM55-2 1
CUL_TCM97001 3
AURIOL 3
ABS700 1
TCM97... 5
Prologue 1
CUL_TX 7
DOIF
FHEM 120
DOIFtools 1
ENIGMA2
Quad Plus 1
FBAHAHTTP 1
FBDECT 12
FB_CALLLIST 1
FB_CALLMONITOR 1
FHEMWEB 3
FHT
fht80b 3
FLOORPLAN 4
FRITZBOX
FRITZ!Box 7490 1
FS20 2
FileLog 49
GCALVIEW 1
HMLAN 1
HMinfo 1
HTTPMOD 2
HUEBridge 1
HUEDevice 3
LLC010 3
IPCAM 2
IT 62
itswitch 3
itremote 1
MPD 1
MQTT2_DEVICE
A_01_tasmota_basic 2
A_01a_tasmota_basic_state_power1 1
MQTT2_SERVER 1
OREGON 1
PRESENCE
local-bluetooth 2
Pushbullet 1
SD_WS 1
SD_WS07 2
SIGNALduino 1
SIGNALduino_un 3
SIRD 1
STV 1
SVG 32
SYSMON 1
Siro 5
Text2Speech 1
Weather
DarkSkyAPI 1
WifiLight 2
XiaomiBTLESens
thermoHygroSens 2
flowerSens 1
XiaomiSmartHome 1
XiaomiSmartHome_Device
sensor_wleak.aq1 1
alexa 1
allowed 1
at 3
autocreate 1
cmdalias 9
configDB
SQLITE (b64) 1
dummy 50
eventTypes 1
freezemon 1
notify 7
readingsGroup 20
remotecontrol 2
structure 1
telnet 1
watchdog 14
weblink 10
Merke:
Eine Meldung wie "ich habe das gleiche Problem" hilft mir nicht, sie erzeugt hoechstens Stress.
Was hilft, sind die geforderten Ausgaben, HOWTOs zum Nachstellen, oder Patches.
Bitte AttrTemplate bis auf Weiteres aus dem restore zurueckkopieren, ich versuche bis morgen einen Fix zu erstellen.
Ich habe gerade ein Update eines meiner Testsysteme gemacht und kann keine Veränderung feststellen.
fhem.pl 18799 2019-03-05 20:27:15Z rudolfkoenig
90_at.pm 17561 2018-10-18 14:45:30Z rudolfkoenig
57_Calendar.pm 18712 2019-02-24 13:09:53Z betateilchen
98_cmdalias.pm 16300 2018-03-01 08:48:21Z rudolfkoenig
93_DbLog.pm 18787 2019-03-04 17:43:22Z DS_Starter
98_fheminfo.pm 18323 2019-01-18 19:37:39Z betateilchen
01_FHEMWEB.pm 18764 2019-03-01 08:59:38Z rudolfkoenig
92_FileLog.pm 18224 2019-01-12 18:48:47Z rudolfkoenig
95_holiday.pm 18112 2019-01-01 14:52:36Z rudolfkoenig
00_MQTT2_CLIENT.pm 18794 2019-03-05 10:56:08Z rudolfkoenig
10_MQTT2_DEVICE.pm 18803 2019-03-06 17:09:02Z rudolfkoenig
91_notify.pm 17225 2018-08-29 12:34:29Z rudolfkoenig
98_openweathermap.pm 14102 2017-04-25 10:54:58Z betateilchen
99_SUNRISE_EL.pm 18732 2019-02-25 13:15:34Z rudolfkoenig
98_SVG.pm 18777 2019-03-03 13:16:05Z rudolfkoenig
98_telnet.pm 17529 2018-10-14 12:57:06Z rudolfkoenig
99_Utils.pm 15713 2017-12-28 11:01:02Z rudolfkoenig
98_version.pm 15140 2017-09-26 09:20:09Z markusbloch
AttrTemplate.pm 18845 2019-03-10 11:32:58Z rudolfkoenig
Blocking.pm 17553 2018-10-17 15:56:35Z rudolfkoenig
configDB.pm 18614 2019-02-16 22:57:05Z betateilchen
DevIo.pm 18702 2019-02-23 15:10:58Z rudolfkoenig
HttpUtils.pm 17831 2018-11-24 15:09:17Z rudolfkoenig
myUtilsTemplate.pm 7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm 18197 2019-01-09 20:50:34Z rudolfkoenig
TcpServerUtils.pm 18528 2019-02-08 11:30:37Z rudolfkoenig
System Info
ConfigType: configDB
SVN rev: 18870
OS: linux
Perl: 5.24.1
uniqueId: aca...
Modules Model Count
Calendar 1
DbLog
SQLITE 1
FHEMWEB 1
FileLog 1
MQTT2_CLIENT 1
MQTT2_DEVICE 1
SVG 2
at 2
cmdalias 1
configDB
SQLITE (b64) 1
holiday 1
notify 2
openweathermap 1
telnet 1
Vielen Dank, wegen mir keinen Stress bitte.
Bei den Meisten wird es ja klaglos laufen, heult ja keiner.
Hier meine FHEM-Info:
System Info
ConfigType: configFile
SVN rev: 18870
OS: linux
Perl: 5.24.1
uniqueId: 6c3...
Modules Model Count
CUL 1
CUL_FHTTK
FHT80TF-2 4
CUL_WS
S300TH 2
ASH2200 4
DOIF
FHEM 46
FBAHAHTTP 1
FBDECT 1
Powerline546E 2
Dect200 7
FHEMWEB 1
FLOORPLAN 1
FS20 23
fs20su 3
dummySender 3
fs20di 1
FileLog 36
HMS
hms100-wd 1
hms100-tf 2
MilightBridge 1
MilightDevice 2
PRESENCE
lan-ping 26
RPI_GPIO 2
SVG 44
SYSMON 1
allowed 2
at 15
autocreate 1
dummy 43
eventTypes 1
notify 50
readingsGroup 1
structure 2
telnet 1
weblink 30
Hallo Rudolf,
bei mir ist der Seitenaufbau nach dem update heute morgen auch extrem träge geworden, teilweise 10-20 Sekunden, was vorher 1 oder 2 SekundenSekunde gedauert hat. Ich habe mal ein 'top' gemacht, und der perl Prozess beansprucht beim Raum-wechsel immer 100%. Ich habe eine ASUS Tinkerboard mit Linaro (Stretch).
Hier die FHEM INFO, hoffe es hilft:
System Info
ConfigType: configFile
SVN rev: 18870
OS: linux
Perl: 5.24.1
uniqueId: d36...
Modules Model Count
Astro 1
CO20 1
CUL_HM
HM-WDS30-OT2-SM 1
HM-Sen-MDIR-WM55 2
HM-ES-PMSw1-Pl 1
CCU-FHEM 1
HM-PB-6-WM55 4
HM-RC-Key4-2 3
HM-TC-IT-WM-W-EU 5
HM-Sen-RD-O 1
HM-ES-TX-WM 2
HM-RC-4-2 1
HM-CC-RT-DN 6
DOIF
Perl 1
FHEM 11
DOIFtools 1
DWD_OpenData 1
DWD_OpenData_Weblink 1
DbLog
SQLITE 1
Departure 1
EGPM 20
EGPM2LAN 5
ElectricityCalculator 1
FBAHAHTTP 1
FBDECT
Dect200 6
FB_CALLLIST 1
FB_CALLMONITOR 1
FHEMWEB 4
FRITZBOX 1
FRITZ!Box 7590 1
FileLog 2
GCALVIEW 1
GUEST 2
GasCalculator 1
HMCCU 1
HMCCUDEV 13
HMLAN 1
HMUARTLGW
HM-MOD-UART 3
HMinfo 1
HTTPMOD 5
HTTPSRV 2
HUEBridge 1
HUEDevice 11
LTW013 6
LTW012 2
LST002 4
Plug 01 2
LWB006 3
LWB010 1
LCT010 1
IPCAM 2
LightScene 1
MQTT 1
MQTT_DEVICE 1
MSGMail 1
Nmap 1
PRESENCE
lan-lepresenced 4
function 13
lan-bluetooth 5
PROPLANTA 1
Pushover 1
RESIDENTS 2
ROOMMATE 1
RainTMC 1
SIP 1
SONOS 1
SONOSPLAYER
Sonos_S1 5
Sonos_S12 1
Sonos_ZP120 1
SVG 40
Shelly
shelly1 1
TRAFFIC 1
TelegramBot 1
UWZ 1
Weather
OpenWeatherMapAPI 1
DarkSkyAPI 1
XiaomiBTLESens
flowerSens 13
XiaomiDevice 3
alexa 1
allowed 4
at 17
autocreate 1
average 3
cmdalias 16
co2mini 1
dash_dhcp 1
dewpoint 2
dummy 79
harmony 1
holiday 1
livetracking 1
logProxy 1
mailcheck 1
notify 209
readingsGroup 10
remotecontrol 1
sequence 12
statistics 1
structure 5
telnet 1
watchdog 22
weblink 15
[Vermutung]
Die Ursache ist nicht AttrTemplate.pm selbst, sondern eine Konfiguration in der FHEM Installation, in der mit vielen/komplexen Filtern gearbeitet wird.
Interessant finde ich, dass alle hier im Thread betroffenen Anwender devices vom Typ readingsgroup im Einsatz haben und eine Verzögerung feststellen. Bei mir wird readingsgroup grundsätzlich nicht verwendet und es gibt keine Verzögerung.
[/Vermutung]
Zitat von: betateilchen am 12 März 2019, 13:41:59
Die Ursache ist nicht AttrTemplate.pm selbst, sondern eine Konfiguration in der FHEM Installation, in der mit vielen/komplexen Filtern gearbeitet wird.
Nur um Sicherzugehen: Bei dem update wurde auch die mqtt2.template-file mit auf den Stand von heute morgen gebracht?
Da hatte ich gestern "ein paar" Filter reingebaut; nicht das die jetzt das eigentliche Problem sind (via setExtensions)...
Zitat von: rudolfkoenig am 12 März 2019, 10:59:48
Bitte AttrTemplate bis auf Weiteres aus dem restore zurueckkopieren, ich versuche bis morgen einen Fix zu erstellen.
Bitte dann auch um Info, was ich ggf. wieder an dem template-file ändern soll.
@all, die Probleme mit der Geschwindigkeit haben:
Bitte mal testen, ob es reicht, die mqtt2.template-file auf den vorigen Stand zurückzudrehen. (Die AttrTemplate.pm war vermutlich gestern schon im update, die Probleme wurden aber erst nach dem svn-update dieser template-file gemeldet...)
Nach nochmaliger Prüfung finde ich die Idee der Redainsgroup-Ursache trotz meiner mangelnden Kompetenz nicht schlecht. Meine betrroffenen Seiten enthalten nicht nur genannte Grafiken, sondern auch RGs. Da hatte ich nicht dran gedacht, wegen der Hue-Devices, deren Seite auch verzögert angezeigt wird. Allerdings stecken die auch in einer RG. Seiten ohne RG haben keine Verzögerung, allerdings bei mir leider auch keine Grafik. Floorplan geht hingegen mit allen Varianten zügig.
Ich kann das mit den Readingsgroups nicht bestätigen, ich habe jetzt mal alle Räume durchprobiert.
Gefühlt ist es da langsamer, wo ich viele 'devStateIcons' und 'webCmd' benutze.
Ich habe einen Raum 'Schalter', wo alle Schalter (Homematic/EGPMLAN/Dummy/HomematicIP/Shelly/ mit "attr devStateIcon off:ios-off:on on:ios-on-gree:off .*:noIcon" belegt sind, der dauert recht lange.
Auch der 'Lights' Raum, wo alle Hue Devices drin sind, die auch devStateIcon benutzten und auch webCmd mit ' on:off:pct:ct:ct 490:ct 380:ct 270:ct 160'
Mqtt2 benutzte ich nicht, wohl aber ein MQTT_Device.
Keine Ahnung ob das hilft, ich weiss auch nicht so genau, wonach ich suchen soll. Bis dahin.
Ich habe eine neue Version eingecheckt, bitte testen.
Die Aenderung von Vorgestern hat die direkte/einfache Internal-Pruefung beim Filtern des Templates durch devspec2array ersetzt, was eine Schleife ueber alle Geraete macht, und ein passend gefiltertes Array zurueckliefert. Leider wird dieser Aufruf von AttrTemplate einmal fuer alle Geraete, die potentiell AttrTemplate aufrufen (z.Bsp. alle mit SetExtensions) ausgefuehrt, und O(N^2) ist ein Problem fuer grosse Ns, wie die erwaehnten Installationen mit 350+ oder 650+ Geraeten, deswegen meine Frage nach fheminfo.
Ich habe einen Raum mit 1000 dummies (jeweils mit attr setList on off und attr useSetExtensions) erzeugt, und der Raum war nach 5 Minuten noch nicht zum Anzeigen fertig.
Ich habe devspec2Array mit einer optionalen initialList erweitert, was (falls vorhanden) statt die komplette Geraeteliste verwendet wird, damit sollte die Komplexitaet nur noch O(N) sein => mein Aufruf dauerte danach nur 3 Sekunden.
Hallo Rudi,
ich bekomme folgende Fehlermeldung nach einem 'reload AttrTemplate.pm':
Too many arguments for main::devspec2array at ./FHEM/AttrTemplate.pm line 81, near "]) "
Too many arguments for main::devspec2array at ./FHEM/AttrTemplate.pm line 102, near "]) "
Mach mal bitte ein Neustart
Zitat von: CoolTux am 12 März 2019, 20:00:16
Mach mal bitte ein Neustart
Bloß nicht!
Die Fehlermeldung von inoma hatte ich auch, daher habe ich FHEM neu gestartet. Praktisch alle Module, die intern setExtensions verwenden, werden nach diesen Fehlermeldungen nicht mehr geladen...
Autsch. Sorry. Das hatte ich nicht kommen sehen.
Habs nicht gemacht. Puh!
Also rein vom diff der fhem.pl kann ich das Verhalten nicht verstehen. Es wurde jeweils nur eine weitere optionale Variable angefügt.
Ich habe auch erst gedacht, das sei "nur" ein MySensors-Problem (da habe ich es als erstes gesehen bzw. das war das letzte, was im log stand), nur mit dem Quellcode in AttrTemplate in den betreffenden Zeilen wäre ich auch nicht darauf gekommen.
Da in MySensors an der Stelle schon länger was nicht ganz rund läuft, habe ich erst angefangen, dazu hier was zu tippen und erst danach "die ganze Freude" entdeckt...
10_MYSENSORS_DEVICE.pm "stirbt" in Zeile 70, da steht:
use SetExtensions qw/ :all /;
Ein reload reicht grundsätzlich nicht, wenn sich die Signatur einer Funktion geändert hat.
Zitat von: betateilchen am 12 März 2019, 20:21:56
Ein reload reicht grundsätzlich nicht, wenn sich die Signatur einer Funktion geändert hat.
Ein Neustart ist aber im Moment auch nur für ein Testsystem zu empfehlen ;) : Wie lang soll der logauszug bei einem Restart werden?
2019.03.12 19:42:51 1: reload: Error:Modul 33_readingsProxy deactivated:
Attempt to reload SetExtensions.pm aborted.
Compilation failed in require at ./FHEM/33_readingsProxy.pm line 26.
BEGIN failed--compilation aborted at ./FHEM/33_readingsProxy.pm line 26.
2019.03.12 19:42:51 0: Attempt to reload SetExtensions.pm aborted.
Compilation failed in require at ./FHEM/33_readingsProxy.pm line 26.
BEGIN failed--compilation aborted at ./FHEM/33_readingsProxy.pm line 26.
2019.03.12 19:42:51 1: reload: Error:Modul 14_CUL_TCM97001 deactivated:
Attempt to reload SetExtensions.pm aborted.
Compilation failed in require at ./FHEM/14_CUL_TCM97001.pm line 52.
BEGIN failed--compilation aborted at ./FHEM/14_CUL_TCM97001.pm line 52.
2019.03.12 19:42:51 0: Attempt to reload SetExtensions.pm aborted.
Compilation failed in require at ./FHEM/14_CUL_TCM97001.pm line 52.
BEGIN failed--compilation aborted at ./FHEM/14_CUL_TCM97001.pm line 52.
Auf die Schnelle noch betroffen dummy, MQTT2_DEVICE, MYSENSORS_DEVICE
Ich habe devspec2array in fhem.pl und AttrTemplate.pm geaendert.
Morgen ab 8 kann man update in fhem ausfuehren, und danach FHEM neu starten.
Solange muss man fhem.pl _und_ AttrTemplate.pm aus SVN auschecken, _und_ FHEM neu starten.
Wenn man nicht alle dieser Punkte durchfuehrt, dann kriegt man die hier beschriebenen Probleme.
Eben den Test gemacht: Scheint zu passen, auf die Schnelle keine Auffälligkeiten :) .
Moin Zusammen,
ich habe vorhin ein Update gemacht und leider noch das gleiche träge Verhalten :o
Hole fhem.pl und AttrTemplate.pm wieder aus dem Backup zurück...
VG Sebastian
Die Dateien aus dem svn landen grundsätzlich immer erst kurz vor 8 Uhr im update. Einfach später nochmal wiederholen...
Zitat von: binford6000 am 13 März 2019, 07:14:46
ich habe vorhin ein Update gemacht und leider noch das gleiche träge Verhalten :o
Wer lesen kann - und dies auch tut! - ist klar im Vorteil.
Zitat von: rudolfkoenig am 12 März 2019, 21:04:24
Morgen ab 8 kann man update in fhem ausfuehren, und danach FHEM neu starten.
Hi, vielen Dank für die Beseitigung der Bremse. Bei mir funktioniert alles wieder so, wie vorher. Also alles in Ordnung.
Danke für die rasche Behebung - bei mir lädt FHEM jetzt auch wieder wie gewohnt schnell.
auch bei mir läuft alles wieder in gewohnter Geschwindigkeit. :)
Danke an Rudi!
Hoi,
Ich bin immer wieder fasziniert, wie schnell eine "freizeitliche unendgeldliche Community" auf ein Problem reagiert im vergleich zu Konzernen mit teurem Support und Lizenzgewirrwar.
Danke für den schnellen Fix ! 8)
Der lesefaule hat's jetzt tatsächlich auch geschafft ::)
@alle Beteiligten: Danke fürs schnelle fixen! :)
VG Sebastian
Tausend Dank für den schnellen Fix..!
Ich bin mir nicht sicher, ob mein Problem die gleiche Ursache hat.
Aber wenn, ist es bei mir nach dem Update noch nicht besser geworden.
Wenn ich eine Lampe schalte (On über nanoCul 433), wird diese umgehend geschaltet (auch die Icon-Anzeige).
Beim Ausschalten habe ich aber nach wie vor extreme Verzögerungen. Das Schalten dauert ~4 Sekunden und das Icon springt nach 8 Sekunden um.
Das gleiche Verhalten betrifft alle Lampen/Steckdosen (davon habe ich 12 Stück).
Internals:
00 0
DEF 00111100110000000000001000 0 0100
FUUID 5c743f44-f33f-1bf5-8eb7-f6e3555c0ca5245b
IODev nanoCUL433
NAME SD.4
NR 815
STATE Aus
TYPE IT
XMIT 0011110011000000000000100000100
XMITdimdown 00
XMITdimup 00
XMITon 1
CODE:
1 0011110011000000000000100000100
READINGS:
2019-03-06 16:38:08 group 0
2019-03-06 16:38:08 protocol V3
2019-03-14 09:44:56 state off
2019-03-06 16:38:08 unit 0100
Attributes:
IODev nanoCUL433
ITrepetition 6
alias Steckdose 4 (Stehlampe)
automation Licht
devStateIcon An:general_an@green Aus:general_aus@red
eventMap on:An off:Aus
group Licht
icon ge_wht_steckdose
model itswitch
room Wohnzimmer
userattr automation room_map structexclude
Für das Problem vielleicht lieber ein Thread im IT Forum auf machen und einen Link in diesen Thread setzen als erster Verdachtspunkt.
Danke für den Hinweis, habe ich verlinkt.
Kleiner Zusatz:
Ich habe auch gerade festgestellt, dass das schalten auf OFF und der Delay von 8 Sekunden das Frontend komplett einfriert.
Erst nach "Umschalten" des Icons im Frontend ist dies wieder erreichbar. Mit dem Module Freezemon gibt es keinen "bad guy", somit leider keinen Hinweis für mich.
Freezemon: possible freeze starting at 10:52:03, delay is 10.776 possibly caused by: no bad guy found :-(
Dann kannst Du als erstes stacktrace im gloabal Device an schalten und dann im Log schauen wenn Du schaltest.
Okay, gemacht.
attr global stacktrace 1
Da wird aber im Log nach Schalten einer Steckdose kein Stacktrace geschrieben.
Freezemon merkt weiterhin den Delay von ~10 Sekunden an aber hat keinen "bad guy".
Dann stell mal bitte global verbose auf 5 und dann schalte mal. ACHTUNG! Danach gleich wieder verbose auf 3 stellen sonst wird Dein Logfile riesig.
Die Steckdose gehörte noch zu zwei Structures, die habe ich mal entfernt um ein "sauberes" minimales Device zu haben.
Das Delay ist verschwunden und damit auch der Zusammenhang zu AttrTemplate.pm.
Tut mir leid für den Aufwand, danke für Deine Hilfe CoolTux.
Ich recherchiere mal weiter, nun habe ich ja einen Anhaltspunkt.