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 (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
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.
:-[ 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.
poste mal die ausgabe von hminfo configcheck und protoevents.
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
ZitatconfigCheck 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
ZitatprotoEvents 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: | - # - | - | - | -
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.
Zitat von: herrmannj am 17 November 2017, 16:08:04
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 (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