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
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?
Herzlichen Dank, Martin! Das klingt nach einem guten Stück geleisteter "Forschungsarbeit" :-)
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
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
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
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
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... :)
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.
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
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...
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
Hauptsache, das autoReadReg bleibt irgendwie ABSCHALTBAR...
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.
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.
Hi,
an solchen konzepten arbeite ich - habe die ersten Versuche am Laufen. An den Optionen, was wählbar ist, muss ich noch arbeiten.
0) für alle mit Handbetrieb: keine Angst, man wird es komplett ausschalten können
1) Ich sehe beim "holen" 2 Kategorien: 'Status' und 'Register/Config'.
1a) status: das ist ein weit kleinerer Teil. Aus meiner Sicht ist Status unverzichtbar. Es MUSS nach jedem neustart gelesen werden. Man kann es sich eigentlich nicht leisten, hier nicht aktuell zu sein. Gelesen werden muss i) nach neustart ii) nach pon des Device iii)in verschiedenen Fällen, wenn trigger das Device verändern
- man wird "nur status" wählen können
- status kommt in eine eigene Q.
- die Status-Q hat vorrang vor der config -Q
- die status-Q wird blockiert wenn "high-load" erreicht ist. Das lässt 10% puffer für schaltkommandos
2) config (register und peers) erhalten eine nachrangige Q.
- die Verarbeitung wird gestoppt wenn ein gewisser Level(einstellbar) erreicht ist. 40% als default sind angemessen - so kann man 2 restarts überleben. Die Sperre bei high-load steht sowieso
2a) modi
- aktuell werden immer alle Register gelesen(wenn das Attribut gesetzt ist).
- neu werden nach boot nur die Register gelesen, die nicht aus dem state-file kommen. Das reduziert die Last erheblich - bringt aber eine (erträgliche?) Unsicherheit
- weniger kritisch sind die weiteren Stufen: lesen nach power-on, nach config-schreiben. Kann man aber abschalten, wie bisher
- Ein weiterer Mode ist nach meiner Vorstellung der backgound-update. Beschränkt auf 2 Devices je Stunde. Man müsste die ältesten zuerst erneuern....
3) sonstige Queues: aktuell nur der command-stack. der wird parallel verarbeitet - und ohne "bremse", bis overload erreicht ist. manuell ausgelöste "getConfig" und "statusRequest" unterstehen nicht den oben erwähnten Einschränkungen.
Einbauen könnte ich, dass ein manueller getConfig einen möglichen Eintrag aus der "config-Q" löscht.
Einstellbar werden:
- level der Automatik (autoReadReg)
- level, wann config-Q gestoppt wird
- min wartezeit zwischen config-Q polling
- background-reading noch unklar.
Fehlt noch etwas?
Gruss Martin
Hallo Martin,
danke, sieht nach viel Arbeit aus ist aber logisch eingängig!
Mit Q im Text wie bei
Zitat- status kommt in eine eigene Q.
ist generell wohl queue/queues gemeint!
Billy
korrekt - sind ein paar Tippfehler weniger drin ;-)
Hallo,
klingt alles sehr gut!
Wo das jetzt sowieso alles überarbeitet ist, noch eine weitere Anmerkung. Du hattest erwähnt, dass die Dinge im CommandStack nach einer Weile verworfen werden weil dann Schaltkommandos ggf. nicht mehr sinnvoll sind. Dies mag für viele Aktoren so stimmen, es gibt aber auch solche Aktoren, die ausschließlich von FHEM bedient werden, in meinem Beispiel z.B. meine Fussbodenheizung (normaler Schaltaktor an/aus). Im einfachsten Fall habe ich zwei ATs, eins zum Einschalten, eins zum Ausschalten. Wenn jetzt aus irgendwelchen Gründen der HMLAN genau um die Zeit, wo da eingeschaltet werden soll, im Overload etc. ist, dann wird ggf. einen ganzen Tag lang die Heizung nicht eingeschaltet. Ebeneso doof bei Aktoren, die ggf. nicht mehr oder NIE mehr ausgeschaltet werden.
Ggf. ist ja eine Option für einen HM-Kanal denkbar, die besagt, dass dort nie die Queue verworfen wird (ggf. ist das aber auch zu kompliziert?) ... wenn ich mir was wünschen dürfte hätte ich jedenfalls gerne Kanäle, bei dem ich per SET einen Sollzustand setze, und mich dann darauf verlasse, dass FHEM "alles tun wird" um diesen Zustand auch herbeizuführen, und notfalls auch eben erst ne Stunde später, so lange ich keinen anderen Sollzustand setze.
Im Moment kann ich das auch erreichen aber da muss ich dann mti anderen Scripten immer mal wieder den Status abfragen und mit vorgeschalteten Dummy-Devices arbeiten die den Sollzustand zwischenspeichern.
Danke für die Berücksichtigung dieser Idee :-)
das ist eine klasse idee. vileicht sogar noch mit der erweiterung angeben zu können wie lange so ein 'forced' kommando versucht werden soll. bis zum nächsten kommando oder für ein bestimmtes zeitfenster.
rollladen runter z.b. nur die nächsten x stunden oder bis eine andere einstellung kommt.
gruss
andre
guter Punkt - muss man aber erst einmal diskutieren,
Also aktuell habt ihr die Möglichkeit im Device msgRepeat zu setzen. Das legt fest, wie oft eine Nachricht wiederholt werden soll. Kann man auch 10000 eingeben....
Noch wird hierbei der Disconnect nicht "ausgeblendet" - vielleicht baue ich dies noch ein....
Nun zu den Details deines Requests
- soll dass für alle Kommandos zu einem Device gelten? jedes regSet... einfach alles? oder soll es eher als Parameter zu einem Kommando dazu kommen?
- wie oft soll es wiederholt werden? Beachte, dass dann nichts andere gesendet werden kann. Außerdem wird das HMLAN belastet- also alle paar Minuten?
- wenn ein Device dann ein NACK sendet soll auch das ignoriert werden?
vor solchen "blockieren" habe ich immer etwas respekt. Es wird der gesamte Verkehr beeinflusst.
Wenn ihr konkrete Vorstellungen habt....
Gruss Martin
Welche Gründe kann es denn geben, dass ein Device ein NACK sendet?
Gerade das regSet - da ist es ja klar dass ausser FHEM niemand dieser Werte schreibt. Wenn ich ein regSet mache will ich mich doch eigentlich darauf verlassen dass das Register auch irgendwann im Device "landet". Oder übersehe ich etwas? Wie oft man dann versuchen soll, neu zu schreiben, ist natürlich eine gute Frage. Wenn ich mal das Extrembeispiel annehme - für immer - oder zumindest für sehr lange - dann könnte ja vll. der Abstand zwischen den Versuchen immer weiter erhöht werden, nach jedem erfolglosen Versuch. Dass dann nix anderes an das Device geschickt werden kann, scheint mir auch klar - aber das ist ja sowieso schon so, wenn die Versuche ja erfolglos sind. Welche anderen Gründe, außer dass das Device "abgestürzt" ist oder ne gestörte Funkverbindung hat kann es geben?
Ich glaube um eine vernünftige Lösung zu bauen, müsste man sozusagen die Usecases mal durchgehen, die es alle geben kann - also vll aus der Perspektive "Warum kann ein Senden schief gehen". Ich kenne halt auch nicht alle möglichen Ursachen dafür. Relativ sicher bin ich mir aber, dass es interessant ist, zumindest im Falle von Overload und Disconnect des HMLAN diese Messages - für bestimmte Devices - nicht zu verwerfen.
Also wenn man es nicht so kompliziert machen will vll einfach:
- Attribut, dass bewirkt, dass eine zu sendende Nachricht nicht verworfen wird, nur weil der HMLAN nicht geht, sondern nur dann, wenn die Anzahl der tatsächlich vom HMLAN ausgesendeten Versuche msgRepeat überschreitet. Dann sollte auch eine Fehlermeldung im Log stehen, die so auswertbar ist, dass ich mich als User automatisch darüber informieren kann. Aber dann sollte das natürlich auch selten genug sein, man will ja keinen Email-Spam.
hi,
demnächst kommen vorerst die angesprochene Änderung.
Der Einbau des "Wiederholen" hat ein paar Fallen:
ein register- schreiben besteht nicht aus einer sondern mindestens 3 messages. Wenn die letzte schief geht kann man die nicht wiederholen, man braucht alle...
das Wiederholen muss die Modi berücksichtigen - wakeup/config/burst/normal
z.B."set on" werde ich nicht ewig wiederholen - jedenfalls nicht ohne explizite Anweisung. Somit muss man also einen wiederhol-parser einbauen, der das ganze klassifiziert.
NACK kann es aus verschiedenen Gründen geben: nicht existente Register schreiben oder lesen, falsche peers löschen, Baustein noch nicht fertig, könnte später klappen. Die Liste ist nicht komplett und sicher nicht 100% einheitlich.
das mit dem langen wiederholen ist nicht ohne... so werde ich mein System nicht einstellen. Es wird - zumindest bei mir - immer einen Endpunkt geben - mit Alarm. Das sollten auch alle normalen User machen. Schon allein das Abbrechen sauber verständlich zu machen ist schwer.
Prinzipiell stimme ich zu, so ist es unbefriedigend.
Ich denke wir sollten stufig vorgehen. Nach der aktuellen Änderung kommt:
- Behandlung von IO-dev Problemen ändern: laufende Kommandos wieder in die Queue zurück.
- Benachrichtigung, was nicht übertragen wurde präzisieren. Die high-level Kommandos habe ich nicht
Mal sehen, wo wir hinkommen, wenn wir uns langsam vor tasten.
Gruss Martin
so schritt 1:
Version 4053 mit folgenden details:
autoReadReg vertraut nach reboot den registerlisten aus dem state-file. Es werden ein paar checks gemacht, nur wenn etwas inkorrekt ist wird für dieses Device/channel gelesen.
status request wird bedingungslos durchgeführt (wenn autoReadReg mindestens 1 ist.)
man kann nur statusRequest durchführen lassen (option 8) - register und peers werden dann nie automatisch gelesen.
das register-lesen ist in 2 Qs aufgeteilt. somit kann ich "normale" und "wakeup/config" devices unterscheiden/steuern. damit erschlage ich das Problem, dass wakeup devices sich auch der "sendeschwelle" unterwerfen.
Die Schwelle defautl für auto-config-lesen liegt bei 40% (kalkulierter!! wert)
Es kann jetzt eigentlich autoReadReg auch für Config devices gesetzt werden - FHEM wartet ab, bis jemand config drückt...
Eine Übersicht erhält man mit HMInfo
set hm protoEvents
(wide-screen)
oder
set hm protoEvents short
(normal-screen ;-))
Gruss Martin
bei den Umstellungen habe ich wie gewöhnlich Bug versteckt.
die ersten beiden habe ich jetzt entfernt:
setzen der Reglist 0 (z.B burstRx ) hatte Probleme.
conditional burst war nicht mehr zuverlässing - und hat ggf. den stack gelöscht. Sollte jetzt wieder korrekt funktionieren
Hallo zusammen,
ich möchte das doch sehr heiße/spanende und durchaus wichtiges! Thema nicht in den Threads versickern lassen – daher mein Kommentar dazu.
Jeder der ein paar Monate in das Thema ,,Haus Automation" Zeit und das Geld investiert hat, macht sich mit der zunehmenden Anzahl an Komponenten Gedanken ,,wie weit komme ich mit der bisher gewählten Infrastruktur /Strategie(HM) (abgesehen der FW-Probleme/Qualität von HM)",,
Mal querdenken: Es gibt ein System (offensichtlich/primär HMLAN/HMUSB) das Grenzen hat ,,man versucht aktuell technisch alles rauszuholen(Spagat)" - > zunächst alles unverwerflich ,, .
Frage lohnt sich der technische Spagat bei ,,den" HLMLAN/USB Preisen?
Frage: Lohnt es sich nicht den Aufwand in das eine unkomplizierte Handhabung von HMLAN/USB Cluster zu investieren – hmid - Ohje... Probleme abgesehen?
Idee: 70€ investieren (zumutbar ab einen gewissen count an HM devices ) dafür aber ein unproblematischer Betrieb.
,,WIE ERWEHNT MAL QUERDENKEN?" (*GEFAHR: HIRNRISSIG=DISKUSSIONSWÜRDIG?!)
Viele Grüße
Arthur
Hallo Arthur,
ich geben dir recht - ab einer bestimmten Anzahl Komponenten sollte/muss man über ein zweites HMLAN/USB nachdenken. Wenn man viel investiert hat ist der Preis sicher zu relativieren.
HMInfo erlaubt einen Einblick, wie start ein HMLAN belastet ist und ob man sich Gedanken machen sollte. Bei größeren Systemen sollte/muss man sich eh einen Überblick über Protokoll-unstimmingkeiten verschaffen.
Das Thema halte ich auch für extrem wichtig.
An der Optimierung des Performancebedarfs versuche ich weiter zu arbeiten - zusammen mit dem ebenso wichtigen Anspruch, dass die angezeigten Infos aktuell und akkurat sind
Gruss Martin
ist jetzt schon lange her aber bin hier zufällig gelandet. Hatte mir damals tatsächlich eine FS20 Steckdose an den HMLAN geklemmt.
Wenn der Overload getriggert wird mach ich das Ding für 5 Sekunden stromlos. Die Zeit reicht aus und danach geht es immer wieder.
Mag sicher viele geben die das für falsch halten, da man die 1% Regel ja hier nicht mehr einhält. Ich wohne allerdings so sehr auf dem Land dass ich mir sicher bin hier ist niemand anderes ....
ich hoffe aber, dass es nicht oft vorkommt. Im normalbetrieb - auch bei updates - sollte es keinen Probleme geben - auch bei größeren Installationen. Sollte es häufiger auftreten wäre zu untersuchen, warum (zu viele Abfragen...) . Die Messagestatistiken wären dann interassant.
Beim Testen ist es etwas anderes.
Hallo,
ich bekomme nach mehrfachen reboot's allerhöchstens einen highload.
Was versteht Ihr denn unter einer "größeren" Installation?
MfGroby
was meinst du denn genau mit Reboot? den HMLAN stromlos zu machen?
oder wird bei dir FHEM neu gestartet - das würde ja genau dazu führen dass eine Menge Funkverkehr entsteht, da ja - je nach Setting von AutoReadReg alle Devices dann abgefragt werden.
Ich habe bei mir ca. 40 HM Devices ...ein FHEM-Start mit AutoReadREg auf 4 bei allen Devices verbraucht ca. 40% des HMLAN-Kontingents. Wenn man an was bastelt und aus welchen Gründen auch immer FHEM in kurzer Zeit mehrfach neu startet geht es dann natürlich nicht weiter. Seitdem ich aber den HMLAN automatisch kurz vom Strom trenne, gibts das Problem nicht mehr. Das Trennen ist auch nicht ohne Nachteile, aber für mich so besser.
Bei einer bestimmten Größe braucht man ggf. trotzdem 2 Devices.
Sendet denn HM auf dem zweiten IODevice automatisch, wenn das 1. im Overload ist oder nicht connected ist?
Mit reboot meine ich fhem "shutdown restart".
Ich habe z. Zt. 56 HM devices mit nur 1 HMLan. Darunter 11 HK Thermostate, 1 Wetterstation sowie Bewegungsmelder, Feuchtigkeitsmesser, Rauchmelder und Fenstergriffe. Die Frage ist braucht man denn den "burst-modus" oder jeden "getConfig"?
Bei mir schalten Fensterkontakte die HK's in den WindowOpen Modus. Ich verwende autoReadReg = 4_ReqStatus für die Switches und 8_ReqState für die Rauchmelder wo ich wirklich wissen will wie der Status ist. Alles andere kann m.E. warten und hat deswegen nur autoReadReg = 0_off. Bei Bedarf frage ich "getConfig" einfach selber ab...
Deswegen denke ich ein Highload nach diversen fhem "shutdown restart"s innerhalb kürzester Zeit völlig in Ordnung und ist sollte eher die Ausnahme sein...
Ich habe gerade noch einen "shutdown restart" bei msgLoadEst: 1hour:0% mit folgendem Ergebnis gemacht:
IODevs:HML:opened pending=0 condition:ok
msgLoadEst: 1hour:9% 10min steps: 9/0/0/0/0/0
PS: Overload kenn ich gar nicht!!!
gute Frage, was eine größere Installation ist.
Wenn du kein overload bekommst ist das ok.
Nach reboot von FHEM kann es sein, dass einige Stati abgefragt werden. Das automatische Abfragen wird verzögert, sollte highload "erscheinen".
Nach reboot kann es demnach zu erhöhter lost kommen
Hallo,
ich habe mir hier alle Nachrichten durchgelesen.
Ich habe seit gestern ein Problem mit dem HMUSB und cond:ERROR-Overload
Ich besitze im Moment nur 8 HM Aktoren und 2 HM Fernbedienungen(HM-RC-Sec4-2). Von einem Tag zum anderen hat der HMUSB nun fast durchgänging Overload...
Diese habe ich nach lesen dieser Nachrichten bei allen HM gesetzt(autoReadReg 0_off; burstAccess 0_off) > keine Änderung
An was kann dieses Problem liegen? Ich kann ja somit keinerlei Aktoren mehr Schalten wenn Overload ist.
Ich bin noch relativer Anfänger mit FHEM und HM.
Ich hoffe mir kann irgendwer weiterhelfen :-(
Viele Grüße
Thomas
Hie rnoch meine LOG von der letzten Zeit des OVERLOAD
A) rohmessages loggen
B) hminfo protevents ansehen . ggf ein clear machen um besser zählen zu können. Dann nachsehen, wer etwas bekommt
C) keine Bilder sondern logs schicken
der hmusb benötigt fw 0.967 und einen aktuellen hmland, damit die aktuelle load ermittelt werden kann.
Zitat von: frank am 03 Januar 2016, 23:49:57
der hmusb benötigt fw 0.967 und einen aktuellen hmland, damit die aktuelle load ermittelt werden kann.
so den HMUSB habe ich nun auf die aktuelle FW 0.967 gebracht.
und HMLAND müsste mit Version (hmland 0.102-git) nun auch aktuell sein oder?
Wo wird nun "die aktuelle load ermittelt" > wo erkenne ich dies und was muss ich damit machen?
Zitat von: martinp876 am 03 Januar 2016, 22:15:55
A) rohmessages loggen
bedeutet dies ich mache ein FileLog vom HMUSB?
define FileLog_HMUSB FileLog ./log/HMUSB-%Y.log HMUSB
attr FileLog_HMUSB logtype text
attr FileLog_HMUSB room HMUSB
da wird im Moment immer nur "2016-01-04_19:05:20 HMUSB loadLvl: low" angezeigt.
Oder was meinst du damit?
Vielen Dank für eure Infos
Gruß Thomas
Siehe wiki hm sniffen
Zitat von: martinp876 am 04 Januar 2016, 19:30:18
Siehe wiki hm sniffen
Danke habe ich getan.
Ich habe einen Verdacht:
Ich habe vor ein paar Tagen einen HM Batterie-Aktor angelernt(HM-LC-SW1-BA-PCB) nach dem anlernen erst mal wieder stromlos in die Kiste gepackt. autoReadReg war bei ihm auf 4_reqStatus
Ich habe ihn gerade wieder(ohne ihm Strom zu geben) von 0_reqStatus auf 4_reqStatus gesetzt. Nun erscheinen im Log mehrfach Nachrichten wie:
2016.01.04 19:51:11.426 0: HMLAN_Parse: HMUSB V:03C7 sNo:MEQ0232631 d:372DDE O:372DDE t:004D1063 IDcnt:0008 L:18 %
2016.01.04 19:51:13.382 0: HMLAN_Parse: HMUSB R:R0DFA93E3 stat:0008 t:00000000 d:FF r:7FFF m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:13.382 0: HMLAN_Parse: HMUSB no ACK from 39224D
2016.01.04 19:51:16.099 0: HMLAN_Send: HMUSB S:S0DFAA654 stat: 00 t:00000000 d:01 r:0DFAA654 m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:17.923 0: HMLAN_Parse: HMUSB R:R0DFAA654 stat:0008 t:00000000 d:FF r:7FFF m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:17.924 0: HMLAN_Parse: HMUSB no ACK from 39224D
2016.01.04 19:51:21.866 0: HMLAN_Send: HMUSB S:S0DFABCDB stat: 00 t:00000000 d:01 r:0DFABCDB m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:23.683 0: HMLAN_Parse: HMUSB R:R0DFABCDB stat:0008 t:00000000 d:FF r:7FFF m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:23.684 0: HMLAN_Parse: HMUSB no ACK from 39224D
2016.01.04 19:51:26.627 0: HMLAN_Send: HMUSB S:S0DFACF75 stat: 00 t:00000000 d:01 r:0DFACF75 m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:28.452 0: HMLAN_Parse: HMUSB R:R0DFACF75 stat:0008 t:00000000 d:FF r:7FFF m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:28.453 0: HMLAN_Parse: HMUSB no ACK from 39224D
2016.01.04 19:51:31.296 0: HMLAN_Send: HMUSB S:S0DFAE1B1 stat: 00 t:00000000 d:01 r:0DFAE1B1 m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:33.125 0: HMLAN_Parse: HMUSB R:R0DFAE1B1 stat:0008 t:00000000 d:FF r:7FFF m:02 B001 372DDE 39224D 010E
2016.01.04 19:51:33.126 0: HMLAN_Parse: HMUSB no ACK from 39224Dkönnte es daran gelegen haben sowie die ältere HMUSB FW.!?
Bis jetzt läuft der HMUSBB noch.
Sollte ich meine HM-Geräte wieder auf 4_reqStatus setzten oder alle dauerhaft auf 0_reqStatus lassen?
meine Devices stehen alle auf Status 5. Ich will immer und automatisch korrekte Daten.
Burst Devices kann/sollte man auf msgRepeat 0 setzen. Ist das Device nicht und wird getestet sendet FHEM einen Burst - HMLAN wiederholt 1-mal.
Das kann man 100 mal in 1 h machen.
Wenn du nun msgRepeat auf 3 stehen hast geht es nur noch 30 mal. Das kann schon problematisch sein.
Aber ich empfehle hier
get hm protoEvents
Das sollte man sowieso im Auge behalten. (alternativ im Status des hminfo - hier unbedingt autoUpdate aktivieren)
Zitat von: martinp876 am 04 Januar 2016, 20:22:20
meine Devices stehen alle auf Status 5. Ich will immer und automatisch korrekte Daten.
Burst Devices kann/sollte man auf msgRepeat 0 setzen. Ist das Device nicht und wird getestet sendet FHEM einen Burst - HMLAN wiederholt 1-mal.
Das kann man 100 mal in 1 h machen.
Wenn du nun msgRepeat auf 3 stehen hast geht es nur noch 30 mal. Das kann schon problematisch sein.
Eine Frage noch meine Fernbedienungen HM-RC-4-2 sollte ich nun auch auf
autoReadReg 5_off
burstAccess 0_off < deleteattr
msgRepeat 0
setzen!?
oder anders?
Die mache kein burst. Das burst hatte ist demnach egal. Leider kann man Attribute nicht einschränken.
Msgrepeat ist nicht wichtig. Fhem stoppt wenn es nicht klappt.
Gesendet wird in diesem Fall nach einem press.
Ein overload ist nicht zu erwarte da ist vie Luft.
Aber prüfen es doch einfach