Funklast HMLAN seit Ende Oktober von ~14% auf 50-60% gegangen

[hauwech]

Hallo zusammen,
ich habe mit vor längerer Zeit einen Plot nach https://wiki.fhem.de/wiki/HM-CFG-LAN:_%C3%9Cberwachung_der_1%25-Regel gebaut, um die Funklast im Auge zu haben.
Seit Ende Oktober sehe ich, daß die mittlere Funklast des HMLAN von vorher etwa 14% im Schnitt auf meist um die 50% bis über 60% gegangen ist.
In der Zeit ist aber nur ein Fensterkontakt und ein 2-fach Wandtaster dazugekommen. Ich habe nun erstmal für die meisten Devices event-on-change-reading auf .* gestellt, damit geht die Last auf etwa 40% zurück, aber die Plots für die Heizkörperthermostate sehen jetzt K... aus.
Wenn ich in HMInfo die protoEvents anschaue, sehe ich in der Spalte snd nix Auffälliges. Aber das ist wohl auch nicht maßgebend, weil, wenn ich das richtig verstanden habe, für die Ermittlung der 1% Regel die Anzahl/Datenmenge der vom IO Device (HMLAN) gesendeten Telegramme gilt, nicht die Antworten der Devices.
Wie kann ich denn rausfinden, warum und mit wem der HMLAN so intensiv schwätzt?
Kann mich jemand auf die richtige Spur setzen?

Gruß Roland

[herrmannj]

event-on-change-reading hat doch nichts mit der Duty rate zu tun.

Mit den von Dir gelieferten Infos kann man sonst nicht weiter machen. Such wo ein notify oder ähnlich auf events reagiert und was sendet.

[hauwech]

  Du hast Recht. Keine Ahnung, was mich auf den Holzweg gebracht hat, war ne schwere Woche...
Ich versuche noch mal intensiver, anhand der Logs rauszufinden, was passiert sein könnte.

[frank]

poste mal die ausgabe von hminfo configcheck und protoevents.

[hauwech]

Möglicherweise habe ich den Übeltäter erwischt. Ich habe einen 8-Kanal Switch HM-MOD-Re-8 im Einsatz, mit dem ich mit farbigen LEDs die Müllabfuhrtermine visualisiere. Bei dem war die Batterie leer, was fhem veranlaßt hat, im 30-Minuten-Intervall statusRequests an alle 8 Kanäle zu senden (meine Theorie). Ich hatte angesichts des langen Intervalls bis dahin die entsprechenden Logeinträge nicht für relevant gehalten. Das HMInfo protoEvents hat mich dann aber doch stutzig gemacht.
Ich habe ihm eine neue Batterie spendiert, seitdem geht die Funklast wieder auf 14% zurück. Wieder was gelernt. Ich hatte zuerst neu hinzugekommene Devices im Verdacht. Falls ich doch wieder auf dem Holzweg bin, melde ich mich nochmal.
configCheck ist aber auch nicht sauber (schon länger). Das Display ist von Anfang an störrisch, die angemahnten peers werden nicht benutzt. Vielleicht gehe ich der Sache im Winter mal genauer nach.
Danke
Roland

configCheck done:

missing register list
    AlarmStatus:   RegL_00.,RegL_01.
    HG_Display:   RegL_00.
    HG_Display_01:   RegL_01.
    HG_Display_02:   RegL_01.
    HG_Display_03:   RegL_01.
    HG_Display_04:   RegL_01.
    HG_Display_05:   RegL_01.
    HG_Display_06:   RegL_01.
    HG_Display_07:   RegL_01.
    HG_Display_08:   RegL_01.
    HG_Display_09:   RegL_01.
    HG_Display_10:   RegL_01.
    HG_FL_Gong:   RegL_00.
    HG_TH_Klingel:   RegL_00.,RegL_01.
    HG_TR_WT_Btn_01:   RegL_04.HG_WZ_RL_Tuer_chn-01
    HG_WZ_TTuer:   RegL_00.,RegL_01.,RegL_04.HG_WZ_HZ_WT_WindowRec

peer list incomplete. Use getConfig to read it.
    incomplete: HG_Display_06:
    incomplete: HG_Display_07:
    incomplete: HG_Display_08:
    incomplete: HG_Display_09:
    incomplete: HG_Display_10:

peer not verified. Check that peer is set on both sides
    HG_TR_SW p:HG_TR_WT_chn-03
    v_disarm p:HandsenderAlarm_disarm
    v_light p:HandsenderAlarm_light

PairedTo missing/unknown
    AlarmStatus
    HG_Display
    HG_FL_Gong
    HG_KU_DunstabzugsHaube

protoEvents done:
    name                   :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr
    AlarmStatus            : done_Errors:1  |  -       | 57:      | 57:      # 59       | 57:      |  -       |  -
    HG_AZ_HZ               : done           |  -       | 5:       |  -       #  -       |  -       |  -       |  -
    HG_BM_1                : done           |  -       | 64:      |  -       #  -       |  -       |  -       |  -
    HG_BM_Bad              : done           |  -       | 106:     |  -       #  -       |  -       |  -       |  -
    HG_BM_WK               : done           |  -       | 132:     |  -       #  -       |  -       |  -       |  -
    HG_BZ_Fenster          : done           |  -       | 32:      |  -       #  -       |  -       |  -       |  -
    HG_BZ_HZ               : done           |  -       | 2:       |  -       #  -       |  -       |  -       |  -
    HG_BZ_HZ_WT            :  -             |  -       |  -       |  -       #  -       |  -       |  -       |  -
    HG_Display             : done           |  -       | 24:      | 3:       # 4        | 1:       |  -       |  -
    HG_FL_Gong             : done_Errors:1  |  -       | 57:      | 171:     # 58       | 57:      |  -       |  -
    HG_FL_Muell            : done           |  -       | 232:     | 124:     # 424      | 122:     |  -       |  -
    HG_GWC_Fenster         : done           |  -       | 30:      |  -       #  -       |  -       |  -       |  -

[jkriegl]

Habe festgestellt, dass der raspi 3 seit update 2. Nov. im Durschnitt höher taktet.
Bin dann auf 30. Okt. zurückgegangen, Taktung wie davor.
Habe dann am 15. Nov. nur ein update 10_CUL_HM.pm gemacht und siehe da die Taktung ist wieder höher. Beobachte.

[hauwech]

event-on-change-reading hat doch nichts mit der Duty rate zu tun.

Irgendwo hatte ich mal gelesen, das das event-on-change-reading bei einem geholfen hatte, jetzt hab' ich's gefunden:
https://forum.fhem.de/index.php/topic,44222.msg361131.html#msg361131
Aber wenn ich jetzt drüber nachdenke, senkt das Attribut die Datenmenge im Log, nicht die Funklast.

Gruß Roland