Verzögerungen in der WEB-Oberfläche durch MAXLAN?

[Harald]

Hallo zusammen,

ich habe seit einiger Zeit (4-6Wochen?) das Problem, dass manchmal das Aufrufen einer neuen Seite in der Weboberfäche sehr lange dauert. Die Reaktionszeiten schwanken von wenigen Sekunden bis zu einigen Minuten. Zu anderen Zeiten geht das Umschalten blitzschnell.
Nun habe ich das Modul 99_perfmon aktiviert und gefunden, dass anscheinend ein Zusammenhang mit MAXLAN besteht.
Allein die Summe der unteren 8 Zeilen beträgt > 1 Minute!

Code Auswählen Erweitern

2014.01.20 16:07:58 3: [Bad] MaxScanRun.430 sdNextScan:2014-01-20 16:07:57 strDesiTime:2014-01-20 16:07:57
2014.01.20 16:07:58 3: [Bad] MaxScanRun.444 TYPE:MAXLAN IOName:MAXLAN
2014.01.20 16:07:58 3: Opening MAXLAN device 192.168.0.222:62910
2014.01.20 16:07:58 3: MAXLAN device opened
2014.01.20 16:08:02 3: [Bad] MaxScanRun.740 <<set Bad desiredTemperature auto 19>>, Eco-Mode:0
2014.01.20 16:08:02 3: [Wohnzimmer1] MaxScanRun.430 sdNextScan:2014-01-20 16:22:26 strDesiTime:2014-01-20 16:08:00
2014.01.20 16:08:02 3: [Wohnzimmer1] MaxScanRun.444 TYPE:MAXLAN IOName:MAXLAN
2014.01.20 16:08:02 3: [Kueche] MaxScanRun.430 sdNextScan:2014-01-20 16:22:37 strDesiTime:2014-01-20 16:08:01
2014.01.20 16:08:02 3: [Kueche] MaxScanRun.444 TYPE:MAXLAN IOName:MAXLAN
2014.01.20 16:08:02 3: [Flur] MaxScanRun.430 sdNextScan:2014-01-20 16:22:47 strDesiTime:2014-01-20 16:08:01
2014.01.20 16:08:02 3: [Flur] MaxScanRun.444 TYPE:MAXLAN IOName:MAXLAN
2014.01.20 16:08:02 1: Perfmon: possible freeze starting at 16:07:58, delay is 4.189
2014.01.20 16:08:05 3: Opening MAXLAN device 192.168.0.222:62910
2014.01.20 16:08:05 3: MAXLAN device opened
2014.01.20 16:08:08 1: Perfmon: possible freeze starting at 16:08:06, delay is 2.548
.
.
2014.01.20 16:16:27 1: Perfmon: possible freeze starting at 16:16:22, delay is 5.836
2014.01.20 16:16:30 1: Perfmon: possible freeze starting at 16:16:28, delay is 2.078
2014.01.20 16:16:37 1: Perfmon: possible freeze starting at 16:16:35, delay is 2.415
2014.01.20 16:16:39 1: Perfmon: possible freeze starting at 16:16:38, delay is 1.916
2014.01.20 16:17:12 1: Perfmon: possible freeze starting at 16:16:55, delay is 17.152
2014.01.20 16:17:12 3: Opening MAXLAN device 192.168.0.222:62910
2014.01.20 16:17:12 3: MAXLAN device opened
2014.01.20 16:17:46 1: Perfmon: possible freeze starting at 16:17:13, delay is 33.716
Hat jemand eine Idee, woher das kommt und wie man das beheben kann?

VIele Grüße

Harald

[Harald]

Hallo zusammen,

hat denn keiner eine Idee, warum ausgerechnet MAXLAN (?) solche Verzögerungen verursacht? Hat jemand Erfahrungen mit anderen Geräten, die über LAN angesprochen werden?
Hier noch ein Beispiel:

Code Auswählen Erweitern


2014.02.07 13:34:28 1: Perfmon: possible freeze starting at 13:34:26, delay is 2.53
2014.02.07 13:34:31 3: Opening MAXLAN device 192.168.0.222:62910
2014.02.07 13:34:31 3: MAXLAN device opened
2014.02.07 13:34:33 1: Perfmon: possible freeze starting at 13:34:32, delay is 1.741
2014.02.07 13:34:33 3: [MaxScan] MaxScanRun.352 -------------------- begin
2014.02.07 13:34:33 3: [MaxScan] MaxScanRun.828 next scan in seconds:1065
2014.02.07 13:34:33 3: [MaxScan] MaxScanRun.835 -------------------- finished
2014.02.07 13:36:13 1: Perfmon: possible freeze starting at 13:36:00, delay is 13.501
2014.02.07 13:36:26 1: Perfmon: possible freeze starting at 13:36:14, delay is 12.089
2014.02.07 13:36:35 1: Perfmon: possible freeze starting at 13:36:27, delay is 8.22
2014.02.07 13:36:54 1: Perfmon: possible freeze starting at 13:36:50, delay is 4.99
2014.02.07 13:36:56 1: Perfmon: possible freeze starting at 13:36:55, delay is 1.727
2014.02.07 13:37:24 1: Perfmon: possible freeze starting at 13:37:12, delay is 12.872
2014.02.07 13:37:37 1: Perfmon: possible freeze starting at 13:37:25, delay is 12.539
2014.02.07 13:37:37 3: Opening MAXLAN device 192.168.0.222:62910
2014.02.07 13:37:37 3: MAXLAN device opened
2014.02.07 13:37:49 1: Perfmon: possible freeze starting at 13:37:38, delay is 11.087
2014.02.07 13:40:39 3: Opening MAXLAN device 192.168.0.222:62910
2014.02.07 13:40:39 3: MAXLAN device opened
2014.02.07 13:40:42 1: Perfmon: possible freeze starting at 13:40:40, delay is 2.173

Viele Grüße

Harald

[jisleib]

Hallo Harald,

auch bei mir kommt diese Verzögerung. Nicht so extrem wie bei dir, ich verwende auch den Scanner nicht, der scheint zusätzlich zu verzögern.
Wenn du Global verbose mal auf 5 setzt merkst du das da Zeilen mit "Triggering" und "Notify loop" drin stehen welche bei den MAX und auch anderen Geräten manchmal relativ viel Zeit benötigen.
Ich habe dazu mal bei allen MAX-Geräten das attr do-not-notify verwendet und siehe da keine Perform Meldung mehr. Leider werden aber auch dadurch die Werte in den Readings nicht mehr automatisch geändert. Da die Verzögerung bei mir nicht so stark ist (1-2 sec.) habe ich die do-not-notifys wieder gelöscht. (setzen auf 0 bringt nichts !)
Das Zeitproblem kommt also nicht direkt von MAX oder MAXLAN sondern wohl eher aus dem System (fhem.pl). Würden z.B. nur Werte die sich auch wirklich geändert haben aktuallisiert werden dürfte das weniger Zeit kosten. Aktuell werden bei mir in den MAX Geräten fast alle Readings rot (Zeitstempel).

Ach ja, das liegt auch an "ondemand". Ohne kommt es auch nicht zu den Perform Meldungen. So bleibt halt die Verbindung ständig offen und kein anderes Tool (z.B. andFhem) kann mehr darauf zugreifen. Bei "ondemand" wird immer eine neue Verbindung aufgebeut und die komplette Konfiguration aus dem Cube ausgelesen und verarbeitet, ohne wird nur auf ein Telegramm pro Gerät (L:) geschaut.

Gruß Jürgen

[jisleib]

Hallo Harald,

hier eine mögliche Lösung. Steht auch in der FHEM reference, man muss es nur finden und auch verstehen. Bei mir hats gedauert.

das Attribut "event-on-change-reading" bei allen MAX Geräten mit .* setzen.

sieht dann in der .cfg so aus

attr MAX_012345 event-on-change-reading .*

auch bei anderen Geräten (z.B. Dummy) kann dieses Attribut so belegt werden. Damit wird nur bei einer Änderung ein Event ausgelöst. Ohne das Attribut wird bei jedem lesen des Gerätes egal ob sich ein Wert geändert hat oder nicht ein Event ausgelöst. Das schont die Resourcen. Man sieht das gut bei den Readings die ohne das Attribut immer rot (Zeitstempel) werden. Mit Attribut wirds nur noch rot wenn sich der Wert ändert.

Gruß Jürgen

[Harald]

Hallo Jürgen,

herzlichen Dank für Deine ausführlichen Erläuterungen. Jetzt verstehe ich die Zusammenhänge schon besser. Das mit dem "attr MAX_012345 event-on-change-reading .*" leuchtet mir auch ein und ich werde das demnächst ausprobieren. Ondemand würde ich schon gerne weiter benutzen, damit andFHEM, MAX!-Buddy und die originale MAX!-Software weiter nutzbar bleiben.

Vielleicht bekomme ich durch Deine Anregungen FHEM dazu, etwas schneller auf meine Wünsche zu reagieren 

Den Scanner nutze ich seit einigen Tagen nicht mehr. Wie Du vielleicht gelesen hast, hatte ich Probleme, dass unregelmäßig, undeffiniert die Solltemperatur geändert wurde. Das ist jetzt nicht mehr der Fall. Ich vermute, dass sich die beiden Systeme, MAX! und FHEM mit ihren Timings ins Gehege kamen und es so zu Überschneidungen und Fehlfunktionen kam. Ich muss natürlich in Kauf nehmen, dass die Isttemperaturen der Thermostate ggf. nicht kontinuierlich geschrieben werden. Durch den Einsatz von externen Temperatursensoren, deren Werte mit in die Raumdiagramme geschrieben werden, kann ich das jedoch verschmerzen.

Viele Grüße und nochmals besten Dank

Harald

[jisleib]

Hallo Harald,

ich hab das gestern bei mir ausprobiert mit dem Attribut attr MAX_012345 event-on-change-reading .* und hab keine Perform Meldungen mehr, nur wenn ich wirklich das System belaste, z.B. Aufruf eines Plots.
Aufgefallen ist mir daß jetzt die Plots nur noch Werte aufzeichnen welche sich ändern, irgendwie auch logisch.
Aber mit z.B.
  attr MAX_012345 event-on-update-reading valveposition für Heizthermostate (ich verwende nur valveposition im Plot, der Rest kommt vom Wandthermostat)
und
  attr MAX_012345 event-on-update-reading desiredTemperature,temperature für Wandthermostate
sehen bei mir die Plots wieder normal aus.
Das Attribut event-on-update-reading sagt also aus welcher Wert doch als Event und für die Plots aktuallisiert werden soll.

Gruß Jürgen

PS.: Ich bin aufgrund der Schwierigkeiten mit den Istwerten auf Wandthermostate umgestiegen. Du könntest auch das interne Wochenprogramm nehmen und immer ein halbes Grad auf und ab schalten. Mit 13 Schaltpunkten hast auch alle 2 Stunden eine Änderung. 

[Harald]

Hallo Jürgen,

Du könntest auch das interne Wochenprogramm nehmen und immer ein halbes Grad auf und ab schalten

Das macht ja der Scanner von John. Damit hatte ich ja o.g. Schwierigkeiten und ihn deshalb nicht mehr in Berieb.

Muss mich mals schlau machen, was die Wandthermostate kosten und überlegen, ob ich das investieren will oder ob mir meine jetztige Lösung ausreicht.

Mit "event-on-update-reading" und "event-on-change-reading" werde ich gelegentlich testen, ob es für mich zu Verbesserungen führt. Das hat z.Z. nicht oberste Priorität

Danke nochmals für die Hinweise und viele Grüße

Harald

[Fredo]

Hallo Harald und Jürgen,
ich habe das gleiche Problem mit den manchmal (gefühlte 50% der Fälle) extrem verzögert erscheinenden Seiten. Konnte auch bisher kein Benutzungsmuster identifizieren, das wiederholbar zu den Verzögerungen führt. Interessant ist, dass es scheinbar nur mit Firefox auftritt - siehe auch http://forum.fhem.de/index.php/topic,18669.msg126410.html.
Grüße, Fredo