HM-Overload strategie, conditional Burst (RT, TC und andere) sowie daten-update

martinp876 · 13 Oktober 2013, 20:32:55

Hi,

ich habe den HMLAN in Sachen Performance noch einmal getestet.
Da hier eine Wartezeit - und somit eine Auszeit für jegliches Senden - von bis zu 1h auf dem Spiel steht hat dies natürlich höchste Priorität.

Nach meinen Berechnungen verträgt HMLAN in 1h ~1680 Messages - incl ACK.
Leider kann man(ich) den wahren "Füllstand" des HMLAN nicht auslesen - nur mit zählen ist möglich.

A) Erfassungsproblem:
gezählt werden können nur Ereignisse während FHEM läuft. Nach einem FHEM-restart werden die Zähler in FHEM rückgesetzt, nicht aber die des HMLAN. Somit ist die Erfassung "löchrig".
Darüber hinaus meldet HMLAN bei 90% "Füllstand" immer "high-Load". Dieser Wert ist daher verlässlich.

B) Darstellung
im HMLAN gibt es einen Eintrag "msgLoad" in der die errechnete Auslastung in % darstellt. Zusätzlich erhält man eine Auflistung in 10min Raster.
Man kann hier also -grob granular- erkennen, welcher 'block' wann freigegeben wird. HMLAN arbeitet nicht in diesen Blöcken sondern Message-individuell.

C) Burst Problematik
Im Rahmen der Tests habe ich festgestellt, dass einmal "aufwecken" ein äquivalent von 18 messages bedeutet. Wacht das Device nicht auf muss der Wert mal 3 genommen werden. Das bedeutet, dass ein fehlgeschlagenes "aufwecken" 3% des "Stundenkontingent" verbraucht.
Nach 33 solcher Versuche schaltet HMLAN ab!
Nach ~100 erfolgreichem aufwecken auch!
Aktuell sind hier besonders "conditional-Burst" Devices "performancefresser" - insbesondere wenn man burst abgeschaltet hat. Der "burst-Versuch" muss also in heden Fall begrenzt werden.
Somit ist es evtl nicht erwünscht dass, burst probiert wird. Dies mag für beide Fälle gelten, wenn ihn ausgeschaltet hat und auch wenn burst "ein" ist, z.B für eine Fensterkontakt

Maßnahme 1)
Attribut "burstAccess" [0_off|1_auto] steuert, dass der TC/RT oder andere bei '0_off' den Burst NICHT probiert sondern bis zum Aufwachen wartet.
Default ist "off" - um die Kapazität zu erhöhen.
2) hmMsgLowLimit wird jetzt in % angegeben, Bereich 10-120. 120% weil es uz messfehlern kömmen könnte. wen nichts gesetzt ist stoppt autoRegRead bei 80%
Es kann/wird zu fehlern beim restart führen, da der Wert bei eingen auf 550 steht. Ein Problem entsteht daruch nicht, den wert einfach löchen oder nach Gusto setzen

D) was, wenn overload ansteht
ich kennen keinen weg, dies remote zurückzusetzen. Man muss entweder warten bis HMLAN das senden wieder frei gibt oder HMLAN stromlos machen.
Das warten kann Theoretisch bis 1h dauern, wenn alle 1680 message-equivalente auf einmal aufgebraucht wurden.

E) Weiteres vorgehen
-burst-devices müssen weiter unter Kontrolle gebracht werden. Insbesondere das setzen des "aufwach"-bits.
- für das "Rücklesen" von Registern und Status muss eine optimierte Strategie entworfen werden. AutoReadReg muss überarbeitet werden.

F) sonstiges
ich vermute, dass nach einer gewissen "message-dichte" zum HMLAN dieser reseted - oder mindestens den TCP-stack neu started. Bei dieser Gelegenheit wird auch der "Stundenzähler" rückgesetzt.
Ich werden versuchen, die Randbedingungen zu ergründen.... und dann Maßnahmen zu definieren.

Ich hoffe, das ist ein erster Schritt die Performance eines HMLAN besser zu nutzen.

Version 4040,
4 Files!
Gruss Martin

betateilchen · 13 Oktober 2013, 21:41:16

Hallo Martin,

Deine Ausführungen habe ich alle verstanden. Darf ich trotzdem ein paar (vielleicht doof klingende) Fragen stellen?

Warum treten die ganzen beschriebenen Overload-Probleme bei mir ohne jegliche dieser Gegenmassnahmen NICHT auf?
Hängt das nur damit zusammen, dass ich kein autoReadReg (genauer: nur bei einem einzigen Gerät, dort auf Wert 3) verwende?
Oder verhält sich der USB Stick grundsätzlich anders als der HMLAN, obwohl die fhem-intern ja beide mit 00_HMLAN betrieben werden?

peterk_de · 13 Oktober 2013, 22:11:49

Herzlichen Dank, Martin! Das klingt nach einem guten Stück geleisteter "Forschungsarbeit"

martinp876 · 13 Oktober 2013, 22:23:52

Hallo Udo,

wie sich der USB-stick verhält kann ich nicht sagen, habe keinen. Da ich vermute, dass eQ3 die Lastschwelle absichtlich eingebaut hat (immerhin kommt es mit Ankündigung) und dies m.E. den sinn hat, den "Luftraum zu schützen" - und drittens eQ3 genug expertise hat so ein Konzept durchzuziehen gehe ich davon aus, dass der USBstick die gleiche (oder ähnliche) schwelle hat.

autoReadReg hat sicher seinen Beitrag geleistet. Wenn ich dich recht verstanden habe hast du burstRx auf "off" um Batterie zu sparen. Das bedeutet, dass bei jedem "neustart" einer Message-aktion erst einmal versucht wird, ob das Device burst kann. Das geht dann schief (wenn burstRx=off). Somit verbraucht es 3% der stunden Performance je device (TC oder RT, auch noch ein paar andere). Zum Aufwachen wird dann der messagekram doch noch gesendet.

das mit den "versuche mal ob Burst an ist" hatte ich eingebaut ohne zu wissen wie es sich auf die "1h" auswirkt. Mit dem Wissen muss man es natürlich erheblich vorsichtiger einsetzen! An einem "mode" für den User brüte ich noch... mal sehen ob mir ein "zwischen-ding" einfällt. Evtl ein neues Kommando - macht eigentlich sinn.

Dass das "aufwecken" so "teuer" ist dazu habe ich folgende Theorie:
ich bin immer noch der Meinung, dass das in-betriebhalten des Empfängers im Burst-mode nicht wirklich viel Batterie kostet. Das Problem ist aber, dass bei jeden Aufweck-signal alle burst-devices aufwachen und prüfen müssen, ob die Nachricht für sie ist. Und das kostet sicher Energie. Daher die gehobenen 'Anforderungen'. Ob man dies nutzen kann... mal sehen - gruppen-wecken....

Ich werden noch an ein paar anderen "sammel-aktionen" ausarbeiten. HMInfo-templates sind eine Möglichkeit. außerdem das setzen der temp-liste beim RT mit "prep" - spart einige Kommandos. Beim TC ist es komplexer... aber auch möglich. Ein mittlerer Umbau des 'prep/exec' konzepts.

Noch ein Gedanke ist das sammeln und filtern von getConfig. Das stellt aber die Message-sequenz ggf. um.
Das Verfahren muss einleuchtend bleiben, damit der Nutzer es mit geringem Aufwand verstehen kann.

Die 1h-Grenze macht ganz schön arbeit.... da muss einiges verbessert werden, ein paar grundlegende Dinge....

Gruss Martin

betateilchen · 13 Oktober 2013, 22:39:19

Hallo Martin,

danke für Deine Erklärungen.

Zitat von: martinp876 am 13 Oktober 2013, 22:23:52Wenn ich dich recht verstanden habe hast du burstRx auf "off" um Batterie zu sparen.

Nein, das habe ich mW. nirgends so geschrieben, denn burstRx ist bei mir (bei allen RTs) angeschaltet. Könnte sein, dass Du mich da irgendwie verwexelst.

Viele Grüße
Udo

unimatrix · 14 Oktober 2013, 13:58:28

Hi,

Hast du in den Versionen vom Wochenende schon angefangen was umzubauen? Seit Samstag habe ich irgendwie ständig disconnects und dann sieht man den HMLAN viele Minuten wie die Power-LED blinkt (also disconnected) und oft wenn dann ein Reconnect kommt, dann werden ganz kurz Signale aus der Warteschlange von FHEM gesendet und auch was empfangen was offenbar der HMLAN intern gequeued hat und dann stürzt er ab (rote LED leuchtet ein paar SEkunden, die anderen sind dabei aus, dann startet er neu)

K.a. vll wird er beim Reconnect mit Messages überflutet so dass er dann abraucht? Das hat sich nach ein paar Stunden erst gefangen aber es kommt immer wieder mal vor. So habe ich einen Zustand, in dem man sich nicht darauf verlassen kann, dass der HMLAN läuft (und ohne das kann man bei mir nichtmal mehr die Türklingel hören (ok das ist meine Schuld)) ... aber es kann auch morgens kalt im Bad sein und solche unschönen Effekte halt...

Danke und VG

martinp876 · 14 Oktober 2013, 15:27:46

hi,

umgebaut ist schon ein klein wenig länger. Bensonders die Funktion des ConditionalBurst könnte zu einer Belastung werden.
Seit gestern ist dies aber wieder abgeschaltet. Du kannst es wieder einschalten- also dass FHEM austestet, ob der TC/RT burst on hat - attribut "burstAccess".
Mit der Version von gestern Abend kannst du in "msgLoadEst" sehen, was HMLAN noch "frei" hat - siehe Einschränkungen weiter oben im Threat.

Ich arbeite gerade an einer Version, in der man den "Burst" manuell triggern kann. Also erst kommandos an einen TC eingeben und dann entweder warten bis der TC/RT aufwacht oder "set TC burstXmit" schicken. Natürlich muss der TC/RT burst freigegeben haben (register burstRx)

Nächste Änderung:
auch beim TC und bei regSet kann man (ab Morgen) "prep" eingeben um Änderungen vorzubereiten. Anschließend "exec" (beim letzten set kommando) um alles ans Device zu schicken.
Vorteil ist, dass es oft erhebliche weniger messages braucht. Probleme bei tempList kann man damit reduzieren/vermeiden.

Gruss Martin

unimatrix · 14 Oktober 2013, 15:51:28

ah ok verstanden. Klingt sehr gut.

Bist du sicher, dass der HMLAN seine Leichen im Keller vergisst, wenn man im stromlos macht? Ich habe das gefühl, der merkt sich das und man muss einfach WARTEN.

Das mit Prep/Exec wäre ja vll auch lösbar, indem man einfach einen Timeout einbaut? Also die geprepten Sachen nach dem Ablauf einer gewissen Zeit einfach schickt. Wer sofort schicken will muss eben einen Exec machen. Wenn man seine Thermostate über FHEM auf desired-temps setzt dann ist man ja sicher daran interessiert, dass dies sofort passiert wenn man es auslöst.

Die neue Version werde ich vll heute mal aufspielen, ich bin allerdings unter der Woche in Dänemark und dann übers VPN mal eben so ein Update kann im schlimmsten Fall halt dazu führen dass meine Frau zu Hause zu frieren anfängt und es sich remote nicht reparieren lässt bzw. ich ihr ständig sage, mach mal den HMLAN stromlos. Obwohl, vll sollte ich den mal an eine FS20 Steckdose ranbauen. Wenn der HMLAN wirklich seine Last VERGISST, dann wäre doch ein kurzes Aus/Einschalten über FS20 ein nettes Feature...

betateilchen · 14 Oktober 2013, 16:20:02

Zitat von: unimatrix am 14 Oktober 2013, 15:51:28Bist du sicher, dass der HMLAN seine Leichen im Keller vergisst, wenn man im stromlos macht?

Da wäre ich mich auch nicht so 100% sicher.

martinp876 · 14 Oktober 2013, 19:46:32

Nach meinen tests vergisst HMLAN alles nach PowerOn. Würde mich extrem wundern, wenn es nicht so wäre. HMLAN arbeitet nach meinen Erkenntnissen aus dem RAM - keine Ahnung, ob - ausser der FW -irgend etwas im flash gespeichert wird.
Stromlos sollte man es schon 5-10 sec machen. Wenn ihr neue Erkenntnisse habt, gerne.
ich habe den HMLAN mehrfach "überlastet", kurz stromlos, noch einmal. immer der gleiche Level.

Wenn ihr vom Reset/disconnect redet - das ist eine andere Baustelle. Da ist auch noch der IP-stack euerer Zentrale beteiligt - und die wird nicht rebooted. kann sein dass hier etwas bleibt.

das mit prep/exec ist, glaube ich falsch verstanden - auch burstXmit und burstAccess:

prep/exec bezieht sich ausschließlich auf Register setzen. mit prep sammelt man keine messages sondern die register in der Zentrale. mit exec wird dann ein block zusammengebaut und gesendet. Ein device verträgt dies erheblich besser als Einzeländerungen. Beispiel RT: will man die templiste der Woche setzen sind das 7 commands. wenn jedes Command einzeln gesendet wird muss der RT jeden Block einzeln schreiben. Vermutlich wird kein EEPROM sondern ein flash genutzt - jedenfalls braucht er zum Schreiben Zeit. Das hat zur Folge, dass das 2. Kommando sehr wahrscheinlich austimed - RT schreibt noch an der Ersten. RT ist das langsamste mir bekannte device - ich vermute man hat hier von eeprom auf flash umgestellt, weil billiger... aber egal.

exec macht klar, dass alles eingegeben ist und gesendet werden kann. Senden bedeuted, dass es in den commandstack kommt - nicht dass es "in die Luft" geht. FHEM sendet einen Block je List/peer kombination - das ist maximal ergonomisch.

Einen timeout halte ich für ungünstig. Tippt jemand von Hand, kann es dauern - bei scripts ist das eine andere Sache. Wie gross muss also der timeout sein? Schwer zu bestimmen.

mit exec stehen nun alle command auf den Stack - je nach device wird gesendet, auf anlernen oder aufwachen gewartet oder ein burst gesendet.

desired-temp ist kein register. das hat also nichts mit prep/exec zu tun.

HMInfo nutzt diese Technik schon länger in zusammenhang mit templates.

burstXmit und burstAccess:
das Attribut burstAccess ist m.E. durch das Kommando burstXmit überholt.
steht burstAccess auf '1_auto' wir bei jeden messageblock, der eingegeben wird (also bei jeden Kommando oder kommando-block bei script) versucht das Device aufzuwecken.
burstXmit macht das gleiche, aber eben unter direkter User-kontrolle. Der User kann seine Registeränderungen sofort absenden oder warten. In automatischen methoden (notify) kann man sich überlegen, besser auf wakeup zu warten....

Ob ich das update remote einspielen wollte... nicht unbedingt.
dein HMLAN sollte aber nach 1h wieder oben sein - länger hat es noch nie gedauert, eher deutlich kürzer.
das mit den switch ist nicht schlecht. Kannst du sogar automatisieren

Die Version 4042 ist verfügbar
Gruss Martin

unimatrix · 14 Oktober 2013, 20:14:21

Hi,

danke - alles verstanden!

Habe vor 3 Stunden ein updatefhem gemacht (von DK aus) ... seitdem scheint alles zu laufen. die Anzeige im HMLAN mit den Prozenten ist sehr hilfreich! Konnte gut sehen dass bei autoreadreg=4 nach einem FHEM Neustart nach ein paar Minuten 70% erreicht waren. Dann war alles durch. Damit wird klar, startet man FHEM in kurzer Zeit zwei mal neu, hat man kurz danach den Overload. Soweit aber alles normal und zumindest das mit dem Overload geht dann offenbar, und das klingt plausibel, nach stromlos wieder weg.

Das mit dem Disconnect scheint dann aber wirklich ein anderes Problem zu sein. Ich habe mir zugegebenermaßen dazu noch nicht die Logs richtig angesehen. Ich kann meinen HMLAN vom Sofa im Wohnzimemr aus sehen und wenn ich dann da so sitze und der ne Stunde lang nur blinkt, und ab und zu mal neustartet - dann muss ja irgendwas falsch sein. Muss mir davon wie gesagt mal die Logs genau ansehen. Vll. ist er ja auch kaputt, wenn dieses Problem sonst keiner hat... Ist immerhin daueron seit über 2 Jahren.

Das mit der FS20 oder auch Elro-Steckdose ist vll. gar nicht so schlecht. Dann bau ich mir ein notify, dass bei Overload das Ding für 15 Sekunden ausschaltet. Sicher nicht gemäß dem Prinzip "Luftraum sauberhalten" aber ok...

martinp876 · 14 Oktober 2013, 22:48:40

Hi,

man kann autoReadReg entzerren. da es keine CUL_HM entity gibt baue ich diese Dinge nach HMInfo - das ist der Level über einzelnen devices.
das Attribut hmAutoReadScan steuert wie schnell autoRead gepollt wird. man kann max 600sec einstellen. Das bedeuted 1 device alle 5 min. Löst das Problem nicht wirklich - es dauert somit ewig bis man alles gelesen hat.
1h ist so oder so eine lange Zeit. Aber die Daten will ich auch...
was mir so durch den Kopf geht sind 2 Elemente:
a) prüfen ob Daten schon vorhanden und komplett sind. Lesen nach dem Einschalten nur wenn etwas fehlt.
b) regelmässig "background lesen". max 2 devices/Stunde - nur wenn "load-level" < 30%.
damit sollten die Register immer aktuell sein, nie älter als sagen wir 1 Woche. Demnach könnte man in a) einbauen dass Daten älter als 1 Woche ungültig sind..... ist aber evtl überflüssig.

nun - die Idee muss noch ein bisschen reifen. Die Steuerung kommt sicher nach HMInfo - da es gesamt-CUL_HM betrifft.

Die Disconnects sind ein anderer Fall - jedenfalls die die ich beobachtet habe. Ich bin überzeugt, dass der HMLAN reseted hat. Danach war der LoadLevel rückgesetzt. Das ist er nach einem disconnect durch ethernet-kabel ziehen nicht. Ich denke die keepalive waren ok - muss noch einmal prüfen.
Gruss Martin

betateilchen · 14 Oktober 2013, 22:53:52

Hauptsache, das autoReadReg bleibt irgendwie ABSCHALTBAR...

martinp876 · 14 Oktober 2013, 23:25:56

Alles andere auch - wie immer, so es den kommen sollte.
Jeder kann sich auch die Daten manuell holen, wenn er will.
Ein Automation System sollte es aber auch automatisch können - so mein Verständnis von Automation.

unimatrix · 15 Oktober 2013, 10:40:47

Ok hier haben wir das Dilemma "schnell Daten wollen" versus "Overload".

Wäre es nicht vll eine einfache Lösung, das automatische Lesen von Daten immer dann zu unterdrücken, wenn z.B. 50% des Kontingents der zurückliegenden Stunde schon verbraucht sind?

User mit nicht so vielen HM-Geräten kommen dann sehr schnell an aktuelle Daten. Andere User mit vielen Geräten kommen halt nur nach und nach ran, aber der HMLAN geht nicht in Overload. Dieses "nur alle 5 Minuten ein Gerät" kann man sich doch ab jetzt eigentlichs paren, weil man ja weiß, wieviel der HMLAN noch verträgt. Da ist es ja sogar besser, nicht so lange zu warten, desto eher verschwinden dann die "Datenschulden" aus der Stunde.