overload u. AutoReadReg, event-on-change-reading

[Peterson]

Hallo,

ich habe seit kurzem einige Probleme mit dem overload. Ich habe einiges hier im Forum gelesen und auch in der commandref, aber ich werde da nicht so richtig schlau draus.

Ich habe den Verbose auf 5 gestellt und mit Hilfe des Logs herausbekommen, dass meine 3 HM-CC-RT-DN sehr geschwätzig sind und diesen overload verursachen.

Mein Gedanke: Wie bekommt man es hin, dass die RTs nicht alle 3 Minuten zig Infos zum HM-LAN hinpusten sondern z.B. nur bei Änderungen?

Meine Konfig bzgl. den RTs ist wie folgt:

Code Auswählen Erweitern


define Wohnz_Links_Thermostat CUL_HM 236F48
attr Wohnz_Links_Thermostat IODev HMLAN1
attr Wohnz_Links_Thermostat actCycle 000:10
attr Wohnz_Links_Thermostat actStatus alive
attr Wohnz_Links_Thermostat autoReadReg 4_reqStatus
attr Wohnz_Links_Thermostat expert 2_full
attr Wohnz_Links_Thermostat firmware 1.0
attr Wohnz_Links_Thermostat model HM-CC-RT-DN
attr Wohnz_Links_Thermostat room CUL_HM
attr Wohnz_Links_Thermostat serialNr KEQXXXXXXX
attr Wohnz_Links_Thermostat subType thermostat
attr Wohnz_Links_Thermostat webCmd getConfig:clear msgEvents:burstXmit
define FileLog_Wohnz_Links_Thermostat FileLog ./log/Wohnz_Links_Thermostat-%Y-%m.log Wohnz_Links_Thermostat
attr FileLog_Wohnz_Links_Thermostat logtype text
attr FileLog_Wohnz_Links_Thermostat room CUL_HM
define Wohnz_Links_Thermostat_Weather CUL_HM 236F4801
attr Wohnz_Links_Thermostat_Weather model HM-CC-RT-DN
attr Wohnz_Links_Thermostat_Weather peerIDs 00000000,
define Wohnz_Links_Thermostat_Climate CUL_HM 236F4802
attr Wohnz_Links_Thermostat_Climate model HM-CC-RT-DN
attr Wohnz_Links_Thermostat_Climate peerIDs 00000000,
define Wohnz_Links_Thermostat_WindowRec CUL_HM 236F4803
attr Wohnz_Links_Thermostat_WindowRec model HM-CC-RT-DN
attr Wohnz_Links_Thermostat_WindowRec peerIDs 00000000,
attr Wohnz_Links_Thermostat_WindowRec stateFormat last:trigLast
define Wohnz_Links_Thermostat_Clima CUL_HM 236F4804
attr Wohnz_Links_Thermostat_Clima event-on-change-reading .*
attr Wohnz_Links_Thermostat_Clima model HM-CC-RT-DN
attr Wohnz_Links_Thermostat_Clima peerIDs 00000000,
define Wohnz_Links_Thermostat_ClimaTeam CUL_HM 236F4805
attr Wohnz_Links_Thermostat_ClimaTeam model HM-CC-RT-DN
attr Wohnz_Links_Thermostat_ClimaTeam peerIDs 00000000,
define Wohnz_Links_Thermostat_remote CUL_HM 236F4806
attr Wohnz_Links_Thermostat_remote model HM-CC-RT-DN
attr Wohnz_Links_Thermostat_remote peerIDs 00000000,


Ich muss dazu sagen, dass das Ganze mir deswegen aufgefallen ist, weil ich mit einem HM-PB2-W55-2, einem HM-LC-SW1-FM und HM-LC-SW1-BA-PCB ein paar Test vorgenommen habe und dies immer zu diesen Test geschehen war. Letztendlich in kurzer Zeit 4-5 Mal den W55 gedrückt habe um damit die Aktoren zu schalten. Aber ich kann mir nicht vorstellen, dass dies die Ursache sein kann.

BTW, ich habe versucht mit "event-on-change-reading" die log Einträge zu reduzieren. Dies hat auch nicht gegriffen. Es werden immer noch alle 3 Minuten zig Einträge vorgenommen obewohl sich wertemäßi gnichts geändert hat.  Ist da noch was was ich übersehen oder falsch gemacht habe? Ich dachte, dass mit dem Eintrag das funktionieren müsste.

Ich hoffe ihr könnt mir helfen.

Gruß,

Peterson


P.S.: Hat irgendjemand einen Link, der mehr Aufschluss über die Logeinträge gibt?

[Puschel74]

Hallo,

Fragen zu HM gehören wohin?
Wozu haben wir einen Homematic-Bereich (wozu haben wir überhaupt unterschiedliche Bereiche im Forum) wenn ihr alle möglichen Fragen erstmal hier deponiert?

Aber mal kurz zu deinen Fragen:
event-on-change-reading greift erst in FHEM
Das Device sendet deswegen immer noch (logischerweise).
Aber das senden der Geräte führt mWn NICHT zu einem overload.
Wenn du an deinem W55 Morsezeichen sendest wirst du wohl oder übel mal in die 1%-Regel laufen - das kann also durchaus die Ursache sein.

dass meine 3 HM-CC-RT-DN sehr geschwätzig sind und diesen overload verursachen.

Das halte ich für ein Gerücht aber da ich keine HM-CC-RT-DN habe kann ich deine Vermutung nicht widerlegen.
Daher bin ich mal so frei und nehm dir das mitdenken ab und schieb deinen Beitrag in den passenden Bereich.

Grüße

[Peterson]

Hallo Puschel74,

danke für das verschieben. manchmal bin ich mir nicht so sicher wo die abgrenzung meines problems zu Thema ist. Da ich noch nicht so tiefgreifend fitt im Thema FHEM und Hausautomation bin, habe ich gedacht, dass ich ersteinmal im anfängerbereich poste. Aber ich kann auch Dich verstehen und Du hast ja auch recht. Ich werde beim nächsten Post darauf achten.

Nun zu meinem Problem:
Mit event-on-change-reading habe ich auch so verstanden, dass dies erst in FHEM Auswirkung hat. Aber was ist an der Konfiguration falsch oder wo sind eventuell zu der Funktion Abhängigkeiten, die ich nicht in Blick habe oder nicht verstehe? Ich habe es so herausgelesen, dass diese Funktion im fhem.cfg wie in meinem erste Post beschrieben eingebettet wird und dann sollte es funktionieren. Jedoch, wie gesagt, gehen in dem RT Logs immer noch alle 3 Minuten die WEter ein ohne dass diese sich veränder thaben. Wo könnte die Ursache liegen?

Bzgl. overload:
Ich habe auch hier im Forum gelesen, dass das lesen bzw. empfangen von Meldungen den Overload provoziert. Aber was provoziert es denn dann? An welchen Einträgen im Log kann ich das erkennen? Das 4-5 Mal Drücken kann ich mir nicht vorstellen, dass dies das sein könnte.
Aber ich habe auch hier im Forum herausgelesen, dass auch mehr Infos gesendet werden als ich annehmen, aber darum meine Frage wie man im Log die entsprechenden Parameter ermitteln kann.

Gruß,

Peterson

[Puschel74]

Hallo,

daher hab ich deine Frage auch zu martin geschoben.
Bei HM kennt er sich einfach besser aus (logisch als Maintainer  ).

Aber es ist doch erstmal egal was in den Logs ankommt - die Geräte senden dennoch in ihrem Zeitfenster die Daten.
Selbst wenn das Log leer bleiben würde senden die Geräte.
Ob und wie das auf die 1%-Regel wirkt kann ich dir nicht sagen.
Meiner bescheidenen Meinung nach wird diese Regel nur durch FHEM resp. durch culfw (oder die Firmware im HM-Adapter) berücksichtigt.
Ob da dann ein Sensor seine Daten in die Gegend brüllt juckt doch das IO-Device nicht da es das sowieso nicht beeinflussen kann.
Einzig wenn das IO-Device was sendet wird geprüft ob noch genügend "Sendezeit" frei ist.
Und senden muss es wenn du auf deinen W55 "hämmerst".
Wenn dann natürlich zufällig nicht so viel Sendezeit frei ist gibt es den overload (ich vermute mal das es so ähnlich wie LOVF bei FS20 ist).

Aber wie gesagt: Hier können deine Fragen besser und kompetenter (und vor allem richtig) beantwortet werden.

Grüße

[Peterson]

Hallo,

danke nochmal für Deine Anregungen und Gedanken.
Du hast recht, die Daten werden eh vom HM-LAN empfangenund das Modul als auch FHEM können ledichglich die Daten nur annehmen. Allerdings wollte ich die Log Informationen reduzieren. Was ja auch eigentlich mit dem event-on-change-reading gehen sollte aber nicht funktioniert. Dieses Thema hat m.E. auch nichts mit dem Overload zu tun und das ist sicherlich auch das was Du meintes. Ich habe dieses Thema nur mit reingebracht, weil mir beim Posting der Konfig der Befehl aufviel. Ich hätte wohl einen eigenen Tread eröffnen sollen.

Zum Thema Overload: Mich würde zunächst auch interessieren, wie sich das Senden im Log darstellt? Dann könnte ich dies zumindest versuchen weiter zu interpretieren.

Hier einige Einträge, die vielleicht damit zusammenhängen und jemand weiss was sie bedeuten:
HMLAN/RAW: ...
HMLAN_Parse: HMLAN1 ...
HMLAN1 dispatch ...
eventTypes: ...
Triggering ...
HMLAN_Send:  HMLAN1 I:K (Das sieht eindeutig aus aber was bedeutet das I:K?)
HMLAN/RAW: /HHM-LAN-IF ...
HMLAN_Parse: ...


Gibt es eigentlich eine Übersicht von log Infos mit ihren Bedeutung (soweit herausgefunden) irgendwo im Forum? Ich habe leider noch nichts gefunden.

Die Frage ist auch wie ich auf die 1% (36 Sekunden je Std) anhand des Logs ermitteln kann?


Gruß,

Peterson

[Peterson]

Hallo,

die Nacht war ein bischen unruhig und ich mich hat das Thema nicht losgelassen so dass mir noch ein paar gedanken gekommen sind.

Es ist doch so, dass jeder Paketversand beim Empfänger bestätigt wird. Z.B. bei den Türkontakten wird beim öffnen ein Datenpaket zur HM-LAN gesendet, welche dieses mit dem Zurücksenden eines ACK-Packet bestätigt. Ist dies auch bei den RTs so? Werden alle Daten wie Temperaturen, Stellung etc. in einem Paket gesendet und nur einmal bestätigt oder wird jeder Wert einzeln vom RT gesendet und vom HM-LAN einzeln bestätigt?.
Jetzt würde mich interessieren, wie dieses vor sich geht und wie man dies im Log erkennen kann. kann da jemand helfen?
Ich frage mich wieviel Pakete oder besser eigentlich Zeit bei welchen Geräten gesendet werden.
Bei meinem Problem speziell die HM-PB2-W55-2, HM-LC-SW1-FM und HM-LC-SW1-BA-PCB wäre es interessant.

Naja, das Problem würde ich natürlich auch gerne lösen wollen. Falls da jemand Hilfe bieten kann, wäre ich sehr sehr dankbar.

BTW: Ich hatte im Betreff auch AutoReadReg geschrieben. Kann das irgendwie helfen. Ich bin nicht ganz schlau draus geworden.

Gruß,

Peterson

[martinp876]

s ist doch so, dass jeder Paketversand beim Empfänger bestätigt wird.

vom Empfänger - wenn einer definiert ist und der die message ok findet.

Ist dies auch bei den RTs so?

ja

Werden alle Daten wie Temperaturen, Stellung etc. in einem Paket gesendet und nur einmal bestätigt oder wird jeder Wert einzeln vom RT gesendet und vom HM-LAN einzeln bestätigt?.

es können mehrere Werte in einer Message sein. es werden nur messages bestätigt, keine Werte.
manche messages werden an Broadcast gesendet  - dann gibt es keine ACK.

Jetzt würde mich interessieren, wie dieses vor sich geht und wie man dies im Log erkennen kann. kann da jemand helfen?
Ich frage mich wieviel Pakete oder besser eigentlich Zeit bei welchen Geräten gesendet werden.

dann logge doch wie in sniffen beschrieben - setze als logIDs die ID deines DUT ein. Beides ist dort zu sehen.

Irgendwie habe ich verloren, was du (noch) suchst. Eine generelle Anleitung zum decoden von messages machst du am besten mit vielen Versuchen, sniffen und hmLogEvents. letzteres immer wieder ausschalten - das ist i.a. zu langsam!

[Peterson]

Hallo Martin,

nach einer größeren Pause, habe ich mich mal wieder ran wagen können.

Es sind 2 Punkte:

1. das Thema Overload
2. Reduierung der Einträge in Logfiles

zu Thema 1:
Also Fundamental wäre für mich (und ich kann mir auch vorstellen für einige andere) ersteinmal ein Art Manual/Übersicht mit Interpretation/Beschreibung der Meldungen wichtig.
Ich kann auch mit viel Zeitaufwand versuchen dies (was eventuell schon andere vorher) selbst herausfinden, wie Du es beschrieben hast. M.E. ist es aber effektiver wenn bereits bestehendes Wissen von Experten wie Dich schon konzentriert (z.B. in einem Wiki) als Einstieg nachlesbar ist. Aber ich denke wir haben alle das gleiche Verständnis über ein Forum und Wiki und ich will hier auch keine Grundsatzdiskusion lostreten vor allem weil ich dieses Forum sehr lebendig und informativ finde und Euren (Experten)-Einsatz sehr zu schätzen weiss.

Im Weiteren wäre für eine Übersicht über die Art und Weise der Kommunikation wichtig. Wie Du schon beschrieben hast "es können mehrere Werte in einer Message sein. es werden nur messages bestätigt, keine Werte." ist schon für mich ein wichtiger Hinweis.

zu Thema 2:
In den letzten Post hatte ich ja beschrieben, dass ich trotz des "event-on-change-reading" keine Reduzierung der Einträge im Log des RTs feststellte.
Irgendwas ist noch nicht i.O.. Jedoch ich habe zur Zeit keinen Ansatz dafür.

[betateilchen]

2. Reduierung der Einträge in Logfiles

Es wäre ja schon extrem hilfreich, wenn Homematic nicht für jeden Mist einen event erzeugen würde, von denen > 90% absolut nutzlos sind, da man sie nie in einem notify oder log sinnvoll verwenden wird. Da dieses Verhalten bei Homematic inzwischen sogar schon Rudi hier im Forum auf die Barrikaden treibt, hege ich inzwischen wieder leise Hoffnung, dass sich dieser Zustand vielleicht doch irgendwann ändert - vielleicht braucht es nur ein königliches Donnerwetter.

Man kann schließlich auch readings füllen, ohne einen event zu erzeugen.

[frank]

Es wäre ja schon extrem hilfreich, wenn Homematic nicht für jeden Mist einen event erzeugen würde, von denen > 90% absolut nutzlos sind, da man sie nie in einem notify oder log sinnvoll verwenden wird. Da dieses Verhalten bei Homematic inzwischen sogar schon Rudi hier im Forum auf die Barrikaden treibt, hege ich inzwischen wieder leise Hoffnung, dass sich dieser Zustand vielleicht doch irgendwann ändert - vielleicht braucht es nur ein königliches Donnerwetter.

Man kann schließlich auch readings füllen, ohne einen event zu erzeugen.

ich frage mich echt, was uns so eine haarsträubende aussage bringen soll. mir zeigt es nur, dass du die commandref nicht gelesen hast, oder nicht verstanden und deshalb wohl keine ahnung hast, wie man die events abschalten kann. eine freundliche bitte um rat, wie du dies abschalten kannst, hätte doch wohl gereicht.

event-on-change-reading
The attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, only changes of the listed readings create events. In other words, if a reading listed here is updated with the new value identical to the old value, no event is created. If an optional [:threshold] is given after a reading name events are only generated if the change is >= threshold.
The precedence of event-on-update-reading and event-on-change-reading is as follows:

    If both attributes are not set, any update of any reading of the device creates an event.
    If any of the attributes is set, no events occur for updates or changes of readings not listed in any of the attributes.
    If a reading is listed in event-on-update-reading, an update of the reading creates an event no matter whether the reading is also listed in event-on-change-reading.

ich gehe davon aus, dass die commandref zu diesem thema korrekt ist, denn bis zum äussersten habe ich es noch nicht ausgereizt. demnach sollte ein einfaches attribut mit zb event-on-change und nur einem reading als argument, sämtliche events ausser dem explizit angegebenen abschalten.

Code Auswählen Erweitern

attr my_thermostat event-on-change-reading measured-temp
dadurch sollten nur events von measured-temp auftauchen und diese auch nur bei änderung. das sollte dich doch zufriedenstellen können, oder? wenn du sogar noch einen wert angibst ([:threshold]), reduzieren sich die events noch weiter. so kann sich jeder genau das event generieren, dass er möchte. besser ich kann es abschalten, als dass ich es nicht einschalten kann.

gruss frank

[Peterson]

Hallo Frank,

auch an dieser Stelle nochmal vielen Dank an Dich.

Ich kann bestätigen, dass die commandref i.O (ich würde mir jedoch als Ergänzung wünschen, dass die möglichen Parameter noch benannt werden z.B. das "no"). ist. Es hat nur an der Umsetzung gehapert.
Ich hab natürlich schon an verschiedenen Stellen nach einer Lösung gesucht und u.a. auch was speziell für den Thermostat gefunden. Jedoch wurden hier die Channel mit dem Attribute versehen. Dies habe ich angewendet, aber es hat irgendwie nicht gegriffen. Auf den Gedanken, das Attribute mal direkt auf den Aktor anzuwenden bin ich ich, muss ich zu meiner Schande gestehen, nicht gekommen.
Aber wie so oft im Leben gibt es auch Mitmenschen die auch bei so banalen Sachen einen guten Tipp geben.

Wunderbar, somit bleibt nur noch das Thema overload bzw. Loginfos offen. Vielleicht kommt da noch was zusammen.

Gruß,

Peterson