HM-CFG-LAN: Überwachung der 1%-Regel: Unterschied zwischen den Versionen

Aus FHEMWiki
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 4: Zeile 4:
In solchen Situationen kann es von Nutzen sein, mittels Plot einen Überblick über die aktuelle Auslastung zu bekommen, um eigene Codefehler von dem werksseitig eingebauten Sendestopp zu unterscheiden. Am Beispiel eines [[HomeMatic]]-Gerätes wird im Folgenden gezeigt, wie eine derartige "Überwachung" erreicht werden kann.
In solchen Situationen kann es von Nutzen sein, mittels Plot einen Überblick über die aktuelle Auslastung zu bekommen, um eigene Codefehler von dem werksseitig eingebauten Sendestopp zu unterscheiden. Am Beispiel eines [[HomeMatic]]-Gerätes wird im Folgenden gezeigt, wie eine derartige "Überwachung" erreicht werden kann.


Der Sendestopp der HMLAN unit wird durch die Werte "ERROR-Overload" und "Warning-HighLoad" angezeigt. Dabei handelt es sich um direkte Readings der HMLAN unit und sind auf alle Fälle als richtig bzw. "absolut" anzusehen.
=== "ERROR-Overload" und "Warning-HighLoad" ===
Der Sendestopp der HMLAN-unit wird durch die Werte "ERROR-Overload" angezeigt bzw. durch "Warning-HighLoad" vorgewarnt. Dabei handelt es sich um direkte Readings der HMLAN-unit und sind auf alle Fälle als richtig bzw. "absolut" anzusehen. Sollte die HMLAN-unit in diesen Zustand sein, wird sie keine Telegramme mehr senden, jedoch wird sie weiterhin alle Telegramme empfangen.
 
 
=== "msgLoadEst 1hour" ===
Die angezeigten "msgLoadEst" - Werte stellen keine 100%ige Genauigkeit dar, da sie "nur" annähernd berechnet werden können. Es kann daher theoretisch vorkommen, dass der Plot die 100% - Marke noch nicht erreicht hat, aber der "ERROR-Overload" Indikator bereits anzeigt, dass die HMLAN-unit seine Sendungen eingestellt hat.
 
<pre>
msgLoadEst 1hour:44% 10min steps: 12/2/7/23/0/0
</pre>
 
besagt, dass in der aktuellen Stunde 44% der Sendekapazität verbraucht sind. Im aktuellen 10min-Rahmen sind es 12%, in den 10min davor waren es 2%, davor 7% und davor 23%.
 
Dieser Zähler befindet sich direkt in der HMLAN-unit somit kann FHEM diesen Zähler nicht zurücksetzen. Nur durch Warten oder einen Reset der HMLAN-unit ist ein Rückstellen möglich.
 




== Einschränkungen ==
== Einschränkungen ==
Die angezeigten "msgLoadEst" - Werte stellen keine 100%ige Genauigkeit dar, da sie "nur" annähernd berechnet werden können. Es kann daher theoretisch vorkommen, dass der Plot die 100% - Marke noch nicht erreicht hat, aber der "ERROR-Overload" Indikator bereits anzeigt, dass der HMLAN seine Sendungen eingestellt hat.


Daher muss man die folgenden Einschränkungen hinsichtlich des Plots immer beachten:
Man muss die folgenden Einschränkungen hinsichtlich des Plots immer beachten:


* Nach dem (shutdown)-restart fängt FHEM wieder bei 0 an zu zählen. Da der HMLAN aber nicht zwangsläufig ebenfalls reseted wurde, kann bereits eine messageload im HMLAN vorliegen die fhem aufgrund des restarts nicht erfassen kann.
* Nach dem (shutdown)-restart fängt FHEM wieder bei 0 an zu zählen. Da die HMLAN-unit aber nicht zwangsläufig ebenfalls reseted wurde, kann bereits eine messageload in der HMLAN-unit vorliegen die fhem aufgrund des restarts nicht erfassen kann.


* FHEM kann nicht zwischen einem reboot und einem disconnect der HMLAN unit unterscheiden. Daher wird ein disconnect als reboot gewertet. Dies führt unter Umständen ebenfalls zu einer "ERROR-Overload" - Nachricht obwohl der Plot die 100%-Marke noch nicht erreicht hat.
* FHEM kann nicht zwischen einem reboot und einem disconnect der HMLAN-unit unterscheiden. Daher wird ein disconnect als reboot gewertet. Dies führt unter Umständen ebenfalls zu einer "ERROR-Overload" - Nachricht obwohl der Plot die 100%-Marke noch nicht erreicht hat.


* FHEM kann die automatischen Wiederholungen des HMLAN nicht erfassen und können daher nicht berücksichtigt werden.
* FHEM kann die automatischen Wiederholungen der HMLAN-unit nicht erfassen und können daher nicht berücksichtigt werden.


* Die AES Verschlüsselung, welche weitere Telegramme sendet, kann aktuell nicht gezählt werden
* Die AES Verschlüsselung, welche weitere Telegramme sendet, kann aktuell nicht gezählt werden


=== Updates ===
== Versions Updates ==
[http://forum.fhem.de/index.php/topic,21678.msg151621.html#msg151621 Version 5278]: Die Länge des Nachrichtentelegrams wird berücksichtigt.  
[http://forum.fhem.de/index.php/topic,21678.msg151621.html#msg151621 Version 5278]: Die Länge des Nachrichtentelegrams wird berücksichtigt.  



Version vom 27. März 2014, 15:18 Uhr

Einleitung

Gerade in der Entwicklungsphase kann es passieren, dass z.B. durch den Einsatz von Testroutinen der Bereich der 1% Regel erreicht wird und dadurch ein Gerät vorübergehend nicht mehr senden kann.

In solchen Situationen kann es von Nutzen sein, mittels Plot einen Überblick über die aktuelle Auslastung zu bekommen, um eigene Codefehler von dem werksseitig eingebauten Sendestopp zu unterscheiden. Am Beispiel eines HomeMatic-Gerätes wird im Folgenden gezeigt, wie eine derartige "Überwachung" erreicht werden kann.

"ERROR-Overload" und "Warning-HighLoad"

Der Sendestopp der HMLAN-unit wird durch die Werte "ERROR-Overload" angezeigt bzw. durch "Warning-HighLoad" vorgewarnt. Dabei handelt es sich um direkte Readings der HMLAN-unit und sind auf alle Fälle als richtig bzw. "absolut" anzusehen. Sollte die HMLAN-unit in diesen Zustand sein, wird sie keine Telegramme mehr senden, jedoch wird sie weiterhin alle Telegramme empfangen.


"msgLoadEst 1hour"

Die angezeigten "msgLoadEst" - Werte stellen keine 100%ige Genauigkeit dar, da sie "nur" annähernd berechnet werden können. Es kann daher theoretisch vorkommen, dass der Plot die 100% - Marke noch nicht erreicht hat, aber der "ERROR-Overload" Indikator bereits anzeigt, dass die HMLAN-unit seine Sendungen eingestellt hat.

msgLoadEst 1hour:44% 10min steps: 12/2/7/23/0/0 

besagt, dass in der aktuellen Stunde 44% der Sendekapazität verbraucht sind. Im aktuellen 10min-Rahmen sind es 12%, in den 10min davor waren es 2%, davor 7% und davor 23%.

Dieser Zähler befindet sich direkt in der HMLAN-unit somit kann FHEM diesen Zähler nicht zurücksetzen. Nur durch Warten oder einen Reset der HMLAN-unit ist ein Rückstellen möglich.


Einschränkungen

Man muss die folgenden Einschränkungen hinsichtlich des Plots immer beachten:

  • Nach dem (shutdown)-restart fängt FHEM wieder bei 0 an zu zählen. Da die HMLAN-unit aber nicht zwangsläufig ebenfalls reseted wurde, kann bereits eine messageload in der HMLAN-unit vorliegen die fhem aufgrund des restarts nicht erfassen kann.
  • FHEM kann nicht zwischen einem reboot und einem disconnect der HMLAN-unit unterscheiden. Daher wird ein disconnect als reboot gewertet. Dies führt unter Umständen ebenfalls zu einer "ERROR-Overload" - Nachricht obwohl der Plot die 100%-Marke noch nicht erreicht hat.
  • FHEM kann die automatischen Wiederholungen der HMLAN-unit nicht erfassen und können daher nicht berücksichtigt werden.
  • Die AES Verschlüsselung, welche weitere Telegramme sendet, kann aktuell nicht gezählt werden

Versions Updates

Version 5278: Die Länge des Nachrichtentelegrams wird berücksichtigt.


Plot von Highload/Overload und msgLoadEst-Werten

Beispiel-Plot mit einer Auslastung von ca. 80%

Dazu muss im Einzelnen wie folgt vorgegangen werden:

  • Um einen Plot erzeugen zu können, wird ein Log benötigt.
  • Um ein Log erzeugen zu können, wird ein Event benötigt, welches geloggt werden kann.
  • Um das Event loggen zu können, wird ein CronJob benötigt, der dieses Event wiederholt im Abstand x bereitstellt.

Der CronJob wird mittels "at" im Zeitabstand x= 1 Minute als Reading bereitgestellt, welches den Wert von "msgLoadEst-1hour" erhält. Hierdurch werden 60 Werte pro Stunde in die Logdatei geschrieben. Sollte dies zu Performanceeinbußen auf Seiten des Fhem-Trägersystems führen, kann der "+*00:01:00"-Wert entsprechend erhöht werden.

Erforderliche Definition in der Konfiguration (fhem.cfg):

define a_hmlan_internals at +*00:01:00 {\ 
my $trafficStr = InternalVal("HMLAN1","msgLoadEst","???");;\
my $trafficHour = $1 if($trafficStr =~ m/1hour:(.*)% 10min steps/);;\ 
fhem("setreading HMLAN1 hmTrfHour ".$trafficHour." %" );;\ 
} 

Dadurch wird ein Event ausgelöst, das (z.B. mit den folgenden Definitionen) geloggt werden kann:

define FileLog_Technik_IO FileLog %L/Technik_IO-%Y-%M.log global:.*|HMLAN1:cond:.*|HMLAN1:hmTrfHour:.*
attr FileLog_Technik_IO logtype text
attr FileLog_Technik_IO room Log

Die graphische Darstellung (Plot) wird durch die Definition

define SVG_FileLog_Technik_IO_1 SVG FileLog_Technik_IO:SVG_FileLog_Technik_IO_1:CURRENT
attr SVG_FileLog_Technik_IO_1 alias 10. hmlan attr SVG_FileLog_Technik_IO_1 label "traffic: min [$data{min1}] - avg [$data{avg1}] - max [$data{max1}] - last [$data{currval1}] ----- [".localtime()."]"
attr SVG_FileLog_Technik_IO_1 room 90_Technik 

... in Verbindung mit folgenden Plot-Anweisungen (im vorgestellten Beispiel in der SVG_FileLog_Technik_IO_1.gplot Datei) erzeugt:

# Created by FHEM/98_SVG.pm, 2014-03-22 12:11:58 set terminal png transparent size <SIZE> crop set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics "init" 6,"err" 4,"wng" 3,"?" 1,"ok" 0 set y2tics set grid y2tics set ylabel "condition"
set y2label "msgLoadEst % / hr"
set yrange [0:7]

#FileLog 4:HMLAN1.hmTrfHour\x3a::
#FileLog 4:HMLAN1.cond\x3a::$fld[3]=~"init"?6:$fld[3]=~"ERROR-Overload"?4:$fld[3]=~"Warning-HighLoad"?3:$fld[3]=~"ok"?0:1
#FileLog 3:global.*::$fld[2]=~"SHUTDOWN"?6:$fld[2]=~"INITIALIZED"?0:0

plot "<IN>" using 1:2 axes x1y2 title 'msgLoadEst' ls l6fill lw 1 with steps,\
     "<IN>" using 1:2 axes x1y1 title 'condition' ls l0 lw 1 with steps,\
     "<IN>" using 1:2 axes x1y1 title 'shutdown' ls l2fill lw 1 with steps 

Links

  • Beitrag / Diskussion zu diesem Thema im Fhem Forum