hallo allerseits,
ich wollte mal meinen hmlan unter die lupe nehmen und möglichst viele infos loggen. die interessantesten (msgKeepAlive, msgLoadEst, msgParseDly) stehen leider in der internals rubrik, generieren also keine events um sie bequem in eine datei zu loggen. darum habe ich über attr userReadings mit dem code
traffic {InternalVal("HMLAN1","msgLoadEst","???")}versucht, ein reading zu erzeugen, das die nötigen events generiert. leider nein.
ZitatuserReadings
A comma-separated list of definitions of user-defined readings. Each definition has the form:
<reading>[:<trigger>] [<modifier>] { <perl code> }
After a single or bulk readings update, the user-defined readings are set by evaluating the perl code { <perl code> } for all definitions and setting the value of the respective user-defined reading <reading> to the result. If <trigger> is given, then all processing for this specific user reading is only done if one of the just updated "reading: value" combinations matches <trigger>, which is treated as a regexp.
nach dieser definition wird die userReadings-berechnung erst durch ein erneutes setzen eines echten readings getriggert. da die readings beim hmlan fast gar nicht erneuert werden, kann ich dieses vorgehen wohl vergessen. ich hatte erwartet, dass die erneuerung des internalsReading die berechnung triggern würde.
gibt es eine möglichkeit auf die änderung eines internalsReading ein event zu erzeugen?
über den umweg eines "at", das mir mit setreading die readings bereitstellt, wäre ich nicht so angetan, da mir so eventuell informationen verloren gehen können. ebenso wie beim "fremdgesteuerten" userReading.
ich habe auch schon mit addvaltrigger rumgespielt. aber nichts besonderes festgestellt.
über eure vorschläge wäre ich erfreut.
gruss frank
die internal values erzeugen keine events und du kannst weder notifys noch user readings dran hängen.
wenn dich die werte wirklich interessieren bleibt nur ein at.
gruss
andre
Hi,
was willst du eigentlich sehen?
Zitatund möglichst viele infos loggen.
rohmessages - fast alles andere wird statistisch erfasst
Gruss Martin
hallo martin,
Zitatwas willst du eigentlich sehen?
1. über msgLoadEst: zu welchen zeiten gibt es maxima, um gegenzuwirken oder zu erkennen wer erzeugt warum soviel traffic. ausprobieren welche auswirkung hat die unterdrückung jedes x-ten climateEvents beim vtc/vvd. lohnt sich sowas und wenn wieviel.
2. erkenntnisse zu den hmlan-disconnects gewinnen.
3. gibt es irgendwelche zusammenhänge mit den systemverzögerungen, die zu den miss beim vtc führen?
....usw.
als mess- und regeltechniler will man halt sehen, was so los ist, um erkenntnisse daraus zu gewinnen. :)
gruss frank
Hi Frank,
zu 1) siehe auch HMInfo msgStat
zu 2) die kannst du per notify bearbeiten.
zu 3) warum nicht apptime loggen - per notify bei einem miss?
Zitatals mess- und regeltechniler will man halt sehen...
klar - aber dann weisst du sicher auch, dass man sich auf details konzentrieren muss. Will man zu viel aufzeichnen verändert man das system. Passiv messen ist nicht. Daher die Frage, was du eigentlich untersuchen willst.
Ansonsten musst du das gesamte System einfach mit den Entsprechenden Tools instrumentieren - da wird dann alles gelogt.
Gruss Martin
hallo martin,
also eigentlich wollte ich mir nur mal deinen schönen statistikwert msgLoadEst loggen, um zu sehen, wie der sich so über den tag verhält. wäre für mich halt mal ganz interessant. darum hatte ich, um einen trick gebeten!
gruss frank
ich habe das jetzt mal mit at gemacht.
nach wenigen minuten schon die ersten erkenntnisse!
bei einem disconnect setzt martin seine traffic-statistik zurück.
oder steckt da sogar mehr dahinter??? ???
gruss frank
Hi Frank,
ich kann dir nicht folgen
msgStat wird nach disconnect nicht zurückgesetzt.
msgparsedelay wird nach disconnect nicht zurückgesetzt.
protoEvents wird nach disconnect nicht zurückgesetzt.
welche Statistiken haben wir noch in hmlan/usb ?
msgLoadEst ist keine Statistic sondern eine angenommene Belastung des HMLAN - sollte so beschrieben sein. Wenn dieser resetet ist sie Null. Bei einem Disconnect muss dies angenommen werden, sonst blockieren wir.
was sind die Erkenntnisse?
Gruss Martin
hallo martin,
Zitatwas sind die Erkenntnisse?
ich hätte wohl explizit angeben sollen, dass sich der traffic meiner grafik der 1hour-komponente von msgLoadEst entspricht, sorry.
meine persönlichen erkenntnisse sind, dass msgLoadEst nach einem diconnect auf 0 gesetzt wird.
dies wird nun von dir bestätigt:
ZitatWenn dieser resetet ist sie Null. Bei einem Disconnect muss dies angenommen werden, sonst blockieren wir.
nach deiner beschreibung in messageHandling.txt war mir nicht klar, dass auf 0 zurückgesetzt wird.
ZitatHMLAN Sendebeschränkung:
HMLAN hat eine maximale Sendekapazität je Stunde. Wird diese überschritten wird nichts mehr gesendet bis der Wert wieder unterschritten ist. Diese Kapazität wird insbesondere belastet wenn burst gesendet werden muss um ein Device aufzuwecken. Daher sollte man sich überlegen wann man conditional burst einsetzt.
Die aktuelle Belastung eines HMLAN kann in ioDevice "msgLoadEst" eingesehen werden. Dies ist eine Hochrechnung. Der exakte Wert kann insbesondere nach disconnects und restarts von FHEM nicht errechnet sondern nur angenommen werden.
gruss frank
Hi Frank,
ok, steht so nicht drin. Es ist aber eine Hochrechnung der erwarteten aktuellen Belastung des HMLAN. Nach einem Disconnect ist damit zu rechnen, dass es ein Reboot war. Stimmt nicht immer, kann ich aber nicht unterscheiden.
Die Statistic sollte dir eigentlich einen schönen Überblick geben - schon fertig aufbereitet.
Gruss Martin
Kleines Heads-Up, falls noch jemand die 1% Regel plottet und kürzlich oder zukünftig aktualisiert: msgLoadEst wurde durch msgLoadCurrent ersetzt, welches direkt die stündliche Last angibt. Die Berechnung im Job "a_hmlan_internals" (wie sie im Wiki dokumentiert ist) kann also wegfallen.
aber leider ist noch kein reading entstanden, wodurch das at zum auslesen immer noch benötigt wird.