Overload durch HMInfo tempList restore

[holgerschlegel]

Hallo,

in meiner Installation gibt es insgesamt (nur) 4 Wandthermostate (Typ HM-TC-IT-WM-W-EU).
Vor ein paar Wochen habe ich mal mittels "set HMInfo tempList save" die Temperaturlisten (3 je Thermostat) ausgelesen und als Datei tempList.cfg gespeichert.

Jetzt habe ich die Heizprogramme angepasst und wollte sie mittels "set HMInfo tempList restore" wieder in die Thermostate laden.
Allerdings führt der Befehl dazu, das das HMLAN Device binnen Sekunden auf overload und suspended geht.

Wenn ich mir dann die Temperaturlisten der _Climate Kanäle anschaue, passt etwa die Hälfte der Listen zu dem was ich setzen wollte. Aber eben nicht alle.
Außerdem ist keine Liste verified. Ein nach endes des Overload abgesetztes "getConfig" hat gezeigt, das tatsächlich nicht alle Temperaturlisten wie gewünscht angekommen sind.


Gibt es eine Möglichkeit / Option den HMInfo tempList restore Befehl geziehlt für einzelne Geräte durchzuführen?
Damit könnte man/ich jedes Thermostat einzeln Anpassen, auch dann wenn die tempList.cfg bereits komplett geändert ist.


Davon ab und nur aus interesse:
Gibt es Richtwerte oder Erfahrungen ab welcher Anzahl von Homematic Geräten die 1%-Regel im normal Betrieb (nicht während der Konfiguration) zu einem Problem wird?

Grüße
Holger

[martinp876]

Wegen 4 listen restore sollte es keinen overload geben. Das sind burst devices¡.... Evtl. Kollidieren sie. Glaube ich eigentlich nicht. Aber das kannst du mit hminfo protevents prüfen. Anzahl Wiederholungen u.ae.
Die Tabelle würde mich interessieren. Beachte, dass beim nächsten restore immer nur die Unterschiede geschrieben werden. Es wird also immer weniger geschrieben. Wichtig: getconfig zwischendurch! Sonst werden die Unterschiede nicht erkannt.

Hminfo hat ferner filter du solltest mit -f Name ein device anwählen können. Einfach einmal help probieren.

Und dann noch direkt von device. Geht auch.

[holgerschlegel]

Danke für die Tipps mit -f und protEvents.

Nach mehreren restore und getConfig Zyklen mit Wartezeiten aufgrund von Overloads konnte ich letztlich doch alle Thermostate auf die gewünschten Werte einstellen.


Hier trotzdem die protEvents Tabelle, bzw. der relevante Teil davon:

Code Auswählen Erweitern

    name             :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr
    Az.Heizung       : done           | -        |1:        | -        # -        | -        | -        | -
    Az.Thermostat    : done           | -        |423:      |5:        #74        |4:        | -        |2:
    Ba.Heizung       :  -             | -        | -        | -        # -        | -        | -        | -
    Ba.Thermostat    : done           | -        |452:      |117:      #36        |4:        | -        |1:
    Sz.Fenster       : done           | -        |3:        | -        # -        | -        | -        | -
    Sz.Heizung       : done           | -        |2:        | -        # -        | -        | -        | -
    Sz.Thermostat    : done           | -        |351:      |5:        #9         |1:        | -        | -
    Wz.Heizung_Dach  : done           | -        |3:        | -        # -        | -        | -        | -
    Wz.Heizung_Front : done           | -        |3:        | -        # -        | -        | -        | -
    Wz.Thermostat    : done           | -        |378:      |90:       #81        |3:        | -        |3:

Es gibt noch ein paar weitere Devices (Fenstersensoren, Stromzähler, VirtualCCU, ...), zu denen aber keine Nachrichten in der Tabelle angezeigt werden.

Woran erkenne ich, ob ein Device ein "burst device" ist?
Bei den Thermostaten und Heizungsantrieben (in der Liste mit Heizung benannt) steht das Register "R-burstRx" auf "on". Aber das waren die Standardwerte nach dem erstellen der Devices im FHEM.

Eventuell noch relevant sind die "autoReadReg" Einstellungen. Bei der Stellantrieben "4_reqStatus", bei den Thermostate "5_readMissing".

Ich schalte bei den Thermostaten mittels AT und etwas Perl die Wochenprogramme über das Register "R-weekPrgSel" um - zwischen prog1 für "Arbeitswoche", prog2 für "Urlaub zu Hause" und prog3 für "Urlaub auswärts".
Das hat bei mir zum Zeitpunkt der Einrichtung nur mit "autoReadReg" = "5_readMissing" funktioniert. Sonst blieb in dem Register auch nach Stunden noch der Wert mit dem Prefix "set_" stehen (z.B. "set_prog1" anstatt "prog1").
Können die dadurch zusätzlich entstehenden Nachrichten das Problem sein?

[martinp876]

kryptisch:
get hm param -d rxType
explizit:
set hm models


das set_ bleibt stehen bis die Register gelesen wurden. Ich nutze ausschliesslich 5 - fhem versucht es schonend zu lesen. Wenn viel last ist (IO usage) wird fhem warten mit der abfrage.