AttrTemplate.pm mach mein fhem träge

Begonnen von Invers, 12 März 2019, 10:32:47

Vorheriges Thema - Nächstes Thema

Invers

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.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

rudolfkoenig

Was sind "Seiten ohne Grafik"?
Kannst du bitte die Ausgabe von fheminfo hier anhaengen?


Tom111

Hallo,

ich habe genau das selbe Problem, jedoch auf allen Seiten auch ohne Diagramm:
https://forum.fhem.de/index.php/topic,98466.0.html
:-\
FHEM 5.9 auf Raspberry Pi - 3B+ - Stretch-5.10.88+ | CUL868 CC1101 - USB - Lite module - V3 FW 1.67
Fritz!Box 7490 OS 07.29 / Fritz!Dect200 / Fritz!Powerline 546E
FS20ST-4/ FS20 DI-5/ FS20LS/ FS20 PIRI-2-KU/ FS20 TFK/ FS20S4A/FS20 SU-3/FS20 S20-3
HMS100TF/FHT80TF-2/ASH2200/S300TH/MiLight-Bridge V

Invers

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
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

rudolfkoenig

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.

betateilchen

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
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Invers

Vielen Dank, wegen mir keinen Stress bitte.
Bei den Meisten wird es ja klaglos laufen, heult ja keiner.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Tom111

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
FHEM 5.9 auf Raspberry Pi - 3B+ - Stretch-5.10.88+ | CUL868 CC1101 - USB - Lite module - V3 FW 1.67
Fritz!Box 7490 OS 07.29 / Fritz!Dect200 / Fritz!Powerline 546E
FS20ST-4/ FS20 DI-5/ FS20LS/ FS20 PIRI-2-KU/ FS20 TFK/ FS20S4A/FS20 SU-3/FS20 S20-3
HMS100TF/FHT80TF-2/ASH2200/S300TH/MiLight-Bridge V

Jamo

#8
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
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

betateilchen

[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]
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

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...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Invers

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.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

Jamo

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.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

rudolfkoenig

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.

Jamo

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 "]) "
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

CoolTux

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

Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Autsch. Sorry. Das hatte ich nicht kommen sehen.
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

Jamo

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

CoolTux

Also rein vom diff der fhem.pl kann ich das Verhalten nicht verstehen. Es wurde jeweils nur eine weitere optionale Variable angefügt.
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

Beta-User

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 /;
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

Ein reload reicht grundsätzlich nicht, wenn sich die Signatur einer Funktion geändert hat.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

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.

Beta-User

Eben den Test gemacht: Scheint zu passen, auf die Schnelle keine Auffälligkeiten :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

binford6000

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

Beta-User

Die Dateien aus dem svn landen grundsätzlich immer erst kurz vor 8 Uhr im update. Einfach später nochmal wiederholen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Invers

Hi, vielen Dank für die Beseitigung der Bremse. Bei mir funktioniert alles wieder so, wie vorher. Also alles in Ordnung.
Pi3B+ mit SSD/ Bullseye | FB7590 AX | 12 x Dect200 | CUL433+868 | SDuino | HM-LAN | 3 x Heizung FHT + FKontakte | KeyMatic + 4 FB | HM Wandtaster 2-fach m. LED | 6 x Türkont. TFK-TI | HM-Bew.-Melder innen | 3 x Smoked. HM-SEC-SD-2

kkoeniger

Danke für die rasche Behebung - bei mir lädt FHEM jetzt auch wieder wie gewohnt schnell.
LG,
Karl

Tom111

auch bei mir läuft alles wieder in gewohnter Geschwindigkeit.  :)
Danke an Rudi!
FHEM 5.9 auf Raspberry Pi - 3B+ - Stretch-5.10.88+ | CUL868 CC1101 - USB - Lite module - V3 FW 1.67
Fritz!Box 7490 OS 07.29 / Fritz!Dect200 / Fritz!Powerline 546E
FS20ST-4/ FS20 DI-5/ FS20LS/ FS20 PIRI-2-KU/ FS20 TFK/ FS20S4A/FS20 SU-3/FS20 S20-3
HMS100TF/FHT80TF-2/ASH2200/S300TH/MiLight-Bridge V

chopsor

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)
Hier könnte Ihre Werbung stehen !

binford6000

Der lesefaule hat's jetzt tatsächlich auch geschafft  ::)
@alle Beteiligten: Danke fürs schnelle fixen!  :)

VG Sebastian

der-Lolo

Tausend Dank für den schnellen Fix..!

HansDampfHH

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
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

CoolTux

Für das Problem vielleicht lieber ein Thread im IT Forum auf machen und einen Link in diesen Thread setzen als erster Verdachtspunkt.
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

HansDampfHH

#36
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 :-(
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

CoolTux

Dann kannst Du als erstes stacktrace im gloabal Device an schalten und dann im Log schauen wenn Du schaltest.
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

HansDampfHH

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".

FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

CoolTux

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.
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

HansDampfHH

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.
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink